| Message ID | 20250207-ppcyaml-v2-12-8137b0c42526@posteo.net (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | YAML conversion of several Freescale/PowerPC DT bindings | expand |
Hello, On 07/02/2025 at 22:30:29 +01, J. Neuschäfer via B4 Relay <devnull+j.ne.posteo.net@kernel.org> wrote: > From: "J. Neuschäfer" <j.ne@posteo.net> > > In some scenarios, such as under the Freescale eLBC bus, there are raw > NAND chips with a unit address that has a comma in it (cs,offset). > Relax the $nodename pattern in raw-nand-chip.yaml to allow such unit > addresses. This is super specific to this controller, I'd rather avoid that in the main (shared) files. I believe you can force another node name in the controller's binding instead? Thanks, Miquèl
On Mon, Feb 10, 2025 at 09:27:22AM +0100, Miquel Raynal wrote: > Hello, > > On 07/02/2025 at 22:30:29 +01, J. Neuschäfer via B4 Relay <devnull+j.ne.posteo.net@kernel.org> wrote: > > > From: "J. Neuschäfer" <j.ne@posteo.net> > > > > In some scenarios, such as under the Freescale eLBC bus, there are raw > > NAND chips with a unit address that has a comma in it (cs,offset). > > Relax the $nodename pattern in raw-nand-chip.yaml to allow such unit > > addresses. > > This is super specific to this controller, I'd rather avoid that in the > main (shared) files. I believe you can force another node name in the > controller's binding instead? It's a bit tricky. AFAICS, when I declare a node name pattern in my specific binding in addition to the generic binding, the result is that both of them apply, so I can't relax stricter requirements: # raw-nand-chip.yaml properties: $nodename: pattern: "^nand@[a-f0-9]$" # fsl,elbc-fcm-nand.yaml properties: $nodename: pattern: "^nand@[a-f0-9](,[0-9a-f]*)?$" # dtc /.../fsl,elbc-fcm-nand.example.dtb: nand@1,0: $nodename:0: 'nand@1,0' does not match '^nand@[a-f0-9]$' from schema $id: http://devicetree.org/schemas/mtd/fsl,elbc-fcm-nand.yaml# (I changed the second pattern to nand-fail@... and dtc warned about it mismatching too.) Perhaps I'm missing a DT-schema trick to override a value/pattern. Alternatively (pending discussion on patch 11/12), I might end up not referencing raw-nand-chip.yaml. Best regards, J. Neuschäfer
Hello, >> > In some scenarios, such as under the Freescale eLBC bus, there are raw >> > NAND chips with a unit address that has a comma in it (cs,offset). >> > Relax the $nodename pattern in raw-nand-chip.yaml to allow such unit >> > addresses. >> >> This is super specific to this controller, I'd rather avoid that in the >> main (shared) files. I believe you can force another node name in the >> controller's binding instead? > > It's a bit tricky. AFAICS, when I declare a node name pattern in my > specific binding in addition to the generic binding, the result is that > both of them apply, so I can't relax stricter requirements: > > # raw-nand-chip.yaml > properties: > $nodename: > pattern: "^nand@[a-f0-9]$" > > # fsl,elbc-fcm-nand.yaml > properties: > $nodename: > pattern: "^nand@[a-f0-9](,[0-9a-f]*)?$" Well, I guess this is creating a second possible node name. > # dtc > /.../fsl,elbc-fcm-nand.example.dtb: > nand@1,0: $nodename:0: 'nand@1,0' does not match '^nand@[a-f0-9]$' > from schema $id: > http://devicetree.org/schemas/mtd/fsl,elbc-fcm-nand.yaml# What about fixing the DT instead? > (I changed the second pattern to nand-fail@... and dtc warned about it > mismatching too.) > > Perhaps I'm missing a DT-schema trick to override a value/pattern. > > Alternatively (pending discussion on patch 11/12), I might end up not > referencing raw-nand-chip.yaml. Ok. Thanks, Miquèl
On Mon, Feb 17, 2025 at 10:31:08AM +0100, Miquel Raynal wrote: > Hello, > > >> > In some scenarios, such as under the Freescale eLBC bus, there are raw > >> > NAND chips with a unit address that has a comma in it (cs,offset). > >> > Relax the $nodename pattern in raw-nand-chip.yaml to allow such unit > >> > addresses. > >> > >> This is super specific to this controller, I'd rather avoid that in the > >> main (shared) files. I believe you can force another node name in the > >> controller's binding instead? > > > > It's a bit tricky. AFAICS, when I declare a node name pattern in my > > specific binding in addition to the generic binding, the result is that > > both of them apply, so I can't relax stricter requirements: > > > > # raw-nand-chip.yaml > > properties: > > $nodename: > > pattern: "^nand@[a-f0-9]$" > > > > # fsl,elbc-fcm-nand.yaml > > properties: > > $nodename: > > pattern: "^nand@[a-f0-9](,[0-9a-f]*)?$" > > Well, I guess this is creating a second possible node name. > > > # dtc > > /.../fsl,elbc-fcm-nand.example.dtb: > > nand@1,0: $nodename:0: 'nand@1,0' does not match '^nand@[a-f0-9]$' > > from schema $id: > > http://devicetree.org/schemas/mtd/fsl,elbc-fcm-nand.yaml# > > What about fixing the DT instead? In this particular context under the Freescale eLBC ("enhanced Local Bus Controller"), nand@1,0 makes complete sense, because it refers to chip select 1, offset 0. The eLBC binding (which has existed without YAML formalization for a long time) specifies that each device address includes a chip select and a base address under that CS. The alternative of spelling it as nand@100000000 makes readability strictly worse (IMO). Due to the conflicting requirements of keeping compatibility with historic device trees and complying with modern DT conventions, I'm already ignoring a validation warning from dtc, which suggests to use nand@100000000 instead of nand@1,0 because the eLBC bus has historically been specified with compatible = ..., "simple-bus", so I guess the fsl,elbc-fcm-nand binding can't be perfect anyway. In any case, I'll drop this patch during further development. Thank you for your inputs, J. Neuschäfer
diff --git a/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml b/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml index 092448d7bfc5ccd246ca4b2341464e18722a2d51..1c9e3a40d8f9f77115525e5a6be0951aae001ae0 100644 --- a/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml +++ b/Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml @@ -25,7 +25,7 @@ description: | properties: $nodename: - pattern: "^nand@[a-f0-9]$" + pattern: "^nand@[a-f0-9](,[0-9a-f]*)?$" reg: description: