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? -- 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
