.../devicetree/bindings/usb/qcom,dwc3.yaml | 13 +- .../devicetree/bindings/usb/qcom,snps-dwc3.yaml | 608 +++++++++++++++++++++ .../devicetree/bindings/usb/snps,dwc3-common.yaml | 417 ++++++++++++++ .../devicetree/bindings/usb/snps,dwc3.yaml | 391 +------------ arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 12 +- arch/arm64/boot/dts/qcom/sa8540p-ride.dts | 5 +- arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 12 +- .../dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 11 +- arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 138 +++-- drivers/of/dynamic.c | 1 - drivers/usb/dwc3/core.c | 169 ++++-- drivers/usb/dwc3/core.h | 3 + drivers/usb/dwc3/dwc3-qcom.c | 323 ++++++++--- 13 files changed, 1483 insertions(+), 620 deletions(-)
The USB IP-block found in most Qualcomm platforms is modelled in the
Linux kernel as 3 different independent device drivers, but as shown by
the already existing layering violations in the Qualcomm glue driver
they can not be operated independently.
With the current implementation, the glue driver registers the core and
has no way to know when this is done. As a result, e.g. the suspend
callbacks needs to guard against NULL pointer dereferences when trying
to peek into the struct dwc3 found in the drvdata of the child.
Missing from the upstream Qualcomm USB support is handling of role
switching, in which the glue needs to be notified upon DRD mode changes.
Several attempts has been made through the years to register callbacks
etc, but they always fall short when it comes to handling of the core's
probe deferral on resources etc.
Furhtermore, the DeviceTree binding is a direct representation of the
Linux driver model, and doesn't necessarily describe "the USB IP-block".
This series therefor attempts to flatten the driver split, and operate
the glue and core out of the same platform_device instance. And in order
to do this, the DeviceTree representation of the IP block is flattened.
---
Changes in v2:
- Rewrite after ACPI removal, multiport support and interrupt fixes
- Completely changed strategy for DeviceTree binding, as previous idea
of using snps,dwc3 as a generic fallback required unreasonable changes
to that binding.
- Abandoned idea of supporting both flattened and unflattened device
model in the one driver. As Johan pointed out, it will leave the race
condition holes and will make the code harder to understand.
Furthermore, the role switching logic that we intend to introduce
following this would have depended on the user updating their
DeviceTree blobs.
- Per above, introduced the dynamic DeviceTree rewrite
- Link to v1: https://lore.kernel.org/all/20231016-dwc3-refactor-v1-0-ab4a84165470@quicinc.com/
---
Bjorn Andersson (7):
dt-bindings: usb: snps,dwc3: Split core description
dt-bindings: usb: Introduce qcom,snps-dwc3
of: dynamic: Don't discard children upon node attach
usb: dwc3: core: Expose core driver as library
usb: dwc3: qcom: Don't reply on drvdata during probe
usb: dwc3: qcom: Transition to flattened model
arm64: dts: qcom: sc8280x: Flatten the USB nodes
.../devicetree/bindings/usb/qcom,dwc3.yaml | 13 +-
.../devicetree/bindings/usb/qcom,snps-dwc3.yaml | 608 +++++++++++++++++++++
.../devicetree/bindings/usb/snps,dwc3-common.yaml | 417 ++++++++++++++
.../devicetree/bindings/usb/snps,dwc3.yaml | 391 +------------
arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 12 +-
arch/arm64/boot/dts/qcom/sa8540p-ride.dts | 5 +-
arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 12 +-
.../dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 11 +-
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 138 +++--
drivers/of/dynamic.c | 1 -
drivers/usb/dwc3/core.c | 169 ++++--
drivers/usb/dwc3/core.h | 3 +
drivers/usb/dwc3/dwc3-qcom.c | 323 ++++++++---
13 files changed, 1483 insertions(+), 620 deletions(-)
---
base-commit: 864b1099d16fc7e332c3ad7823058c65f890486c
change-id: 20231016-dwc3-refactor-931e3b08a8b9
Best regards,
--
Bjorn Andersson <quic_bjorande@quicinc.com>
On Sun, Aug 11, 2024 at 08:11:57PM -0700, Bjorn Andersson wrote: > The USB IP-block found in most Qualcomm platforms is modelled in the > Linux kernel as 3 different independent device drivers, but as shown by > the already existing layering violations in the Qualcomm glue driver > they can not be operated independently. > > With the current implementation, the glue driver registers the core and > has no way to know when this is done. As a result, e.g. the suspend > callbacks needs to guard against NULL pointer dereferences when trying > to peek into the struct dwc3 found in the drvdata of the child. > > Missing from the upstream Qualcomm USB support is handling of role > switching, in which the glue needs to be notified upon DRD mode changes. > Several attempts has been made through the years to register callbacks > etc, but they always fall short when it comes to handling of the core's > probe deferral on resources etc. > > Furhtermore, the DeviceTree binding is a direct representation of the > Linux driver model, and doesn't necessarily describe "the USB IP-block". > > This series therefor attempts to flatten the driver split, and operate > the glue and core out of the same platform_device instance. And in order > to do this, the DeviceTree representation of the IP block is flattened. Thanks, we faced the same problem. Can you cc me next time? Frank > > --- > Changes in v2: > - Rewrite after ACPI removal, multiport support and interrupt fixes > - Completely changed strategy for DeviceTree binding, as previous idea > of using snps,dwc3 as a generic fallback required unreasonable changes > to that binding. > - Abandoned idea of supporting both flattened and unflattened device > model in the one driver. As Johan pointed out, it will leave the race > condition holes and will make the code harder to understand. > Furthermore, the role switching logic that we intend to introduce > following this would have depended on the user updating their > DeviceTree blobs. > - Per above, introduced the dynamic DeviceTree rewrite > - Link to v1: https://lore.kernel.org/all/20231016-dwc3-refactor-v1-0-ab4a84165470@quicinc.com/ > > --- > Bjorn Andersson (7): > dt-bindings: usb: snps,dwc3: Split core description > dt-bindings: usb: Introduce qcom,snps-dwc3 > of: dynamic: Don't discard children upon node attach > usb: dwc3: core: Expose core driver as library > usb: dwc3: qcom: Don't reply on drvdata during probe > usb: dwc3: qcom: Transition to flattened model > arm64: dts: qcom: sc8280x: Flatten the USB nodes > > .../devicetree/bindings/usb/qcom,dwc3.yaml | 13 +- > .../devicetree/bindings/usb/qcom,snps-dwc3.yaml | 608 +++++++++++++++++++++ > .../devicetree/bindings/usb/snps,dwc3-common.yaml | 417 ++++++++++++++ > .../devicetree/bindings/usb/snps,dwc3.yaml | 391 +------------ > arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 12 +- > arch/arm64/boot/dts/qcom/sa8540p-ride.dts | 5 +- > arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 12 +- > .../dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 11 +- > arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 138 +++-- > drivers/of/dynamic.c | 1 - > drivers/usb/dwc3/core.c | 169 ++++-- > drivers/usb/dwc3/core.h | 3 + > drivers/usb/dwc3/dwc3-qcom.c | 323 ++++++++--- > 13 files changed, 1483 insertions(+), 620 deletions(-) > --- > base-commit: 864b1099d16fc7e332c3ad7823058c65f890486c > change-id: 20231016-dwc3-refactor-931e3b08a8b9 > > Best regards, > -- > Bjorn Andersson <quic_bjorande@quicinc.com> >
On Tue, Aug 13, 2024 at 02:07:01PM -0400, Frank Li wrote: > On Sun, Aug 11, 2024 at 08:11:57PM -0700, Bjorn Andersson wrote: > > The USB IP-block found in most Qualcomm platforms is modelled in the > > Linux kernel as 3 different independent device drivers, but as shown by > > the already existing layering violations in the Qualcomm glue driver > > they can not be operated independently. > > > > With the current implementation, the glue driver registers the core and > > has no way to know when this is done. As a result, e.g. the suspend > > callbacks needs to guard against NULL pointer dereferences when trying > > to peek into the struct dwc3 found in the drvdata of the child. > > > > Missing from the upstream Qualcomm USB support is handling of role > > switching, in which the glue needs to be notified upon DRD mode changes. > > Several attempts has been made through the years to register callbacks > > etc, but they always fall short when it comes to handling of the core's > > probe deferral on resources etc. > > > > Furhtermore, the DeviceTree binding is a direct representation of the > > Linux driver model, and doesn't necessarily describe "the USB IP-block". > > > > This series therefor attempts to flatten the driver split, and operate > > the glue and core out of the same platform_device instance. And in order > > to do this, the DeviceTree representation of the IP block is flattened. > Bjorn Andersson: Any follow up on this thread? Frank > Thanks, we faced the same problem. Can you cc me next time? > > Frank > > > > --- > > Changes in v2: > > - Rewrite after ACPI removal, multiport support and interrupt fixes > > - Completely changed strategy for DeviceTree binding, as previous idea > > of using snps,dwc3 as a generic fallback required unreasonable changes > > to that binding. > > - Abandoned idea of supporting both flattened and unflattened device > > model in the one driver. As Johan pointed out, it will leave the race > > condition holes and will make the code harder to understand. > > Furthermore, the role switching logic that we intend to introduce > > following this would have depended on the user updating their > > DeviceTree blobs. > > - Per above, introduced the dynamic DeviceTree rewrite > > - Link to v1: https://lore.kernel.org/all/20231016-dwc3-refactor-v1-0-ab4a84165470@quicinc.com/ > > > > --- > > Bjorn Andersson (7): > > dt-bindings: usb: snps,dwc3: Split core description > > dt-bindings: usb: Introduce qcom,snps-dwc3 > > of: dynamic: Don't discard children upon node attach > > usb: dwc3: core: Expose core driver as library > > usb: dwc3: qcom: Don't reply on drvdata during probe > > usb: dwc3: qcom: Transition to flattened model > > arm64: dts: qcom: sc8280x: Flatten the USB nodes > > > > .../devicetree/bindings/usb/qcom,dwc3.yaml | 13 +- > > .../devicetree/bindings/usb/qcom,snps-dwc3.yaml | 608 +++++++++++++++++++++ > > .../devicetree/bindings/usb/snps,dwc3-common.yaml | 417 ++++++++++++++ > > .../devicetree/bindings/usb/snps,dwc3.yaml | 391 +------------ > > arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 12 +- > > arch/arm64/boot/dts/qcom/sa8540p-ride.dts | 5 +- > > arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 12 +- > > .../dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 11 +- > > arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 138 +++-- > > drivers/of/dynamic.c | 1 - > > drivers/usb/dwc3/core.c | 169 ++++-- > > drivers/usb/dwc3/core.h | 3 + > > drivers/usb/dwc3/dwc3-qcom.c | 323 ++++++++--- > > 13 files changed, 1483 insertions(+), 620 deletions(-) > > --- > > base-commit: 864b1099d16fc7e332c3ad7823058c65f890486c > > change-id: 20231016-dwc3-refactor-931e3b08a8b9 > > > > Best regards, > > -- > > Bjorn Andersson <quic_bjorande@quicinc.com> > >
On Tue, Oct 08, 2024 at 04:09:45PM -0400, Frank Li wrote: > On Tue, Aug 13, 2024 at 02:07:01PM -0400, Frank Li wrote: > > On Sun, Aug 11, 2024 at 08:11:57PM -0700, Bjorn Andersson wrote: > > > The USB IP-block found in most Qualcomm platforms is modelled in the > > > Linux kernel as 3 different independent device drivers, but as shown by > > > the already existing layering violations in the Qualcomm glue driver > > > they can not be operated independently. > > > > > > With the current implementation, the glue driver registers the core and > > > has no way to know when this is done. As a result, e.g. the suspend > > > callbacks needs to guard against NULL pointer dereferences when trying > > > to peek into the struct dwc3 found in the drvdata of the child. > > > > > > Missing from the upstream Qualcomm USB support is handling of role > > > switching, in which the glue needs to be notified upon DRD mode changes. > > > Several attempts has been made through the years to register callbacks > > > etc, but they always fall short when it comes to handling of the core's > > > probe deferral on resources etc. > > > > > > Furhtermore, the DeviceTree binding is a direct representation of the > > > Linux driver model, and doesn't necessarily describe "the USB IP-block". > > > > > > This series therefor attempts to flatten the driver split, and operate > > > the glue and core out of the same platform_device instance. And in order > > > to do this, the DeviceTree representation of the IP block is flattened. > > > > Bjorn Andersson: > Any follow up on this thread? > Thanks for reaching out, Frank. I did pick this up again a few days back. I'm struggling with Rob's request for not peeking into struct property and/or utilizing overlays. Hoping to figure this out shortly, so I can get v3 in shape. Regards, Bjorn
On Tue, Oct 08, 2024 at 07:54:48PM -0700, Bjorn Andersson wrote: > On Tue, Oct 08, 2024 at 04:09:45PM -0400, Frank Li wrote: > > On Tue, Aug 13, 2024 at 02:07:01PM -0400, Frank Li wrote: > > > On Sun, Aug 11, 2024 at 08:11:57PM -0700, Bjorn Andersson wrote: > > > > The USB IP-block found in most Qualcomm platforms is modelled in the > > > > Linux kernel as 3 different independent device drivers, but as shown by > > > > the already existing layering violations in the Qualcomm glue driver > > > > they can not be operated independently. > > > > > > > > With the current implementation, the glue driver registers the core and > > > > has no way to know when this is done. As a result, e.g. the suspend > > > > callbacks needs to guard against NULL pointer dereferences when trying > > > > to peek into the struct dwc3 found in the drvdata of the child. > > > > > > > > Missing from the upstream Qualcomm USB support is handling of role > > > > switching, in which the glue needs to be notified upon DRD mode changes. > > > > Several attempts has been made through the years to register callbacks > > > > etc, but they always fall short when it comes to handling of the core's > > > > probe deferral on resources etc. > > > > > > > > Furhtermore, the DeviceTree binding is a direct representation of the > > > > Linux driver model, and doesn't necessarily describe "the USB IP-block". > > > > > > > > This series therefor attempts to flatten the driver split, and operate > > > > the glue and core out of the same platform_device instance. And in order > > > > to do this, the DeviceTree representation of the IP block is flattened. > > > > > > > Bjorn Andersson: > > Any follow up on this thread? > > > > Thanks for reaching out, Frank. I did pick this up again a few days > back. > > I'm struggling with Rob's request for not peeking into struct property > and/or utilizing overlays. Hoping to figure this out shortly, so I can > get v3 in shape. Bjorn: Do you still work on this? Or I missed somethings. Frank > > Regards, > Bjorn
© 2016 - 2026 Red Hat, Inc.