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

[Russell King - ARM Linux]

On Tue, Nov 15, 2016 at 01:39:42PM -0800, Tim Harvey wrote:
> On Tue, Nov 15, 2016 at 1:35 PM, Russell King - ARM Linux
> <linux at armlinux.org.uk> wrote:
> > On Tue, Nov 15, 2016 at 12:27:53PM -0800, Tim Harvey wrote:
> >> On Mon, Nov 14, 2016 at 11:08 AM, Russell King - ARM Linux
> >> <linux at armlinux.org.uk> wrote:
> >> > 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.
> >>
> >> >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?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.