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@xxxxxxxxxxxxxxxx> > > > --- > > > 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
