lwn.git/drivers/usb/misc, branch docs-5.16-2

USB: iowarrior: fix control-message timeouts

2021-10-26T17:12:28+00:00

USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Use the common control-message timeout define for the five-second timeout and drop the driver-specific one. Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.") Cc: stable@vger.kernel.org # 2.6.21 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20211025115159.4954-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman

Revert "usb: misc: ehset: Workaround for "special" hubs"

2021-10-07T10:48:54+00:00

This reverts commit ce3e90d5a0cdbcb2ddebbf9e4363e59fa779ad3a. The commit in question added list of quirky hubs, but the match implementation clearly hasn't been tested at all. First, hub_udev->dev.parent does not represent a USB interface so using to_usb_interface() makes no sense and we'd be passing a random pointer to usb_match_id(). Second, if hub_udev is a root hub it doesn't even even represent a USB device. Signed-off-by: Johan Hovold Fixes: ce3e90d5a0cd ("usb: misc: ehset: Workaround for "special" hubs") Cc: Razvan Heghedus Link: https://lore.kernel.org/r/20211007090601.19156-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman

usb: misc: ehset: Workaround for "special" hubs

2021-10-05T10:39:46+00:00

The USB2.0 spec chapter 11.24.2.13 says that the USB port which is going under test needs to be put in suspend state before sending the test command. Many hubs, don't enforce this precondition and they work fine without this step. But there are some "special" hubs, which requires to disable the port power before sending the test command. Because the USB spec mention that the port should be suspended, also do this step before sending the test command. This could rise the problem with other hubs which are not compliant with the spec and the test command will not work if the port is suspend. If such hubs are found, a similar workaround like the disable part could be implemented to skip the suspend port command. Signed-off-by: Razvan Heghedus Link: https://lore.kernel.org/r/20210915121615.3790-1-heghedus.razvan@gmail.com Signed-off-by: Greg Kroah-Hartman

usb: misc: brcmstb-usb-pinmap: add IRQ check

2021-08-13T11:05:50+00:00

The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with the invalid IRQ #s. Fixes: 517c4c44b323 ("usb: Add driver to allow any GPIO to be used for 7211 USB signals") Reviewed-by: Florian Fainelli Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/806d0b1a-365b-93d9-3fc1-922105ca5e61@omp.ru Signed-off-by: Greg Kroah-Hartman

usb: misc: adutux: use swap()

2021-08-05T10:31:34+00:00

Use swap() in order to make code cleaner. Issue found by coccinelle. Signed-off-by: Salah Triki Link: https://lore.kernel.org/r/20210803005343.GA1578854@pc Signed-off-by: Greg Kroah-Hartman

usb: ftdi-elan: remove redundant continue statement in a while-loop

2021-06-24T12:12:09+00:00

The continue statement at the end of the while-loop is redundant, remove it. Signed-off-by: Colin Ian King Addresses-Coverity: ("Continue has no effect") Link: https://lore.kernel.org/r/20210621095545.9659-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman

Revert "USB: misc: Add onboard_usb_hub driver"

2021-06-18T06:39:24+00:00

This reverts commit b4e326165e21d6a11483f6a4de2174b933413554 as the patch series is causing build issues in linux-next at the moment. Cc: Matthias Kaehlcke Link: https://lore.kernel.org/r/YMuRcrE8xlWnFSWW@google.com Signed-off-by: Greg Kroah-Hartman

USB: misc: Add onboard_usb_hub driver

2021-06-15T13:48:35+00:00

The main issue this driver addresses is that a USB hub needs to be powered before it can be discovered. For discrete onboard hubs (an example for such a hub is the Realtek RTS5411) this is often solved by supplying the hub with an 'always-on' regulator, which is kind of a hack. Some onboard hubs may require further initialization steps, like changing the state of a GPIO or enabling a clock, which requires even more hacks. This driver creates a platform device representing the hub which performs the necessary initialization. Currently it only supports switching on a single regulator, support for multiple regulators or other actions can be added as needed. Different initialization sequences can be supported based on the compatible string. Besides performing the initialization the driver can be configured to power the hub off during system suspend. This can help to extend battery life on battery powered devices which have no requirements to keep the hub powered during suspend. The driver can also be configured to leave the hub powered when a wakeup capable USB device is connected when suspending, and power it off otherwise. Technically the driver consists of two drivers, the platform driver described above and a very thin USB driver that subclasses the generic driver. The purpose of this driver is to provide the platform driver with the USB devices corresponding to the hub(s) (a hub controller may provide multiple 'logical' hubs, e.g. one to support USB 2.0 and another for USB 3.x). Note: the current series only supports hubs connected directly to a root hub (through xhci-plat), support for other configurations could be added if needed. Co-developed-by: Ravi Chandra Sadineni Acked-by: Alan Stern Signed-off-by: Ravi Chandra Sadineni Signed-off-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/20210609150159.v12.2.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeid Signed-off-by: Greg Kroah-Hartman

usb: misc: brcmstb-usb-pinmap: check return value after calling platform_get_resource()

2021-06-09T09:04:27+00:00

It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Fixes: 517c4c44b323 ("usb: Add driver to allow any GPIO to be used for 7211 USB signals") Cc: stable Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20210605080914.2057758-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman

USB: trancevibrator: fix control-request direction

2021-05-21T18:10:43+00:00

The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Fix the set-speed request which erroneously used USB_DIR_IN and update the default timeout argument to match (same value). Fixes: 5638e4d92e77 ("USB: add PlayStation 2 Trance Vibrator driver") Cc: stable@vger.kernel.org # 2.6.19 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210521133109.17396-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman