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

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

[Tim Harvey]

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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tim Harvey]

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

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

[Fabio Estevam]

Hi Tim,

On Fri, Oct 28, 2016 at 1:23 PM, Tim Harvey <tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Fabio Estevam]

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

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

[Javier Martinez Canillas]

Hello Tim,

On Fri, Oct 28, 2016 at 12:23 PM, Tim Harvey <tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Javier Martinez Canillas]

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

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

[Mark Rutland]

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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Rutland]

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.

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

[Tim Harvey]

On Fri, Oct 28, 2016 at 8:37 AM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tim Harvey]

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

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

[Russell King - ARM Linux]

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-5wv7dgnIgG8@public.gmane.org> 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-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Russell King - ARM Linux]

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.

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

[Tim Harvey]

On Mon, Nov 14, 2016 at 11:08 AM, Russell King - ARM Linux
<linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tim Harvey]

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

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

[Russell King - ARM Linux]

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-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> 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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Russell King - ARM Linux]

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.

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

[Tim Harvey]

On Tue, Nov 15, 2016 at 1:35 PM, Russell King - ARM Linux
<linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> 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-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tim Harvey]

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

Re: 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-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> 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-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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@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.

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

[Russell King - ARM Linux]

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-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> 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-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> 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-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
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-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
    Acked-by: Michael Turquette <mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Russell King - ARM Linux]

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.

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

[Fabio Estevam]

[Adding Masahiro and Michael]

On Tue, Nov 15, 2016 at 9:55 PM, Russell King - ARM Linux
<linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> 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-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> 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-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> 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-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> 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-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
>     Acked-by: Michael Turquette <mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>     Signed-off-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Fabio Estevam]

[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

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

[Ulf Hansson]

On 28 October 2016 at 17:37, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Ulf Hansson]

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

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

[Stefan Agner]

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-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> 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-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> 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-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> 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-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
>     Acked-by: Michael Turquette <mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>     Signed-off-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Stefan Agner]

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

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

[Stefan Agner]

On 2016-11-16 06:45, Ulf Hansson wrote:
> On 28 October 2016 at 17:37, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Stefan Agner]

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