* specifying order of /dev/mmcblk devices via device-tree?
@ 2016-10-28 15:23 Tim Harvey
2016-10-28 15:33 ` Fabio Estevam
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Tim Harvey @ 2016-10-28 15:23 UTC (permalink / raw)
To: linux-arm-kernel
Greetings,
I have an IMX6 board that has the following:
sdhc1: mmc0: sdio radio
sdhc2: mmc1: /dev/mmcblk1: microSD connector
sdhc3: mmc2: /dev/mmcblk2: on-board eMMC
I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2
registered as /dev/mmcblk1 so that permanent storage is the first
mmcblk device as I think this is more intuitive however currently
these get instanced in the order they appear in the imx6qdl.dtsi
device-tree configuration and are not able to be mapped the way I want
them in my dts file.
Is there a way, or if not is there a desire for a way, to specify the
order of /dev/mmcblk devices via device-tree?
Regards,
Tim
^ permalink raw reply [flat|nested] 15+ messages in thread* specifying order of /dev/mmcblk devices via device-tree? 2016-10-28 15:23 specifying order of /dev/mmcblk devices via device-tree? Tim Harvey @ 2016-10-28 15:33 ` Fabio Estevam 2016-10-28 15:37 ` Javier Martinez Canillas 2016-10-28 15:37 ` Mark Rutland 2 siblings, 0 replies; 15+ messages in thread From: Fabio Estevam @ 2016-10-28 15:33 UTC (permalink / raw) To: linux-arm-kernel Hi Tim, On Fri, Oct 28, 2016 at 1:23 PM, Tim Harvey <tharvey@gateworks.com> wrote: > Greetings, > > I have an IMX6 board that has the following: > sdhc1: mmc0: sdio radio > sdhc2: mmc1: /dev/mmcblk1: microSD connector > sdhc3: mmc2: /dev/mmcblk2: on-board eMMC > > I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2 > registered as /dev/mmcblk1 so that permanent storage is the first > mmcblk device as I think this is more intuitive however currently > these get instanced in the order they appear in the imx6qdl.dtsi > device-tree configuration and are not able to be mapped the way I want > them in my dts file. > > Is there a way, or if not is there a desire for a way, to specify the > order of /dev/mmcblk devices via device-tree? You could use UUID to specify the rootfs location on your board. Please check: http://git.denx.de/?p=u-boot.git;a=commit;h=ca4f338e2efece5196eb2178e5f7d07be828da6e ^ permalink raw reply [flat|nested] 15+ messages in thread
* specifying order of /dev/mmcblk devices via device-tree? 2016-10-28 15:23 specifying order of /dev/mmcblk devices via device-tree? Tim Harvey 2016-10-28 15:33 ` Fabio Estevam @ 2016-10-28 15:37 ` Javier Martinez Canillas 2016-10-28 15:37 ` Mark Rutland 2 siblings, 0 replies; 15+ messages in thread From: Javier Martinez Canillas @ 2016-10-28 15:37 UTC (permalink / raw) To: linux-arm-kernel Hello Tim, On Fri, Oct 28, 2016 at 12:23 PM, Tim Harvey <tharvey@gateworks.com> wrote: > Greetings, > > I have an IMX6 board that has the following: > sdhc1: mmc0: sdio radio > sdhc2: mmc1: /dev/mmcblk1: microSD connector > sdhc3: mmc2: /dev/mmcblk2: on-board eMMC > > I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2 > registered as /dev/mmcblk1 so that permanent storage is the first > mmcblk device as I think this is more intuitive however currently > these get instanced in the order they appear in the imx6qdl.dtsi > device-tree configuration and are not able to be mapped the way I want > them in my dts file. > One should not rely on a specific MMC block device numbering, since this could change. Look at commit 9aaf3437aa72 ("mmc: block: Use the mmc host device index as the mmcblk device index"). > Is there a way, or if not is there a desire for a way, to specify the > order of /dev/mmcblk devices via device-tree? > There was an attempt to use aliasses for this but got nacked: https://lkml.org/lkml/2016/4/29/610 As Fabio said, you should either use UUID or labels instead: https://wiki.archlinux.org/index.php/persistent_block_device_naming > Regards, > > Tim > Best regards, Javier ^ permalink raw reply [flat|nested] 15+ messages in thread
* specifying order of /dev/mmcblk devices via device-tree? 2016-10-28 15:23 specifying order of /dev/mmcblk devices via device-tree? Tim Harvey 2016-10-28 15:33 ` Fabio Estevam 2016-10-28 15:37 ` Javier Martinez Canillas @ 2016-10-28 15:37 ` Mark Rutland 2016-10-28 16:45 ` Tim Harvey 2016-11-16 14:45 ` Ulf Hansson 2 siblings, 2 replies; 15+ messages in thread From: Mark Rutland @ 2016-10-28 15:37 UTC (permalink / raw) To: linux-arm-kernel On Fri, Oct 28, 2016 at 08:23:04AM -0700, Tim Harvey wrote: > Greetings, > > I have an IMX6 board that has the following: > sdhc1: mmc0: sdio radio > sdhc2: mmc1: /dev/mmcblk1: microSD connector > sdhc3: mmc2: /dev/mmcblk2: on-board eMMC > > I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2 > registered as /dev/mmcblk1 so that permanent storage is the first > mmcblk device as I think this is more intuitive however currently > these get instanced in the order they appear in the imx6qdl.dtsi > device-tree configuration and are not able to be mapped the way I want > them in my dts file. > > Is there a way, or if not is there a desire for a way, to specify the > order of /dev/mmcblk devices via device-tree? As with many other devices, there is no standard way of controlling the Linux enumeration (and given the ID space is shared with other dynamic devices it's not something that could generally work). These should be refererd to by UUID if possible. If not, we could cosider adding a by-dt-path or something like that. Thanks, Mark. ^ permalink raw reply [flat|nested] 15+ messages in thread
* specifying order of /dev/mmcblk devices via device-tree? 2016-10-28 15:37 ` Mark Rutland @ 2016-10-28 16:45 ` Tim Harvey 2016-11-14 19:08 ` Russell King - ARM Linux 2016-11-16 14:45 ` Ulf Hansson 1 sibling, 1 reply; 15+ messages in thread From: Tim Harvey @ 2016-10-28 16:45 UTC (permalink / raw) To: linux-arm-kernel On Fri, Oct 28, 2016 at 8:37 AM, Mark Rutland <mark.rutland@arm.com> wrote: > On Fri, Oct 28, 2016 at 08:23:04AM -0700, Tim Harvey wrote: >> Greetings, >> >> I have an IMX6 board that has the following: >> sdhc1: mmc0: sdio radio >> sdhc2: mmc1: /dev/mmcblk1: microSD connector >> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC >> >> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2 >> registered as /dev/mmcblk1 so that permanent storage is the first >> mmcblk device as I think this is more intuitive however currently >> these get instanced in the order they appear in the imx6qdl.dtsi >> device-tree configuration and are not able to be mapped the way I want >> them in my dts file. >> >> Is there a way, or if not is there a desire for a way, to specify the >> order of /dev/mmcblk devices via device-tree? > > As with many other devices, there is no standard way of controlling the > Linux enumeration (and given the ID space is shared with other dynamic > devices it's not something that could generally work). > > These should be refererd to by UUID if possible. > > If not, we could cosider adding a by-dt-path or something like that. > > Thanks, > Mark. Mark / Javier/ Fabio, Thanks - this is very useful. Yes, I agree that using UUID's is the way to go and now I see how that can be easily accessed via uboot 'part' command. Regards, Tim ^ permalink raw reply [flat|nested] 15+ messages in thread
* specifying order of /dev/mmcblk devices via device-tree? 2016-10-28 16:45 ` Tim Harvey @ 2016-11-14 19:08 ` Russell King - ARM Linux 2016-11-15 20:27 ` Tim Harvey 0 siblings, 1 reply; 15+ messages in thread From: Russell King - ARM Linux @ 2016-11-14 19:08 UTC (permalink / raw) To: linux-arm-kernel 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. On Fri, Oct 28, 2016 at 09:45:00AM -0700, Tim Harvey wrote: > On Fri, Oct 28, 2016 at 8:37 AM, Mark Rutland <mark.rutland@arm.com> wrote: > > On Fri, Oct 28, 2016 at 08:23:04AM -0700, Tim Harvey wrote: > >> Greetings, > >> > >> I have an IMX6 board that has the following: > >> sdhc1: mmc0: sdio radio > >> sdhc2: mmc1: /dev/mmcblk1: microSD connector > >> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC > >> > >> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2 > >> registered as /dev/mmcblk1 so that permanent storage is the first > >> mmcblk device as I think this is more intuitive however currently > >> these get instanced in the order they appear in the imx6qdl.dtsi > >> device-tree configuration and are not able to be mapped the way I want > >> them in my dts file. > >> > >> Is there a way, or if not is there a desire for a way, to specify the > >> order of /dev/mmcblk devices via device-tree? > > > > As with many other devices, there is no standard way of controlling the > > Linux enumeration (and given the ID space is shared with other dynamic > > devices it's not something that could generally work). > > > > These should be refererd to by UUID if possible. > > > > If not, we could cosider adding a by-dt-path or something like that. > > > > Thanks, > > Mark. > > Mark / Javier/ Fabio, > > Thanks - this is very useful. > > Yes, I agree that using UUID's is the way to go and now I see how that > can be easily accessed via uboot 'part' command. > > Regards, > > Tim > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* specifying order of /dev/mmcblk devices via device-tree? 2016-11-14 19:08 ` Russell King - ARM Linux @ 2016-11-15 20:27 ` Tim Harvey 2016-11-15 21:35 ` Russell King - ARM Linux 0 siblings, 1 reply; 15+ messages in thread From: Tim Harvey @ 2016-11-15 20:27 UTC (permalink / raw) To: linux-arm-kernel On Mon, Nov 14, 2016 at 11:08 AM, Russell King - ARM Linux <linux@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. Regards, Tim ^ permalink raw reply [flat|nested] 15+ messages in thread
* specifying order of /dev/mmcblk devices via device-tree? 2016-11-15 20:27 ` Tim Harvey @ 2016-11-15 21:35 ` Russell King - ARM Linux 2016-11-15 21:39 ` Tim Harvey 0 siblings, 1 reply; 15+ messages in thread From: Russell King - ARM Linux @ 2016-11-15 21:35 UTC (permalink / raw) To: linux-arm-kernel 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@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. -- 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* specifying order of /dev/mmcblk devices via device-tree? 2016-11-15 21:35 ` Russell King - ARM Linux @ 2016-11-15 21:39 ` Tim Harvey 2016-11-15 22:10 ` Russell King - ARM Linux 0 siblings, 1 reply; 15+ messages in thread From: Tim Harvey @ 2016-11-15 21:39 UTC (permalink / raw) To: linux-arm-kernel On Tue, Nov 15, 2016 at 1:35 PM, Russell King - ARM Linux <linux@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@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 Tim ^ permalink raw reply [flat|nested] 15+ messages in thread
* specifying order of /dev/mmcblk devices via device-tree? 2016-11-15 21:39 ` Tim Harvey @ 2016-11-15 22:10 ` Russell King - ARM Linux 2016-11-15 23:55 ` Russell King - ARM Linux 0 siblings, 1 reply; 15+ messages in thread From: Russell King - ARM Linux @ 2016-11-15 22:10 UTC (permalink / raw) To: linux-arm-kernel 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@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@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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* specifying order of /dev/mmcblk devices via device-tree? 2016-11-15 22:10 ` Russell King - ARM Linux @ 2016-11-15 23:55 ` Russell King - ARM Linux 2016-11-16 0:33 ` Fabio Estevam 2016-11-19 1:18 ` Stefan Agner 0 siblings, 2 replies; 15+ messages in thread From: Russell King - ARM Linux @ 2016-11-15 23:55 UTC (permalink / raw) To: linux-arm-kernel 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@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@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@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@socionext.com> Acked-by: Michael Turquette <mturquette@baylibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh@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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* specifying order of /dev/mmcblk devices via device-tree? 2016-11-15 23:55 ` Russell King - ARM Linux @ 2016-11-16 0:33 ` Fabio Estevam 2016-11-19 1:18 ` Stefan Agner 1 sibling, 0 replies; 15+ messages in thread From: Fabio Estevam @ 2016-11-16 0:33 UTC (permalink / raw) To: linux-arm-kernel [Adding Masahiro and Michael] On Tue, Nov 15, 2016 at 9:55 PM, Russell King - ARM Linux <linux@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@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@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@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@socionext.com> > Acked-by: Michael Turquette <mturquette@baylibre.com> > Signed-off-by: Greg Kroah-Hartman <gregkh@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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* specifying order of /dev/mmcblk devices via device-tree? 2016-11-15 23:55 ` Russell King - ARM Linux 2016-11-16 0:33 ` Fabio Estevam @ 2016-11-19 1:18 ` Stefan Agner 1 sibling, 0 replies; 15+ messages in thread From: Stefan Agner @ 2016-11-19 1:18 UTC (permalink / raw) To: linux-arm-kernel 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: >> 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@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@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@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@socionext.com> > Acked-by: Michael Turquette <mturquette@baylibre.com> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* specifying order of /dev/mmcblk devices via device-tree? 2016-10-28 15:37 ` Mark Rutland 2016-10-28 16:45 ` Tim Harvey @ 2016-11-16 14:45 ` Ulf Hansson 2016-11-19 1:23 ` Stefan Agner 1 sibling, 1 reply; 15+ messages in thread From: Ulf Hansson @ 2016-11-16 14:45 UTC (permalink / raw) To: linux-arm-kernel On 28 October 2016 at 17:37, Mark Rutland <mark.rutland@arm.com> wrote: > On Fri, Oct 28, 2016 at 08:23:04AM -0700, Tim Harvey wrote: >> Greetings, >> >> I have an IMX6 board that has the following: >> sdhc1: mmc0: sdio radio >> sdhc2: mmc1: /dev/mmcblk1: microSD connector >> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC >> >> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2 >> registered as /dev/mmcblk1 so that permanent storage is the first >> mmcblk device as I think this is more intuitive however currently >> these get instanced in the order they appear in the imx6qdl.dtsi >> device-tree configuration and are not able to be mapped the way I want >> them in my dts file. >> >> Is there a way, or if not is there a desire for a way, to specify the >> order of /dev/mmcblk devices via device-tree? > > As with many other devices, there is no standard way of controlling the > Linux enumeration (and given the ID space is shared with other dynamic > devices it's not something that could generally work). > > These should be refererd to by UUID if possible. > > If not, we could cosider adding a by-dt-path or something like that. So does that mean you think using "DT aliases" would be okay? As Javier pointed out, there have been some attempts [1] for that, but they didn't make it. Perhaps we need to re-consider, and if so please re-review the DT bindings patch from that series. Kind regards Uffe [1] https://lkml.org/lkml/2016/4/29/610 or http://www.spinics.net/lists/linux-mmc/msg36701.html ^ permalink raw reply [flat|nested] 15+ messages in thread
* specifying order of /dev/mmcblk devices via device-tree? 2016-11-16 14:45 ` Ulf Hansson @ 2016-11-19 1:23 ` Stefan Agner 0 siblings, 0 replies; 15+ messages in thread From: Stefan Agner @ 2016-11-19 1:23 UTC (permalink / raw) To: linux-arm-kernel On 2016-11-16 06:45, Ulf Hansson wrote: > On 28 October 2016 at 17:37, Mark Rutland <mark.rutland@arm.com> wrote: >> On Fri, Oct 28, 2016 at 08:23:04AM -0700, Tim Harvey wrote: >>> Greetings, >>> >>> I have an IMX6 board that has the following: >>> sdhc1: mmc0: sdio radio >>> sdhc2: mmc1: /dev/mmcblk1: microSD connector >>> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC >>> >>> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2 >>> registered as /dev/mmcblk1 so that permanent storage is the first >>> mmcblk device as I think this is more intuitive however currently >>> these get instanced in the order they appear in the imx6qdl.dtsi >>> device-tree configuration and are not able to be mapped the way I want >>> them in my dts file. >>> >>> Is there a way, or if not is there a desire for a way, to specify the >>> order of /dev/mmcblk devices via device-tree? >> >> As with many other devices, there is no standard way of controlling the >> Linux enumeration (and given the ID space is shared with other dynamic >> devices it's not something that could generally work). >> >> These should be refererd to by UUID if possible. >> >> If not, we could cosider adding a by-dt-path or something like that. > > So does that mean you think using "DT aliases" would be okay? As > Javier pointed out, there have been some attempts [1] for that, but > they didn't make it. > Perhaps we need to re-consider, and if so please re-review the DT > bindings patch from that series. I really would like to see some sort of stable MMC block device ordering. by-dt-path solutions requires initramfs, which adds complexity and boot time. Both not very welcome in simple embedded devices. PARTUUID is relying on a particular instance of a partition, which is not the same as to say boot from the second partition of device X. The main problem I see in my patchset is that it works around the fact MMC is a bus. Adding the mmc controller number to the block device name would avoid that issue (mmc0blk0...), not sure if a such a drastic change would be acceptable. -- Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2016-11-19 1:23 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-10-28 15:23 specifying order of /dev/mmcblk devices via device-tree? Tim Harvey 2016-10-28 15:33 ` Fabio Estevam 2016-10-28 15:37 ` Javier Martinez Canillas 2016-10-28 15:37 ` Mark Rutland 2016-10-28 16:45 ` Tim Harvey 2016-11-14 19:08 ` Russell King - ARM Linux 2016-11-15 20:27 ` Tim Harvey 2016-11-15 21:35 ` Russell King - ARM Linux 2016-11-15 21:39 ` Tim Harvey 2016-11-15 22:10 ` Russell King - ARM Linux 2016-11-15 23:55 ` Russell King - ARM Linux 2016-11-16 0:33 ` Fabio Estevam 2016-11-19 1:18 ` Stefan Agner 2016-11-16 14:45 ` Ulf Hansson 2016-11-19 1:23 ` Stefan Agner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).