[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ffm23zhsp4ksbgmk6slehc2pcy47i5xb7eqhuf6ixlphoj7lbv@o524z6na3mtr>
Date: Tue, 11 Mar 2025 21:02:03 +0200
From: Dmitry Baryshkov <lumag@...nel.org>
To: Bjorn Andersson <andersson@...nel.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Bjorn Andersson <bjorn.andersson@....qualcomm.com>, 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 <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 v4 6/7] usb: dwc3: qcom: Transition to flattened model
On Mon, Mar 10, 2025 at 09:46:24PM -0500, Bjorn Andersson wrote:
> On Fri, Mar 07, 2025 at 08:41:33AM +0200, Dmitry Baryshkov wrote:
> > On Wed, Feb 26, 2025 at 04:17:53PM -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.
> > > Even with these checks, there are no way to fully protect ourselves from
> > > the race conditions that occur if the DWC3 is unbound.
> > >
> > > 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.
> > >
> > > Moving to a model where the DWC3 core is instantiated in a synchronous
> > > fashion avoids above described race conditions.
> > >
> > > It is however not feasible to do so without also flattening the
> > > DeviceTree binding, as assumptions are made in the DWC3 core and
> > > frameworks used that the device's associated of_node will the that of
> > > the core. Furthermore, the DeviceTree binding is a direct
> > > representation of the Linux driver model, and doesn't necessarily
> > > describe "the USB IP-block".
> > >
> > > The Qualcomm DWC3 glue driver is therefor transitioned to initialize and
> > > operate the DWC3 within the one device context, in synchronous fashion.
> > >
> > > To provide a limited time backwards compatibility, a snapshot of the
> > > driver is retained in a previous commit. As such no care is taken in the
> > > dwc3-qcom driver for the qcom,dwc3 backwards compatibility.
> > >
> > > Signed-off-by: Bjorn Andersson <bjorn.andersson@....qualcomm.com>
> > > ---
> > > drivers/usb/dwc3/dwc3-qcom.c | 138 +++++++++++++++++++++----------------------
> > > 1 file changed, 69 insertions(+), 69 deletions(-)
> > >
> > > diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> > > index 9d04c2457433..63e60f15ceaa 100644
> > > --- a/drivers/usb/dwc3/dwc3-qcom.c
> > > +++ b/drivers/usb/dwc3/dwc3-qcom.c
> > > @@ -4,7 +4,6 @@
> > > * Inspired by dwc3-of-simple.c
> > > */
> > >
> > > -#include <linux/cleanup.h>
> > > #include <linux/io.h>
> > > #include <linux/of.h>
> > > #include <linux/clk.h>
> > > @@ -14,7 +13,6 @@
> > > #include <linux/kernel.h>
> > > #include <linux/extcon.h>
> >
> > As a heads up, would it make sense to also drop extcon support while we
> > are transitioning to the new driver / DT bindings?
> >
>
> Yes, I believe this code should be cleaned out in favor of relying on
> the core's implementation thereof and callbacks into the qcom-code for
> configuration the glue hardware - which looks to be the same callback we
> want to add for the usb_role_switch.
Hmm. So do you want to clean it later? Or do you plan to drop extcon
from the next iteration?
>
> Regards,
> Bjorn
>
> > > #include <linux/interconnect.h>
> > > -#include <linux/of_platform.h>
> > > #include <linux/platform_device.h>
> > > #include <linux/phy/phy.h>
> > > #include <linux/usb/of.h>
> >
> > --
> > With best wishes
> > Dmitry
--
With best wishes
Dmitry
Powered by blists - more mailing lists