From: "Théo Lebrun" <theo.lebrun@bootlin.com> To: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Conor Dooley" <conor+dt@kernel.org>, "Roger Quadros" <rogerq@kernel.org>, "Peter Chen" <peter.chen@kernel.org>, "Pawel Laszczak" <pawell@cadence.com>, "Nishanth Menon" <nm@ti.com>, "Vignesh Raghavendra" <vigneshr@ti.com>, "Tero Kristo" <kristo@kernel.org> Cc: linux-usb@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, "Grégory Clement" <gregory.clement@bootlin.com>, "Conor Dooley" <conor.dooley@microchip.com> Subject: Re: [PATCH v2 1/7] dt-bindings: usb: ti,j721e-usb: add ti,j7200-usb compatible Date: Wed, 22 Nov 2023 11:46:14 +0100 [thread overview] Message-ID: <CX5A3OSPKM1Q.1CPN17KI0PD7A@tleb-bootlin-xps13-01> (raw) In-Reply-To: <d0cc33d4-2b1a-43cd-8cd9-6b58d6c71c85@linaro.org> 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
WARNING: multiple messages have this Message-ID (diff)
From: "Théo Lebrun" <theo.lebrun@bootlin.com> To: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>, "Conor Dooley" <conor+dt@kernel.org>, "Roger Quadros" <rogerq@kernel.org>, "Peter Chen" <peter.chen@kernel.org>, "Pawel Laszczak" <pawell@cadence.com>, "Nishanth Menon" <nm@ti.com>, "Vignesh Raghavendra" <vigneshr@ti.com>, "Tero Kristo" <kristo@kernel.org> Cc: linux-usb@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, "Grégory Clement" <gregory.clement@bootlin.com>, "Conor Dooley" <conor.dooley@microchip.com> Subject: Re: [PATCH v2 1/7] dt-bindings: usb: ti,j721e-usb: add ti,j7200-usb compatible Date: Wed, 22 Nov 2023 11:46:14 +0100 [thread overview] Message-ID: <CX5A3OSPKM1Q.1CPN17KI0PD7A@tleb-bootlin-xps13-01> (raw) In-Reply-To: <d0cc33d4-2b1a-43cd-8cd9-6b58d6c71c85@linaro.org> 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-11-22 10:46 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-11-20 17:06 [PATCH v2 0/7] usb: cdns: fix suspend on J7200 by assuming reset-on-resume Théo Lebrun 2023-11-20 17:06 ` Théo Lebrun 2023-11-20 17:06 ` [PATCH v2 1/7] dt-bindings: usb: ti,j721e-usb: add ti,j7200-usb compatible Théo Lebrun 2023-11-20 17:06 ` Théo Lebrun 2023-11-20 17:32 ` Krzysztof Kozlowski 2023-11-20 17:32 ` Krzysztof Kozlowski 2023-11-21 16:53 ` Théo Lebrun 2023-11-21 16:53 ` Théo Lebrun 2023-11-21 17:11 ` Krzysztof Kozlowski 2023-11-21 17:11 ` Krzysztof Kozlowski 2023-11-22 10:46 ` Théo Lebrun [this message] 2023-11-22 10:46 ` Théo Lebrun 2023-11-22 12:00 ` Krzysztof Kozlowski 2023-11-22 12:00 ` Krzysztof Kozlowski 2023-11-22 17:14 ` Théo Lebrun 2023-11-22 17:14 ` Théo Lebrun 2023-11-20 17:06 ` [PATCH v2 2/7] usb: cdns3-ti: remove runtime PM Théo Lebrun 2023-11-20 17:06 ` Théo Lebrun 2023-11-22 23:42 ` Kevin Hilman 2023-11-22 23:42 ` Kevin Hilman 2023-11-20 17:06 ` [PATCH v2 3/7] usb: cdns3-ti: move reg writes from probe into an init_hw helper Théo Lebrun 2023-11-20 17:06 ` Théo Lebrun 2023-11-20 17:06 ` [PATCH v2 4/7] usb: cdns3-ti: add suspend/resume procedures for J7200 Théo Lebrun 2023-11-20 17:06 ` Théo Lebrun 2023-11-20 17:31 ` Krzysztof Kozlowski 2023-11-20 17:31 ` Krzysztof Kozlowski 2023-11-21 16:48 ` Théo Lebrun 2023-11-21 16:48 ` Théo Lebrun 2023-11-20 17:06 ` [PATCH v2 5/7] usb: cdns3: add quirk to platform data for reset-on-resume Théo Lebrun 2023-11-20 17:06 ` Théo Lebrun 2023-11-21 10:40 ` Peter Chen 2023-11-21 10:40 ` Peter Chen 2023-11-20 17:06 ` [PATCH v2 6/7] usb: cdns3-ti: signal reset-on-resume to xHCI for J7200 platform Théo Lebrun 2023-11-20 17:06 ` Théo Lebrun 2023-11-21 16:53 ` Roger Quadros 2023-11-21 16:53 ` Roger Quadros 2023-11-21 17:06 ` Théo Lebrun 2023-11-21 17:06 ` Théo Lebrun 2023-11-20 17:06 ` [PATCH v2 7/7] arm64: dts: ti: k3-j7200: use J7200-specific USB compatible Théo Lebrun 2023-11-20 17:06 ` Théo Lebrun 2023-11-20 17:32 ` Krzysztof Kozlowski 2023-11-20 17:32 ` Krzysztof Kozlowski 2023-11-20 17:33 ` [PATCH v2 0/7] usb: cdns: fix suspend on J7200 by assuming reset-on-resume Krzysztof Kozlowski 2023-11-20 17:33 ` Krzysztof Kozlowski 2023-11-22 23:44 ` Kevin Hilman 2023-11-22 23:44 ` Kevin Hilman
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CX5A3OSPKM1Q.1CPN17KI0PD7A@tleb-bootlin-xps13-01 \ --to=theo.lebrun@bootlin.com \ --cc=conor+dt@kernel.org \ --cc=conor.dooley@microchip.com \ --cc=devicetree@vger.kernel.org \ --cc=gregkh@linuxfoundation.org \ --cc=gregory.clement@bootlin.com \ --cc=kristo@kernel.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=krzysztof.kozlowski@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=nm@ti.com \ --cc=pawell@cadence.com \ --cc=peter.chen@kernel.org \ --cc=robh+dt@kernel.org \ --cc=rogerq@kernel.org \ --cc=vigneshr@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.