- 10 Aug, 2019 2 commits
-
-
Simon Horman authored
For consistency with the naming of (most) other documentation files for DT bindings for Renesas IP blocks rename the Renesas USB3.0 peripheral documentation file from renesas,usb3.txt to renesas,usb3-peri.txt This refines a recent rename from renesas_usb3.txt to renesas,usb3.txt. The motivation is to more accurately reflect the IP block documented in this file. Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Niklas Sderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20190809213710.31783-1-horms+renesas@verge.net.auSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
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.deSigned-off-by:
-
- 09 Aug, 2019 18 commits
-
-
YueHaibing authored
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.comSigned-off-by:
-
Alan Stern authored
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.orgSigned-off-by:
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Gustavo A. R. Silva authored
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@embeddedorSigned-off-by:
-
Gustavo A. R. Silva authored
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:
-
- 08 Aug, 2019 4 commits
-
-
Greg Kroah-Hartman authored
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.comSigned-off-by:
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Greg Kroah-Hartman authored
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.comSigned-off-by:
-
- 07 Aug, 2019 2 commits
-
-
Greg Kroah-Hartman authored
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 authored
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:
-
- 06 Aug, 2019 2 commits
-
-
Greg Kroah-Hartman authored
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.orgSigned-off-by:
-
Greg Kroah-Hartman authored
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:
-
- 05 Aug, 2019 2 commits
-
-
Kai-Heng Feng authored
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.comSigned-off-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20190802130408.20336-1-yuehaibing@huawei.comSigned-off-by:
-
- 02 Aug, 2019 1 commit
-
-
Dmitry Torokhov authored
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.orgSigned-off-by:
-
- 01 Aug, 2019 3 commits
-
-
Miquel Raynal authored
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.comSigned-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
Colin Ian King authored
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.comSigned-off-by:
-
- 30 Jul, 2019 6 commits
-
-
Stephen Boyd authored
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.orgSigned-off-by:
-
Gustavo A. R. Silva authored
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:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20190729000631.GA24165@embeddedorSigned-off-by:
-
Gustavo A. R. Silva authored
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: -
Marek Szyprowski authored
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.comSigned-off-by:
-
Marek Szyprowski authored
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:
Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20190726081453.9456-3-m.szyprowski@samsung.comSigned-off-by:
-
Marek Szyprowski authored
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:
Rob Herring <robh@kernel.org> Signed-off-by:
-
