The EIC7700 USB requires a USB PHY reset operation; otherwise, the USB
will not work. The reason why the USB driver that was applied can work
properly is that the USB PHY has already been reset in ESWIN's U-Boot.
However, the proper functioning of the USB driver should not be dependent
on the bootloader. Therefore, it is necessary to incorporate the USB PHY
reset signal into the DT bindings.
This patch does not introduce any backward incompatibility since the dts
is not upstream yet. As array of reset operations are used in the driver,
no modifications to the USB controller driver are needed.
Fixes: c640a4239d ("dt-bindings: usb: Add ESWIN EIC7700 USB controller")
Cc: stable <stable@kernel.org>
Signed-off-by: Hang Cao <caohang@eswincomputing.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260415064238.1784-1-caohang@eswincomputing.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The deprecated 'usb-phy' property is documented already in usb.yaml and
doesn't need a type definition here. It just needs constraints on how
many entries there are.
As this is a host controller, reference usb-hcd.yaml which then
references usb.yaml.
Fixes: 70fcdc82cf ("dt-bindings: usb: ti,omap4-musb: convert to DT schema")
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260508182556.1759173-1-robh@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The top-level part defines variable number of clocks and interrupts, and
each "if:then:" block narrows them. It however narrows only the
maxItems leaving minItems undefined, which then takes different values
depending on dtschema being used.
Recommended style is to avoid ambiguity in such case, thus if top-level
part has broad constraints, then each "if:then:" must specify both upper
and lower limits.
Add missing constraints, mostly minItems but also maxItems for one
variant.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260323-dt-bindings-snps-qcom-dwc3-cleanup-v2-2-3bcd37c0a5b5@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Update the Cadence USBSS DRD binding to document that it also covers
the USBSSP (SuperSpeed Plus, USB 3.1 gen2x1) controller. Both USBSS
and USBSSP share the same DRD/OTG register interface, so the driver
auto-detects the controller version at runtime — no additional
compatible string is needed.
Changes to the binding:
- Update title and add description
- maximum-speed: add super-speed-plus
This patch is Assisted-by: Cursor:claude-4.6-opus
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260316064831.274865-2-peter.chen@cixtech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add compatible string for DWC3 USB controller found in SpacemiT K3 SoC.
The USB2.0 host controller in K3 SoC actually use DWC3 IP but only support
USB2.0 functionality, thus in the hardware layer, it has only one USB2 PHY.
While in K1 SoC, the USB controller has both USB2 and USB3 Combo PHY
connected, but able to work in a reduced USB2.0 mode which requres only
one USB2 PHY, leaves the USB3 Combo PHY to PCIe controller. So both K1
and K3 SoC are able to work in the USB2.0 mode which requires one PHY.
Explicitly reduce number of phy property to minimal one.
Signed-off-by: Yixun Lan <dlan@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260320-02-k3-usb20-support-v2-1-308ea0e44038@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Type-C chip know the cable orientation and then normally will set the
switch channel to correctly configure the data path. Some chips itself
support to output the control signal by indicating the capability in
bit[0] of STANDARD_OUTPUT_CAPABILITIES register and do it in
CONFIG_STANDARD_OUTPUT register. For PTN5110 which doesn't present this
capability currently there is no way to achieve the orientation setting.
Add an optional "orientation-gpios" property to achieve the same purpose.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Link: https://patch.msgid.link/20260319-support-setting-orientation-use-gpio-v4-1-ab6dfa8610c2@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
