[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZwXweChRh5bjc1nS@hu-bjorande-lv.qualcomm.com>
Date: Tue, 8 Oct 2024 19:54:48 -0700
From: Bjorn Andersson <quic_bjorande@...cinc.com>
To: Frank Li <Frank.li@....com>
CC: Bjorn Andersson <andersson@...nel.org>,
Greg Kroah-Hartman
<gregkh@...uxfoundation.org>,
Rob Herring <robh@...nel.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
<konrad.dybcio@...aro.org>, <linux-usb@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v2 0/7] usb: dwc3: qcom: Flatten dwc3 structure
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
Powered by blists - more mailing lists