Hello,
On Tue Nov 21, 2023 at 6:11 PM CET, Krzysztof Kozlowski wrote:
> On 21/11/2023 17:53, Théo Lebrun wrote:
> > On Mon Nov 20, 2023 at 6:32 PM CET, Krzysztof Kozlowski wrote:
> >> On 20/11/2023 18:06, Théo Lebrun wrote:
> >>> On this platform, the controller & its wrapper are reset on resume. This
> >>> makes it have a different behavior from other platforms.
> >>>
> >>> We allow using the new compatible with a fallback onto the original
> >>> ti,j721e-usb compatible. We therefore allow using an older kernel with
> >>
> >> Where is fallback ti,j721e-usb used? Please point me to the code.
> >
> > No fallback is implemented in code. Using a kernel that doesn't have
> > this patch series but a more recent devicetree: DT has both
> > devicetrees & the kernel will know which driver to use.
>
> I meant your bindings. You said - with fallback to ti,j721e-usb. I do
> not see it. To me the commit description is not accurate.
I see your point, I'll remove that aspect.
> > That is opposed to having only compatible = "ti,j7200-usb". If using an
> > old kernel, it would not know what driver to match it to.
> >
> > [...]
> >
> >>> --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml
> >>> +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml
> >>> @@ -12,11 +12,15 @@ maintainers:
> >>> properties:
> >>> compatible:
> >>> oneOf:
> >>> + - const: ti,j7200-usb
> >>> - const: ti,j721e-usb
> >>> - const: ti,am64-usb
> >>> - items:
> >>> - const: ti,j721e-usb
> >>> - const: ti,am64-usb
> >>> + - items:
> >>> + - const: ti,j721e-usb
> >>
> >> This makes little sense. It's already on the list. Twice! Don't add it
> >> third time.
> >>
> >> I am sorry, but this binding makes no sense. I mean, existing binding
> >> makes no sense, but your change is not making it anyhow better.
> >
> > The goal of the DT schema pre-patch was to allow all three:
> >
> > compatible = "ti,j721e-usb";
> > compatible = "ti,am64-usb";
> > compatible = "ti,j721e-usb", "ti,am64-usb";
>
> Which does not make sense.
>
> How ti,j721e-usb can be and cannot be compatible with am64 in the same time?
The code tells us that there is no difference between ti,j721e-usb &
ti,am64-usb. And the commit adding the of_device_id entry agrees, see
4f30b9d2315f (usb: cdns3: Add support for TI's AM64 SoC, 2021-01-19).
Here is the entire patch because it is so small:
diff --git a/drivers/usb/cdns3/cdns3-ti.c b/drivers/usb/cdns3/cdns3-ti.c
index 90e246601537..eccb1c766bba 100644
--- a/drivers/usb/cdns3/cdns3-ti.c
+++ b/drivers/usb/cdns3/cdns3-ti.c
@@ -214,6 +214,7 @@ static int cdns_ti_remove(struct platform_device *pdev)
static const struct of_device_id cdns_ti_of_match[] = {
{ .compatible = "ti,j721e-usb", },
+ { .compatible = "ti,am64-usb", },
{},
};
MODULE_DEVICE_TABLE(of, cdns_ti_of_match);
> > I've followed the same scheme & added both of those:
> >
> > compatible = "ti,j7200-usb";
> > compatible = "ti,j7200-usb", "ti,j721e-usb";
> >
> > I messed up the ordering in the added 'items' options, but the logic
> > seems right to me. And dtbs_check agrees. Am I missing something?
>
> Logic is wrong. Device either is or is not compatible with something. At
> least usually. We have some exceptions like SMMU for Adreno. Is this the
> case? Why the device is and is not compatible with some other variant?
My understanding is this: j721e & am64 are strictly equivalent. On our
j7200 we know we reset on resume. I see three ways forward:
- properties:
compatible:
oneOf:
- const: ti,j7200-usb
- const: ti,j721e-usb
- const: ti,am64-usb
We keep both ti,j721e-usb & ti,am64-usb separate even though they are
compatible. It makes for simpler changes & it avoids touching
devicetrees.
- properties:
compatible:
oneOf:
- const: ti,j7200-usb
- const: ti,j721e-usb
AM64 is a duplicate of J721E. Remove it and update upstream
devicetrees.
- properties:
compatible:
oneOf:
- const: ti,j7200-usb
- items:
- const: ti,j721e-usb
- const: ti,am64-usb
J721E & AM64 are compatible, express that & update devicetrees.
Option one is simpler & doesn't change devicetrees so I'd lean in that
direction. What's your opinion?
Regards,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
