[PATCH v2 12/12] dt-bindings: mtd: raw-nand-chip: Relax node name pattern

[J. Neuschäfer]

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 at 1,0: $nodename:0: 'nand at 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 at 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 at 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 at 100000000 instead of nand at 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