| Message ID | 20240203002834.171462-4-william.zhang@broadcom.com |
|---|---|
| State | New |
| Headers | show |
| Series | dt-bindings: mtd: brcmnand: Updates for bcmbca SoCs | expand |
On Fri, Feb 02, 2024 at 04:28:24PM -0800, William Zhang wrote: > Add brcm,nand-ecc-use-strap to get ecc and spare area size settings from > board boot strap for broadband board designs because they do not specify > ecc setting in dts but rather using the strap setting. > > Signed-off-by: William Zhang <william.zhang@broadcom.com> > > --- > > Changes in v4: > - Move ecc strap property to this separate patch and remove some > non-binding related text from the description > > Changes in v3: None > Changes in v2: None > > Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml > index d0168d55c73e..2599d902ec3a 100644 > --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml > +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml > @@ -147,6 +147,14 @@ patternProperties: > layout. > $ref: /schemas/types.yaml#/definitions/uint32 > > + brcm,nand-ecc-use-strap: > + description: > + This flag indicates the ecc strength and spare area size should > + be retrieved from the SoC NAND boot strap setting instead of > + nand-ecc-strength and brcm,nand-oob-sector-size or auto detection. I'm still on the fence about this being overly prescriptive about the operating systems behaviour. I think it would be good to say why the strap values are better than those explicitly provided in DT rather than just saying "these strap values should be used". > + This is commonly used by the BCMBCA SoC board design. > + $ref: /schemas/types.yaml#/definitions/flag > + > unevaluatedProperties: false > > allOf: > -- > 2.37.3 >
On 2/3/24 06:49, Conor Dooley wrote: > On Fri, Feb 02, 2024 at 04:28:24PM -0800, William Zhang wrote: >> Add brcm,nand-ecc-use-strap to get ecc and spare area size settings from >> board boot strap for broadband board designs because they do not specify >> ecc setting in dts but rather using the strap setting. >> >> Signed-off-by: William Zhang <william.zhang@broadcom.com> >> >> --- >> >> Changes in v4: >> - Move ecc strap property to this separate patch and remove some >> non-binding related text from the description >> >> Changes in v3: None >> Changes in v2: None >> >> Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml >> index d0168d55c73e..2599d902ec3a 100644 >> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml >> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml >> @@ -147,6 +147,14 @@ patternProperties: >> layout. >> $ref: /schemas/types.yaml#/definitions/uint32 >> >> + brcm,nand-ecc-use-strap: >> + description: >> + This flag indicates the ecc strength and spare area size should >> + be retrieved from the SoC NAND boot strap setting instead of >> + nand-ecc-strength and brcm,nand-oob-sector-size or auto detection. > > I'm still on the fence about this being overly prescriptive about the > operating systems behaviour. I think it would be good to say why the > strap values are better than those explicitly provided in DT rather than > just saying "these strap values should be used". > This is a board/SoC design choice. I wouldn't advise it as better choice as other board/SoC may not have that option. But definitively for BCMBCA SoC board design, it is better and much easier and convenient option than explicit dt setting. How about: This property provides a choice for retrieving ecc strength and spare area size from the SoC NAND boot strap setting. It is commonly used by the BCMBCA SoC board design. >> + This is commonly used by the BCMBCA SoC board design. >> + $ref: /schemas/types.yaml#/definitions/flag >> + >> unevaluatedProperties: false >> >> allOf: >> -- >> 2.37.3 >>
Hi, conor@kernel.org wrote on Sat, 3 Feb 2024 14:49:50 +0000: > On Fri, Feb 02, 2024 at 04:28:24PM -0800, William Zhang wrote: > > Add brcm,nand-ecc-use-strap to get ecc and spare area size settings from > > board boot strap for broadband board designs because they do not specify > > ecc setting in dts but rather using the strap setting. > > > > Signed-off-by: William Zhang <william.zhang@broadcom.com> > > > > --- > > > > Changes in v4: > > - Move ecc strap property to this separate patch and remove some > > non-binding related text from the description > > > > Changes in v3: None > > Changes in v2: None > > > > Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml > > index d0168d55c73e..2599d902ec3a 100644 > > --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml > > +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml > > @@ -147,6 +147,14 @@ patternProperties: > > layout. > > $ref: /schemas/types.yaml#/definitions/uint32 > > > > + brcm,nand-ecc-use-strap: > > + description: > > + This flag indicates the ecc strength and spare area size should > > + be retrieved from the SoC NAND boot strap setting instead of > > + nand-ecc-strength and brcm,nand-oob-sector-size or auto detection. > > I'm still on the fence about this being overly prescriptive about the > operating systems behaviour. I think it would be good to say why the > strap values are better than those explicitly provided in DT rather than > just saying "these strap values should be used". I don't know if there is a point is saying why they would be better, as they are not. It is a -questionable- design choice. However I would just get rid of any mention to other properties. Just say one should expect the strap value to be read and applied by the system when this property is present. > > + This is commonly used by the BCMBCA SoC board design. > > + $ref: /schemas/types.yaml#/definitions/flag > > + > > unevaluatedProperties: false > > > > allOf: > > -- > > 2.37.3 > > Thanks, Miquèl
Hi Miquel, On 2/5/24 05:26, Miquel Raynal wrote: > Hi, > > conor@kernel.org wrote on Sat, 3 Feb 2024 14:49:50 +0000: > >> On Fri, Feb 02, 2024 at 04:28:24PM -0800, William Zhang wrote: >>> Add brcm,nand-ecc-use-strap to get ecc and spare area size settings from >>> board boot strap for broadband board designs because they do not specify >>> ecc setting in dts but rather using the strap setting. >>> >>> Signed-off-by: William Zhang <william.zhang@broadcom.com> >>> >>> --- >>> >>> Changes in v4: >>> - Move ecc strap property to this separate patch and remove some >>> non-binding related text from the description >>> >>> Changes in v3: None >>> Changes in v2: None >>> >>> Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml | 8 ++++++++ >>> 1 file changed, 8 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml >>> index d0168d55c73e..2599d902ec3a 100644 >>> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml >>> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml >>> @@ -147,6 +147,14 @@ patternProperties: >>> layout. >>> $ref: /schemas/types.yaml#/definitions/uint32 >>> >>> + brcm,nand-ecc-use-strap: >>> + description: >>> + This flag indicates the ecc strength and spare area size should >>> + be retrieved from the SoC NAND boot strap setting instead of >>> + nand-ecc-strength and brcm,nand-oob-sector-size or auto detection. >> >> I'm still on the fence about this being overly prescriptive about the >> operating systems behaviour. I think it would be good to say why the >> strap values are better than those explicitly provided in DT rather than >> just saying "these strap values should be used". > > I don't know if there is a point is saying why they would be better, as > they are not. It is a -questionable- design choice. However I would > just get rid of any mention to other properties. Just say one should > expect the strap value to be read and applied by the system when this > property is present. > Agree we don't need to say which is better as it is just a design choice. And it is used by all BCMBCA internal ref boards and customer designs. But if we just say strap value is read and applied, it is vague and nobody would know what is applied. I replied this email yesterday and suggest the followings: This property provides a choice for retrieving ecc strength and spare area size from the SoC NAND boot strap setting. It is commonly used by the BCMBCA SoC board design. Hope this make everyone happy and we can move forward. >>> + This is commonly used by the BCMBCA SoC board design. >>> + $ref: /schemas/types.yaml#/definitions/flag >>> + >>> unevaluatedProperties: false >>> >>> allOf: >>> -- >>> 2.37.3 >>> > > > Thanks, > Miquèl
Hi William, william.zhang@broadcom.com wrote on Mon, 5 Feb 2024 10:05:14 -0800: > Hi Miquel, > > On 2/5/24 05:26, Miquel Raynal wrote: > > Hi, > > > > conor@kernel.org wrote on Sat, 3 Feb 2024 14:49:50 +0000: > > > >> On Fri, Feb 02, 2024 at 04:28:24PM -0800, William Zhang wrote: > >>> Add brcm,nand-ecc-use-strap to get ecc and spare area size settings from > >>> board boot strap for broadband board designs because they do not specify > >>> ecc setting in dts but rather using the strap setting. > >>> > >>> Signed-off-by: William Zhang <william.zhang@broadcom.com> > >>> > >>> --- > >>> > >>> Changes in v4: > >>> - Move ecc strap property to this separate patch and remove some > >>> non-binding related text from the description > >>> > >>> Changes in v3: None > >>> Changes in v2: None > >>> > >>> Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml | 8 ++++++++ > >>> 1 file changed, 8 insertions(+) > >>> > >>> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml > >>> index d0168d55c73e..2599d902ec3a 100644 > >>> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml > >>> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml > >>> @@ -147,6 +147,14 @@ patternProperties: > >>> layout. > >>> $ref: /schemas/types.yaml#/definitions/uint32 > >>> >>> + brcm,nand-ecc-use-strap: > >>> + description: > >>> + This flag indicates the ecc strength and spare area size should > >>> + be retrieved from the SoC NAND boot strap setting instead of > >>> + nand-ecc-strength and brcm,nand-oob-sector-size or auto detection. > >> > >> I'm still on the fence about this being overly prescriptive about the > >> operating systems behaviour. I think it would be good to say why the > >> strap values are better than those explicitly provided in DT rather than > >> just saying "these strap values should be used". > > > > I don't know if there is a point is saying why they would be better, as > > they are not. It is a -questionable- design choice. However I would > > just get rid of any mention to other properties. Just say one should > > expect the strap value to be read and applied by the system when this > > property is present. > > > Agree we don't need to say which is better as it is just a design choice. And it is used by all BCMBCA internal ref boards and customer designs. But if we just say strap value is read and applied, it is vague and nobody would know what is applied. I replied this email yesterday and suggest the followings: > > This property provides a choice for retrieving ecc strength and spare area size from the SoC NAND boot strap setting. It is commonly used by the BCMBCA SoC board design. What about: This property requires the host system to get the ECC strength and step size from the SoC NAND boot strap setting. This is a common hardware design on BCMBCA based boards. I would also like to constrain this more by adding an exclusive use wrt the nand-ecc-* properties. So either you put this property, or you put the generic nand-ecc-* properties, or you put nothing (which, again, is by far the best solution), but in no case you can have a mix. > > Hope this make everyone happy and we can move forward. I was advising to avoid mentioning too specific DT properties, but mentioning the kind of impact it has (on the choice for the ECC strength and size) is fine. > > > >>> + This is commonly used by the BCMBCA SoC board design. > >>> + $ref: /schemas/types.yaml#/definitions/flag > >>> + > >>> unevaluatedProperties: false > >>> >>> allOf: > >>> -- >>> 2.37.3 > >>> > > > > Thanks, > > Miquèl Thanks, Miquèl
On 2/6/24 01:34, Miquel Raynal wrote: > Hi William, > > william.zhang@broadcom.com wrote on Mon, 5 Feb 2024 10:05:14 -0800: > >> Hi Miquel, >> >> On 2/5/24 05:26, Miquel Raynal wrote: >>> Hi, >>> >>> conor@kernel.org wrote on Sat, 3 Feb 2024 14:49:50 +0000: >>> >>>> On Fri, Feb 02, 2024 at 04:28:24PM -0800, William Zhang wrote: >>>>> Add brcm,nand-ecc-use-strap to get ecc and spare area size settings from >>>>> board boot strap for broadband board designs because they do not specify >>>>> ecc setting in dts but rather using the strap setting. >>>>> >>>>> Signed-off-by: William Zhang <william.zhang@broadcom.com> >>>>> >>>>> --- >>>>> >>>>> Changes in v4: >>>>> - Move ecc strap property to this separate patch and remove some >>>>> non-binding related text from the description >>>>> >>>>> Changes in v3: None >>>>> Changes in v2: None >>>>> >>>>> Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml | 8 ++++++++ >>>>> 1 file changed, 8 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml >>>>> index d0168d55c73e..2599d902ec3a 100644 >>>>> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml >>>>> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml >>>>> @@ -147,6 +147,14 @@ patternProperties: >>>>> layout. >>>>> $ref: /schemas/types.yaml#/definitions/uint32 >>>>> >>> + brcm,nand-ecc-use-strap: >>>>> + description: >>>>> + This flag indicates the ecc strength and spare area size should >>>>> + be retrieved from the SoC NAND boot strap setting instead of >>>>> + nand-ecc-strength and brcm,nand-oob-sector-size or auto detection. >>>> >>>> I'm still on the fence about this being overly prescriptive about the >>>> operating systems behaviour. I think it would be good to say why the >>>> strap values are better than those explicitly provided in DT rather than >>>> just saying "these strap values should be used". >>> >>> I don't know if there is a point is saying why they would be better, as >>> they are not. It is a -questionable- design choice. However I would >>> just get rid of any mention to other properties. Just say one should >>> expect the strap value to be read and applied by the system when this >>> property is present. >>> >> Agree we don't need to say which is better as it is just a design choice. And it is used by all BCMBCA internal ref boards and customer designs. But if we just say strap value is read and applied, it is vague and nobody would know what is applied. I replied this email yesterday and suggest the followings: >> >> This property provides a choice for retrieving ecc strength and spare area size from > the SoC NAND boot strap setting. It is commonly used by the BCMBCA SoC board design. > > What about: > > This property requires the host system to get the ECC strength and step > size from the SoC NAND boot strap setting. This is a common hardware > design on BCMBCA based boards. > Sounds good. Will update. > I would also like to constrain this more by adding an exclusive use wrt > the nand-ecc-* properties. So either you put this property, or you put > the generic nand-ecc-* properties, or you put nothing (which, again, is > by far the best solution), but in no case you can have a mix. > Right, nobody should have a mix but in case it happens, the driver code handles that well by taking nand-ecc-* property. So not sure if the exclusion check is really important. Anyway I will add a condition check in the yaml on them as you requested. >> >> Hope this make everyone happy and we can move forward. > > I was advising to avoid mentioning too specific DT properties, but > mentioning the kind of impact it has (on the choice for the ECC > strength and size) is fine. > >> >> >>>>> + This is commonly used by the BCMBCA SoC board design. >>>>> + $ref: /schemas/types.yaml#/definitions/flag >>>>> + >>>>> unevaluatedProperties: false >>>>> >>> allOf: >>>>> -- >>> 2.37.3 >>>>> > > >>> Thanks, >>> Miquèl > > > Thanks, > Miquèl
diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml index d0168d55c73e..2599d902ec3a 100644 --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml @@ -147,6 +147,14 @@ patternProperties: layout. $ref: /schemas/types.yaml#/definitions/uint32 + brcm,nand-ecc-use-strap: + description: + This flag indicates the ecc strength and spare area size should + be retrieved from the SoC NAND boot strap setting instead of + nand-ecc-strength and brcm,nand-oob-sector-size or auto detection. + This is commonly used by the BCMBCA SoC board design. + $ref: /schemas/types.yaml#/definitions/flag + unevaluatedProperties: false allOf:
Add brcm,nand-ecc-use-strap to get ecc and spare area size settings from board boot strap for broadband board designs because they do not specify ecc setting in dts but rather using the strap setting. Signed-off-by: William Zhang <william.zhang@broadcom.com> --- Changes in v4: - Move ecc strap property to this separate patch and remove some non-binding related text from the description Changes in v3: None Changes in v2: None Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml | 8 ++++++++ 1 file changed, 8 insertions(+)