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

Tue Nov 15 16:33:19 PST 2016

[Adding Masahiro and Michael]

On Tue, Nov 15, 2016 at 9:55 PM, Russell King - ARM Linux
<linux at armlinux.org.uk> wrote:
> On Tue, Nov 15, 2016 at 10:10:02PM +0000, Russell King - ARM Linux wrote:
>> 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?
>
> It turns out to be this commit:
>
> commit 6eb1c9496b81680f2cd2e0eda06c531317e2e28d
> Author: Masahiro Yamada <yamada.masahiro at socionext.com>
> 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 <yamada.masahiro at socionext.com>
>     Acked-by: Michael Turquette <mturquette at baylibre.com>
>     Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
>
> which changes the init order.  In 4.8, we get:
>
> calling  mmc_pwrseq_simple_driver_init+0x0/0x20 @ 1
> bus: 'platform': driver_probe_device: matched device usdhc1_pwrseq with driver pwrseq_simple
> bus: 'platform': really_probe: probing driver pwrseq_simple with device usdhc1_pwrseq
> platform usdhc1_pwrseq: Driver pwrseq_simple requests probe deferral
> platform usdhc1_pwrseq: Added to deferred list
> initcall mmc_pwrseq_simple_driver_init+0x0/0x20 returned 0 after 737 usecs
>
> which then goes on to cause:
>
> calling  sdhci_esdhc_imx_driver_init+0x0/0x20 @ 1
> bus: 'platform': driver_probe_device: matched device 2190000.usdhc with driver sdhci-esdhc-imx
> bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2190000.usdhc
> platform 2190000.usdhc: Driver sdhci-esdhc-imx requests probe deferral
> platform 2190000.usdhc: Added to deferred list
>
> followed by:
>
> bus: 'platform': driver_probe_device: matched device 2194000.usdhc with driver sdhci-esdhc-imx
> bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2194000.usdhc
> sdhci-esdhc-imx 2194000.usdhc: Got CD GPIO
> driver: 'sdhci-esdhc-imx': driver_bound: bound to device '2194000.usdhc'
> bus: 'platform': really_probe: bound device 2194000.usdhc to driver sdhci-esdhc-imx
> initcall sdhci_esdhc_imx_driver_init+0x0/0x20 returned 0 after 58205 usecs
>
> and eventually:
>
> mmc0: host does not support reading read-only switch, assuming write-enable
> mmc0: new ultra high speed SDR104 SDHC card at address 0001
> mmcblk0: mmc0:0001 00000 14.9 GiB
>  mmcblk0: p1 p2
>
> In 4.9-rc5, we instead get:
>
> calling  gpio_clk_driver_init+0x0/0x20 @ 1
> bus: 'platform': driver_probe_device: matched device sdio-clock with driver gpio-clk
> bus: 'platform': really_probe: probing driver gpio-clk with device sdio-clock
> driver: 'gpio-clk': driver_bound: bound to device 'sdio-clock'
> bus: 'platform': really_probe: bound device sdio-clock to driver gpio-clk
> ...
> calling  mmc_pwrseq_simple_driver_init+0x0/0x20 @ 1
> bus: 'platform': driver_probe_device: matched device usdhc1_pwrseq with driver pwrseq_simple
> bus: 'platform': really_probe: probing driver pwrseq_simple with device usdhc1_pwrseq
> driver: 'pwrseq_simple': driver_bound: bound to device 'usdhc1_pwrseq'
> bus: 'platform': really_probe: bound device usdhc1_pwrseq to driver pwrseq_simple
> initcall mmc_pwrseq_simple_driver_init+0x0/0x20 returned 0 after 876 usecs
> ...
> calling  sdhci_esdhc_imx_driver_init+0x0/0x20 @ 1
> bus: 'platform': driver_probe_device: matched device 2190000.usdhc with driver sdhci-esdhc-imx
> bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2190000.usdhc
> sdhci-esdhc-imx 2190000.usdhc: allocated mmc-pwrseq
> driver: 'sdhci-esdhc-imx': driver_bound: bound to device '2190000.usdhc'
> bus: 'platform': really_probe: bound device 2190000.usdhc to driver sdhci-esdhc-imx
> bus: 'platform': driver_probe_device: matched device 2194000.usdhc with driver sdhci-esdhc-imx
> bus: 'platform': really_probe: probing driver sdhci-esdhc-imx with device 2194000.usdhc
> driver: 'sdhci-esdhc-imx': driver_bound: bound to device '2194000.usdhc'
> bus: 'platform': really_probe: bound device 2194000.usdhc to driver sdhci-esdhc-imx
> initcall sdhci_esdhc_imx_driver_init+0x0/0x20 returned 0 after 384864 usecs
> ...
> mmc1: host does not support reading read-only switch, assuming write-enable
> mmc1: new ultra high speed SDR104 SDHC card at address 0001
> mmcblk1: mmc1:0001 00000 14.9 GiB
>  mmcblk1: p1 p2
>
>
> --
> 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.
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html