specifying order of /dev/mmcblk devices via device-tree?

On 2016-11-15 15:55, Russell King - ARM Linux wrote:

On Tue, Nov 15, 2016 at 10:10:02PM +0000, Russell King - ARM Linux wrote:

quoted

On Tue, Nov 15, 2016 at 01:39:42PM -0800, Tim Harvey wrote:

quoted

On Tue, Nov 15, 2016 at 1:35 PM, Russell King - ARM Linux
[off-list ref] wrote:

quoted

On Tue, Nov 15, 2016 at 12:27:53PM -0800, Tim Harvey wrote:

quoted

On Mon, Nov 14, 2016 at 11:08 AM, Russell King - ARM Linux
[off-list ref] wrote:

quoted

So, someone merged a patch which makes mmcblk devices follow the
host controller numbering.

Now my cubox-i fails to boot correctly because the SD card in the
_only_ SD card slot now gets called "mmcblk1" and not "mmcblk0".

USDHC1 is wired to the on-microsom WiFi, and never has anything
remotely near a SD card or eMMC present.  So, this change is
confusing on these platforms.

Moreover, this is _going_ to break SolidRun distros if people upgrade
their kernels.

It may be appropriate for eMMC, but it's not appropriate everywhere.

This is a user visible _regression_ in 4.9-rc.  Whoever did this,
please revert whatever change caused this, and next time limit it
to only eMMC.

Thanks.

I see the same thing on newer kernels, which is why I asked the
question. I didn't expect (or even want honestly) a non mmcblk0 boot
device and was looking for a way to control that via dt. Now I'm
understanding that to avoid this kind of bootloader/kernel dependence
issue I should be using UUID's to identify the boot device.

quoted

From my testing it looks like the change your looking for occurred

some time ago and is somewhere between 4.5 and 4.6 and not a 4.9
regression specifically.

That depends how you look at it.  Yes, there's a change in 4.5 to 4.6
which ties the block device number to the host device index, but that's
really only part of the story here.

4.8 definitely identifies the SD card in iMX6 usdhc2 as "mmcblk0".
4.9-rc identifies the SD card as "mmcblk1".  This makes it a 4.9 change
of behaviour - there can be no argument about that.

Now, digging further into this today, it appears that:

v4.8: usdhc2 was probed first, and is given mmc0.
      usdhc1 is probed second, and is given mmc1.

v4.9-rc: usdhc1 is probed first, and is given mmc0.
         usdhc2 is probed second, and is given mmc1.

I haven't yet been able to figure out why there's been this change
of probe order.  There's no change that I can see in the iMX6 DT
files that would account for this.

I bisected it and the commit your looking for is
9aaf3437aa72ed5370bf32c99580a3fa2c330e3d

No it's not.

Let me try and put it plainer:

* Commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d ties the mmc block
  device number (mmcblkN) to the mmc host interface number (mmcN).
  This change happened between 4.5 and 4.6.

* The change I'm seeing happened between 4.8 and 4.9-rc.  I'm not
  seeing a change of behaviour between 4.5 and 4.6.

* The change I'm seeing changes the order of the physical device
  associated with the hosts named mmc0 and mmc1 in the kernel.

* Because physical devices associated with the mmc0 and mmc1 hosts
  swap over, the mmcblkN number changes due to the commit you point
  out.

* So, the change that I'm seeing between 4.8 and 4.9-rc is not caused
  by commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d, but by something
  else changing the order in which the two usdhc physical hardware
  blocks get probed.

Does this make it clearer?

It turns out to be this commit:

commit 6eb1c9496b81680f2cd2e0eda06c531317e2e28d
Author: Masahiro Yamada [off-list ref]
Date:   Mon Sep 19 01:16:44 2016 +0900

    clk: probe common clock drivers earlier

    Several SoCs implement platform drivers for clocks rather than
    CLK_OF_DECLARE().  Clocks should come earlier because they are
    prerequisites for many of other drivers.  It will help to mitigate
    EPROBE_DEFER issues.

    Also, drop the comment since it does not carry much value.

    Signed-off-by: Masahiro Yamada [off-list ref]
    Acked-by: Michael Turquette [off-list ref]
    Signed-off-by: Greg Kroah-Hartman [off-list ref]

which changes the init order.  In 4.8, we get:

Afaik, init order is not guaranteed, it never was. Usually the order
ends up to be in some order of the device tree, but one could also parse
the device tree in reverse order (which would be an interesting
experiment).

If we want to rely on ordering, we need to add alias support.

--
Stefan