<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/Documentation/devicetree/bindings/mtd/nand-controller-legacy.yaml, branch master</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>dt-bindings: mtd: refactor NAND bindings and add nand-controller-legacy.yaml</title>
<updated>2026-03-25T14:28:41+00:00</updated>
<author>
<name>Frank Li</name>
<email>Frank.Li@nxp.com</email>
</author>
<published>2026-03-24T22:16:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0ba8da2f318efc006ae5c080a4abfbabb5d110e2'/>
<id>0ba8da2f318efc006ae5c080a4abfbabb5d110e2</id>
<content type='text'>
The modern NAND controller binding requires NAND chips to be described as
child nodes of the controller, for example:

  nand-controller {
          ...
          nand@0 {
                  /* raw NAND chip properties */
          };
  };

However, many existing device trees place NAND chip properties directly
within the controller node because those controllers support only a single
chip. This layout is still widely used by older platforms and by other DT
consumers such as U-Boot. Migrating all existing users to the new layout
will take time.

Several kernel drivers, such as ams-delta.c, davinci_nand.c and
fsmc_nand.c, still expect the legacy layout where raw NAND properties are
defined in the controller node.

To support both layouts during the transition:

- Extract NAND chip-related properties into separate schemas
  (nand-property.yaml and raw-nand-property.yaml) from
  nand-chip.yaml and raw-nand-chip.yaml.
- Introduce nand-controller-legacy.yaml to allow both the
  legacy and modern layouts.
- Add a select condition in nand-controller.yaml to prevent
  node name pattern matching for fsl,* NAND controllers.

Keep compatibility with existing device trees while allowing gradual
migration to the modern binding structure.

Signed-off-by: Frank Li &lt;Frank.Li@nxp.com&gt;
Reviewed-by: Rob Herring (Arm) &lt;robh@kernel.org&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The modern NAND controller binding requires NAND chips to be described as
child nodes of the controller, for example:

  nand-controller {
          ...
          nand@0 {
                  /* raw NAND chip properties */
          };
  };

However, many existing device trees place NAND chip properties directly
within the controller node because those controllers support only a single
chip. This layout is still widely used by older platforms and by other DT
consumers such as U-Boot. Migrating all existing users to the new layout
will take time.

Several kernel drivers, such as ams-delta.c, davinci_nand.c and
fsmc_nand.c, still expect the legacy layout where raw NAND properties are
defined in the controller node.

To support both layouts during the transition:

- Extract NAND chip-related properties into separate schemas
  (nand-property.yaml and raw-nand-property.yaml) from
  nand-chip.yaml and raw-nand-chip.yaml.
- Introduce nand-controller-legacy.yaml to allow both the
  legacy and modern layouts.
- Add a select condition in nand-controller.yaml to prevent
  node name pattern matching for fsl,* NAND controllers.

Keep compatibility with existing device trees while allowing gradual
migration to the modern binding structure.

Signed-off-by: Frank Li &lt;Frank.Li@nxp.com&gt;
Reviewed-by: Rob Herring (Arm) &lt;robh@kernel.org&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
