Re: sam9x5: MTD numbering changed

Le jeudi 02 novembre 2017 à 13:39 +0100, Boris Brezillon a écrit :

+Nicolas

Hi Richard,

On Thu, 02 Nov 2017 12:17:16 +0100
Richard Genoud [off-list ref] wrote:

quoted

Hi,

I've got an at91sam9g35-cm based board, with 4 partition on the
spi-
dataflas and 5 partitions on the NAND flash.
Before commit 1004a2977bdc ("ARM: dts: at91: Switch to the new NAND
bindings"),
the NAND partitions were mtd0-4 and spi-dataflash partitions mtd5-
8.

Since commit 1004a2977bdc ("ARM: dts: at91: Switch to the new NAND
bindings"),
the spi-dataflash partitions are discovered before the NAND
partitions.
So NAND partition became mtd4-8 and spi-dataflash partition mtd0-3.

This broke some script that relied on the mtd numbering.

Updating those scripts to rely on the mtd device name instead of
number is not really a problem. The real problem is when an older
script using mtd numbering is run on the new system : I expect dead
kittens everywhere !

Crap! That was one of the thing I was afraid of when changing the
binding: probe order has an impact on ids assigned to MTD devs, and
since things are not defined at the same place in the DT, it changes
the probe order.

quoted

So, I'd like to know if there's a way to force the older numbering
?

Reverting the patches is probably the easiest way (and it's easily
backportable). Now, if we want to switch to the new bindings at some
point we'll need to support DT aliases for mtd devs:

aliases {
	mtdX = &flashpartN;
	mtdY = &flashdevM;
};

The problem with this solution is that it only works if all
partitions
are defined in the DT, which is not always the case (they can be
defined
on the command line with mtdparts=).

Yes, and if they are different from the ones declared in
at91sam9x5cm.dtsi, they are likely defined with mtdparts=, since AFAIK,
we can't remove a declared partitionning.

I'll disable the ebi and switch back to the old binding in my dts for
now.

quoted

(I tried poking around the DTS without succès).

any idea ?

I don't have a perfect solution, but the problem you report clearly
shows that relying on MTD numbering is unsafe and should be avoided.

Clearly, but who doesn't ? ;)


Thanks !

Richard.

Regards,

Boris

quoted

regards,
Richard.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html