Static structure "ti_tusb8041_data" is exactly the same as
"ti_tusb8020b_data" and "cypress_hx2vl_data" is the same as
"microchip_usb424_data". Drop the duplicated structures to reduce
driver size and memory usage without affecting functionality.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260318084626.34314-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add the ID entries and platform data for the Corechips SL6341 onboard
USB 2.0/3.0 hub controller, which requires a reset pin and a power supply
for proper operation.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
Link: https://patch.msgid.link/20260311-sl6341-v1-3-0a890056f054@flipper.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a regulator-only entry matching OF-described USB Type-A connectors.
This allows platforms to explicitly model VBUS supply regulators for these
ports instead of calling them PHY supplies or making the respective
regulators always-on in their device trees.
Type-A ports won't typically need a dedicated driver, as there is nothing
to configure apart from the power supply, so there is no controller driver
to traverse the OF graph and request the VBUS regulator, unlike for Type-C
ports. Thus make it an onboard USB device, which it kind of really is.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
Link: https://patch.msgid.link/20260217-typea-vbus-v1-1-657b4e55a4c2@flipper.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The WCH CH334/CH335[0] are USB2.0 protocol compliant 4-port USB HUB
controller chips, supporting USB2.0 high-speed and full-speed for
upstream ports, and USB2.0 high-speed 480Mbps, full-speed 12Mbps and
low-speed 1.5Mbps for downstream ports, supporting not only low-cost STT
mode (single TT schedules 4 downstream ports in time share), but also
supports high performance MTT mode (4 TTs each corresponding to 1 port,
concurrent processing).
[0]: https://www.wch-ic.com/downloads/CH334DS1_PDF.html
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Link: https://patch.msgid.link/20260113095827.115-3-kernel@airkyi.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Camera is built into the Thinkbook 16 G7 QOY and directly attached on the
usb_2 controller (dwc3 USB2 only). It has a separate power supply that needs
to be controlled for PM.
Add the support for this device for the power supply.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Link: https://lore.kernel.org/r/20250629-tb16-dt-v7-2-35276341338f@oldschoolsolutions.biz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The TUSB8044 is similar to the TUSB8041. This adds the PID/VID values
and allows to specify the reset GPIO signal on the board.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Link: https://lore.kernel.org/r/20250507131143.2243079-1-mike.looijmans@topic.nl
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Parade PS5511 is 4+1 port USB 3.2 gen 1 hub with a reset pin and two power
supplies (3V3 and 1V1).
Add the support for this hub for the reset pin control and power supply.
Signed-off-by: Pin-yen Lin <treapking@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20250422082957.2058229-5-treapking@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Realtek RTL8188ETV 2.4 GHz WiFi modules (detected as RTL8188EU by the
RTL8XXXXU driver) are found soldered into some embedded devices, such as
the Fernsehfee 3.0 set-top box.
They require a 3.3V power supply.
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Link: https://lore.kernel.org/r/20250408-rtl-onboard-v2-2-0b6730b90e31@posteo.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This hub is powered by digital and analog 3V3 power rails, so provide
the possibility to use different regulators for digital (vdd) and analog
(vdda) power rails.
Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com>
Link: https://lore.kernel.org/r/20250213094338.1611389-3-catalin.popescu@leica-geosystems.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Introduce dedicated field 'power_on_delay_us' in onboard platform data
and update its delay for USB5744 configuration. Hub itself requires some
delay after reset to get to state where configuration data is going to
be accepted. Without delay upcoming support for configuration via SMBUS
is reporting a failure on the first SMBus write.
i2c 2-002d: error -ENXIO: BYPASS_UDC_SUSPEND bit configuration failed
Similar delay is likely also required for default configuration but
because there is enough time (code execution) between reset and usage
of the hub any issue is not visible but it doesn't mean delay shouldn't
be reflected.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Suggested-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/1725732196-70975-2-git-send-email-radhey.shyam.pandey@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit
multicore controller for voice processing.
This device requires a specific power sequence, which consists of
enabling the regulators that control the 3V3 and 1V0 device supplies,
and a reset de-assertion after a delay of at least 100ns.
Once in normal operation, the XVF3500 registers itself as a USB device,
and it does not require any device-specific operations in the driver.
[1] https://www.xmos.com/xvf3500/
Acked-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
Link: https://lore.kernel.org/r/20240325-onboard_xvf3500-v8-8-29e3f9222922@wolfvision.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Most of the functionality this driver provides can be used by non-hub
devices as well.
To account for the hub-specific code, add a flag to the device data
structure and check its value for hub-specific code.
The 'always_powered_in_supend' attribute is only available for hub
devices, keeping the driver's default behavior for non-hub devices (keep
on in suspend).
Acked-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
Link: https://lore.kernel.org/r/20240325-onboard_xvf3500-v8-6-29e3f9222922@wolfvision.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch prepares onboad_hub to support non-hub devices by renaming
the driver files and their content, the headers and their references.
The comments and descriptions have been slightly modified to keep
coherence and account for the specific cases that only affect onboard
hubs (e.g. peer-hub).
The "hub" variables in functions where "dev" (and similar names) variables
already exist have been renamed to onboard_dev for clarity, which adds a
few lines in cases where more than 80 characters are used.
No new functionality has been added.
Acked-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
Link: https://lore.kernel.org/r/20240325-onboard_xvf3500-v8-2-29e3f9222922@wolfvision.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
