linux-kernel - Re: [PATCH v3 00/12] usb: dwc3: qcom: Flatten dwc3 structure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250123212259.GA381176-robh@kernel.org>
Date: Thu, 23 Jan 2025 15:22:59 -0600
From: Rob Herring <robh@...nel.org>
To: Bjorn Andersson <andersson@...nel.org>
Cc: Bjorn Andersson <bjorn.andersson@....qualcomm.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Felipe Balbi <balbi@...nel.org>,
	Wesley Cheng <quic_wcheng@...cinc.com>,
	Saravana Kannan <saravanak@...gle.com>,
	Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Konrad Dybcio <konradybcio@...nel.org>, Frank Li <Frank.li@....com>,
	linux-arm-msm@...r.kernel.org, linux-usb@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 00/12] usb: dwc3: qcom: Flatten dwc3 structure

On Wed, Jan 22, 2025 at 09:07:43PM -0600, Bjorn Andersson wrote:
> 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@...nel.org> 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.

Ok, fair enough.

I would still prefer the overlays live in arch/*/boot/dts/qcom/ even if 
we don't do the rest.

Rob