Message-ID: <CAL_JsqLThor3MXF1nzfegBWC1fJDKAJ9-GP-riTyqbhmWscMjw@mail.gmail.com>
Date: Tue, 13 Aug 2024 09:06:34 -0600
From: Rob Herring <robh@...nel.org>
To: Bjorn Andersson <quic_bjorande@...cinc.com>
Cc: Bjorn Andersson <andersson@...nel.org>, 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 <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 6/7] usb: dwc3: qcom: Transition to flattened model

On Mon, Aug 12, 2024 at 4:16 PM Bjorn Andersson
<quic_bjorande@...cinc.com> wrote:
>
> On Mon, Aug 12, 2024 at 03:21:39PM -0600, Rob Herring wrote:
> > On Sun, Aug 11, 2024 at 08:12:03PM -0700, Bjorn Andersson wrote:
> > > From: Bjorn Andersson <quic_bjorande@...cinc.com>
> > >
> > > 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 handle backwards compatibility, and to remove the two-device model,
> > > of_nodes of the old compatible are converted to the new one, early
> > > during probe.
> > >
> > > This happens in the event that a DWC3 core child node is present, the
> > > content of the reg and interrupt properties of this node are merged into
> > > the shared properties, all remaining properties are copied and the core
> > > node is dropped. Effectively transitioning the node from qcom,dwc3 to
> > > qcom,snps-dwc3.
> >
> > In the past we've done this old binding to new binding with an overlay
> > embedded in the kernel. The overlay would just be the .dts change you've
> > made (we should have a tool that takes 2 DTs and generates an overlay as
> > the diff). I suppose it's a few platforms here, but then it is just data
> > and easily deleted when no longer needed (I think the cases I'm
> > remembering did just that because they are gone now. It was TI display
> > and Renesas media stuff IIRC).
> >
>
> Where and how do you apply this overlay?

With "git log -S of_overlay_ drivers/", I found the prior cases. See
841281fe52a7 ("drm: rcar-du: Drop LVDS device tree backward
compatibility") and 739acd85ffdb ("drm/tilcdc: Remove obsolete
"ti,tilcdc,slave" dts binding support")

I would consider putting them in drivers/of/ as well. Then we could
better control the order of applying the overlay and creating devices.
It avoids a lot of the complexity if the overlay is applied first.

> If I can avoid doing the dynamic translation, I'd be happy to do so.
>
> >
> > > Signed-off-by: Bjorn Andersson <quic_bjorande@...cinc.com>
> > > ---
> > >  drivers/usb/dwc3/dwc3-qcom.c | 310 +++++++++++++++++++++++++++++++++++--------
> > >  1 file changed, 251 insertions(+), 59 deletions(-)
> > >
> > > diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> [..]
> > > -static int dwc3_qcom_of_register_core(struct dwc3_qcom *qcom, struct platform_device *pdev)
> > > +static struct property *dwc3_qcom_legacy_prop_concat(const char *name,
> > > +                                                const void *a, size_t a_len,
> > > +                                                const void *b, size_t b_len)
> > >  {
> > > -   struct device_node      *np = pdev->dev.of_node, *dwc3_np;
> > > -   struct device           *dev = &pdev->dev;
> > > -   int                     ret;
> > > +   size_t len = a_len + b_len;
> > >
> > > -   dwc3_np = of_get_compatible_child(np, "snps,dwc3");
> > > -   if (!dwc3_np) {
> > > -           dev_err(dev, "failed to find dwc3 core child\n");
> > > -           return -ENODEV;
> > > -   }
> > > +   struct property *prop __free(kfree) = kzalloc(sizeof(*prop), GFP_KERNEL);
> > > +   char *prop_name __free(kfree) = kstrdup(name, GFP_KERNEL);
> > > +   void *value __free(kfree) = kzalloc(len, GFP_KERNEL);
> > > +   if (!prop || !prop_name || !value)
> > > +           return NULL;
> > >
> > > -   ret = of_platform_populate(np, NULL, NULL, dev);
> > > -   if (ret) {
> > > -           dev_err(dev, "failed to register dwc3 core - %d\n", ret);
> > > -           goto node_put;
> > > +   prop->name = no_free_ptr(prop_name);
> > > +   prop->value = no_free_ptr(value);
> > > +   prop->length = len;
> >
> > We're trying to make struct property opaque or even internal to DT core.
> > Exposing it leaks pointers and then we can't ever free things. This is
> > not helping. The changeset API avoids mucking with struct property.
> >
>
> I will review the changeset API!
>
> > > +
> > > +   memcpy(prop->value, a, a_len);
> > > +   memcpy(prop->value + a_len, b, b_len);
> > > +
> > > +   return_ptr(prop);
> > > +}
> > > +
> > > +/* Replace reg property with base address from dwc3 node and fixed length */
> > > +static int dwc3_qcom_legacy_update_reg(struct device_node *qcom,
> > > +                                  struct device_node *dwc3)
> > > +{
> > > +   int addr_cells;
> > > +   int size_cells;
> > > +   u64 dwc3_addr;
> > > +   int ret;
> > > +
> > > +   ret = of_property_read_reg(dwc3, 0, &dwc3_addr, NULL);
> > > +   if (ret < 0)
> > > +           return ret;
> > > +
> > > +   addr_cells = of_n_addr_cells(qcom);
> > > +   size_cells = of_n_addr_cells(qcom);
> > > +
> > > +   __be32 *reg __free(kfree) = kcalloc(addr_cells + size_cells, sizeof(__be32), GFP_KERNEL);
> > > +   if (!reg)
> > > +           return -ENOMEM;
> > > +
> > > +   reg[addr_cells - 1] = cpu_to_be32(dwc3_addr);
> >
> > Assuming dwc3_addr fits in 32-bit or that the upper 32-bits matches?
> >
>
> The core resides in the lower 32 bits on all existing targets, and I
> expect any new targets that possibly changes that assumption would not
> take the path through this translation (or would need to correct my
> assumption).
>
> > > +   reg[addr_cells + size_cells - 1] = cpu_to_be32(SDM845_QSCRATCH_BASE_OFFSET + SDM845_QSCRATCH_SIZE);
> > > +
> [..]
> > > @@ -773,10 +937,14 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
> > >             goto reset_assert;
> > >     }
> > >
> > > -   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > +   ret = of_address_to_resource(np, 0, &res);
> >
> > So we just leave the platform device resources stale? The right solution
> > is probably to make platform_get_resource() work on demand.
>
> I did consider updating the resource, only in the case that we rewrite
> the information, as it would be slightly cleaner not to leave that
> dangling. But this was cleaner code wise.
>
> > That's what
> > we did for IRQ resources years ago (since those had irqchip driver
> > dependencies).
> >
>
> Right, for platform_get_irq(), but I presume for platform_get_resource()
> we would end up with the union of the different resource-specific lookup
> mechanisms?

You'd just make platform_get_resource() call of_address_to_resource()
internally if there's a node pointer. There could be drivers that
break and it would be slower if we defer probe since it would parse
the DT every probe. But really, an overlay applied earlier is a better
approach IMO.

Rob

Powered by blists - more mailing lists