summaryrefslogtreecommitdiffstats
path: root/drivers/usb/misc/Kconfig
diff options
context:
space:
mode:
authorMatthias Kaehlcke <mka@chromium.org>2022-06-30 21:35:29 +0200
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2022-07-08 14:53:50 +0200
commit8bc063641cebf9d555e41d135db2b5035b521768 (patch)
treeb24ee003c124cb4805df982a52dcf1d5413970ed /drivers/usb/misc/Kconfig
parentdt-bindings: usb: rts5411: Rename property 'companion-hub' to 'peer-hub' (diff)
downloadlinux-8bc063641cebf9d555e41d135db2b5035b521768.tar.xz
linux-8bc063641cebf9d555e41d135db2b5035b521768.zip
usb: misc: Add onboard_usb_hub driver
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). Co-developed-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20220630123445.v24.3.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/usb/misc/Kconfig')
-rw-r--r--drivers/usb/misc/Kconfig16
1 files changed, 16 insertions, 0 deletions
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 4c5ddbd75b7e..9367c12c7e6f 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -295,3 +295,19 @@ config BRCM_USB_PINMAP
This option enables support for remapping some USB external
signals, which are typically on dedicated pins on the chip,
to any gpio.
+
+config USB_ONBOARD_HUB
+ tristate "Onboard USB hub support"
+ depends on OF || COMPILE_TEST
+ help
+ Say Y here if you want to support discrete onboard USB hubs that
+ don't require an additional control bus for initialization, but
+ need some non-trivial form of initialization, such as enabling a
+ power regulator. An example for such a hub is the Realtek
+ RTS5411.
+
+ This driver can be used as a module but its state (module vs
+ builtin) must match the state of the USB subsystem. Enabling
+ this config will enable the driver and it will automatically
+ match the state of the USB subsystem. If this driver is a
+ module it will be called onboard_usb_hub.