[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <u2u3mkybodsk3neura7nvhgd6iwky5cjkbqwpcs3rn3tm7dzpq@ecah6hnm4t6g>
Date: Mon, 10 Mar 2025 21:46:24 -0500
From: Bjorn Andersson <andersson@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: 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 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.
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
Powered by blists - more mailing lists