On Wed, Jan 15, 2025 at 12:51:42PM -0600, Rob Herring wrote: > On Tue, Jan 14, 2025 at 5:04 PM Bjorn Andersson <andersson@xxxxxxxxxx> wrote: > > > > On Tue, Jan 14, 2025 at 11:44:52AM -0600, Rob Herring wrote: > > > On Mon, Jan 13, 2025 at 09:11:33PM -0800, 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 proper 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. > > > > > > > > To avoid littering the dwc3-qcom driver with the migration code - which > > > > we should be able to drop again in a LTS or two - this is now placed in > > > > drivers/of/overlays. > > > > > > > > A patch to convert a single platform - sc8280xp - is included in the > > > > series. The broader conversion will be submitted in a follow up series. > > > > > > Is it not possible to use the same overlays also fixup the .dts files at > > > build time? > > > > > > > I presume so. What would the benefit of that be, over fixing up the > > source asap? > > The overlays would live with all the other dts files (I think kbuild > can add built-in dtbs from arch/*/boot/dts/). We can test at build > time they actually apply, and ensure the new dtb matches what the > fixup overlay creates. > That does sounds tempting, in particular since it sounds like it would provide us with dt-validation of the end result. But, the build-time overlaid dtb files wouldn't be complete, as I programmatically transition some of the properties - to "fix" that I'd have to provide an overlay per board. Second, it was my intention to transition all the boards to the new binding as soon as possible, to avoid adding more overlays when new boards are added. So any support-system we build up for this, would be immediately obsoleted. Regards, Bjorn
