| Message ID | 20240316002026.1808336-1-sean.anderson@linux.dev |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [1/2] dt-bindings: nvmem: Remove fsl,t1023-sfp in favor of fsl,layerscape-sfp | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | warning | total: 0 errors, 2 warnings, 33 lines checked |
| robh/patch-applied | success | |
| robh/dtbs-check | warning | build log |
| robh/dt-meta-schema | success |
On Fri, Mar 15, 2024 at 08:20:25PM -0400, Sean Anderson wrote: > These bindings document the same hardware (just different minor > revisions). Remove the newer fsl,t1023-sfp. > > Fixes: aa1ed6047107 ("dt-bindings: nvmem: Add t1023-sfp efuse support") > Signed-off-by: Sean Anderson <sean.anderson@linux.dev> > --- > > .../bindings/nvmem/fsl,layerscape-sfp.yaml | 21 ++++++++++- > .../bindings/nvmem/fsl,t1023-sfp.yaml | 37 ------------------- > 2 files changed, 19 insertions(+), 39 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml > > diff --git a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml > index 70fb2ad25103..8a54dd1328ea 100644 > --- a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml > +++ b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml > @@ -19,6 +19,13 @@ allOf: > properties: > compatible: > oneOf: > + - description: Trust architecture 2.0 SFP > + items: > + enum: > + - fsl,t1023-sfp > + - fsl,t1040-sfp > + - fsl,t2080-sfp > + - fsl,t4240-sfp You should at least mention where these three compatibles came from, given they were not documented in t1023-sfp.yaml. Additionally, should they fall back to t1023-sfp? I see that there's already some dts files with these compatibles in them but seemingly no driver support as there is for the t1023-sfp. Cheers, Conor. > - description: Trust architecture 2.1 SFP > items: > - const: fsl,ls1021a-sfp > @@ -45,8 +52,18 @@ properties: > required: > - compatible > - reg > - - clock-names > - - clocks > + > +if: > + properties: > + compatible: > + contains: > + enum: > + - fsl,ls1021a-sfp > + - fsl,ls1028a-sfp > +then: > + required: > + - clocks > + - clock-names > > unevaluatedProperties: false > > diff --git a/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml > deleted file mode 100644 > index df826b40d8ca..000000000000 > --- a/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml > +++ /dev/null > @@ -1,37 +0,0 @@ > -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > -%YAML 1.2 > ---- > -$id: http://devicetree.org/schemas/nvmem/fsl,t1023-sfp.yaml# > -$schema: http://devicetree.org/meta-schemas/core.yaml# > - > -title: NXP QorIQ eFuse support > - > -maintainers: > - - Richard Alpe <richard@bit42.se> > - > -description: > - Read support for the eFuses (SFP) on NXP QorIQ series SoC's. > - > -allOf: > - - $ref: nvmem.yaml# > - > -properties: > - compatible: > - const: fsl,t1023-sfp > - > - reg: > - maxItems: 1 > - > -required: > - - compatible > - - reg > - > -unevaluatedProperties: false > - > -examples: > - - | > - efuse@e8000 { > - compatible = "fsl,t1023-sfp"; > - reg = <0xe8000 0x1000>; > - }; > -... > -- > 2.35.1.1320.gc452695387.dirty >
On Fri, Mar 15, 2024 at 08:20:25PM -0400, Sean Anderson wrote: > These bindings document the same hardware (just different minor > revisions). Remove the newer fsl,t1023-sfp. > > Fixes: aa1ed6047107 ("dt-bindings: nvmem: Add t1023-sfp efuse support") I don't think Fixes is appropriate here. What was broken? > Signed-off-by: Sean Anderson <sean.anderson@linux.dev> > --- > > .../bindings/nvmem/fsl,layerscape-sfp.yaml | 21 ++++++++++- > .../bindings/nvmem/fsl,t1023-sfp.yaml | 37 ------------------- > 2 files changed, 19 insertions(+), 39 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml Otherwise, Reviewed-by: Rob Herring <robh@kernel.org>
On 2024-03-17 22:12, Rob Herring wrote: > On Fri, Mar 15, 2024 at 08:20:25PM -0400, Sean Anderson wrote: >> These bindings document the same hardware (just different minor >> revisions). Remove the newer fsl,t1023-sfp. >> >> Fixes: aa1ed6047107 ("dt-bindings: nvmem: Add t1023-sfp efuse >> support") > > I don't think Fixes is appropriate here. What was broken? I also don't think Fixes is appropriate. Apart from that: Acked-by: Richard Alpe <richard@bit42.se>
On 3/17/24 11:10, Conor Dooley wrote: > On Fri, Mar 15, 2024 at 08:20:25PM -0400, Sean Anderson wrote: >> These bindings document the same hardware (just different minor >> revisions). Remove the newer fsl,t1023-sfp. >> >> Fixes: aa1ed6047107 ("dt-bindings: nvmem: Add t1023-sfp efuse support") >> Signed-off-by: Sean Anderson <sean.anderson@linux.dev> >> --- >> >> .../bindings/nvmem/fsl,layerscape-sfp.yaml | 21 ++++++++++- >> .../bindings/nvmem/fsl,t1023-sfp.yaml | 37 ------------------- >> 2 files changed, 19 insertions(+), 39 deletions(-) >> delete mode 100644 Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml >> >> diff --git a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml >> index 70fb2ad25103..8a54dd1328ea 100644 >> --- a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml >> +++ b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml >> @@ -19,6 +19,13 @@ allOf: >> properties: >> compatible: >> oneOf: >> + - description: Trust architecture 2.0 SFP >> + items: >> + enum: >> + - fsl,t1023-sfp > >> + - fsl,t1040-sfp >> + - fsl,t2080-sfp >> + - fsl,t4240-sfp > > You should at least mention where these three compatibles came from, > given they were not documented in t1023-sfp.yaml They come from the existing DTSs for these processors. Will add this to the commit message. > Additionally, should > they fall back to t1023-sfp? I see that there's already some dts files > with these compatibles in them but seemingly no driver support as there > is for the t1023-sfp. I checked the reference manuals for these processors, and all of them use TA 2.0. --Sean >> - description: Trust architecture 2.1 SFP >> items: >> - const: fsl,ls1021a-sfp >> @@ -45,8 +52,18 @@ properties: >> required: >> - compatible >> - reg >> - - clock-names >> - - clocks >> + >> +if: >> + properties: >> + compatible: >> + contains: >> + enum: >> + - fsl,ls1021a-sfp >> + - fsl,ls1028a-sfp >> +then: >> + required: >> + - clocks >> + - clock-names >> >> unevaluatedProperties: false >> >> diff --git a/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml >> deleted file mode 100644 >> index df826b40d8ca..000000000000 >> --- a/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml >> +++ /dev/null >> @@ -1,37 +0,0 @@ >> -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> -%YAML 1.2 >> ---- >> -$id: http://devicetree.org/schemas/nvmem/fsl,t1023-sfp.yaml# >> -$schema: http://devicetree.org/meta-schemas/core.yaml# >> - >> -title: NXP QorIQ eFuse support >> - >> -maintainers: >> - - Richard Alpe <richard@bit42.se> >> - >> -description: >> - Read support for the eFuses (SFP) on NXP QorIQ series SoC's. >> - >> -allOf: >> - - $ref: nvmem.yaml# >> - >> -properties: >> - compatible: >> - const: fsl,t1023-sfp >> - >> - reg: >> - maxItems: 1 >> - >> -required: >> - - compatible >> - - reg >> - >> -unevaluatedProperties: false >> - >> -examples: >> - - | >> - efuse@e8000 { >> - compatible = "fsl,t1023-sfp"; >> - reg = <0xe8000 0x1000>; >> - }; >> -... >> -- >> 2.35.1.1320.gc452695387.dirty >>
On Mon, Mar 18, 2024 at 11:08:00AM -0400, Sean Anderson wrote: > On 3/17/24 11:10, Conor Dooley wrote: > > Additionally, should > > they fall back to t1023-sfp? I see that there's already some dts files > > with these compatibles in them but seemingly no driver support as there > > is for the t1023-sfp. > > I checked the reference manuals for these processors, and all of them use TA 2.0. Sounds like a fallback is suitable then, although that will require updating the various dts files.
On 3/18/24 11:40, Conor Dooley wrote: > On Mon, Mar 18, 2024 at 11:08:00AM -0400, Sean Anderson wrote: >> On 3/17/24 11:10, Conor Dooley wrote: > >> > Additionally, should >> > they fall back to t1023-sfp? I see that there's already some dts files >> > with these compatibles in them but seemingly no driver support as there >> > is for the t1023-sfp. >> >> I checked the reference manuals for these processors, and all of them use TA 2.0. > > Sounds like a fallback is suitable then, although that will require > updating the various dts files. Yes, a fallback (like what is done for the T-series) would be suitable, but given that these devicetrees have been in-tree for eight years I think it would be preferable to support the existing bindings for compatibility purposes. --Sean
On Mon, Mar 18, 2024 at 11:48:06AM -0400, Sean Anderson wrote: > On 3/18/24 11:40, Conor Dooley wrote: > > On Mon, Mar 18, 2024 at 11:08:00AM -0400, Sean Anderson wrote: > >> On 3/17/24 11:10, Conor Dooley wrote: > > > >> > Additionally, should > >> > they fall back to t1023-sfp? I see that there's already some dts files > >> > with these compatibles in them but seemingly no driver support as there > >> > is for the t1023-sfp. > >> > >> I checked the reference manuals for these processors, and all of them use TA 2.0. > > > > Sounds like a fallback is suitable then, although that will require > > updating the various dts files. > > Yes, a fallback (like what is done for the T-series) would be suitable, > but given that these devicetrees have been in-tree for eight years I > think it would be preferable to support the existing bindings for > compatibility purposes. Just cos stuff snuck into the tree in dts files doesn't make it right though, I'd rather the bindings were done correctly. I don't care if you want to support all of the compatibles in the driver so that it works with the existing devicetrees though, as long as you mention the rationale in the commit message.
On 3/19/24 13:55, Conor Dooley wrote: > On Mon, Mar 18, 2024 at 11:48:06AM -0400, Sean Anderson wrote: >> On 3/18/24 11:40, Conor Dooley wrote: >> > On Mon, Mar 18, 2024 at 11:08:00AM -0400, Sean Anderson wrote: >> >> On 3/17/24 11:10, Conor Dooley wrote: >> > >> >> > Additionally, should >> >> > they fall back to t1023-sfp? I see that there's already some dts files >> >> > with these compatibles in them but seemingly no driver support as there >> >> > is for the t1023-sfp. >> >> >> >> I checked the reference manuals for these processors, and all of them use TA 2.0. >> > >> > Sounds like a fallback is suitable then, although that will require >> > updating the various dts files. >> >> Yes, a fallback (like what is done for the T-series) would be suitable, >> but given that these devicetrees have been in-tree for eight years I >> think it would be preferable to support the existing bindings for >> compatibility purposes. > > Just cos stuff snuck into the tree in dts files doesn't make it right > though, I'd rather the bindings were done correctly. I don't care if you > want to support all of the compatibles in the driver so that it works > with the existing devicetrees though, as long as you mention the > rationale in the commit message. It doesn't really matter what the schema has as long as the driver supports existing device trees. --Sean
On 21/03/2024 17:21, Sean Anderson wrote: > On 3/19/24 13:55, Conor Dooley wrote: >> On Mon, Mar 18, 2024 at 11:48:06AM -0400, Sean Anderson wrote: >>> On 3/18/24 11:40, Conor Dooley wrote: >>>> On Mon, Mar 18, 2024 at 11:08:00AM -0400, Sean Anderson wrote: >>>>> On 3/17/24 11:10, Conor Dooley wrote: >>>> >>>>>> Additionally, should >>>>>> they fall back to t1023-sfp? I see that there's already some dts files >>>>>> with these compatibles in them but seemingly no driver support as there >>>>>> is for the t1023-sfp. >>>>> >>>>> I checked the reference manuals for these processors, and all of them use TA 2.0. >>>> >>>> Sounds like a fallback is suitable then, although that will require >>>> updating the various dts files. >>> >>> Yes, a fallback (like what is done for the T-series) would be suitable, >>> but given that these devicetrees have been in-tree for eight years I >>> think it would be preferable to support the existing bindings for >>> compatibility purposes. >> >> Just cos stuff snuck into the tree in dts files doesn't make it right >> though, I'd rather the bindings were done correctly. I don't care if you >> want to support all of the compatibles in the driver so that it works >> with the existing devicetrees though, as long as you mention the >> rationale in the commit message. > > It doesn't really matter what the schema has as long as the driver supports > existing device trees. We do not talk about driver now but bindings. You add new compatibles on a basis that they were already used. This cannot bypass regular review comments, so if during regular review process we would require fallbacks, then you are expected to listen to review also when documenting existing compatibles. Otherwise everyone would prefer to snuck in incorrect code and later document it "it was there!". Best regards, Krzysztof
On 3/22/24 03:01, Krzysztof Kozlowski wrote: > On 21/03/2024 17:21, Sean Anderson wrote: >> On 3/19/24 13:55, Conor Dooley wrote: >>> On Mon, Mar 18, 2024 at 11:48:06AM -0400, Sean Anderson wrote: >>>> On 3/18/24 11:40, Conor Dooley wrote: >>>>> On Mon, Mar 18, 2024 at 11:08:00AM -0400, Sean Anderson wrote: >>>>>> On 3/17/24 11:10, Conor Dooley wrote: >>>>> >>>>>>> Additionally, should >>>>>>> they fall back to t1023-sfp? I see that there's already some dts files >>>>>>> with these compatibles in them but seemingly no driver support as there >>>>>>> is for the t1023-sfp. >>>>>> >>>>>> I checked the reference manuals for these processors, and all of them use TA 2.0. >>>>> >>>>> Sounds like a fallback is suitable then, although that will require >>>>> updating the various dts files. >>>> >>>> Yes, a fallback (like what is done for the T-series) would be suitable, >>>> but given that these devicetrees have been in-tree for eight years I >>>> think it would be preferable to support the existing bindings for >>>> compatibility purposes. >>> >>> Just cos stuff snuck into the tree in dts files doesn't make it right >>> though, I'd rather the bindings were done correctly. I don't care if you >>> want to support all of the compatibles in the driver so that it works >>> with the existing devicetrees though, as long as you mention the >>> rationale in the commit message. >> >> It doesn't really matter what the schema has as long as the driver supports >> existing device trees. > > We do not talk about driver now but bindings. You add new compatibles on > a basis that they were already used. This cannot bypass regular review > comments, so if during regular review process we would require > fallbacks, then you are expected to listen to review also when > documenting existing compatibles. Otherwise everyone would prefer to > snuck in incorrect code and later document it "it was there!". To be clear, the existing nodes look like sfp: sfp@e8000 { compatible = "fsl,t1040-sfp"; reg = <0xe8000 0x1000>; }; which is perfectly serviceable for read-only use (as the clock is only necessary for writing). As these devices are effectively identical, the compatible could also look like what the P-series has: sfp: sfp@e8000 { compatible = "fsl,p2041-sfp", "fsl,qoriq-sfp-1.0"; reg = <0xe8000 0x1000>; }; but in either case, it is desirable for the driver to match based on the more-specific compatible (as well as the less-specific compatible) as we already have enough information from the more-specific compatible to select the correct implementation. --Sean
On Fri, Mar 22, 2024 at 12:26:10PM -0400, Sean Anderson wrote: > On 3/22/24 03:01, Krzysztof Kozlowski wrote: > > On 21/03/2024 17:21, Sean Anderson wrote: > >> On 3/19/24 13:55, Conor Dooley wrote: > >>> On Mon, Mar 18, 2024 at 11:48:06AM -0400, Sean Anderson wrote: > >>>> On 3/18/24 11:40, Conor Dooley wrote: > >>>>> On Mon, Mar 18, 2024 at 11:08:00AM -0400, Sean Anderson wrote: > >>>>>> On 3/17/24 11:10, Conor Dooley wrote: > >>>>> > >>>>>>> Additionally, should > >>>>>>> they fall back to t1023-sfp? I see that there's already some dts files > >>>>>>> with these compatibles in them but seemingly no driver support as there > >>>>>>> is for the t1023-sfp. > >>>>>> > >>>>>> I checked the reference manuals for these processors, and all of them use TA 2.0. > >>>>> > >>>>> Sounds like a fallback is suitable then, although that will require > >>>>> updating the various dts files. > >>>> > >>>> Yes, a fallback (like what is done for the T-series) would be suitable, > >>>> but given that these devicetrees have been in-tree for eight years I > >>>> think it would be preferable to support the existing bindings for > >>>> compatibility purposes. > >>> > >>> Just cos stuff snuck into the tree in dts files doesn't make it right > >>> though, I'd rather the bindings were done correctly. I don't care if you > >>> want to support all of the compatibles in the driver so that it works > >>> with the existing devicetrees though, as long as you mention the > >>> rationale in the commit message. > >> > >> It doesn't really matter what the schema has as long as the driver supports > >> existing device trees. > > > > We do not talk about driver now but bindings. You add new compatibles on > > a basis that they were already used. This cannot bypass regular review > > comments, so if during regular review process we would require > > fallbacks, then you are expected to listen to review also when > > documenting existing compatibles. Otherwise everyone would prefer to > > snuck in incorrect code and later document it "it was there!". > > To be clear, the existing nodes look like > > sfp: sfp@e8000 { > compatible = "fsl,t1040-sfp"; > reg = <0xe8000 0x1000>; > }; > > which is perfectly serviceable for read-only use (as the clock is only > necessary for writing). As these devices are effectively identical, the > compatible could also look like what the P-series has: I'd rather you just picked the oldest device and used that as the fallback, rather than introducing an "<blah>-sfp-2.0" compatible. The 2.1 and 3.0 ones don't have anything like that. > sfp: sfp@e8000 { > compatible = "fsl,p2041-sfp", "fsl,qoriq-sfp-1.0"; > reg = <0xe8000 0x1000>; > }; None of the seem to be documented either btw: rg fsl,qoriq-sfp-1.0 arch/powerpc/boot/dts/fsl/p5020si-post.dtsi 371: compatible = "fsl,p5020-sfp", "fsl,qoriq-sfp-1.0"; arch/powerpc/boot/dts/fsl/p2041si-post.dtsi 339: compatible = "fsl,p2041-sfp", "fsl,qoriq-sfp-1.0"; arch/powerpc/boot/dts/fsl/p4080si-post.dtsi 386: compatible = "fsl,p4080-sfp", "fsl,qoriq-sfp-1.0"; arch/powerpc/boot/dts/fsl/p3041si-post.dtsi 366: compatible = "fsl,p3041-sfp", "fsl,qoriq-sfp-1.0"; arch/powerpc/boot/dts/fsl/p5040si-post.dtsi 331: compatible = "fsl,p5040-sfp", "fsl,qoriq-sfp-1.0"; > > but in either case, it is desirable for the driver to match based on the > more-specific compatible (as well as the less-specific compatible) as we > already have enough information from the more-specific compatible to > select the correct implementation. > > --Sean
On 3/22/24 14:14, Conor Dooley wrote: > On Fri, Mar 22, 2024 at 12:26:10PM -0400, Sean Anderson wrote: >> On 3/22/24 03:01, Krzysztof Kozlowski wrote: >> > On 21/03/2024 17:21, Sean Anderson wrote: >> >> On 3/19/24 13:55, Conor Dooley wrote: >> >>> On Mon, Mar 18, 2024 at 11:48:06AM -0400, Sean Anderson wrote: >> >>>> On 3/18/24 11:40, Conor Dooley wrote: >> >>>>> On Mon, Mar 18, 2024 at 11:08:00AM -0400, Sean Anderson wrote: >> >>>>>> On 3/17/24 11:10, Conor Dooley wrote: >> >>>>> >> >>>>>>> Additionally, should >> >>>>>>> they fall back to t1023-sfp? I see that there's already some dts files >> >>>>>>> with these compatibles in them but seemingly no driver support as there >> >>>>>>> is for the t1023-sfp. >> >>>>>> >> >>>>>> I checked the reference manuals for these processors, and all of them use TA 2.0. >> >>>>> >> >>>>> Sounds like a fallback is suitable then, although that will require >> >>>>> updating the various dts files. >> >>>> >> >>>> Yes, a fallback (like what is done for the T-series) would be suitable, >> >>>> but given that these devicetrees have been in-tree for eight years I >> >>>> think it would be preferable to support the existing bindings for >> >>>> compatibility purposes. >> >>> >> >>> Just cos stuff snuck into the tree in dts files doesn't make it right >> >>> though, I'd rather the bindings were done correctly. I don't care if you >> >>> want to support all of the compatibles in the driver so that it works >> >>> with the existing devicetrees though, as long as you mention the >> >>> rationale in the commit message. >> >> >> >> It doesn't really matter what the schema has as long as the driver supports >> >> existing device trees. >> > >> > We do not talk about driver now but bindings. You add new compatibles on >> > a basis that they were already used. This cannot bypass regular review >> > comments, so if during regular review process we would require >> > fallbacks, then you are expected to listen to review also when >> > documenting existing compatibles. Otherwise everyone would prefer to >> > snuck in incorrect code and later document it "it was there!". >> >> To be clear, the existing nodes look like >> >> sfp: sfp@e8000 { >> compatible = "fsl,t1040-sfp"; >> reg = <0xe8000 0x1000>; >> }; >> >> which is perfectly serviceable for read-only use (as the clock is only >> necessary for writing). As these devices are effectively identical, the >> compatible could also look like what the P-series has: > > I'd rather you just picked the oldest device and used that as the > fallback, rather than introducing an "<blah>-sfp-2.0" compatible. > The 2.1 and 3.0 ones don't have anything like that. Because of course no one looked around at the other SoCs and noticed that they all have the same TA version and use the same document for this device. I would rather use a common name based on the version, rather than arbitrarily picking a SoC to be "compatible" with. This doesn't make sense to me, since each SoC's reference manual just calls out to the appropriate TA manual for all register definitions. >> sfp: sfp@e8000 { >> compatible = "fsl,p2041-sfp", "fsl,qoriq-sfp-1.0"; >> reg = <0xe8000 0x1000>; >> }; > > None of the seem to be documented either btw: > rg fsl,qoriq-sfp-1.0 > arch/powerpc/boot/dts/fsl/p5020si-post.dtsi > 371: compatible = "fsl,p5020-sfp", "fsl,qoriq-sfp-1.0"; > > arch/powerpc/boot/dts/fsl/p2041si-post.dtsi > 339: compatible = "fsl,p2041-sfp", "fsl,qoriq-sfp-1.0"; > > arch/powerpc/boot/dts/fsl/p4080si-post.dtsi > 386: compatible = "fsl,p4080-sfp", "fsl,qoriq-sfp-1.0"; > > arch/powerpc/boot/dts/fsl/p3041si-post.dtsi > 366: compatible = "fsl,p3041-sfp", "fsl,qoriq-sfp-1.0"; > > arch/powerpc/boot/dts/fsl/p5040si-post.dtsi > 331: compatible = "fsl,p5040-sfp", "fsl,qoriq-sfp-1.0"; Yeah. As noted in the next patch, someone with access to the TA 1.0 manual would need to have a look. --Sean >> >> but in either case, it is desirable for the driver to match based on the >> more-specific compatible (as well as the less-specific compatible) as we >> already have enough information from the more-specific compatible to >> select the correct implementation. >> >> --Sean
diff --git a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml index 70fb2ad25103..8a54dd1328ea 100644 --- a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml +++ b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml @@ -19,6 +19,13 @@ allOf: properties: compatible: oneOf: + - description: Trust architecture 2.0 SFP + items: + enum: + - fsl,t1023-sfp + - fsl,t1040-sfp + - fsl,t2080-sfp + - fsl,t4240-sfp - description: Trust architecture 2.1 SFP items: - const: fsl,ls1021a-sfp @@ -45,8 +52,18 @@ properties: required: - compatible - reg - - clock-names - - clocks + +if: + properties: + compatible: + contains: + enum: + - fsl,ls1021a-sfp + - fsl,ls1028a-sfp +then: + required: + - clocks + - clock-names unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml deleted file mode 100644 index df826b40d8ca..000000000000 --- a/Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml +++ /dev/null @@ -1,37 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/nvmem/fsl,t1023-sfp.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: NXP QorIQ eFuse support - -maintainers: - - Richard Alpe <richard@bit42.se> - -description: - Read support for the eFuses (SFP) on NXP QorIQ series SoC's. - -allOf: - - $ref: nvmem.yaml# - -properties: - compatible: - const: fsl,t1023-sfp - - reg: - maxItems: 1 - -required: - - compatible - - reg - -unevaluatedProperties: false - -examples: - - | - efuse@e8000 { - compatible = "fsl,t1023-sfp"; - reg = <0xe8000 0x1000>; - }; -...
These bindings document the same hardware (just different minor revisions). Remove the newer fsl,t1023-sfp. Fixes: aa1ed6047107 ("dt-bindings: nvmem: Add t1023-sfp efuse support") Signed-off-by: Sean Anderson <sean.anderson@linux.dev> --- .../bindings/nvmem/fsl,layerscape-sfp.yaml | 21 ++++++++++- .../bindings/nvmem/fsl,t1023-sfp.yaml | 37 ------------------- 2 files changed, 19 insertions(+), 39 deletions(-) delete mode 100644 Documentation/devicetree/bindings/nvmem/fsl,t1023-sfp.yaml