The ARM w90x900 platform is getting removed, so this driver is obsolete.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20190809202749.742267-16-arnd@arndb.de


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB_WUSB should depends on CONFIG_USB, otherwise building fails

drivers/staging/wusbcore/wusbhc.o: In function `wusbhc_giveback_urb':
wusbhc.c:(.text+0xa28): undefined reference to `usb_hcd_giveback_urb'

Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 71ed79b0

 ("USB: Move wusbcore and UWB to staging as it is obsolete")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190809102150.66896-1-yuehaibing@huawei.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

It has been requested that usbfs should implement runtime power
management, instead of forcing the device to remain at full power as
long as the device file is open.  This patch introduces that new
feature.

It does so by adding three new usbfs ioctls:

	USBDEVFS_FORBID_SUSPEND: Prevents the device from going into
	runtime suspend (and causes a resume if the device is already
	suspended).

	USBDEVFS_ALLOW_SUSPEND: Allows the device to go into runtime
	suspend.  Some time may elapse before the device actually is
	suspended, depending on things like the autosuspend delay.

	USBDEVFS_WAIT_FOR_RESUME: Blocks until the call is interrupted
	by a signal or at least one runtime resume has occurred since
	the most recent ALLOW_SUSPEND ioctl call (which may mean
	immediately, even if the device is currently suspended).  In
	the latter case, the device is prevented from suspending again
	just as if FORBID_SUSPEND was called before the ioctl returns.

For backward compatibility, when the device file is first opened
runtime suspends are forbidden.  The userspace program can then allow
suspends whenever it wants, and either resume the device directly (by
forbidding suspends again) or wait for a resume from some other source
(such as a remote wakeup).  URBs submitted to a suspended device will
fail or will complete with an appropriate error code.

This combination of ioctls is sufficient for user programs to have
nearly the same degree of control over a device's runtime power
behavior as kernel drivers do.

Still lacking is documentation for the new ioctls.  I intend to add it
later, after the existing documentation for the usbfs userspace API is
straightened out into a reasonable form.

Suggested-by: Mayuresh Kulkarni <mkulkarni@opensource.cirrus.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>

Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1908071013220.1514-100000@iolanthe.rowland.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB drivers now support the ability for the driver core to handle the
creation and removal of device-specific sysfs files in a race-free
manner.  Take advantage of that by converting the driver to use this by
moving the sysfs attributes into a group and assigning the dev_groups
pointer to it.

Link: https://lore.kernel.org/r/20190806144502.17792-12-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB drivers now support the ability for the driver core to handle the
creation and removal of device-specific sysfs files in a race-free
manner.  Take advantage of that by converting the driver to use this by
moving the sysfs attributes into a group and assigning the dev_groups
pointer to it.

Cc: Ding Xiang <dingxiang@cmss.chinamobile.com>
Link: https://lore.kernel.org/r/20190806144502.17792-11-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB drivers now support the ability for the driver core to handle the
creation and removal of device-specific sysfs files in a race-free
manner.  Take advantage of that by converting the driver to use this by
moving the sysfs attributes into a group and assigning the dev_groups
pointer to it.

Cc: Valentina Manea <valentina.manea.m@gmail.com>
Cc: Shuah Khan <shuah@kernel.org>
Link: https://lore.kernel.org/r/20190806144502.17792-13-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB drivers now support the ability for the driver core to handle the
creation and removal of device-specific sysfs files in a race-free
manner.  Take advantage of that by converting the driver to use this by
moving the sysfs attributes into a group and assigning the dev_groups
pointer to it.

Link: https://lore.kernel.org/r/20190806144502.17792-4-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB drivers now support the ability for the driver core to handle the
creation and removal of device-specific sysfs files in a race-free
manner.  Take advantage of that by converting the driver to use this by
moving the sysfs attributes into a group and assigning the dev_groups
pointer to it.

Cc: Matthieu CASTET <castet.matthieu@free.fr>
Cc: Stanislaw Gruszka <stf_xl@wp.pl>
Link: https://lore.kernel.org/r/20190806144502.17792-5-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB drivers now support the ability for the driver core to handle the
creation and removal of device-specific sysfs files in a race-free
manner.  Take advantage of that by converting the driver to use this by
moving the sysfs attributes into a group and assigning the dev_groups
pointer to it.

Cc: Pete Zaitcev <zaitcev@redhat.com>
Link: https://lore.kernel.org/r/20190806144502.17792-6-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB drivers now support the ability for the driver core to handle the
creation and removal of device-specific sysfs files in a race-free
manner.  Take advantage of that by converting the driver to use this by
moving the sysfs attributes into a group and assigning the dev_groups
pointer to it.

Cc: Guido Kiener <guido.kiener@rohde-schwarz.com>
Cc: Steve Bayless <steve_bayless@keysight.com>
Link: https://lore.kernel.org/r/20190806144502.17792-7-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB drivers now support the ability for the driver core to handle the
creation and removal of device-specific sysfs files in a race-free
manner.  Take advantage of that by converting the driver to use this by
moving the sysfs attributes into a group and assigning the dev_groups
pointer to it.

Link: https://lore.kernel.org/r/20190806144502.17792-9-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB drivers now support the ability for the driver core to handle the
creation and removal of device-specific sysfs files in a race-free
manner.  Take advantage of that by converting the driver to use this by
moving the sysfs attributes into a group and assigning the dev_groups
pointer to it.

Link: https://lore.kernel.org/r/20190806144502.17792-8-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB drivers now support the ability for the driver core to handle the
creation and removal of device-specific sysfs files in a race-free
manner.  Take advantage of that by converting the driver to use this by
moving the sysfs attributes into a group and assigning the dev_groups
pointer to it.

Link: https://lore.kernel.org/r/20190806144502.17792-10-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Platform drivers now have the option to have the platform core create
and remove any needed sysfs attribute files.  So take advantage of that
and do not register "by hand" any sysfs files.

Cc: Peter Chen <Peter.Chen@nxp.com>
Link: https://lore.kernel.org/r/20190805193636.25560-1-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Platform drivers now have the option to have the platform core create
and remove any needed sysfs attribute files.  So take advantage of that
and do not register "by hand" any sysfs files.

Cc: Felipe Balbi <balbi@kernel.org>
Link: https://lore.kernel.org/r/20190805193636.25560-3-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Platform drivers now have the option to have the platform core create
and remove any needed sysfs attribute files.  So take advantage of that
and do not register "by hand" any sysfs files.

Cc: Felipe Balbi <balbi@kernel.org>
Link: https://lore.kernel.org/r/20190805193636.25560-4-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Platform drivers now have the option to have the platform core create
and remove any needed sysfs attribute files.  So take advantage of that
and do not register "by hand" any sysfs files.

Cc: Felipe Balbi <balbi@kernel.org>
Link: https://lore.kernel.org/r/20190806073235.25140-1-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Mark switch cases where we are expecting to fall through.

This patch fixes the following warning (Building: tct_hammer_defconfig arm):

drivers/usb/gadget/udc/s3c2410_udc.c:314:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/gadget/udc/s3c2410_udc.c:418:7: warning: this statement may fall through [-Wimplicit-fallthrough=]

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20190805191426.GA12414@embeddedor


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Mark switch cases where we are expecting to fall through.

This patch fixes the following warning (Building: at91_dt_defconfig arm):

drivers/usb/gadget/udc/atmel_usba_udc.c:329:13: warning: this statement may fall through [-Wimplicit-fallthrough=]

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20190805184842.GA8627@embeddedor


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Joe rightly points out that we should be using the "Obsolete" status for
these two subsystems.

Also I got the path name wrong for the wusbcore tree.

Reported-by: Joe Perches <joe@perches.com>
Fixes: 71ed79b0 ("USB: Move wusbcore and UWB to staging as it is obsolete")
Link: https://lore.kernel.org/r/20190808092509.GA20173@kroah.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The driver core now supports the option to automatically create and
remove any needed sysfs attribute files for a driver when the device is
bound/removed from it.  Convert the uscsi_ccg code to use that instead
of trying to create sysfs files "by hand".

Cc: Ajay Gupta <ajayg@nvidia.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20190805193636.25560-6-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Platform drivers now have the option to have the platform core create
and remove any needed sysfs attribute files.  So take advantage of that
and do not register "by hand" any sysfs files.

Acked-by: Bin Liu <b-liu@ti.com>
Link: https://lore.kernel.org/r/20190805193636.25560-2-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The UWB and wusbcore code is long obsolete, so let us just move the code
out of the real part of the kernel and into the drivers/staging/
location with plans to remove it entirely in a few releases.

Link: https://lore.kernel.org/r/20190806101509.GA11280@kroah.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Now that the driver core supports dev_groups for individual drivers,
expose that pointer to struct usb_device_driver to make it easier for USB
drivers to also use it.

Yes, users of usb_device_driver are much rare, but there are instances
already that use custom sysfs files, so adding this support will make
things easier for those drivers.  usbip is one example, hubs might be
another one.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20190806144502.17792-3-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Now that the driver core supports dev_groups for individual drivers,
expose that pointer to struct usb_driver to make it easier for USB
drivers to also use it.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20190806144502.17792-2-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Platform drivers now have the option to have the platform core create
and remove any needed sysfs attribute files.  So take advantage of that
and do not register "by hand" any sysfs files.

Cc: Valentina Manea <valentina.manea.m@gmail.com>
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20190805193636.25560-5-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'dev_groups_all_drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core into usb-next

dev_groups added to struct driver

Persistent tag for others to pull this branch from

This is the first patch in a longer series that adds the ability for the
driver core to create and remove a list of attribute groups
automatically when the device is bound/unbound from a specific driver.

See:
	https://lore.kernel.org/r/20190731124349.4474-2-gregkh@linuxfoundation.org


for details on this patch, and examples of how to use it in other
drivers.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The QCA Rome USB Bluetooth controller has several issues once LPM gets
enabled:
- Fails to get enumerated in coldboot. [1]
- Drains more power (~ 0.2W) when the system is in S5. [2]
- Disappears after a warmboot. [2]

The issue happens because the device lingers at LPM L1 in S5, so device
can't get enumerated even after a reboot.

Disable LPM at shutdown to solve the issue.

[1] https://bugs.launchpad.net/bugs/1757218
[2] https://patchwork.kernel.org/patch/10607097/



Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20190805142412.23965-1-kai.heng.feng@canonical.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lore.kernel.org/r/20190802130408.20336-1-yuehaibing@huawei.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add the ability for the driver core to create and remove a list of
attribute groups automatically when the device is bound/unbound from a
specific driver.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Richard Gong <richard.gong@linux.intel.com>
Link: https://lore.kernel.org/r/20190731124349.4474-2-gregkh@linuxfoundation.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

In the past, USB PHY handling has been moved in the HCD core. Some
host controller drivers needing more control of the PHYs, they have
been granted the freedom to handle themselves the PHY states and to
prevent the HCD core to do so in commit 4e88d4c0 ("usb: add a flag
to skip PHY initialization to struct usb_hcd"). With this change, any
USB host controller could set the hcd->skip_phy_initialization flag so
that the HCD core would just skip the PHY initialization sequence.

However, in the USB subsystem, there are currently two entirely
different forms of PHY: one is called 'usb_phy' and is
USB-subsystem-wide, while there is also the generic and kernel-wide
'phy' from the (recent) generic PHY framework.

When the commit above was introduced, both type of PHYs where handled
by the HCD core.

Later, commit bc40f534

 ("USB: core: hcd: drop support for legacy
phys") removed the support for the former type of PHYs in the HCD
core. These 'usb_phy' are still present though, but managed from the
controller drivers only. Hence, setting the
hcd->skip_phy_initialization flag just because a 'usb_phy' is
initialized by a controller driver is a non-sense.

For instance on Armada CP110, a 'usb_phy' is there to enable the power
supply to the USB host, while there is also a COMPHY block providing
SERDES lanes configuration that is referenced as a PHY from the common
PHY framework.

Right now, users of the xhci-plat.c driver either use a 'usb_phy' only
and do not care about the attempt of generic PHY initialization within
the HCD core (as there is none); or they use a single 'phy' and the
code flow does not pass through the block setting
hcd->skip_phy_initialization anyway.

While there is not users of both PHY types at the same time, drop this
limitation from the xhci-plat.c driver. Note that the tegra driver
probably has the same limitation and could definitely benefit from a
similar change.

Cc: Johan Hovold <johan@kernel.org>
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20190731121150.2253-1-miquel.raynal@bootlin.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20190731134241.18647-1-geert+renesas@glider.be


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Variable ret is being initialized with a value that is never read
and ret is being re-assigned a little later on. The assignment is
redundant and hence can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20190731223917.16532-1-colin.king@canonical.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We don't need dev_err() messages when platform_get_irq() fails now that
platform_get_irq() prints an error message itself when something goes
wrong. Let's remove these prints with a simple semantic patch.

// <smpl>
@@
expression ret;
struct platform_device *E;
@@

ret =
(
platform_get_irq(E, ...)
|
platform_get_irq_byname(E, ...)
);

if ( \( ret < 0 \| ret <= 0 \) )
{
(
-if (ret != -EPROBE_DEFER)
-{ ...
-dev_err(...);
-... }
|
...
-dev_err(...);
)
...
}
// </smpl>

While we're here, remove braces on if statements that only have one
statement (manually).

Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20190730181557.90391-47-swboyd@chromium.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Mark switch cases where we are expecting to fall through.

This patch fixes the following warnings:

drivers/usb/phy/phy-ab8500-usb.c: In function 'ab8500_usb_link_status_update':
drivers/usb/phy/phy-ab8500-usb.c:424:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
   event = UX500_MUSB_RIDB;
   ~~~~~~^~~~~~~~~~~~~~~~~
drivers/usb/phy/phy-ab8500-usb.c:425:2: note: here
  case USB_LINK_NOT_CONFIGURED_8500:
  ^~~~
drivers/usb/phy/phy-ab8500-usb.c:440:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
   event = UX500_MUSB_RIDC;
   ~~~~~~^~~~~~~~~~~~~~~~~
drivers/usb/phy/phy-ab8500-usb.c:441:2: note: here
  case USB_LINK_STD_HOST_NC_8500:
  ^~~~
drivers/usb/phy/phy-ab8500-usb.c:459:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
   event = UX500_MUSB_RIDA;
   ~~~~~~^~~~~~~~~~~~~~~~~
drivers/usb/phy/phy-ab8500-usb.c:460:2: note: here
  case USB_LINK_HM_IDGND_8500:
  ^~~~
drivers/usb/phy/phy-ab8500-usb.c: In function 'ab8505_usb_link_status_update':
drivers/usb/phy/phy-ab8500-usb.c:332:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
   event = UX500_MUSB_RIDB;
   ~~~~~~^~~~~~~~~~~~~~~~~
drivers/usb/phy/phy-ab8500-usb.c:333:2: note: here
  case USB_LINK_NOT_CONFIGURED_8505:
  ^~~~
drivers/usb/phy/phy-ab8500-usb.c:352:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
   event = UX500_MUSB_RIDC;
   ~~~~~~^~~~~~~~~~~~~~~~~
drivers/usb/phy/phy-ab8500-usb.c:353:2: note: here
  case USB_LINK_STD_HOST_NC_8505:
  ^~~~
drivers/usb/phy/phy-ab8500-usb.c:370:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
   event = UX500_MUSB_RIDA;
   ~~~~~~^~~~~~~~~~~~~~~~~
drivers/usb/phy/phy-ab8500-usb.c:371:2: note: here
  case USB_LINK_HM_IDGND_8505:
  ^~~~

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20190729000631.GA24165@embeddedor


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Mark switch cases where we are expecting to fall through.

This patch fixes the following warning (Building: arm):

drivers/usb/host/ohci-tmio.c: In function ‘tmio_stop_hc’:
./include/linux/device.h:1499:2: warning: this statement may fall through [-Wimplicit-fallthrough=]
  _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/usb/host/ohci-tmio.c:99:4: note: in expansion of macro ‘dev_err’
    dev_err(&dev->dev, "Unsupported amount of ports: %d\n", ohci->num_ports);
    ^~~~~~~
In file included from drivers/usb/host/ohci-hcd.c:1257:0:
drivers/usb/host/ohci-tmio.c:100:3: note: here
   case 3:
   ^~~~
drivers/usb/host/ohci-tmio.c:101:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
    pm |= CCR_PM_USBPW3;
       ^
drivers/usb/host/ohci-tmio.c:102:3: note: here
   case 2:
   ^~~~
drivers/usb/host/ohci-tmio.c:103:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
    pm |= CCR_PM_USBPW2;
       ^
drivers/usb/host/ohci-tmio.c:104:3: note: here
   case 1:
   ^~~~

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20190729222201.GA19408@embeddedor


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Move USB PHYs to a standard arrays for Exynos EHCI/OHCI devices. This
resolves the conflict between Exynos EHCI/OHCI sub-nodes and generic USB
device bindings. Once the Exynos EHCI/OHCI sub-nodes are removed, the
boards can finally provide sub-nodes for the USB devices using generic USB
device bindings.

Suggested-by: Måns Rullgård <mans@mansr.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20190726081453.9456-4-m.szyprowski@samsung.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add the code for getting generic PHYs from standard device tree array
from the main controller device node. This is a first step in resolving
the conflict between Exynos EHCI/OHCI sub-nodes and generic USB device
bindings. Later the sub-nodes currently used for assigning PHYs to root
ports of the controller will be removed making a place for the generic
USB device bindings nodes.

Suggested-by: Måns Rullgård <mans@mansr.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20190726081453.9456-3-m.szyprowski@samsung.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 69bec725 ("USB: core: let USB device know device node") added
support for attaching devicetree node for USB devices. Those nodes are
children of their USB host controller. However Exynos EHCI and OHCI
driver bindings already define child-nodes for each physical root hub
port and assigns respective PHY controller and parameters to them. This
leads to the conflict. A workaround for it has been merged as commit
01d40714

 ("usb: exynos: add workaround for the USB device bindings
conflict"), but it disabled support for USB device binding for Exynos
EHCI/OHCI controllers.

To resolve it properly, lets move PHYs from the sub-nodes to a standard
array under the 'phys' property.

Suggested-by: Måns Rullgård <mans@mansr.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20190726081453.9456-2-m.szyprowski@samsung.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We need the USB fixes in here as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>