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
