On Thu, 31 May 2018 19:54:08 +0200 Stefan Agner <stefan@xxxxxxxx> wrote: > >> + > >> + mtd->dev.parent = &pdev->dev; > >> + mtd->name = "tegra_nand"; > > > > I just figured it was undocumented (yet) but you could have a label > > string property in your nand DT node that tells you the name of the > > MTD device instead of something too generic like tegra_nand. > > > > Using label in the NAND chip subnode actually causes current U-Boot to > delete (!!) the chip node and create partitions on the controller node. > > See: > https://elixir.bootlin.com/u-boot/latest/source/common/fdt_support.c#L757 > > The code essentially uses the property label to detect whether its a > NAND chip or a partition... Why not fixing that in uboot? The representation where the NAND device and NAND controller are mixed in a single node called nand@xxx is just wrong from a HW PoV, and it seems uboot is using this representation, which is probably why you have a problem when trying to find the partition directly under the NAND controller node. > > At least this is the case when using fdt_fixup_mtdparts and passing the > controller compatible ("nvidia,tegra20-nand") in node_info, Just a digression, but I recommend using "nvidia,tegra20-nand-controller" for the compatible, because the node is describing the NAND controller not the NAND chip. > what our > downstream U-Boot is currently doing. Maybe we should pass the > compatible property of the NAND chip? Or maybe you should search for partitions in children of the controller node instead of searching directly under the controller node itself. > But afaik, chips do not have a > compatible necessarily. Nope, and it should stay like that. > > So using label in the chip node is currently a no-go for me. I hope I'm wrong but I fear this is not the only problem you'll face when switching to a controller+chip representation. This is just the tip of the iceberg. > > Will send out v3 soon. Sure, let's see how v3 looks. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
