[Adding Masahiro and Michael] On Tue, Nov 15, 2016 at 9:55 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> > 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@xxxxxxxxxxxxx> > Acked-by: Michael Turquette <mturquette@xxxxxxxxxxxx> > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
