| Message ID | 20220825214423.903672-9-michael@walle.cc |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | nvmem: core: introduce NVMEM layouts | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success | |
| robh/patch-applied | success | |
| robh/dtbs-check | warning | build log |
| robh/dt-meta-schema | success |
On 26/08/2022 00:44, Michael Walle wrote: > The "user-otp" and "factory-otp" compatible string just depicts a > generic NVMEM device. But an actual device tree node might as well > contain a more specific compatible string. Make it possible to add > more specific binding elsewere and just match part of the compatibles typo: elsewhere > here. > > Signed-off-by: Michael Walle <michael@walle.cc> > --- > Documentation/devicetree/bindings/mtd/mtd.yaml | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mtd/mtd.yaml b/Documentation/devicetree/bindings/mtd/mtd.yaml > index 376b679cfc70..0291e439b6a6 100644 > --- a/Documentation/devicetree/bindings/mtd/mtd.yaml > +++ b/Documentation/devicetree/bindings/mtd/mtd.yaml > @@ -33,9 +33,10 @@ patternProperties: > > properties: > compatible: > - enum: > - - user-otp > - - factory-otp > + contains: > + enum: > + - user-otp > + - factory-otp This does not work in the "elsewhere" place. You need to use similar approach as we do for syscon or primecell. > > required: > - compatible Best regards, Krzysztof
Am 2022-08-31 09:37, schrieb Krzysztof Kozlowski: > On 26/08/2022 00:44, Michael Walle wrote: >> The "user-otp" and "factory-otp" compatible string just depicts a >> generic NVMEM device. But an actual device tree node might as well >> contain a more specific compatible string. Make it possible to add >> more specific binding elsewere and just match part of the compatibles > > typo: elsewhere > >> here. >> >> Signed-off-by: Michael Walle <michael@walle.cc> >> --- >> Documentation/devicetree/bindings/mtd/mtd.yaml | 7 ++++--- >> 1 file changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/mtd/mtd.yaml >> b/Documentation/devicetree/bindings/mtd/mtd.yaml >> index 376b679cfc70..0291e439b6a6 100644 >> --- a/Documentation/devicetree/bindings/mtd/mtd.yaml >> +++ b/Documentation/devicetree/bindings/mtd/mtd.yaml >> @@ -33,9 +33,10 @@ patternProperties: >> >> properties: >> compatible: >> - enum: >> - - user-otp >> - - factory-otp >> + contains: >> + enum: >> + - user-otp >> + - factory-otp > > This does not work in the "elsewhere" place. You need to use similar > approach as we do for syscon or primecell. I'm a bit confused. Looking at Documentation/devicetree/bindings/arm/primecell.yaml it is done in the same way as this binding. Whereas, the syscon use a "select:" on top of it. I'm pretty sure, I've tested it without the select and the validator picked up the constraints. Could you elaborate on what is wrong here? Select missing? -michael
On 31/08/2022 10:48, Michael Walle wrote: > Am 2022-08-31 09:37, schrieb Krzysztof Kozlowski: >> On 26/08/2022 00:44, Michael Walle wrote: >>> The "user-otp" and "factory-otp" compatible string just depicts a >>> generic NVMEM device. But an actual device tree node might as well >>> contain a more specific compatible string. Make it possible to add >>> more specific binding elsewere and just match part of the compatibles >> >> typo: elsewhere >> >>> here. >>> >>> Signed-off-by: Michael Walle <michael@walle.cc> >>> --- >>> Documentation/devicetree/bindings/mtd/mtd.yaml | 7 ++++--- >>> 1 file changed, 4 insertions(+), 3 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/mtd/mtd.yaml >>> b/Documentation/devicetree/bindings/mtd/mtd.yaml >>> index 376b679cfc70..0291e439b6a6 100644 >>> --- a/Documentation/devicetree/bindings/mtd/mtd.yaml >>> +++ b/Documentation/devicetree/bindings/mtd/mtd.yaml >>> @@ -33,9 +33,10 @@ patternProperties: >>> >>> properties: >>> compatible: >>> - enum: >>> - - user-otp >>> - - factory-otp >>> + contains: >>> + enum: >>> + - user-otp >>> + - factory-otp >> >> This does not work in the "elsewhere" place. You need to use similar >> approach as we do for syscon or primecell. > > I'm a bit confused. Looking at > Documentation/devicetree/bindings/arm/primecell.yaml > it is done in the same way as this binding. Yes. primecell is like your mtd here. And how are other places with primcell (like other places with user-otp) done? > > Whereas, the syscon use a "select:" on top of it. I'm > pretty sure, I've tested it without the select and the > validator picked up the constraints. > > Could you elaborate on what is wrong here? Select missing? You got warning from Rob, so run tests. I think you will see the errors, just like bot reported them. Best regards, Krzysztof
On Thu, Aug 25, 2022 at 11:44:17PM +0200, Michael Walle wrote: > The "user-otp" and "factory-otp" compatible string just depicts a > generic NVMEM device. But an actual device tree node might as well > contain a more specific compatible string. Make it possible to add > more specific binding elsewere and just match part of the compatibles > here. > > Signed-off-by: Michael Walle <michael@walle.cc> > --- > Documentation/devicetree/bindings/mtd/mtd.yaml | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) In hindsight it looks like we are mixing 2 different purposes of 'which instance is this' and 'what is this'. 'compatible' is supposed to be the latter. Maybe there's a better way to handle user/factory? There's a similar need with partitions for A/B or factory/update. Rob
Am 2022-08-31 23:48, schrieb Rob Herring: > On Thu, Aug 25, 2022 at 11:44:17PM +0200, Michael Walle wrote: >> The "user-otp" and "factory-otp" compatible string just depicts a >> generic NVMEM device. But an actual device tree node might as well >> contain a more specific compatible string. Make it possible to add >> more specific binding elsewere and just match part of the compatibles >> here. >> >> Signed-off-by: Michael Walle <michael@walle.cc> >> --- >> Documentation/devicetree/bindings/mtd/mtd.yaml | 7 ++++--- >> 1 file changed, 4 insertions(+), 3 deletions(-) > > In hindsight it looks like we are mixing 2 different purposes of 'which > instance is this' and 'what is this'. 'compatible' is supposed to be > the > latter. > > Maybe there's a better way to handle user/factory? There's a similar > need with partitions for A/B or factory/update. I'm not sure I understand what you mean. It has nothing to with user and factory provisionings. SPI flashes have a user programmable and a factory programmable area, some have just one of them. Whereas with A/B you (as in the user or the board manufacturer) defines an area within a memory device to be either slot A or slot B. But here the flash dictates what's factory and what's user storage. It's in the datasheet. HTH -michael
On Wed, Aug 31, 2022 at 5:30 PM Michael Walle <michael@walle.cc> wrote: > > Am 2022-08-31 23:48, schrieb Rob Herring: > > On Thu, Aug 25, 2022 at 11:44:17PM +0200, Michael Walle wrote: > >> The "user-otp" and "factory-otp" compatible string just depicts a > >> generic NVMEM device. But an actual device tree node might as well > >> contain a more specific compatible string. Make it possible to add > >> more specific binding elsewere and just match part of the compatibles > >> here. > >> > >> Signed-off-by: Michael Walle <michael@walle.cc> > >> --- > >> Documentation/devicetree/bindings/mtd/mtd.yaml | 7 ++++--- > >> 1 file changed, 4 insertions(+), 3 deletions(-) > > > > In hindsight it looks like we are mixing 2 different purposes of 'which > > instance is this' and 'what is this'. 'compatible' is supposed to be > > the > > latter. > > > > Maybe there's a better way to handle user/factory? There's a similar > > need with partitions for A/B or factory/update. > > I'm not sure I understand what you mean. It has nothing to with > user and factory provisionings. > > SPI flashes have a user programmable and a factory programmable > area, some have just one of them. Whereas with A/B you (as in the > user or the board manufacturer) defines an area within a memory device > to be either slot A or slot B. But here the flash dictates what's > factory and what's user storage. It's in the datasheet. Ah, right. Nevermind... Rob
diff --git a/Documentation/devicetree/bindings/mtd/mtd.yaml b/Documentation/devicetree/bindings/mtd/mtd.yaml index 376b679cfc70..0291e439b6a6 100644 --- a/Documentation/devicetree/bindings/mtd/mtd.yaml +++ b/Documentation/devicetree/bindings/mtd/mtd.yaml @@ -33,9 +33,10 @@ patternProperties: properties: compatible: - enum: - - user-otp - - factory-otp + contains: + enum: + - user-otp + - factory-otp required: - compatible
The "user-otp" and "factory-otp" compatible string just depicts a generic NVMEM device. But an actual device tree node might as well contain a more specific compatible string. Make it possible to add more specific binding elsewere and just match part of the compatibles here. Signed-off-by: Michael Walle <michael@walle.cc> --- Documentation/devicetree/bindings/mtd/mtd.yaml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)