From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: specifying order of /dev/mmcblk devices via device-tree?
Date: Tue, 15 Nov 2016 23:55:04 +0000 [thread overview]
Message-ID: <20161115235503.GC1041@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20161115221002.GA1041@n2100.armlinux.org.uk>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
To: Tim Harvey <tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>,
Javier Martinez Canillas
<javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: specifying order of /dev/mmcblk devices via device-tree?
Date: Tue, 15 Nov 2016 23:55:04 +0000 [thread overview]
Message-ID: <20161115235503.GC1041@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20161115221002.GA1041-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
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
next prev parent reply other threads:[~2016-11-15 23:55 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-28 15:23 specifying order of /dev/mmcblk devices via device-tree? Tim Harvey
2016-10-28 15:23 ` Tim Harvey
2016-10-28 15:33 ` Fabio Estevam
2016-10-28 15:33 ` Fabio Estevam
2016-10-28 15:37 ` Javier Martinez Canillas
2016-10-28 15:37 ` Javier Martinez Canillas
2016-10-28 15:37 ` Mark Rutland
2016-10-28 15:37 ` Mark Rutland
2016-10-28 16:45 ` Tim Harvey
2016-10-28 16:45 ` Tim Harvey
2016-11-14 19:08 ` Russell King - ARM Linux
2016-11-14 19:08 ` Russell King - ARM Linux
2016-11-15 20:27 ` Tim Harvey
2016-11-15 20:27 ` Tim Harvey
2016-11-15 21:35 ` Russell King - ARM Linux
2016-11-15 21:35 ` Russell King - ARM Linux
2016-11-15 21:39 ` Tim Harvey
2016-11-15 21:39 ` Tim Harvey
2016-11-15 22:10 ` Russell King - ARM Linux
2016-11-15 22:10 ` Russell King - ARM Linux
2016-11-15 23:55 ` Russell King - ARM Linux [this message]
2016-11-15 23:55 ` Russell King - ARM Linux
2016-11-16 0:33 ` Fabio Estevam
2016-11-16 0:33 ` Fabio Estevam
2016-11-19 1:18 ` Stefan Agner
2016-11-19 1:18 ` Stefan Agner
2016-11-16 14:45 ` Ulf Hansson
2016-11-16 14:45 ` Ulf Hansson
2016-11-19 1:23 ` Stefan Agner
2016-11-19 1:23 ` Stefan Agner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161115235503.GC1041@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.