kernel/drivers/usb/misc/onboard_usb_hub.c, branch linux-6.5.y

usb: misc: onboard_hub: add support for Microchip USB2412 USB 2.0 hub

2023-10-19T21:11:08Z

commit e59e38158c61162f2e8beb4620df21a1585117df upstream. The USB2412 is a 2-Port USB 2.0 hub controller that provides a reset pin and a single 3v3 powre source, which makes it suitable to be controlled by the onboard_hub driver. This hub has the same reset timings as USB2514/2517 and the same onboard hub specific-data can be reused for USB2412. Signed-off-by: Javier Carrasco Cc: stable Acked-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/20230911-topic-2412_onboard_hub-v1-1-7704181ddfff@wolfvision.net Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_hub: Don't warn twice about problems during remove

2023-05-30T14:27:17Z

If onboard_hub_power_off() called by onboard_hub_remove() fails it emits an error message. Forwarding the returned error value to the driver core results in another error message. As the return value is otherwise ignored, just drop the return value. There is no side effect apart from suppressing the core's warning. Instead of returning zero unconditionally, convert to .remove_new() which has the same semantics as .remove() that unconditionally returns zero. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20230530073633.2193618-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard-hub: add support for Microchip USB2517 USB 2.0 hub

2023-03-09T13:54:46Z

Add support for Microchip USB2517 USB 2.0 hub to the onboard usb hub driver. Adopt the generic usb-device compatible ("usbVID,PID"). This hub has the same reset timings as USB2514, so reuse that one. There is also an USB2517I which just has industrial temperature range. Signed-off-by: Alexander Stein Cc: stable Acked-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/20230223073920.2912298-1-alexander.stein@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman

Merge 6.2-rc5 into usb-next

2023-01-23T14:38:08Z

We need the USB fixes in here and this resolves merge conflicts as reported in linux-next in the following files: drivers/usb/host/xhci.c drivers/usb/host/xhci.h drivers/usb/typec/ucsi/ucsi.c Reported-by: Stephen Rothwell Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_usb_hub: add VIA LAB VL817 hub support

2023-01-19T13:13:28Z

VIA LAB VL817 is a 4-port USB 3.1 hub and USB 2.0 root hub that has a reset pin to toggle and a 5.0V core supply exported though an integrated LDO is available for powering it. Add the support for this hub, for controlling the reset pin and the core power supply. Add USB device id's for USB 2.0 and USB 3.0 root hub. Signed-off-by: Anand Moon Acked-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/20230118044418.875-9-linux.amoon@gmail.com Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_usb_hub: add Genesys Logic GL852G hub support

2023-01-19T13:13:27Z

Genesys Logic GL852G is a 4-port USB 2.0 STT hub that has a reset pin to toggle and a 5.0V core supply exported though an integrated LDO is available for powering it. Add the support for this hub, for controlling the reset pin and the core power supply. Signed-off-by: Anand Moon Acked-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/20230118044418.875-5-linux.amoon@gmail.com Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_hub: Move 'attach' work to the driver

2023-01-17T16:06:50Z

Currently each onboard_hub platform device owns an 'attach' work, which is scheduled when the device probes. With this deadlocks have been reported on a Raspberry Pi 3 B+ [1], which has nested onboard hubs. The flow of the deadlock is something like this (with the onboard_hub driver built as a module) [2]: - USB root hub is instantiated - core hub driver calls onboard_hub_create_pdevs(), which creates the 'raw' platform device for the 1st level hub - 1st level hub is probed by the core hub driver - core hub driver calls onboard_hub_create_pdevs(), which creates the 'raw' platform device for the 2nd level hub - onboard_hub platform driver is registered - platform device for 1st level hub is probed - schedules 'attach' work - platform device for 2nd level hub is probed - schedules 'attach' work - onboard_hub USB driver is registered - device (and parent) lock of hub is held while the device is re-probed with the onboard_hub driver - 'attach' work (running in another thread) calls driver_attach(), which blocks on one of the hub device locks - onboard_hub_destroy_pdevs() is called by the core hub driver when one of the hubs is detached - destroying the pdevs invokes onboard_hub_remove(), which waits for the 'attach' work to complete - waits forever, since the 'attach' work can't acquire the device lock Use a single work struct for the driver instead of having a work struct per onboard hub platform driver instance. With that it isn't necessary to cancel the work in onboard_hub_remove(), which fixes the deadlock. The work is only cancelled when the driver is unloaded. [1] https://lore.kernel.org/r/d04bcc45-3471-4417-b30b-5cf9880d785d@i2se.com/ [2] https://lore.kernel.org/all/Y6OrGbqaMy2iVDWB@google.com/ Cc: stable@vger.kernel.org Fixes: 8bc063641ceb ("usb: misc: Add onboard_usb_hub driver") Link: https://lore.kernel.org/r/d04bcc45-3471-4417-b30b-5cf9880d785d@i2se.com/ Link: https://lore.kernel.org/all/Y6OrGbqaMy2iVDWB@google.com/ Reported-by: Stefan Wahren Signed-off-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/20230110172954.v2.2.I16b51f32db0c32f8a8532900bfe1c70c8572881a@changeid Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_hub: Invert driver registration order

2023-01-17T16:06:50Z

The onboard_hub 'driver' consists of two drivers, a platform driver and a USB driver. Currently when the onboard hub driver is initialized it first registers the platform driver, then the USB driver. This results in a race condition when the 'attach' work is executed, which is scheduled when the platform device is probed. The purpose of fhe 'attach' work is to bind elegible USB hub devices to the onboard_hub USB driver. This fails if the work runs before the USB driver has been registered. Register the USB driver first, then the platform driver. This increases the chances that the onboard_hub USB devices are probed before their corresponding platform device, which the USB driver tries to locate in _probe(). The driver already handles this situation and defers probing if the onboard hub platform device doesn't exist yet. Cc: stable@vger.kernel.org Fixes: 8bc063641ceb ("usb: misc: Add onboard_usb_hub driver") Link: https://lore.kernel.org/lkml/Y6W00vQm3jfLflUJ@hovoldconsulting.com/T/#m0d64295f017942fd988f7c53425db302d61952b4 Reported-by: Alexander Stein Signed-off-by: Matthias Kaehlcke Tested-by: Stefan Wahren Link: https://lore.kernel.org/r/20230110172954.v2.1.I75494ebee7027a50235ce4b1e930fa73a578fbe2@changeid Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_usb_hub: add Genesys Logic GL850G hub support

2022-12-08T15:47:27Z

Genesys Logic GL850G is a 4-port USB 2.0 STT hub that has a reset pin to toggle and a 3.3V core supply exported (although an integrated LDO is available for powering it with 5V). Add the support for this hub, for controlling the reset pin and the core power supply. Signed-off-by: Icenowy Zheng Acked-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/20221206055228.306074-4-uwu@icenowy.me Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_usb_hub: Drop reset delay in onboard_hub_power_off()

2022-08-18T19:10:59Z

onboard_hub_power_off() currently has a delay after asserting the reset of the hub. There is already a delay in onboard_hub_power_on() before de-asserting the reset, which ensures that the reset is asserted for the required time, so the delay in _power_off() is not needed. Skip the reset GPIO check before calling gpiod_set_value_cansleep(), the function returns early when the GPIO descriptor is NULL. Reviewed-By: Alexander Stein Reviewed-by: Douglas Anderson Signed-off-by: Matthias Kaehlcke Link: https://lore.kernel.org/r/20220805111836.1.Id5a4dc0a2c046236116693aa55672295513a0f2a@changeid Signed-off-by: Greg Kroah-Hartman