[PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Douglas Anderson]

This series picks patches from various different places to produce what
I consider the best solution to getting consistent mmc and mmcblk
ordering.

Why consistent ordering and why not just use UUIDs?  IMHO consistent
ordering solves a few different problems:

1. For poor, feeble-minded humans like me, have sane numbering for
   devices helps a lot.  When grepping through dmesg it's terribly handy
   if a given SDMMC device has a consistent number.  I know that I can
   do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about
   the eMMC.  I know that I can do "dmesg | grep mmc1" to find info
   about the SD card slot.  I don't want it to matter which one probed
   first, I don't want it to matter if I'm working on a variant of the
   hardware that has the SD card slot disabled, and I don't want to care
   what my boot device was.  Worrying about what device number I got
   increases my cognitive load.

2. There are cases where it's not trivially easy during development to
   use the UUID.  Specifically I work a lot with coreboot / depthcharge
   as a BIOS.  When configured properly, that BIOS has a nice feature to
   allow you to fetch the kernel and kernel command line from TFTP by
   pressing Ctrl-N.  In this particular case the BIOS doesn't actually
   know which disk I'd like for my root filesystem, so it's not so easy
   for it to put the right UUID into the command line.  For this
   purpose, knowing that "mmcblk0" will always refer to eMMC is handy.

Changes in v2:
- Rebased atop mmc-next
- Stat dynamic allocation after fixed allocation; thanks Wolfram!
- rk3288 patch new for v2

Douglas Anderson (1):
  ARM: dts: rockchip: Add mmc aliases for rk3288 platform

Jaehoon Chung (1):
  Documentation: mmc: Document mmc aliases

Stefan Agner (2):
  mmc: read mmc alias from device tree
  mmc: use SD/MMC host ID for block device name ID

 Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++++++++++
 arch/arm/boot/dts/rk3288.dtsi                 |  4 ++++
 drivers/mmc/card/block.c                      |  2 +-
 drivers/mmc/core/host.c                       | 17 ++++++++++++++++-
 4 files changed, 32 insertions(+), 2 deletions(-)

-- 
2.8.0.rc3.226.g39d4020

[PATCH v2 1/4] Documentation: mmc: Document mmc aliases

[Douglas Anderson]

From: Jaehoon Chung <jh80.chung@samsung.com>

Now, index of mmc/mmcblk devices is allocated in accordance with probing
time.  If want to use the mmcblk1 for some device, it can use alias.

aliases {
	mmc0 = &mmc0;	/* mmc0/mmcblk0 for eMMC */
	mmc1 = &mmc2;	/* mmc1/mmcblk1 for SD */
	mmc2 = &mmc1;	/* mmc2/mmcblk2 for SDIO*/
};

If there are no corresponding values, it might be allocated with
existing scheme.

Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
[dianders: just bindings now; mention mmc not just mmcblk]
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v2: None

 Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
index ed23b9bedfdc..4b5c23e61adb 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -71,6 +71,10 @@ Optional SDIO properties:
 - wakeup-source: Enables wake up of host system on SDIO IRQ assertion
 		 (Legacy property supported: "enable-sdio-wakeup")
 
+Aliases (Optional):
+- If you want to use the fixed index for devices like mmcX / mmcblkX, should
+be represented in the aliases node using following format "mmc(X)".
+(X is an unique number for the alias.)
 
 MMC power sequences:
 --------------------
@@ -145,3 +149,10 @@ mmc3: mmc@01c12000 {
 		interrupt-names = "host-wake";
 	};
 };
+
+Example with aliases nodes:
+
+aliases {
+	mmc0 = &mmc0;	/* Fixed to mmc0/mmcblk0 for &mmc0 */
+	mmc1 = &mmc2;	/* Fixed to mmc1/mmcblk1 for &mmc2 */
+};
-- 
2.8.0.rc3.226.g39d4020

[PATCH v2 2/4] mmc: read mmc alias from device tree

[Douglas Anderson]

From: Stefan Agner <stefan@agner.ch>

To get the SD/MMC host device ID, read the alias from the device
tree.

This is useful in case a SoC has multipe SD/MMC host controllers while
the second controller should logically be the first device (e.g. if
the second controller is connected to an internal eMMC). Combined
with block device numbering using MMC/SD host device ID, this
results in predictable name assignment of the internal eMMC block
device.

Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
[dianders: rebase + roll in http://crosreview.com/259916]
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v2:
- Rebased atop mmc-next
- Stat dynamic allocation after fixed allocation; thanks Wolfram!

 drivers/mmc/core/host.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index e0a3ee16c0d3..e09f1d6207d3 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -314,11 +314,26 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *dev)
 {
 	int err;
 	struct mmc_host *host;
+	int id;
 
 	host = kzalloc(sizeof(struct mmc_host) + extra, GFP_KERNEL);
 	if (!host)
 		return NULL;
 
+	/* If OF aliases exist, start dynamic assignment after highest */
+	id = of_alias_get_highest_id("mmc");
+	id = (id < 0) ? 0 : id + 1;
+
+	/* If this devices has OF node, maybe it has an alias */
+	if (dev->of_node) {
+		int of_id = of_alias_get_id(dev->of_node, "mmc");
+
+		if (of_id < 0)
+			dev_warn(dev, "/aliases ID not available\n");
+		else
+			id = of_id;
+	}
+
 	/* scanning will be enabled when we're ready */
 	host->rescan_disable = 1;
 
@@ -329,7 +344,7 @@ again:
 	}
 
 	spin_lock(&mmc_host_lock);
-	err = ida_get_new(&mmc_host_ida, &host->index);
+	err = ida_get_new_above(&mmc_host_ida, id, &host->index);
 	spin_unlock(&mmc_host_lock);
 
 	if (err == -EAGAIN) {
-- 
2.8.0.rc3.226.g39d4020

[PATCH v2 3/4] mmc: use SD/MMC host ID for block device name ID

[Douglas Anderson]

From: Stefan Agner <stefan@agner.ch>

By using the SD/MMC host device ID as a starting point for block
device numbering, one can reliably predict the first block device
name (at least for the first controller). This is especially useful
for SoCs with multiple SD/MMC host controller, where the controller
with index 0 is connected to a eMMC device.

Usually the first controller gets the first block device name ID,
however this is not guaranteed. Also if the first controller is
aliased as second controller and visa-versa (using device tree
aliases), the block device name ID assignation is not ordered by
the SD/MMC host device ID (since mmc_rescan is called in order of
the memory mapped pheripherial addresses).

Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v2:
- Rebased atop mmc-next

 drivers/mmc/card/block.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 9ce679255775..360700f3e0ea 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -2197,7 +2197,7 @@ again:
 		return ERR_PTR(-ENOMEM);
 
 	spin_lock(&mmc_blk_lock);
-	ret = ida_get_new(&mmc_blk_ida, &devidx);
+	ret = ida_get_new_above(&mmc_blk_ida, card->host->index, &devidx);
 	spin_unlock(&mmc_blk_lock);
 
 	if (ret == -EAGAIN)
-- 
2.8.0.rc3.226.g39d4020

[PATCH v2 4/4] ARM: dts: rockchip: Add mmc aliases for rk3288 platform

[Douglas Anderson]

Now that mmc aliases are officially in bindings, add them to rk3288.
This could be done to lots of platforms, but this is the one I tested
with.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v2:
- rk3288 patch new for v2

 arch/arm/boot/dts/rk3288.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 31f7e20ef418..4cb15dcd1c1e 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -60,6 +60,10 @@
 		i2c3 = &i2c3;
 		i2c4 = &i2c4;
 		i2c5 = &i2c5;
+		mmc0 = &emmc;
+		mmc1 = &sdmmc;
+		mmc2 = &sdio0;
+		mmc3 = &sdio1;
 		mshc0 = &emmc;
 		mshc1 = &sdmmc;
 		mshc2 = &sdio0;
-- 
2.8.0.rc3.226.g39d4020

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Rob Herring]

On Fri, Apr 29, 2016 at 12:32 PM, Douglas Anderson
<dianders@chromium.org> wrote:
> This series picks patches from various different places to produce what
> I consider the best solution to getting consistent mmc and mmcblk
> ordering.
>
> Why consistent ordering and why not just use UUIDs?  IMHO consistent
> ordering solves a few different problems:
>
> 1. For poor, feeble-minded humans like me, have sane numbering for
>    devices helps a lot.  When grepping through dmesg it's terribly handy
>    if a given SDMMC device has a consistent number.  I know that I can
>    do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about
>    the eMMC.  I know that I can do "dmesg | grep mmc1" to find info
>    about the SD card slot.  I don't want it to matter which one probed
>    first, I don't want it to matter if I'm working on a variant of the
>    hardware that has the SD card slot disabled, and I don't want to care
>    what my boot device was.  Worrying about what device number I got
>    increases my cognitive load.
>
> 2. There are cases where it's not trivially easy during development to
>    use the UUID.  Specifically I work a lot with coreboot / depthcharge
>    as a BIOS.  When configured properly, that BIOS has a nice feature to
>    allow you to fetch the kernel and kernel command line from TFTP by
>    pressing Ctrl-N.  In this particular case the BIOS doesn't actually
>    know which disk I'd like for my root filesystem, so it's not so easy
>    for it to put the right UUID into the command line.  For this
>    purpose, knowing that "mmcblk0" will always refer to eMMC is handy.

Why don't you use labels? This works whether your rootfs is on
/dev/vdXy, /dev/sdXy or /dev/mmcblkXpy. I can feel your pain as I've
been looking at the per device crap that is Android fstab files which
labels solve beautifully and worked without Android changes.

Sorry, I'm not keen to add something that is both MMC and DT specific.
If consistent numbering for devices is a goal in the kernel, then I'd
feel otherwise. But I'm pretty sure that is a non-goal.

Aliases were largely intended for backwards compatibility in cases
where the numbering was already consistent (IOW consoles).

Rob

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Doug Anderson]

Rob,

On Fri, Apr 29, 2016 at 11:12 AM, Rob Herring <robh+dt@kernel.org> wrote:
> On Fri, Apr 29, 2016 at 12:32 PM, Douglas Anderson
> <dianders@chromium.org> wrote:
>> This series picks patches from various different places to produce what
>> I consider the best solution to getting consistent mmc and mmcblk
>> ordering.
>>
>> Why consistent ordering and why not just use UUIDs?  IMHO consistent
>> ordering solves a few different problems:
>>
>> 1. For poor, feeble-minded humans like me, have sane numbering for
>>    devices helps a lot.  When grepping through dmesg it's terribly handy
>>    if a given SDMMC device has a consistent number.  I know that I can
>>    do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about
>>    the eMMC.  I know that I can do "dmesg | grep mmc1" to find info
>>    about the SD card slot.  I don't want it to matter which one probed
>>    first, I don't want it to matter if I'm working on a variant of the
>>    hardware that has the SD card slot disabled, and I don't want to care
>>    what my boot device was.  Worrying about what device number I got
>>    increases my cognitive load.
>>
>> 2. There are cases where it's not trivially easy during development to
>>    use the UUID.  Specifically I work a lot with coreboot / depthcharge
>>    as a BIOS.  When configured properly, that BIOS has a nice feature to
>>    allow you to fetch the kernel and kernel command line from TFTP by
>>    pressing Ctrl-N.  In this particular case the BIOS doesn't actually
>>    know which disk I'd like for my root filesystem, so it's not so easy
>>    for it to put the right UUID into the command line.  For this
>>    purpose, knowing that "mmcblk0" will always refer to eMMC is handy.
>
> Why don't you use labels? This works whether your rootfs is on
> /dev/vdXy, /dev/sdXy or /dev/mmcblkXpy.

I've never used labels.  I can take a look at them.  I presume I'll
have to do a little extra work to tag my "emmc" filesystem properly
when I install to eMMC, but that wouldn't be too bad.  Thanks for the
suggestion.

That solves point #2, but not point #1.  It still adds an extra step
of mapping number to device when looking at logs / sysfs files.

IMHO:

* this patch set is very small.

* this patch set doesn't hurt anyone.

* I believe lots of people feel that this patch set would be useful.

* this patch set is very small and shouldn't be too hard to maintain.

* the MMC maintainer, who would be responsible for dealing with the
code in the future if any problems come up, seem to be OK with it.

> I can feel your pain as I've
> been looking at the per device crap that is Android fstab files which
> labels solve beautifully and worked without Android changes.
>
> Sorry, I'm not keen to add something that is both MMC and DT specific.

It would be quite easy to adjust this to other systems if they
provided similar functionality.  Nearly 100% of this code is just
calling helper functions, so the code would be easy to find and change
if/when there was a generic (non-DT) method for this.

As far as it being MMC specific: it's not.  Do a "git grep" for
of_alias_get_id().  It's used in many, many places.


> If consistent numbering for devices is a goal in the kernel, then I'd
> feel otherwise. But I'm pretty sure that is a non-goal.

Can you provide documentation that this is a non-goal?  I can submit
some patches upstream to make ID allocation behave more randomly if
that would be helpful to upstream.  I'd probably want to disable it
locally, but if you think folks would really like it...  ;)

In all seriousness, though, I'm not sure why randomness in IDs would
be considered a worthwhile goal.  Is it because:

* You're trying to discourage people from building systems where they
hardcode "/dev/mmcblk0" as the eMMC?  Maybe it would be better to
throw a big WARN_ON in the boot log for this?

* You think that numbering like this doesn't scale somehow?  Note that
for a given piece of hardware it's quite likely to have a small number
of MMC slots and it's quite likely that users of this SoC can agree on
the numbering (emmc = 0, SD slots start at 1).

* Some other reason?


-Doug

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 12:31:28PM -0700, Doug Anderson wrote:
> Rob,
> 
> On Fri, Apr 29, 2016 at 11:12 AM, Rob Herring <robh+dt@kernel.org> wrote:
> > On Fri, Apr 29, 2016 at 12:32 PM, Douglas Anderson
> > <dianders@chromium.org> wrote:
> >> This series picks patches from various different places to produce what
> >> I consider the best solution to getting consistent mmc and mmcblk
> >> ordering.
> >>
> >> Why consistent ordering and why not just use UUIDs?  IMHO consistent
> >> ordering solves a few different problems:
> >>
> >> 1. For poor, feeble-minded humans like me, have sane numbering for
> >>    devices helps a lot.  When grepping through dmesg it's terribly handy
> >>    if a given SDMMC device has a consistent number.  I know that I can
> >>    do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about
> >>    the eMMC.  I know that I can do "dmesg | grep mmc1" to find info
> >>    about the SD card slot.  I don't want it to matter which one probed
> >>    first, I don't want it to matter if I'm working on a variant of the
> >>    hardware that has the SD card slot disabled, and I don't want to care
> >>    what my boot device was.  Worrying about what device number I got
> >>    increases my cognitive load.
> >>
> >> 2. There are cases where it's not trivially easy during development to
> >>    use the UUID.  Specifically I work a lot with coreboot / depthcharge
> >>    as a BIOS.  When configured properly, that BIOS has a nice feature to
> >>    allow you to fetch the kernel and kernel command line from TFTP by
> >>    pressing Ctrl-N.  In this particular case the BIOS doesn't actually
> >>    know which disk I'd like for my root filesystem, so it's not so easy
> >>    for it to put the right UUID into the command line.  For this
> >>    purpose, knowing that "mmcblk0" will always refer to eMMC is handy.
> >
> > Why don't you use labels? This works whether your rootfs is on
> > /dev/vdXy, /dev/sdXy or /dev/mmcblkXpy.
> 
> I've never used labels.  I can take a look at them.  I presume I'll
> have to do a little extra work to tag my "emmc" filesystem properly
> when I install to eMMC, but that wouldn't be too bad.  Thanks for the
> suggestion.
> 
> That solves point #2, but not point #1.  It still adds an extra step
> of mapping number to device when looking at logs / sysfs files.

Your original two arguments don't really stand up.

Let's take #2 to start with.

You claim that coreboot doesn't have support to provide the correct UUID.
Why is that a problem?  Distros on x86 don't have support to provide the
correct UUID either.  That's done by the distro when setting the system
up - it provides the kernel loader (eg, grub) with an appropriate
configuration, which includes a root specifier with the correct UUID,
eg:

 root=UUID=a5dcd879-eea2-4d87-bdef-8ee76741e7df

That's for the initramfs to use, but there's a short UUID equivalent for
the kernel itself, or as Rob and myself have already pointed out, the
label system (which is problematical if you have multiple filesystems
with the same label.)  UUID is the better system.

For #1, are you really saying that you're somehow different from all the
x86 platform users, and can't cope with dynamic numbering of devices that
are present on x86 systems?

> It would be quite easy to adjust this to other systems if they
> provided similar functionality.  Nearly 100% of this code is just
> calling helper functions, so the code would be easy to find and change
> if/when there was a generic (non-DT) method for this.

Except the problem is already solved by the UUID or label mount methods,
which work everywhere, even across different media.  So, if you decide
to plug your SD card into a USB reader because the SD slot has become
unreliable, if you mount by UUID or label, the kernel will still find
the right device, even though it's now become /dev/sd* instead of
/dev/mmcblk*.

> > If consistent numbering for devices is a goal in the kernel, then I'd
> > feel otherwise. But I'm pretty sure that is a non-goal.
> 
> Can you provide documentation that this is a non-goal?  I can submit
> some patches upstream to make ID allocation behave more randomly if
> that would be helpful to upstream.  I'd probably want to disable it
> locally, but if you think folks would really like it...  ;)
> 
> In all seriousness, though, I'm not sure why randomness in IDs would
> be considered a worthwhile goal.

*Sigh* you're taking this to an extreme.  Random numbering isn't a goal
in itself.  The kernel just doesn't provide a _guarantee_ the order in
which devices appear or the names which the devices will get.

It means that you _can_ mount by device path if you wish, but you may
occasionally run into cases where the device path changes for one
reason or another (eg, because you've changed the PCIe card slot that
your SATA PCIe card is plugged into, or many other reasons.)

Just use UUID (preferred) or label and enjoy much more flexibility than
your solution adding yet more code to the kernel would give you.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Doug Anderson]

Hi,

On Fri, Apr 29, 2016 at 12:50 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Your original two arguments don't really stand up.
>
> Let's take #2 to start with.
>
> You claim that coreboot doesn't have support to provide the correct UUID.
> Why is that a problem?  Distros on x86 don't have support to provide the
> correct UUID either.  That's done by the distro when setting the system
> up - it provides the kernel loader (eg, grub) with an appropriate
> configuration, which includes a root specifier with the correct UUID,
> eg:
>
>  root=UUID=a5dcd879-eea2-4d87-bdef-8ee76741e7df
>
> That's for the initramfs to use, but there's a short UUID equivalent for
> the kernel itself, or as Rob and myself have already pointed out, the
> label system (which is problematical if you have multiple filesystems
> with the same label.)  UUID is the better system.

Coreboot certainly has support for this.  It assigns the UUID based on
the disk it gets the kernel for.  If you read my email, you'll see
that it only has a problem when doing TFTP boot.  In this case it
doesn't know which disk to use for a UUID.


> For #1, are you really saying that you're somehow different from all the
> x86 platform users, and can't cope with dynamic numbering of devices that
> are present on x86 systems?

See my other email.  ...and yes, if there is no sane ordering then
you've just got to deal.  ...but there is a sane ordering on many
embedded devices.  If you've got a car and you need to get there fast,
you take the car.  It doesn't matter if other people are biking or
walking.


>> It would be quite easy to adjust this to other systems if they
>> provided similar functionality.  Nearly 100% of this code is just
>> calling helper functions, so the code would be easy to find and change
>> if/when there was a generic (non-DT) method for this.
>
> Except the problem is already solved by the UUID or label mount methods,
> which work everywhere, even across different media.  So, if you decide
> to plug your SD card into a USB reader because the SD slot has become
> unreliable, if you mount by UUID or label, the kernel will still find
> the right device, even though it's now become /dev/sd* instead of
> /dev/mmcblk*.

Not saying UUIDs don't solve problems.  I'm just saying that assigning
consistent numbering shouldn't be hurting you.


>> > If consistent numbering for devices is a goal in the kernel, then I'd
>> > feel otherwise. But I'm pretty sure that is a non-goal.
>>
>> Can you provide documentation that this is a non-goal?  I can submit
>> some patches upstream to make ID allocation behave more randomly if
>> that would be helpful to upstream.  I'd probably want to disable it
>> locally, but if you think folks would really like it...  ;)
>>
>> In all seriousness, though, I'm not sure why randomness in IDs would
>> be considered a worthwhile goal.
>
> *Sigh* you're taking this to an extreme.  Random numbering isn't a goal
> in itself.  The kernel just doesn't provide a _guarantee_ the order in
> which devices appear or the names which the devices will get.
>
> It means that you _can_ mount by device path if you wish, but you may
> occasionally run into cases where the device path changes for one
> reason or another (eg, because you've changed the PCIe card slot that
> your SATA PCIe card is plugged into, or many other reasons.)
>
> Just use UUID (preferred) or label and enjoy much more flexibility than
> your solution adding yet more code to the kernel would give you.

Right.  UUIDs are great.  ...but still seeing nothing that says that
assigning consistent numbering hurts you or hurts UUIDs.

-Doug

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 10:32:15AM -0700, Douglas Anderson wrote:
> This series picks patches from various different places to produce what
> I consider the best solution to getting consistent mmc and mmcblk
> ordering.
> 
> Why consistent ordering and why not just use UUIDs?  IMHO consistent
> ordering solves a few different problems:

NAK.  Really.  Use UUIDs, that's the proper solution here.

Exactly the same issue arises if you have more than one ATA or SCSI
adapter in your PC - things can be probed out of order and end up
in different /dev/sd* slots.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Doug Anderson]

Russell,

On Fri, Apr 29, 2016 at 11:12 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 10:32:15AM -0700, Douglas Anderson wrote:
>> This series picks patches from various different places to produce what
>> I consider the best solution to getting consistent mmc and mmcblk
>> ordering.
>>
>> Why consistent ordering and why not just use UUIDs?  IMHO consistent
>> ordering solves a few different problems:
>
> NAK.  Really.  Use UUIDs, that's the proper solution here.

Un-NAK.  UUIDs don't solve point #1.


> Exactly the same issue arises if you have more than one ATA or SCSI
> adapter in your PC - things can be probed out of order and end up
> in different /dev/sd* slots.

Yup, UUIDs are awesome and great and super.  Best invention since
sliced bread, really.  I definitely _won't_ submit a patch to remove
UUID support.  I promise.

A few notes, though:

* Presumably on a PC you've got an extra bit in the middle (like grub
or something like that) that can help you resolve your UUIDs even if
you get your kernel from somewhere else.  In my case, I don't have
that.  Maybe this is a failing of coreboot / depthcharge's netboot and
I suppose.  ...and I suppose I could modify the BIOS to take a root
filesystem of "eMMC" and have it resolve that to the eMMC's UUID or
something like that.  ...or I just take these patches locally and
things keep working like they did before.

* Presumably in the non-embedded world kernel hackers have a different
workflow.  They probably don't swap between different devices with
different configurations on an hourly basis.  They're not in the habit
of totally reimaging their system periodically.  Etc.  Trying to force
the workflow of a PC kernel hacker and an embedded kernel hacker to be
the same doesn't seem like a worthwhile goal.

* Presumably an embedded kernel hacker running with ATA / SCSI could
_usually_ assume that "sda" is his/her root filesystem.  It's unlikely
an embedded system would have more than one "sda" disk builtin and
it's nearly guaranteed (I think) that a builtin ATA / SCSI controller
would probe before any USB based devices.  Sure, if your root
filesystem is USB based (really?) and you've got additional USB
storage devices then you're SOL.  Sorry.

-Doug

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 12:43:39PM -0700, Doug Anderson wrote:
> Russell,
> 
> On Fri, Apr 29, 2016 at 11:12 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Apr 29, 2016 at 10:32:15AM -0700, Douglas Anderson wrote:
> >> This series picks patches from various different places to produce what
> >> I consider the best solution to getting consistent mmc and mmcblk
> >> ordering.
> >>
> >> Why consistent ordering and why not just use UUIDs?  IMHO consistent
> >> ordering solves a few different problems:
> >
> > NAK.  Really.  Use UUIDs, that's the proper solution here.
> 
> Un-NAK.  UUIDs don't solve point #1.

Re-NAK.  I don't think your point #1 is valid.  See my other reply.

> * Presumably on a PC you've got an extra bit in the middle (like grub
> or something like that) that can help you resolve your UUIDs even if
> you get your kernel from somewhere else.

You are over-estimating what grub does.  Grub doesn't resolve UUIDs at
all.  Grub just passes the kernel arguments in its configuration file
for the entry it is booting to the kernel.  It's a static configuration
found in /boot/grub/grub.conf.

It doesn't probe devices for UUIDs.

> * Presumably in the non-embedded world kernel hackers have a different
> workflow.  They probably don't swap between different devices with
> different configurations on an hourly basis.  They're not in the habit
> of totally reimaging their system periodically.  Etc.  Trying to force
> the workflow of a PC kernel hacker and an embedded kernel hacker to be
> the same doesn't seem like a worthwhile goal.

In _my_ world with the "embedded" devices I have, I mount by UUID on
platforms which have multiple MMC devices to avoid exactly the problem
you're having.  This works fine.

If I were to switch the SD card, and I wanted to avoid changing the
boot loader configuration, I'd use label instead, and I'd label all
the SD card rootfs using the same label so I could just swap the cards.

> * Presumably an embedded kernel hacker running with ATA / SCSI could
> _usually_ assume that "sda" is his/her root filesystem.  It's unlikely
> an embedded system would have more than one "sda" disk builtin and
> it's nearly guaranteed (I think) that a builtin ATA / SCSI controller
> would probe before any USB based devices.

You've got a funny view again.  N2100 has two hard disks.  The clearfog
board from SolidRun has two mini-PCIe slots, each of which can have two
SATA interfaces... If you want to use it as a server-type platform with
lots of disks...

> Sure, if your root
> filesystem is USB based (really?) and you've got additional USB
> storage devices then you're SOL.  Sorry.

One of my Versatile Express platforms boots from USB, and has a MMC
slot...  So this argument does not stack up.

Sorry.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Doug Anderson]

Russell,

On Fri, Apr 29, 2016 at 12:57 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
>> * Presumably on a PC you've got an extra bit in the middle (like grub
>> or something like that) that can help you resolve your UUIDs even if
>> you get your kernel from somewhere else.
>
> You are over-estimating what grub does.  Grub doesn't resolve UUIDs at
> all.  Grub just passes the kernel arguments in its configuration file
> for the entry it is booting to the kernel.  It's a static configuration
> found in /boot/grub/grub.conf.
>
> It doesn't probe devices for UUIDs.

OK.  The point was: if folks on PCs have a workflow that works for
them, wonderful.  That workflow doesn't work so great for me.  My
workflow doesn't hurt them.  Why is it bad?


>> * Presumably in the non-embedded world kernel hackers have a different
>> workflow.  They probably don't swap between different devices with
>> different configurations on an hourly basis.  They're not in the habit
>> of totally reimaging their system periodically.  Etc.  Trying to force
>> the workflow of a PC kernel hacker and an embedded kernel hacker to be
>> the same doesn't seem like a worthwhile goal.
>
> In _my_ world with the "embedded" devices I have, I mount by UUID on
> platforms which have multiple MMC devices to avoid exactly the problem
> you're having.  This works fine.
>
> If I were to switch the SD card, and I wanted to avoid changing the
> boot loader configuration, I'd use label instead, and I'd label all
> the SD card rootfs using the same label so I could just swap the cards.

OK.  The point was: if you have a workflow that works for you,
wonderful.  That workflow doesn't work so great for me.  My workflow
doesn't hurt you.  Why is it bad?


>> * Presumably an embedded kernel hacker running with ATA / SCSI could
>> _usually_ assume that "sda" is his/her root filesystem.  It's unlikely
>> an embedded system would have more than one "sda" disk builtin and
>> it's nearly guaranteed (I think) that a builtin ATA / SCSI controller
>> would probe before any USB based devices.
>
> You've got a funny view again.  N2100 has two hard disks.  The clearfog
> board from SolidRun has two mini-PCIe slots, each of which can have two
> SATA interfaces... If you want to use it as a server-type platform with
> lots of disks...

OK.  The point was: if you have a workflow that works for you,
wonderful.  That workflow doesn't work so great for me.  My workflow
doesn't hurt you.  Why is it bad?


>> Sure, if your root
>> filesystem is USB based (really?) and you've got additional USB
>> storage devices then you're SOL.  Sorry.
>
> One of my Versatile Express platforms boots from USB, and has a MMC
> slot...  So this argument does not stack up.

OK.  The point was: if you have a workflow that works for you,
wonderful.  That workflow doesn't work so great for me.  My workflow
doesn't hurt you.  Why is it bad?


-Doug

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 01:04:48PM -0700, Doug Anderson wrote:
> Russell,
> 
> On Fri, Apr 29, 2016 at 12:57 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >> * Presumably on a PC you've got an extra bit in the middle (like grub
> >> or something like that) that can help you resolve your UUIDs even if
> >> you get your kernel from somewhere else.
> >
> > You are over-estimating what grub does.  Grub doesn't resolve UUIDs at
> > all.  Grub just passes the kernel arguments in its configuration file
> > for the entry it is booting to the kernel.  It's a static configuration
> > found in /boot/grub/grub.conf.
> >
> > It doesn't probe devices for UUIDs.
> 
> OK.  The point was: if folks on PCs have a workflow that works for
> them, wonderful.  That workflow doesn't work so great for me.  My
> workflow doesn't hurt them.  Why is it bad?

This discussion is over, since you're not willing to actually discuss
it (illustrated by you cutting and pasting this same thing four
times in your reply.)

My NAK stands until such time that you can partake in a reasonable
discussion.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Doug Anderson]

Hi,

On Fri, Apr 29, 2016 at 2:13 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 01:04:48PM -0700, Doug Anderson wrote:
>> Russell,
>>
>> On Fri, Apr 29, 2016 at 12:57 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> >> * Presumably on a PC you've got an extra bit in the middle (like grub
>> >> or something like that) that can help you resolve your UUIDs even if
>> >> you get your kernel from somewhere else.
>> >
>> > You are over-estimating what grub does.  Grub doesn't resolve UUIDs at
>> > all.  Grub just passes the kernel arguments in its configuration file
>> > for the entry it is booting to the kernel.  It's a static configuration
>> > found in /boot/grub/grub.conf.
>> >
>> > It doesn't probe devices for UUIDs.
>>
>> OK.  The point was: if folks on PCs have a workflow that works for
>> them, wonderful.  That workflow doesn't work so great for me.  My
>> workflow doesn't hurt them.  Why is it bad?
>
> This discussion is over, since you're not willing to actually discuss
> it (illustrated by you cutting and pasting this same thing four
> times in your reply.)
>
> My NAK stands until such time that you can partake in a reasonable
> discussion.

The point of pasting it several times was that you'd answer it.
Apparently that failed.

Perhaps you could answer the question I posed?

-Doug

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 02:17:45PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Fri, Apr 29, 2016 at 2:13 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Apr 29, 2016 at 01:04:48PM -0700, Doug Anderson wrote:
> >> Russell,
> >>
> >> On Fri, Apr 29, 2016 at 12:57 PM, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> >> * Presumably on a PC you've got an extra bit in the middle (like grub
> >> >> or something like that) that can help you resolve your UUIDs even if
> >> >> you get your kernel from somewhere else.
> >> >
> >> > You are over-estimating what grub does.  Grub doesn't resolve UUIDs at
> >> > all.  Grub just passes the kernel arguments in its configuration file
> >> > for the entry it is booting to the kernel.  It's a static configuration
> >> > found in /boot/grub/grub.conf.
> >> >
> >> > It doesn't probe devices for UUIDs.
> >>
> >> OK.  The point was: if folks on PCs have a workflow that works for
> >> them, wonderful.  That workflow doesn't work so great for me.  My
> >> workflow doesn't hurt them.  Why is it bad?
> >
> > This discussion is over, since you're not willing to actually discuss
> > it (illustrated by you cutting and pasting this same thing four
> > times in your reply.)
> >
> > My NAK stands until such time that you can partake in a reasonable
> > discussion.
> 
> The point of pasting it several times was that you'd answer it.
> Apparently that failed.
> 
> Perhaps you could answer the question I posed?

No, because you haven't taken the time to think and consider my
reply, which gives you insight into how your "problem" is no
different from the situation that everyone else has, where it
isn't a problem.

I think the "problem" here is that you've got used to coreboot
doing something that very few other boot loaders do, namely it
automatically extracting a rootfs UUID for you.  The rest of the
world doesn't have that luxury.

So, instead, you want to stuff more code into the kernel to work
around what you think is a problem - a problem which seems to be
unique to yourself.

The UUID and label solutions were created by x86 people to work
around exactly this dynamic device problem, and as my previous
replies have shown, it is superior to fixing the device assignment
as you're trying to do.

However, I don't expect that you'll like this answer, and you'll
probably just re-post your same question after each and every
paragraph rather than considering whether the already existing
solutions could solve your "problem".  So I'm just wasting my time.

This is my last reply.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Doug Anderson]

Russell,

On Fri, Apr 29, 2016 at 2:29 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> No, because you haven't taken the time to think and consider my
> reply, which gives you insight into how your "problem" is no
> different from the situation that everyone else has, where it
> isn't a problem.

I have certainly considered it.


> I think the "problem" here is that you've got used to coreboot
> doing something that very few other boot loaders do, namely it
> automatically extracting a rootfs UUID for you.  The rest of the
> world doesn't have that luxury.

Earlier in this thread Rob nicely proposed a solution to my TFTP.  I
agreed that was a nice solution.  I can certainly use it.  Certainly
there are many places where UUIDs are awesome.  ...but that's still no
reason to assign a random number when a sane and logical numbering
system exists for MMC parts on a given SoC.


> So, instead, you want to stuff more code into the kernel to work
> around what you think is a problem - a problem which seems to be
> unique to yourself.

Not so much.  I think many people have expressed interest in something
like this.  It seems unlikely to be unique.


> The UUID and label solutions were created by x86 people to work
> around exactly this dynamic device problem, and as my previous
> replies have shown, it is superior to fixing the device assignment
> as you're trying to do.

Sure.  They don't have the luxury of having a simple and consistent
numbering so they're forced to use UUIDs for booting and have the
extra mental work of mapping IDs to physical hardware.  ...so they're
forced to use UUIDs.


> However, I don't expect that you'll like this answer, and you'll
> probably just re-post your same question after each and every
> paragraph rather than considering whether the already existing
> solutions could solve your "problem".  So I'm just wasting my time.

Really I just reposted it several times because I notice that you seem
to ignore many points of my emails.  I was really hoping to get you to
address this point.  I notice that you still didn't.  Either you are
just trying to annoy me, or you don't have an answer to how my patch
series hurts you.


> This is my last reply.

Excellent.  I look forward to your silence.

-Doug

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 02:39:35PM -0700, Doug Anderson wrote:
[didn't read most of your reply]

> Really I just reposted it several times because I notice that you seem
> to ignore many points of my emails.  I was really hoping to get you to
> address this point.  I notice that you still didn't.  Either you are
> just trying to annoy me, or you don't have an answer to how my patch
> series hurts you.

I don't see you treating Rob with the same contempt that you have
treated me in this thread, despite Rob and myself both telling you
basically the same thing.

Maybe you should try some of the solutions we're suggesting, rather
than hammering away at your keyboard because you disagree with the
feedback that you're getting, to see whether these other solutions
resolve it.

I notice that your replies focuses solely on UUIDs to my messages,
despite *my* messages also talking about labels.  Therefore, I think
you are _not_ actually reading my replies - if you were, then you
would have noticed that I've been making the same suggestion as Rob.

Also, the speed at which you hammer out your replies (in as little
as minutes) suggests that you aren't reading them.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Doug Anderson]

Russell,

On Fri, Apr 29, 2016 at 2:50 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 02:39:35PM -0700, Doug Anderson wrote:
> [didn't read most of your reply]
>
>> Really I just reposted it several times because I notice that you seem
>> to ignore many points of my emails.  I was really hoping to get you to
>> address this point.  I notice that you still didn't.  Either you are
>> just trying to annoy me, or you don't have an answer to how my patch
>> series hurts you.
>
> I don't see you treating Rob with the same contempt that you have
> treated me in this thread, despite Rob and myself both telling you
> basically the same thing.

Rob wrote a nice thoughtful reply and I tried to give a nice
thoughtful reply back to him.  He raised some good points and I raised
some good points back to him.  I look forward to his future thoughts
on the topic.


-Doug

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 02:56:38PM -0700, Doug Anderson wrote:
> Russell,
> 
> On Fri, Apr 29, 2016 at 2:50 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Apr 29, 2016 at 02:39:35PM -0700, Doug Anderson wrote:
> > [didn't read most of your reply]
> >
> >> Really I just reposted it several times because I notice that you seem
> >> to ignore many points of my emails.  I was really hoping to get you to
> >> address this point.  I notice that you still didn't.  Either you are
> >> just trying to annoy me, or you don't have an answer to how my patch
> >> series hurts you.
> >
> > I don't see you treating Rob with the same contempt that you have
> > treated me in this thread, despite Rob and myself both telling you
> > basically the same thing.
> 
> Rob wrote a nice thoughtful reply and I tried to give a nice
> thoughtful reply back to him.  He raised some good points and I raised
> some good points back to him.  I look forward to his future thoughts
> on the topic.

Meanwhile, I've pointed out that you appear to be coming from a
misunderstanding (that's certainly clear because you believed
initially that grub did something it doesn't), showing that the
"problem" you have is no different from the majority of other
systems running Linux, and you treat me with contempt.

What are you going to do to resolve this?

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Doug Anderson]

Hi,

On Fri, Apr 29, 2016 at 3:16 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 02:56:38PM -0700, Doug Anderson wrote:
>> Russell,
>>
>> On Fri, Apr 29, 2016 at 2:50 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Fri, Apr 29, 2016 at 02:39:35PM -0700, Doug Anderson wrote:
>> > [didn't read most of your reply]
>> >
>> >> Really I just reposted it several times because I notice that you seem
>> >> to ignore many points of my emails.  I was really hoping to get you to
>> >> address this point.  I notice that you still didn't.  Either you are
>> >> just trying to annoy me, or you don't have an answer to how my patch
>> >> series hurts you.
>> >
>> > I don't see you treating Rob with the same contempt that you have
>> > treated me in this thread, despite Rob and myself both telling you
>> > basically the same thing.
>>
>> Rob wrote a nice thoughtful reply and I tried to give a nice
>> thoughtful reply back to him.  He raised some good points and I raised
>> some good points back to him.  I look forward to his future thoughts
>> on the topic.
>
> Meanwhile, I've pointed out that you appear to be coming from a
> misunderstanding (that's certainly clear because you believed
> initially that grub did something it doesn't), showing that the
> "problem" you have is no different from the majority of other
> systems running Linux, and you treat me with contempt.
>
> What are you going to do to resolve this?

As I tried to indicate in earlier emails, I don't actually care how
grub works in this case.  It was originally meant to illustrate the
other people's workflows and mine are not the same.  If they have a
solution that works for them, that's great.

I want my MMC and MMCBLK device numbers to be sane and consistent to
help me parse through dmesg and sysfs.  If it happens to also make it
easy / possible to specify a root filesystem using "mmcblkN" that's
great and I'll probably take advantage of that.

I'm very sorry if those using SATA and ATA disks don't have a way to
get sane and consistent device number ordering.  I really am.  ...but
just because they don't have a well defined ordering doesn't mean
those of us using MMC should have to suffer.  ...and I don't think
giving a sane ordering to MMC devices hurts anyone, does it?

-Doug

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 03:22:50PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Fri, Apr 29, 2016 at 3:16 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Apr 29, 2016 at 02:56:38PM -0700, Doug Anderson wrote:
> >> Russell,
> >>
> >> On Fri, Apr 29, 2016 at 2:50 PM, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Fri, Apr 29, 2016 at 02:39:35PM -0700, Doug Anderson wrote:
> >> > [didn't read most of your reply]
> >> >
> >> >> Really I just reposted it several times because I notice that you seem
> >> >> to ignore many points of my emails.  I was really hoping to get you to
> >> >> address this point.  I notice that you still didn't.  Either you are
> >> >> just trying to annoy me, or you don't have an answer to how my patch
> >> >> series hurts you.
> >> >
> >> > I don't see you treating Rob with the same contempt that you have
> >> > treated me in this thread, despite Rob and myself both telling you
> >> > basically the same thing.
> >>
> >> Rob wrote a nice thoughtful reply and I tried to give a nice
> >> thoughtful reply back to him.  He raised some good points and I raised
> >> some good points back to him.  I look forward to his future thoughts
> >> on the topic.
> >
> > Meanwhile, I've pointed out that you appear to be coming from a
> > misunderstanding (that's certainly clear because you believed
> > initially that grub did something it doesn't), showing that the
> > "problem" you have is no different from the majority of other
> > systems running Linux, and you treat me with contempt.
> >
> > What are you going to do to resolve this?
> 
> As I tried to indicate in earlier emails, I don't actually care how
> grub works in this case.  It was originally meant to illustrate the
> other people's workflows and mine are not the same.  If they have a
> solution that works for them, that's great.

... and so far you haven't really showed how your workflow is soo
different from that found on a typical x86 or ARM platform not using
coreboot.  Give an example of how your workflow would differ from
using u-boot.

> I want my MMC and MMCBLK device numbers to be sane and consistent to
> help me parse through dmesg and sysfs.  If it happens to also make it
> easy / possible to specify a root filesystem using "mmcblkN" that's
> great and I'll probably take advantage of that.

While I can relate to that as a desire, the idea of having a stable
device namespace is something that has been rejected by kernel
developers over quite a period of time for all sorts of devices.

> I'm very sorry if those using SATA and ATA disks don't have a way to
> get sane and consistent device number ordering.  I really am.  ...but
> just because they don't have a well defined ordering doesn't mean
> those of us using MMC should have to suffer.  ...and I don't think
> giving a sane ordering to MMC devices hurts anyone, does it?

My reply would be... why should MMC have special handling that no
other subsystem has?

Here's another example.  Plug in several USB serial adapters.  Which
USB serial /dev/ttyUSB* device corresponds to which adapter?  The
answer is... it depends on the order you plug them in, which could
well be different from the order in which they are found if the
machine reboots.  That's a very real problem.

However, the answer to this problem is not to find some way to bind
a particular /dev/ttyUSB* node to a particular USB device, but to
use the solution(s) already provided - iow, /dev/serial/by-id or
/dev/serial/by-path trees which give a stable view of these devices.

Now, while that allows the appropriate /dev/ttyUSB* device to be
found, it doesn't solve the "which ttyUSB* entry in the kernel
message log corresponds with which adapter" (which is the basis
of your point #1.)  That's not solved, and isn't purposely isn't
solved for any kernel subsystem.

Another example - I have boards here with multiple RTCs... guess
what happens with those?  Yep, same problem.  They get dynamic
/dev/rtc* assignment.

Another example - I have a board with three ethernet devices...
yep, same problem again, the order depends on the driver probe
order, and they get dynamically assigned eth* names.

The list of subsystems that have this property is large, because
it's all dependent on the device/driver probing order.

So, please answer this question: why should _only_ MMC be treated
as a special case?  Please give a _technical_ reason rather than a
_personal_ reason.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Doug Anderson]

Hi,

On Fri, Apr 29, 2016 at 3:44 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> My reply would be... why should MMC have special handling that no
> other subsystem has?

No other subsystem?

* i2c allows numbering devices by alias
* rtc allows numbering devices by alias.
* serial allows numbering devices by alias.
* spi allows numbering devices by alias.
* watchdog allows numbering devices by alias.

...at least that's my impression doing a grep for of_alias_get_id(),
which I suggested earlier in this thread but apparently wasn't done.


> Here's another example.  Plug in several USB serial adapters.  Which
> USB serial /dev/ttyUSB* device corresponds to which adapter?  The
> answer is... it depends on the order you plug them in, which could
> well be different from the order in which they are found if the
> machine reboots.  That's a very real problem.

USB is, by definition, hotplug and probable and there is no ordering.
For peripherals built-in to a SoC there is a sane ordering.  Thus
hotplug peripherals and builtin peripherals shouldn't have the same
requirements.

Quite honestly, it _would_ be quite convenient that if you are on a
SoC and you know it has builtin USB controllers to have the root hubs
numbered in a sane and consistent manner.  An area for a future patch,
maybe.


> However, the answer to this problem is not to find some way to bind
> a particular /dev/ttyUSB* node to a particular USB device, but to
> use the solution(s) already provided - iow, /dev/serial/by-id or
> /dev/serial/by-path trees which give a stable view of these devices.
>
> Now, while that allows the appropriate /dev/ttyUSB* device to be
> found, it doesn't solve the "which ttyUSB* entry in the kernel
> message log corresponds with which adapter" (which is the basis
> of your point #1.)  That's not solved, and isn't purposely isn't
> solved for any kernel subsystem.
>
> Another example - I have boards here with multiple RTCs... guess
> what happens with those?  Yep, same problem.  They get dynamic
> /dev/rtc* assignment.

Are you quite certain about that?  See above.


> Another example - I have a board with three ethernet devices...
> yep, same problem again, the order depends on the driver probe
> order, and they get dynamically assigned eth* names.

Ethernet is often provided by USB and thus hotplug and probable.
Quite honestly if there was a builtin Ethernet adapter provided on a
SoC (not connected over USB), it would be super handy if it was forced
to be "eth0" (and if there were more than one if they could be ordered
in a way that made sense for that SoC).  Dynamic ordering could come
after.


> The list of subsystems that have this property is large, because
> it's all dependent on the device/driver probing order.

Sure.  For hotplug, there is no sane device ordering.

For things built in to an SoC, there is sane device ordering.  Dynamic
ordering should come after static.


> So, please answer this question: why should _only_ MMC be treated
> as a special case?  Please give a _technical_ reason rather than a
> _personal_ reason.

Because technically it makes it easier for people to understand their
system to have a sane ordering for builtin peripherals.


-Doug

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Peter Hurley]

On 04/29/2016 04:01 PM, Doug Anderson wrote:
> * serial allows numbering devices by alias.

Which is in fact a total nightmare.

While stable device order is mandatory in serial because of
console command line parameters and existing userspace expectations,
it is the number one barrier to providing a shared ttyS namespace
for mixed uart platforms.

Stable device order has a very real (and often unforeseen) maintenance
burden.

For example, I noticed these patches are strictly for DT.
I'm assuming that's because guaranteeing stable device order for
mmc in general is more difficult; eg., by performing minimal scan
serially and more expensive portion of the probe async.

Regards,
Peter Hurley

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Peter Hurley]

On 04/29/2016 05:03 PM, Doug Anderson wrote:
> Hi,
> 
> On Fri, Apr 29, 2016 at 4:58 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
> 
>     On 04/29/2016 04:01 PM, Doug Anderson wrote:
>     > * serial allows numbering devices by alias.
> 
>     Which is in fact a total nightmare.
> 
>     While stable device order is mandatory in serial because of
>     console command line parameters and existing userspace expectations,
>     it is the number one barrier to providing a shared ttyS namespace
>     for mixed uart platforms.
> 
>     Stable device order has a very real (and often unforeseen) maintenance
>     burden.
> 
> 
> Interesting. I wonder if these burdens are unique to serial or shared
> by all the other subsystems that allow ordering? Maybe this is all
> because of legacy reasons?

Well, the specific issue is certainly unique to serial.
But what I was suggesting is that 5 years from now, these patches
could be the "legacy reasons" in mmc.

FWIW, there is already a defacto expectation by boot configurations in the
field that a given mmc block device is stable across boots. The reality
is that 100000's of kernel command lines look like:

	root=/dev/mmcblk0p2

This was a recent regression fixed by Ulf in commit 9aaf3437aa72
("mmc: block: Use the mmc host device index as the mmcblk device index")


> Note that for MMC devices we wouldn't be asserting that _every_
> device has a stable order. Only those known at boot.
> 
> 
>     For example, I noticed these patches are strictly for DT.
>     I'm assuming that's because guaranteeing stable device order for
>     mmc in general is more difficult; eg., by performing minimal scan
>     serially and more expensive portion of the probe async.
> 
> 
> Presumably if there were another system similar to DT where we knew
> all the possible built-in devices right at boot then we could
> extend.
> 
> ...but yes, obviously this wouldn't be a sane thing to do for
> anything probable like PCI or USB.

SCSI does. Here's what Linus said:

"So the *simple* model is to just scan the devices minimally serially,
and allocate the names at that point (so the names are reliable
between boots for the same hardware configuration). And then do the
more expensive device setup asynchronously (ie querying device
information, spinning up disks, whatever - things that can take
anything from milliseonds to several seconds, because they are doing
actual IO). So you'd do some very basic (and _often_ fairly quick)
operations serially, but then try to do the expensive parts
concurrently.

The SCSI layer actually goes a bit further than that: it has a fairly
asynchronous scanning thing, but it does allocate the actual host
device nodes serially, and then it even has an ordered list of
"scanning_hosts" that is used to complete the scanning in-order, so
that the sysfs devices show up in the right order even if things
actually got scanned out-of-order. So scans that finished early will
wait for other scans that are for "earlier" devices, and you end up
with what *looks* ordered to the outside, even if internally it was
all done out-of-order.
"

Regards,
Peter Hurley

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Doug Anderson]

Hi,

On Fri, Apr 29, 2016 at 5:31 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
> On 04/29/2016 05:03 PM, Doug Anderson wrote:
>> Hi,
>>
>> On Fri, Apr 29, 2016 at 4:58 PM, Peter Hurley <peter@hurleysoftware.com> wrote:
>>
>>     On 04/29/2016 04:01 PM, Doug Anderson wrote:
>>     > * serial allows numbering devices by alias.
>>
>>     Which is in fact a total nightmare.
>>
>>     While stable device order is mandatory in serial because of
>>     console command line parameters and existing userspace expectations,
>>     it is the number one barrier to providing a shared ttyS namespace
>>     for mixed uart platforms.
>>
>>     Stable device order has a very real (and often unforeseen) maintenance
>>     burden.
>>
>>
>> Interesting. I wonder if these burdens are unique to serial or shared
>> by all the other subsystems that allow ordering? Maybe this is all
>> because of legacy reasons?
>
> Well, the specific issue is certainly unique to serial.
> But what I was suggesting is that 5 years from now, these patches
> could be the "legacy reasons" in mmc.
>
> FWIW, there is already a defacto expectation by boot configurations in the
> field that a given mmc block device is stable across boots. The reality
> is that 100000's of kernel command lines look like:
>
>         root=/dev/mmcblk0p2
>
> This was a recent regression fixed by Ulf in commit 9aaf3437aa72
> ("mmc: block: Use the mmc host device index as the mmcblk device index")

Ah.  Well, in this case it sounds like we've already got an
expectation of stable numbering from boot to boot.  I had missed Ulf's
patch, so I guess part 3 of my series isn't actually needed and can be
dropped.

So it's just a question of whether we allow people to manually specify
via device tree.


Note: if we really think using root=/dev/mmcblkNpM is a bad idea then
we should deprecate it and yell about it in the boot log.  Then 5 (or
20) years down the road we could remove the feature when the legacy
burden become a pain.  Note that even if we deprecated
root=/dev/mmcblkNpM I'd still love to see the numbering be consistent
to help folks parse dmesg.


Thanks for your thoughts!


-Doug

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 05:31:31PM -0700, Peter Hurley wrote:
> FWIW, there is already a defacto expectation by boot configurations in the
> field that a given mmc block device is stable across boots. The reality
> is that 100000's of kernel command lines look like:
> 
> 	root=/dev/mmcblk0p2

Thankfully, MMC does generally give a stable naming across reboots -
I have platforms with eMMC and SD (eg, the SDP4430 board which is in
the test farm) and only when things change in the kernel does the
MMC device name change.

Changes in device ordering can be provoked by the order in which
entries in the DT file appear, and hence the order in which the host
SD interfaces are probed by the kernel.

When it changed, I switched from using the device specifier to using
a UUID.  Now I have no problems since I no longer care which MMC
block device ends up as the SD card.

The kernel there is TFTP'd too.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Rob Herring]

On Fri, Apr 29, 2016 at 6:01 PM, Doug Anderson <dianders@chromium.org> wrote:
> Hi,
>
> On Fri, Apr 29, 2016 at 3:44 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> My reply would be... why should MMC have special handling that no
>> other subsystem has?
>
> No other subsystem?
>
> * i2c allows numbering devices by alias
> * rtc allows numbering devices by alias.
> * serial allows numbering devices by alias.
> * spi allows numbering devices by alias.
> * watchdog allows numbering devices by alias.
>
> ...at least that's my impression doing a grep for of_alias_get_id(),
> which I suggested earlier in this thread but apparently wasn't done.

IMO, we should remove most or all of these not add more. We shoud move
to identifying devices by other OS independent means. Peter already
pointed out why serial is a problem.

Rob

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Javier Martinez Canillas]

Hello Russell,

On Fri, Apr 29, 2016 at 6:16 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 02:56:38PM -0700, Doug Anderson wrote:
>> Russell,
>>
>> On Fri, Apr 29, 2016 at 2:50 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Fri, Apr 29, 2016 at 02:39:35PM -0700, Doug Anderson wrote:
>> > [didn't read most of your reply]
>> >
>> >> Really I just reposted it several times because I notice that you seem
>> >> to ignore many points of my emails.  I was really hoping to get you to
>> >> address this point.  I notice that you still didn't.  Either you are
>> >> just trying to annoy me, or you don't have an answer to how my patch
>> >> series hurts you.
>> >
>> > I don't see you treating Rob with the same contempt that you have
>> > treated me in this thread, despite Rob and myself both telling you
>> > basically the same thing.
>>
>> Rob wrote a nice thoughtful reply and I tried to give a nice
>> thoughtful reply back to him.  He raised some good points and I raised
>> some good points back to him.  I look forward to his future thoughts
>> on the topic.
>
> Meanwhile, I've pointed out that you appear to be coming from a
> misunderstanding (that's certainly clear because you believed
> initially that grub did something it doesn't), showing that the
> "problem" you have is no different from the majority of other
> systems running Linux, and you treat me with contempt.
>
> What are you going to do to resolve this?
>

Maybe a third opinion could make this conversation constructive again.

I think Doug's point is that using a UUID or labels for consistency is
orthogonal to having a deterministic numbering for MMC devices. And I
agree with his point of view for what is worth.

I understand that this not true for other systems and peripherals but
in the specific case of MMC, the changes are minimal as Doug's patches
have shown and even the technical manual of SoCs has an enumeration to
refer each SD/MMC slot.

So I think is fair to say that SD/MMC is different than say USB mass
storage devices as you mentioned, and having a consistent numbering is
very helpful for diagnostics and debugging purposes IMHO.

BTW, I use labels in all my systems because as you said it's nice to
be able to swap cards and not change the bootloader env vars, but I
see how having a deterministic numbering could be useful to others.

Best regards,
Javier

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 06:42:35PM -0400, Javier Martinez Canillas wrote:
> Maybe a third opinion could make this conversation constructive again.
> 
> I think Doug's point is that using a UUID or labels for consistency is
> orthogonal to having a deterministic numbering for MMC devices. And I
> agree with his point of view for what is worth.

Yes, it may be orthogonal, but there are two issues here:

1. How does the system know which MMC device to mount for its rootfs.

This is the point that I've picked up on, which has been solved for
years, and actually pre-dates MMC support in the kernel, and that is
mount by UUID.

The kernel itself has no support for mount-by-label, which is normally
solved by using an initramfs, which contains programs such as mount
etc which will scan the block devices looking for an appropriately
labelled filesystem.  Label has slightly more issues since its possible
that you could end up with two filesystems with the same label (eg, on
x86, you're migrating your disks, and you plug in a disk which has a
label of "/" but is not your intended rootfs.)

Of course, any scheme which relies on an identifier on the disk may
result in some kind of clash if another partition/disk has the same
identifier.

2. The identifier found in kernel messages for each MMC device.

This is where Doug and myself disagree.  I don't see this as a big
problem - the big problem is (1) above, which is the one which can
lead to a non-functional system.  I believe that the actual name
that we end up with is a cosmetic issue.

What I've been trying to point out is that the same cosmetic issue
occurs elsewhere in the kernel, particularly with disks on SATA
interfaces.  I've lost count of the number of times that my IDE
disks on one of my machines have changed between /dev/hda, /dev/hdc,
/dev/sda, /dev/sdc, etc.  Thankfully, these are part of a raid
array, and they are always constructed to appear as /dev/md* devices
which are the devices that are mounted.

The device names that they end up with depend on which drivers are
built-in to the kernel, and the order in which the device drivers
and devices are probed.  There's no way to tell the kernel "I want
PCI card X socket Y to be _this_ device name" and that's a concious
decision that was made years ago.

However, it's a cosmetic issue - reading the log reveals which is
which, and MMC is no different - the information required is in the
log.

Here's some material on the problem:

http://www.tldp.org/HOWTO/Partition/devices.html
http://tldp.org/HOWTO/Partition-Mass-Storage-Definitions-Naming-HOWTO/x99.html
https://lkml.org/lkml/1997/5/4/54
http://marc.info/?l=linux-raid&m=113595057816321&w=2

The first two show that it's well understood (and documented) that
storage devices are dynamically assigned and variable.

The third is an example of how old this problem is - almost twenty
years old, and it hasn't been "solved" on x86 except by using UUID/
labels.

The forth is an example of the "problem" that this dynamic device
assignment causes, and again shows that kernel folk have chosen
not to solve it by way of the problem still existing today.

I guess I don't see it as much of problem because I've been doing
this for over a decade.

Now, thinking outside the box - if it's desirable for eMMC to be
treated differently from regular MMC slots, maybe the solution to
this problem is to have eMMC occupy a separate namespace, rather
than using the /dev/mmcblk* namespace.  IOW, /dev/emmc* ?

The /dev/mmcblk* namespace was designed (by me) to be dynamic,
because MMC (not SD) bus structure allows for multiple cards on the
same MMC host interface, much like a SCSI bus allows for multiple
devices on the same cable.  Hence, tying individual mmcblkN to
the mmcN host interface is wrong.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Trent Piepho]

On Sat, 2016-04-30 at 11:48 +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 29, 2016 at 06:42:35PM -0400, Javier Martinez Canillas wrote:
> > Maybe a third opinion could make this conversation constructive again.

And maybe a forth.

> > I think Doug's point is that using a UUID or labels for consistency is
> > orthogonal to having a deterministic numbering for MMC devices. And I
> > agree with his point of view for what is worth.
> 
> Yes, it may be orthogonal, but there are two issues here:
> 
> 1. How does the system know which MMC device to mount for its rootfs.
> 
> This is the point that I've picked up on, which has been solved for
> years, and actually pre-dates MMC support in the kernel, and that is
> mount by UUID.

What about eMMC boot blocks and replay protected memory block?  These
are special sub-device like features of eMMC that provide storage from
different areas than the normal flash.  The kernel names them something
like "/dev/mmcblk0boot0" and "/dev/mmcblk1rpmb".

They typically don't have partition tables and in fact the kernel
xplicitly does not scan them for a partition table.  So how can they
have a UUID?

Suppose your device has two SD slots, neither with an SD card inserted
in it, one external and one internal behind a locked access panel.  They
serve different purposes.  How do you determine which is which via UUID
when they have no media?

> The kernel itself has no support for mount-by-label, which is normally
> solved by using an initramfs, which contains programs such as mount
> etc which will scan the block devices looking for an appropriately
> labelled filesystem.  Label has slightly more issues since its possible

But what is faster, using an initramfs that loads a working userspace
into RAM, scans the flash device for partition labels, determines the
device ID, and then switches to the real rootfs.  Or having the
bootloader, which already knows the partition the rootfs is in, tell the
kernel what device to mount from the beginning?

Which brings me to another reason for providing device enumeration
information via the device tree that isn't just about mounting the root
filesystem.

The bootloader will create an enumeration of devices so that it can
access them.  The kernel will also create an enumeration of the same
devices.  Should these enumerations be the same, or should they be
different?

Clearly there are advantages to the enumeration being the same.  It's
easier on users if device IDs can be the same between the two
environments, bootloader and kernel, the device can be accessed from.

It also makes it easier if information about a device needs to be passed
from the bootloader to the kernel.  This could be the root filesystem,
but that's not the only thing.  Console serial port is another.  But we
could also want to kernel to know which of the SoC's ports is connected
to the blank eMMC chip it should create a partition table on and format,
and which is connected to the SD card it should store logging data to.

I can't think of any advantage of the enumerations being different.

So if identical enumerations are desirable, how to achieve it?

One way would be to have the bootloader create its enumeration and then
throw it away when the kernel boots.  The the kernel creates a new
enumeration from scratch, using a different system with different code
and a different design, that happens to create the same enumeration that
the bootloader did.  This seems like a bad design to me.  Two different
code bases will need to kept in sync, to always to the same thing in a
different way.  It will be hard to avoid bugs from corner cases that
fail to produce the same enumerations.

Another way would be to have the bootloader tell the kernel what it
enumerated and then have the kernel use this enumeration.  This avoids
the need to keep two code bases in sync.  It avoids bugs where they fail
to produce the same enumeration.

And how to do this pass the enumeration from the bootloader to the
kernel?  The same way all other information from the bootloader is
passed to the kernel, via the device tree.

The alias system that already exists allows the bootloader to tell the
kernel about enumerations it has already created, which it must do since
it runs before the kernel, and would like the kernel to continue to use.

So this isn't just about finding the root filesystem.  It's about
passing enumeration information from the bootloader to the kernel.

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Pavel Machek]

On Fri 2016-04-29 19:12:48, Russell King - ARM Linux wrote:
> On Fri, Apr 29, 2016 at 10:32:15AM -0700, Douglas Anderson wrote:
> > This series picks patches from various different places to produce what
> > I consider the best solution to getting consistent mmc and mmcblk
> > ordering.
> > 
> > Why consistent ordering and why not just use UUIDs?  IMHO consistent
> > ordering solves a few different problems:
> 
> NAK.  Really.  Use UUIDs, that's the proper solution here.

Except that UUIDs do not solve the problem.

You have just booted of nfsroot, and you want to format u-SD card in
the external slot. How do you do that?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Rob Herring]

On Wed, May 4, 2016 at 2:18 AM, Pavel Machek <pavel@ucw.cz> wrote:
> On Fri 2016-04-29 19:12:48, Russell King - ARM Linux wrote:
>> On Fri, Apr 29, 2016 at 10:32:15AM -0700, Douglas Anderson wrote:
>> > This series picks patches from various different places to produce what
>> > I consider the best solution to getting consistent mmc and mmcblk
>> > ordering.
>> >
>> > Why consistent ordering and why not just use UUIDs?  IMHO consistent
>> > ordering solves a few different problems:
>>
>> NAK.  Really.  Use UUIDs, that's the proper solution here.
>
> Except that UUIDs do not solve the problem.
>
> You have just booted of nfsroot, and you want to format u-SD card in
> the external slot. How do you do that?

The same way you format a USB stick when you insert it.

If you have built-in versus removable, then we should expose that
information to userspace rather than some arbitrary encoding in DT
that 0 means built-in and 1 means removable. Or if you have multiple
slots, then use "label" to provide meaningful slot names.

Rob

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Pavel Machek]

On Wed 2016-05-04 07:25:42, Rob Herring wrote:
> On Wed, May 4, 2016 at 2:18 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > On Fri 2016-04-29 19:12:48, Russell King - ARM Linux wrote:
> >> On Fri, Apr 29, 2016 at 10:32:15AM -0700, Douglas Anderson wrote:
> >> > This series picks patches from various different places to produce what
> >> > I consider the best solution to getting consistent mmc and mmcblk
> >> > ordering.
> >> >
> >> > Why consistent ordering and why not just use UUIDs?  IMHO consistent
> >> > ordering solves a few different problems:
> >>
> >> NAK.  Really.  Use UUIDs, that's the proper solution here.
> >
> > Except that UUIDs do not solve the problem.
> >
> > You have just booted of nfsroot, and you want to format u-SD card in
> > the external slot. How do you do that?
> 
> The same way you format a USB stick when you insert it.

Well, and that actually brings related question "how do you format the
right USB stick if you have 5 of them connected". PCs don't have good
solution, but that does not mean it can't be solved.

And no, its not really the same. At least in N900 case, I'm not really
sure if you are expected to manipulate the u-SD card while the system
is on. It is under battery cover.

> If you have built-in versus removable, then we should expose that
> information to userspace rather than some arbitrary encoding in DT
> that 0 means built-in and 1 means removable. Or if you have multiple
> slots, then use "label" to provide meaningful slot names.

Yes, labels would be nice. Plus the slot numbers should be stable, so
that booting does not randomly break.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Måns Rullgård]

Douglas Anderson <dianders@chromium.org> writes:

> This series picks patches from various different places to produce what
> I consider the best solution to getting consistent mmc and mmcblk
> ordering.
>
> Why consistent ordering and why not just use UUIDs?  IMHO consistent
> ordering solves a few different problems:
>
> 1. For poor, feeble-minded humans like me, have sane numbering for
>    devices helps a lot.  When grepping through dmesg it's terribly handy
>    if a given SDMMC device has a consistent number.  I know that I can
>    do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about
>    the eMMC.  I know that I can do "dmesg | grep mmc1" to find info
>    about the SD card slot.  I don't want it to matter which one probed
>    first, I don't want it to matter if I'm working on a variant of the
>    hardware that has the SD card slot disabled, and I don't want to care
>    what my boot device was.  Worrying about what device number I got
>    increases my cognitive load.
>
> 2. There are cases where it's not trivially easy during development to
>    use the UUID.  Specifically I work a lot with coreboot / depthcharge
>    as a BIOS.  When configured properly, that BIOS has a nice feature to
>    allow you to fetch the kernel and kernel command line from TFTP by
>    pressing Ctrl-N.  In this particular case the BIOS doesn't actually
>    know which disk I'd like for my root filesystem, so it's not so easy
>    for it to put the right UUID into the command line.  For this
>    purpose, knowing that "mmcblk0" will always refer to eMMC is handy.
>
> Changes in v2:
> - Rebased atop mmc-next
> - Stat dynamic allocation after fixed allocation; thanks Wolfram!
> - rk3288 patch new for v2
>
> Douglas Anderson (1):
>   ARM: dts: rockchip: Add mmc aliases for rk3288 platform
>
> Jaehoon Chung (1):
>   Documentation: mmc: Document mmc aliases
>
> Stefan Agner (2):
>   mmc: read mmc alias from device tree
>   mmc: use SD/MMC host ID for block device name ID
>
>  Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++++++++++
>  arch/arm/boot/dts/rk3288.dtsi                 |  4 ++++
>  drivers/mmc/card/block.c                      |  2 +-
>  drivers/mmc/core/host.c                       | 17 ++++++++++++++++-
>  4 files changed, 32 insertions(+), 2 deletions(-)

Did anyone ever come up with an acceptable solution for this?  After
three years, I'm getting tired of rebasing these patches onto every new
kernel.

UUIDs or similar are NOT an option for multiple reasons:

- We have two rootfs partitions for ping-pong updates, so simply
  referring to "the thing with ID foo" doesn't work.

- Installing said updates needs direct access the device/partition,
  which may not even have a filesystem.

- The u-boot environment is stored in an eMMC "boot" partition, and
  userspace needs to know where to find it.

I'm sure I'm not the only one in a similar situation.

Russel, feel free to shout abuse at me.  I don't care, but it makes you
look stupid.

-- 
Måns Rullgård

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Tim Harvey]

Tim Harvey - Principal Software EngineerGateworks Corporation -
http://www.gateworks.com/3026 S. Higuera St. San Luis Obispo CA
93401805-781-2000
On Tue, Mar 5, 2019 at 4:39 AM Måns Rullgård <mans@mansr.com> wrote:
>
> Douglas Anderson <dianders@chromium.org> writes:
>
> > This series picks patches from various different places to produce what
> > I consider the best solution to getting consistent mmc and mmcblk
> > ordering.
> >
> > Why consistent ordering and why not just use UUIDs?  IMHO consistent
> > ordering solves a few different problems:
> >
> > 1. For poor, feeble-minded humans like me, have sane numbering for
> >    devices helps a lot.  When grepping through dmesg it's terribly handy
> >    if a given SDMMC device has a consistent number.  I know that I can
> >    do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about
> >    the eMMC.  I know that I can do "dmesg | grep mmc1" to find info
> >    about the SD card slot.  I don't want it to matter which one probed
> >    first, I don't want it to matter if I'm working on a variant of the
> >    hardware that has the SD card slot disabled, and I don't want to care
> >    what my boot device was.  Worrying about what device number I got
> >    increases my cognitive load.
> >
> > 2. There are cases where it's not trivially easy during development to
> >    use the UUID.  Specifically I work a lot with coreboot / depthcharge
> >    as a BIOS.  When configured properly, that BIOS has a nice feature to
> >    allow you to fetch the kernel and kernel command line from TFTP by
> >    pressing Ctrl-N.  In this particular case the BIOS doesn't actually
> >    know which disk I'd like for my root filesystem, so it's not so easy
> >    for it to put the right UUID into the command line.  For this
> >    purpose, knowing that "mmcblk0" will always refer to eMMC is handy.
> >
> > Changes in v2:
> > - Rebased atop mmc-next
> > - Stat dynamic allocation after fixed allocation; thanks Wolfram!
> > - rk3288 patch new for v2
> >
> > Douglas Anderson (1):
> >   ARM: dts: rockchip: Add mmc aliases for rk3288 platform
> >
> > Jaehoon Chung (1):
> >   Documentation: mmc: Document mmc aliases
> >
> > Stefan Agner (2):
> >   mmc: read mmc alias from device tree
> >   mmc: use SD/MMC host ID for block device name ID
> >
> >  Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++++++++++
> >  arch/arm/boot/dts/rk3288.dtsi                 |  4 ++++
> >  drivers/mmc/card/block.c                      |  2 +-
> >  drivers/mmc/core/host.c                       | 17 ++++++++++++++++-
> >  4 files changed, 32 insertions(+), 2 deletions(-)
>
> Did anyone ever come up with an acceptable solution for this?  After
> three years, I'm getting tired of rebasing these patches onto every new
> kernel.
>
> UUIDs or similar are NOT an option for multiple reasons:
>
> - We have two rootfs partitions for ping-pong updates, so simply
>   referring to "the thing with ID foo" doesn't work.
>
> - Installing said updates needs direct access the device/partition,
>   which may not even have a filesystem.
>
> - The u-boot environment is stored in an eMMC "boot" partition, and
>   userspace needs to know where to find it.
>
> I'm sure I'm not the only one in a similar situation.
>
> Russel, feel free to shout abuse at me.  I don't care, but it makes you
> look stupid.
>

Completely agree here - we need a dt solution that allows us to
specify ordering.

I support a variety of IMX6 boards where for PCB routing reasons the
bootable MMC device is not always the first sdhc (sometimes the first
one is an SDIO radio for example). It seems ridiculous that I can't
handle this with:

        aliases {
                mmc0 = &usdhc3; /* MMC boot device */
                mmc1 = &usdhc2; /* SDIO radio */
        };

I see the imx6q-dhcom-som added in
52c7a088badd665a09ca9307ffa91e88d5686a7d re-defines the default
imx6qdl.dtsi mmc0-mmc3 aiases but I don't see any handling of this in
code anywhere - am I missing something?

Marek, why did you change the alias ordering for imx6q-dhcom-som.dtsi?
(maybe your carrying around a patch to make this useful?)

+       aliases {
+               mmc0 = &usdhc2;
+               mmc1 = &usdhc3;
+               mmc2 = &usdhc4;
+               mmc3 = &usdhc1;
+       };

Regards,

Tim

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Marek Vasut]

On 3/15/19 10:52 PM, Tim Harvey wrote:
> Tim Harvey - Principal Software EngineerGateworks Corporation -
> http://www.gateworks.com/3026 S. Higuera St. San Luis Obispo CA
> 93401805-781-2000
> On Tue, Mar 5, 2019 at 4:39 AM Måns Rullgård <mans@mansr.com> wrote:
>>
>> Douglas Anderson <dianders@chromium.org> writes:
>>
>>> This series picks patches from various different places to produce what
>>> I consider the best solution to getting consistent mmc and mmcblk
>>> ordering.
>>>
>>> Why consistent ordering and why not just use UUIDs?  IMHO consistent
>>> ordering solves a few different problems:
>>>
>>> 1. For poor, feeble-minded humans like me, have sane numbering for
>>>    devices helps a lot.  When grepping through dmesg it's terribly handy
>>>    if a given SDMMC device has a consistent number.  I know that I can
>>>    do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about
>>>    the eMMC.  I know that I can do "dmesg | grep mmc1" to find info
>>>    about the SD card slot.  I don't want it to matter which one probed
>>>    first, I don't want it to matter if I'm working on a variant of the
>>>    hardware that has the SD card slot disabled, and I don't want to care
>>>    what my boot device was.  Worrying about what device number I got
>>>    increases my cognitive load.
>>>
>>> 2. There are cases where it's not trivially easy during development to
>>>    use the UUID.  Specifically I work a lot with coreboot / depthcharge
>>>    as a BIOS.  When configured properly, that BIOS has a nice feature to
>>>    allow you to fetch the kernel and kernel command line from TFTP by
>>>    pressing Ctrl-N.  In this particular case the BIOS doesn't actually
>>>    know which disk I'd like for my root filesystem, so it's not so easy
>>>    for it to put the right UUID into the command line.  For this
>>>    purpose, knowing that "mmcblk0" will always refer to eMMC is handy.
>>>
>>> Changes in v2:
>>> - Rebased atop mmc-next
>>> - Stat dynamic allocation after fixed allocation; thanks Wolfram!
>>> - rk3288 patch new for v2
>>>
>>> Douglas Anderson (1):
>>>   ARM: dts: rockchip: Add mmc aliases for rk3288 platform
>>>
>>> Jaehoon Chung (1):
>>>   Documentation: mmc: Document mmc aliases
>>>
>>> Stefan Agner (2):
>>>   mmc: read mmc alias from device tree
>>>   mmc: use SD/MMC host ID for block device name ID
>>>
>>>  Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++++++++++
>>>  arch/arm/boot/dts/rk3288.dtsi                 |  4 ++++
>>>  drivers/mmc/card/block.c                      |  2 +-
>>>  drivers/mmc/core/host.c                       | 17 ++++++++++++++++-
>>>  4 files changed, 32 insertions(+), 2 deletions(-)
>>
>> Did anyone ever come up with an acceptable solution for this?  After
>> three years, I'm getting tired of rebasing these patches onto every new
>> kernel.
>>
>> UUIDs or similar are NOT an option for multiple reasons:
>>
>> - We have two rootfs partitions for ping-pong updates, so simply
>>   referring to "the thing with ID foo" doesn't work.
>>
>> - Installing said updates needs direct access the device/partition,
>>   which may not even have a filesystem.
>>
>> - The u-boot environment is stored in an eMMC "boot" partition, and
>>   userspace needs to know where to find it.
>>
>> I'm sure I'm not the only one in a similar situation.
>>
>> Russel, feel free to shout abuse at me.  I don't care, but it makes you
>> look stupid.
>>
> 
> Completely agree here - we need a dt solution that allows us to
> specify ordering.

Nope, ordering would be a policy and does not describe hardware, thus it
shouldn't be in the DT. Use UUID or PARTUUID, they apply both to raw FS
(fsuuid) and to partitions (part uuid). Linux kernel can mount FS using
PARTUUID, to support UUID you need initramfs.

> I support a variety of IMX6 boards where for PCB routing reasons the
> bootable MMC device is not always the first sdhc (sometimes the first
> one is an SDIO radio for example). It seems ridiculous that I can't
> handle this with:
> 
>         aliases {
>                 mmc0 = &usdhc3; /* MMC boot device */
>                 mmc1 = &usdhc2; /* SDIO radio */
>         };
> 
> I see the imx6q-dhcom-som added in
> 52c7a088badd665a09ca9307ffa91e88d5686a7d re-defines the default
> imx6qdl.dtsi mmc0-mmc3 aiases but I don't see any handling of this in
> code anywhere - am I missing something?
> 
> Marek, why did you change the alias ordering for imx6q-dhcom-som.dtsi?
> (maybe your carrying around a patch to make this useful?)

Nope, likely a cleanup remnant which can be dropped.

> +       aliases {
> +               mmc0 = &usdhc2;
> +               mmc1 = &usdhc3;
> +               mmc2 = &usdhc4;
> +               mmc3 = &usdhc1;
> +       };
> 
> Regards,
> 
> Tim
> 


-- 
Best regards,
Marek Vasut

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Tim Harvey]

Tim Harvey - Principal Software EngineerGateworks Corporation -
http://www.gateworks.com/3026 S. Higuera St. San Luis Obispo CA
93401805-781-2000
On Fri, Mar 15, 2019 at 4:00 PM Marek Vasut <marex@denx.de> wrote:
>
> On 3/15/19 10:52 PM, Tim Harvey wrote:
> > Tim Harvey - Principal Software EngineerGateworks Corporation -
> > http://www.gateworks.com/3026 S. Higuera St. San Luis Obispo CA
> > 93401805-781-2000
> > On Tue, Mar 5, 2019 at 4:39 AM Måns Rullgård <mans@mansr.com> wrote:
> >>
> >> Douglas Anderson <dianders@chromium.org> writes:
> >>
> >>> This series picks patches from various different places to produce what
> >>> I consider the best solution to getting consistent mmc and mmcblk
> >>> ordering.
> >>>
> >>> Why consistent ordering and why not just use UUIDs?  IMHO consistent
> >>> ordering solves a few different problems:
> >>>
> >>> 1. For poor, feeble-minded humans like me, have sane numbering for
> >>>    devices helps a lot.  When grepping through dmesg it's terribly handy
> >>>    if a given SDMMC device has a consistent number.  I know that I can
> >>>    do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about
> >>>    the eMMC.  I know that I can do "dmesg | grep mmc1" to find info
> >>>    about the SD card slot.  I don't want it to matter which one probed
> >>>    first, I don't want it to matter if I'm working on a variant of the
> >>>    hardware that has the SD card slot disabled, and I don't want to care
> >>>    what my boot device was.  Worrying about what device number I got
> >>>    increases my cognitive load.
> >>>
> >>> 2. There are cases where it's not trivially easy during development to
> >>>    use the UUID.  Specifically I work a lot with coreboot / depthcharge
> >>>    as a BIOS.  When configured properly, that BIOS has a nice feature to
> >>>    allow you to fetch the kernel and kernel command line from TFTP by
> >>>    pressing Ctrl-N.  In this particular case the BIOS doesn't actually
> >>>    know which disk I'd like for my root filesystem, so it's not so easy
> >>>    for it to put the right UUID into the command line.  For this
> >>>    purpose, knowing that "mmcblk0" will always refer to eMMC is handy.
> >>>
> >>> Changes in v2:
> >>> - Rebased atop mmc-next
> >>> - Stat dynamic allocation after fixed allocation; thanks Wolfram!
> >>> - rk3288 patch new for v2
> >>>
> >>> Douglas Anderson (1):
> >>>   ARM: dts: rockchip: Add mmc aliases for rk3288 platform
> >>>
> >>> Jaehoon Chung (1):
> >>>   Documentation: mmc: Document mmc aliases
> >>>
> >>> Stefan Agner (2):
> >>>   mmc: read mmc alias from device tree
> >>>   mmc: use SD/MMC host ID for block device name ID
> >>>
> >>>  Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++++++++++
> >>>  arch/arm/boot/dts/rk3288.dtsi                 |  4 ++++
> >>>  drivers/mmc/card/block.c                      |  2 +-
> >>>  drivers/mmc/core/host.c                       | 17 ++++++++++++++++-
> >>>  4 files changed, 32 insertions(+), 2 deletions(-)
> >>
> >> Did anyone ever come up with an acceptable solution for this?  After
> >> three years, I'm getting tired of rebasing these patches onto every new
> >> kernel.
> >>
> >> UUIDs or similar are NOT an option for multiple reasons:
> >>
> >> - We have two rootfs partitions for ping-pong updates, so simply
> >>   referring to "the thing with ID foo" doesn't work.
> >>
> >> - Installing said updates needs direct access the device/partition,
> >>   which may not even have a filesystem.
> >>
> >> - The u-boot environment is stored in an eMMC "boot" partition, and
> >>   userspace needs to know where to find it.
> >>
> >> I'm sure I'm not the only one in a similar situation.
> >>
> >> Russel, feel free to shout abuse at me.  I don't care, but it makes you
> >> look stupid.
> >>
> >
> > Completely agree here - we need a dt solution that allows us to
> > specify ordering.
>
> Nope, ordering would be a policy and does not describe hardware, thus it
> shouldn't be in the DT. Use UUID or PARTUUID, they apply both to raw FS
> (fsuuid) and to partitions (part uuid). Linux kernel can mount FS using
> PARTUUID, to support UUID you need initramfs.

Marek,

Sure... a 'policy' decision would be which bootable device to boot
from but the issue I see that needs solving is for the vendor to be
able to describe via dt what devices are bootable for MMC (an SDIO
wifi device is not bootable yet a eMMC/microSD is).

Isn't this exactly the same issue as what the stdout-path specifies in
the chosen node? Modern SoC's have multiple UART's yet boot firmware
needs to know which one is the serial console just like boot firmware
should be able to figure out what device or devices are bootable.

Perhaps we can add a 'bootdev-path' in the chosen node?

Regards,

Tim

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Doug Anderson]

Hi,

On Fri, Mar 15, 2019 at 4:00 PM Marek Vasut <marex@denx.de> wrote:
>
> > Completely agree here - we need a dt solution that allows us to
> > specify ordering.
>
> Nope, ordering would be a policy and does not describe hardware, thus it
> shouldn't be in the DT. Use UUID or PARTUUID, they apply both to raw FS
> (fsuuid) and to partitions (part uuid). Linux kernel can mount FS using
> PARTUUID, to support UUID you need initramfs.

Two thoughts about that:

1. Some amount of policy is allowed in device tree.  At some point in
time there was a big discussion about the need for a separate "config
tree" that was totally parallel to the device tree so we could put
policy stuff in that.  Nobody wanted that and (as I recall) it was
agreed that in some cases policy could go there if that policy
expressed policy that was the generic intent of how the board ought to
be run.  I believe this is how things like the assigned-clocks is
justified.

2. In some cases this number does describe the hardware.  You look at
the hardware reference manual and see that there are 3 MMC
controllers: 0, 1, and 2.  In such cases it seems like it's an OK
description of the hardware to encode this info into the DTS.

...from what I recall, one big objection is for SoCs that didn't just
have numbers for their controllers.  AKA I think some SoCs might call
their controllers the "eMMC" controller, the "SD" controller, and the
"SDIO" controller.  They may be nearly the same hardware, but perhaps
the SoC allows for a GPIO interrupt on the SDIO controller and perhaps
the eMMC controller exposes the strobe line or has an 8-bit wide
datapath.  In this case making up numbers does become a bit more
arbitrary and folks didn't like it.

IIRC there was general consensus that it'd be OK to somehow specify a
string (AKA non-numeric) name for different SD controllers.  I don't
have pointers to that conversation offhand and it's possible I
imagined it.


-Doug

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Marek Vasut]

On 3/16/19 1:22 PM, Måns Rullgård wrote:
> Marek Vasut <marex@denx.de> writes:
> 
>> On 3/15/19 10:52 PM, Tim Harvey wrote:
>>> Tim Harvey - Principal Software EngineerGateworks Corporation -
>>> http://www.gateworks.com/3026 S. Higuera St. San Luis Obispo CA
>>> 93401805-781-2000
>>> On Tue, Mar 5, 2019 at 4:39 AM Måns Rullgård <mans@mansr.com> wrote:
>>>>
>>>> Douglas Anderson <dianders@chromium.org> writes:
>>>>
>>>>> This series picks patches from various different places to produce what
>>>>> I consider the best solution to getting consistent mmc and mmcblk
>>>>> ordering.
>>>>>
>>>>> Why consistent ordering and why not just use UUIDs?  IMHO consistent
>>>>> ordering solves a few different problems:
>>>>>
>>>>> 1. For poor, feeble-minded humans like me, have sane numbering for
>>>>>    devices helps a lot.  When grepping through dmesg it's terribly handy
>>>>>    if a given SDMMC device has a consistent number.  I know that I can
>>>>>    do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about
>>>>>    the eMMC.  I know that I can do "dmesg | grep mmc1" to find info
>>>>>    about the SD card slot.  I don't want it to matter which one probed
>>>>>    first, I don't want it to matter if I'm working on a variant of the
>>>>>    hardware that has the SD card slot disabled, and I don't want to care
>>>>>    what my boot device was.  Worrying about what device number I got
>>>>>    increases my cognitive load.
>>>>>
>>>>> 2. There are cases where it's not trivially easy during development to
>>>>>    use the UUID.  Specifically I work a lot with coreboot / depthcharge
>>>>>    as a BIOS.  When configured properly, that BIOS has a nice feature to
>>>>>    allow you to fetch the kernel and kernel command line from TFTP by
>>>>>    pressing Ctrl-N.  In this particular case the BIOS doesn't actually
>>>>>    know which disk I'd like for my root filesystem, so it's not so easy
>>>>>    for it to put the right UUID into the command line.  For this
>>>>>    purpose, knowing that "mmcblk0" will always refer to eMMC is handy.
>>>>>
>>>>> Changes in v2:
>>>>> - Rebased atop mmc-next
>>>>> - Stat dynamic allocation after fixed allocation; thanks Wolfram!
>>>>> - rk3288 patch new for v2
>>>>>
>>>>> Douglas Anderson (1):
>>>>>   ARM: dts: rockchip: Add mmc aliases for rk3288 platform
>>>>>
>>>>> Jaehoon Chung (1):
>>>>>   Documentation: mmc: Document mmc aliases
>>>>>
>>>>> Stefan Agner (2):
>>>>>   mmc: read mmc alias from device tree
>>>>>   mmc: use SD/MMC host ID for block device name ID
>>>>>
>>>>>  Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++++++++++
>>>>>  arch/arm/boot/dts/rk3288.dtsi                 |  4 ++++
>>>>>  drivers/mmc/card/block.c                      |  2 +-
>>>>>  drivers/mmc/core/host.c                       | 17 ++++++++++++++++-
>>>>>  4 files changed, 32 insertions(+), 2 deletions(-)
>>>>
>>>> Did anyone ever come up with an acceptable solution for this?  After
>>>> three years, I'm getting tired of rebasing these patches onto every new
>>>> kernel.
>>>>
>>>> UUIDs or similar are NOT an option for multiple reasons:
>>>>
>>>> - We have two rootfs partitions for ping-pong updates, so simply
>>>>   referring to "the thing with ID foo" doesn't work.
>>>>
>>>> - Installing said updates needs direct access the device/partition,
>>>>   which may not even have a filesystem.
>>>>
>>>> - The u-boot environment is stored in an eMMC "boot" partition, and
>>>>   userspace needs to know where to find it.
>>>>
>>>> I'm sure I'm not the only one in a similar situation.
>>>>
>>>> Russel, feel free to shout abuse at me.  I don't care, but it makes you
>>>> look stupid.
>>>>
>>>
>>> Completely agree here - we need a dt solution that allows us to
>>> specify ordering.
>>
>> Nope, ordering would be a policy and does not describe hardware, thus it
>> shouldn't be in the DT. Use UUID or PARTUUID, they apply both to raw FS
>> (fsuuid) and to partitions (part uuid). Linux kernel can mount FS using
>> PARTUUID, to support UUID you need initramfs.
> 
> That doesn't address how to find eMMC boot partitions.

If you have a FS or partition table there, it does.
If you don't, I agree ... that's a problem.

> I don't care the slightest what the numbering is, as long as it is
> stable.  On some hardware, with an unpatched kernel, the mmc device
> numbering changes depending on whether or not an SD card is inserted on
> boot.  Getting rid of that behaviour is really all I want.

Agreed, that would be an improvement.

-- 
Best regards,
Marek Vasut

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Russell King - ARM Linux admin]

On Sat, Mar 16, 2019 at 01:33:58PM +0100, Marek Vasut wrote:
> If you have a FS or partition table there, it does.
> If you don't, I agree ... that's a problem.

eMMC boot partitions are called mmcblkXbootY, and unless you have more
than one eMMC device on the system, they can be found either by looking
for /dev/mmcblk*boot* or by querying udev.  The advantage of using udev
is you can discover the physical device behind it by looking at DEVPATH,
ID_PATH, etc, but you may not have that installed on an embedded device.

However, as I say, just looking for /dev/mmcblk*boot* is sufficient to
find the eMMC boot partitions where there is just one eMMC device
present (which seems to be the standard setup.)

> > I don't care the slightest what the numbering is, as long as it is
> > stable.  On some hardware, with an unpatched kernel, the mmc device
> > numbering changes depending on whether or not an SD card is inserted on
> > boot.  Getting rid of that behaviour is really all I want.
> 
> Agreed, that would be an improvement.

The mmc device numbering was tied to the mmc host numbering a while back
and the order that the hosts are probed should be completely independent
of whether a card is inserted or not:

        snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
                 "mmcblk%u%s", card->host->index, subname ? subname : "");

        snprintf(rpmb_name, sizeof(rpmb_name),
                 "mmcblk%u%s", card->host->index, subname ? subname : "");

I suspect that Mans is quoting something from the dim and distant past
to confuse the issue - as shown above, it is now dependent on the host
numbering order not the order in which cards are inserted.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Stefan Agner]

On 16.03.2019 16:39, Russell King - ARM Linux admin wrote:
> On Sat, Mar 16, 2019 at 01:33:58PM +0100, Marek Vasut wrote:
>> If you have a FS or partition table there, it does.
>> If you don't, I agree ... that's a problem.
> 
> eMMC boot partitions are called mmcblkXbootY, and unless you have more
> than one eMMC device on the system, they can be found either by looking
> for /dev/mmcblk*boot* or by querying udev.  The advantage of using udev
> is you can discover the physical device behind it by looking at DEVPATH,
> ID_PATH, etc, but you may not have that installed on an embedded device.
> 
> However, as I say, just looking for /dev/mmcblk*boot* is sufficient to
> find the eMMC boot partitions where there is just one eMMC device
> present (which seems to be the standard setup.)
> 
>> > I don't care the slightest what the numbering is, as long as it is
>> > stable.  On some hardware, with an unpatched kernel, the mmc device
>> > numbering changes depending on whether or not an SD card is inserted on
>> > boot.  Getting rid of that behaviour is really all I want.
>>
>> Agreed, that would be an improvement.
> 
> The mmc device numbering was tied to the mmc host numbering a while back
> and the order that the hosts are probed should be completely independent
> of whether a card is inserted or not:
> 
>         snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
>                  "mmcblk%u%s", card->host->index, subname ? subname : "");
> 
>         snprintf(rpmb_name, sizeof(rpmb_name),
>                  "mmcblk%u%s", card->host->index, subname ? subname : "");
> 
> I suspect that Mans is quoting something from the dim and distant past
> to confuse the issue - as shown above, it is now dependent on the host
> numbering order not the order in which cards are inserted.

Commit 9aaf3437aa72 ("mmc: block: Use the mmc host device index as the
mmcblk device index") which came in with v4.6 enables constant mmc block
device numbering. I can confirm that it works nicely, and it improved
the situation a lot.

That being said, we still use a patch downstream which allows
renumbering using an alias. We deal with a bunch of different boards
with different SoC's. I have a couple of SD cards with various rootfs
and use internal eMMC boot quite often as well. Remembering which board
uses which numbering is a pain. Maintaining a patch is just easier...
Furthermore, U-Boot allows reordering and all boards I deal with use mmc
0 for the internal eMMC. The aliases allow consistency.

--
Stefan

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Russell King - ARM Linux admin]

On Sun, Mar 17, 2019 at 04:05:14PM +0100, Stefan Agner wrote:
> On 16.03.2019 16:39, Russell King - ARM Linux admin wrote:
> > On Sat, Mar 16, 2019 at 01:33:58PM +0100, Marek Vasut wrote:
> >> If you have a FS or partition table there, it does.
> >> If you don't, I agree ... that's a problem.
> > 
> > eMMC boot partitions are called mmcblkXbootY, and unless you have more
> > than one eMMC device on the system, they can be found either by looking
> > for /dev/mmcblk*boot* or by querying udev.  The advantage of using udev
> > is you can discover the physical device behind it by looking at DEVPATH,
> > ID_PATH, etc, but you may not have that installed on an embedded device.
> > 
> > However, as I say, just looking for /dev/mmcblk*boot* is sufficient to
> > find the eMMC boot partitions where there is just one eMMC device
> > present (which seems to be the standard setup.)
> > 
> >> > I don't care the slightest what the numbering is, as long as it is
> >> > stable.  On some hardware, with an unpatched kernel, the mmc device
> >> > numbering changes depending on whether or not an SD card is inserted on
> >> > boot.  Getting rid of that behaviour is really all I want.
> >>
> >> Agreed, that would be an improvement.
> > 
> > The mmc device numbering was tied to the mmc host numbering a while back
> > and the order that the hosts are probed should be completely independent
> > of whether a card is inserted or not:
> > 
> >         snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
> >                  "mmcblk%u%s", card->host->index, subname ? subname : "");
> > 
> >         snprintf(rpmb_name, sizeof(rpmb_name),
> >                  "mmcblk%u%s", card->host->index, subname ? subname : "");
> > 
> > I suspect that Mans is quoting something from the dim and distant past
> > to confuse the issue - as shown above, it is now dependent on the host
> > numbering order not the order in which cards are inserted.
> 
> Commit 9aaf3437aa72 ("mmc: block: Use the mmc host device index as the
> mmcblk device index") which came in with v4.6 enables constant mmc block
> device numbering. I can confirm that it works nicely, and it improved
> the situation a lot.
> 
> That being said, we still use a patch downstream which allows
> renumbering using an alias. We deal with a bunch of different boards
> with different SoC's. I have a couple of SD cards with various rootfs
> and use internal eMMC boot quite often as well. Remembering which board
> uses which numbering is a pain. Maintaining a patch is just easier...
> Furthermore, U-Boot allows reordering and all boards I deal with use mmc
> 0 for the internal eMMC. The aliases allow consistency.

Maybe eMMC should've been given a different block device name?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Marek Vasut]

On 3/17/19 4:43 PM, Russell King - ARM Linux admin wrote:
> On Sun, Mar 17, 2019 at 04:05:14PM +0100, Stefan Agner wrote:
>> On 16.03.2019 16:39, Russell King - ARM Linux admin wrote:
>>> On Sat, Mar 16, 2019 at 01:33:58PM +0100, Marek Vasut wrote:
>>>> If you have a FS or partition table there, it does.
>>>> If you don't, I agree ... that's a problem.
>>>
>>> eMMC boot partitions are called mmcblkXbootY, and unless you have more
>>> than one eMMC device on the system, they can be found either by looking
>>> for /dev/mmcblk*boot* or by querying udev.  The advantage of using udev
>>> is you can discover the physical device behind it by looking at DEVPATH,
>>> ID_PATH, etc, but you may not have that installed on an embedded device.
>>>
>>> However, as I say, just looking for /dev/mmcblk*boot* is sufficient to
>>> find the eMMC boot partitions where there is just one eMMC device
>>> present (which seems to be the standard setup.)
>>>
>>>>> I don't care the slightest what the numbering is, as long as it is
>>>>> stable.  On some hardware, with an unpatched kernel, the mmc device
>>>>> numbering changes depending on whether or not an SD card is inserted on
>>>>> boot.  Getting rid of that behaviour is really all I want.
>>>>
>>>> Agreed, that would be an improvement.
>>>
>>> The mmc device numbering was tied to the mmc host numbering a while back
>>> and the order that the hosts are probed should be completely independent
>>> of whether a card is inserted or not:
>>>
>>>         snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
>>>                  "mmcblk%u%s", card->host->index, subname ? subname : "");
>>>
>>>         snprintf(rpmb_name, sizeof(rpmb_name),
>>>                  "mmcblk%u%s", card->host->index, subname ? subname : "");
>>>
>>> I suspect that Mans is quoting something from the dim and distant past
>>> to confuse the issue - as shown above, it is now dependent on the host
>>> numbering order not the order in which cards are inserted.
>>
>> Commit 9aaf3437aa72 ("mmc: block: Use the mmc host device index as the
>> mmcblk device index") which came in with v4.6 enables constant mmc block
>> device numbering. I can confirm that it works nicely, and it improved
>> the situation a lot.
>>
>> That being said, we still use a patch downstream which allows
>> renumbering using an alias. We deal with a bunch of different boards
>> with different SoC's. I have a couple of SD cards with various rootfs
>> and use internal eMMC boot quite often as well. Remembering which board
>> uses which numbering is a pain. Maintaining a patch is just easier...
>> Furthermore, U-Boot allows reordering and all boards I deal with use mmc
>> 0 for the internal eMMC. The aliases allow consistency.
> 
> Maybe eMMC should've been given a different block device name?

I presume that's because they have hardware and software partitioning
and that's why you want to discern those two.

-- 
Best regards,
Marek Vasut

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Måns Rullgård]

Stefan Agner <stefan@agner.ch> writes:

> On 16.03.2019 16:39, Russell King - ARM Linux admin wrote:
>> On Sat, Mar 16, 2019 at 01:33:58PM +0100, Marek Vasut wrote:
>>> If you have a FS or partition table there, it does.
>>> If you don't, I agree ... that's a problem.
>> 
>> eMMC boot partitions are called mmcblkXbootY, and unless you have more
>> than one eMMC device on the system, they can be found either by looking
>> for /dev/mmcblk*boot* or by querying udev.  The advantage of using udev
>> is you can discover the physical device behind it by looking at DEVPATH,
>> ID_PATH, etc, but you may not have that installed on an embedded device.
>> 
>> However, as I say, just looking for /dev/mmcblk*boot* is sufficient to
>> find the eMMC boot partitions where there is just one eMMC device
>> present (which seems to be the standard setup.)
>> 
>>> > I don't care the slightest what the numbering is, as long as it is
>>> > stable.  On some hardware, with an unpatched kernel, the mmc device
>>> > numbering changes depending on whether or not an SD card is inserted on
>>> > boot.  Getting rid of that behaviour is really all I want.
>>>
>>> Agreed, that would be an improvement.
>> 
>> The mmc device numbering was tied to the mmc host numbering a while back
>> and the order that the hosts are probed should be completely independent
>> of whether a card is inserted or not:
>> 
>>         snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
>>                  "mmcblk%u%s", card->host->index, subname ? subname : "");
>> 
>>         snprintf(rpmb_name, sizeof(rpmb_name),
>>                  "mmcblk%u%s", card->host->index, subname ? subname : "");
>> 
>> I suspect that Mans is quoting something from the dim and distant past
>> to confuse the issue - as shown above, it is now dependent on the host
>> numbering order not the order in which cards are inserted.
>
> Commit 9aaf3437aa72 ("mmc: block: Use the mmc host device index as the
> mmcblk device index") which came in with v4.6 enables constant mmc block
> device numbering. I can confirm that it works nicely, and it improved
> the situation a lot.

That's the answer I was looking for.  I guess we can drop these patches
from our kernels then.

> That being said, we still use a patch downstream which allows
> renumbering using an alias. We deal with a bunch of different boards
> with different SoC's. I have a couple of SD cards with various rootfs
> and use internal eMMC boot quite often as well. Remembering which board
> uses which numbering is a pain. Maintaining a patch is just easier...
> Furthermore, U-Boot allows reordering and all boards I deal with use mmc
> 0 for the internal eMMC. The aliases allow consistency.

Since pretty much every other device type supports renumbering with DT
aliases, it would make sense to do this for mmc as well.

-- 
Måns Rullgård

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Russell King - ARM Linux admin]

On Sun, Mar 17, 2019 at 04:48:24PM +0000, Måns Rullgård wrote:
> Stefan Agner <stefan@agner.ch> writes:
> 
> > On 16.03.2019 16:39, Russell King - ARM Linux admin wrote:
> >> On Sat, Mar 16, 2019 at 01:33:58PM +0100, Marek Vasut wrote:
> >>> If you have a FS or partition table there, it does.
> >>> If you don't, I agree ... that's a problem.
> >> 
> >> eMMC boot partitions are called mmcblkXbootY, and unless you have more
> >> than one eMMC device on the system, they can be found either by looking
> >> for /dev/mmcblk*boot* or by querying udev.  The advantage of using udev
> >> is you can discover the physical device behind it by looking at DEVPATH,
> >> ID_PATH, etc, but you may not have that installed on an embedded device.
> >> 
> >> However, as I say, just looking for /dev/mmcblk*boot* is sufficient to
> >> find the eMMC boot partitions where there is just one eMMC device
> >> present (which seems to be the standard setup.)
> >> 
> >>> > I don't care the slightest what the numbering is, as long as it is
> >>> > stable.  On some hardware, with an unpatched kernel, the mmc device
> >>> > numbering changes depending on whether or not an SD card is inserted on
> >>> > boot.  Getting rid of that behaviour is really all I want.
> >>>
> >>> Agreed, that would be an improvement.
> >> 
> >> The mmc device numbering was tied to the mmc host numbering a while back
> >> and the order that the hosts are probed should be completely independent
> >> of whether a card is inserted or not:
> >> 
> >>         snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
> >>                  "mmcblk%u%s", card->host->index, subname ? subname : "");
> >> 
> >>         snprintf(rpmb_name, sizeof(rpmb_name),
> >>                  "mmcblk%u%s", card->host->index, subname ? subname : "");
> >> 
> >> I suspect that Mans is quoting something from the dim and distant past
> >> to confuse the issue - as shown above, it is now dependent on the host
> >> numbering order not the order in which cards are inserted.
> >
> > Commit 9aaf3437aa72 ("mmc: block: Use the mmc host device index as the
> > mmcblk device index") which came in with v4.6 enables constant mmc block
> > device numbering. I can confirm that it works nicely, and it improved
> > the situation a lot.
> 
> That's the answer I was looking for.  I guess we can drop these patches
> from our kernels then.
> 
> > That being said, we still use a patch downstream which allows
> > renumbering using an alias. We deal with a bunch of different boards
> > with different SoC's. I have a couple of SD cards with various rootfs
> > and use internal eMMC boot quite often as well. Remembering which board
> > uses which numbering is a pain. Maintaining a patch is just easier...
> > Furthermore, U-Boot allows reordering and all boards I deal with use mmc
> > 0 for the internal eMMC. The aliases allow consistency.
> 
> Since pretty much every other device type supports renumbering with DT
> aliases, it would make sense to do this for mmc as well.

SATA does not.  SCSI devices, whether they are disks, cdroms, tape
drives or whatever have always been allocated dynamically in the
order that they are discovered.

Ethernet also does not, and davem remains opposed the idea of fixed
allocation in the kernel.

It's only a minority that demand fixed enumeration of devices.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Tim Harvey]

On Sun, Mar 17, 2019 at 10:00 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Sun, Mar 17, 2019 at 04:48:24PM +0000, Måns Rullgård wrote:
> > Stefan Agner <stefan@agner.ch> writes:
> >
> > > On 16.03.2019 16:39, Russell King - ARM Linux admin wrote:
> > >> On Sat, Mar 16, 2019 at 01:33:58PM +0100, Marek Vasut wrote:
> > >>> If you have a FS or partition table there, it does.
> > >>> If you don't, I agree ... that's a problem.
> > >>
> > >> eMMC boot partitions are called mmcblkXbootY, and unless you have more
> > >> than one eMMC device on the system, they can be found either by looking
> > >> for /dev/mmcblk*boot* or by querying udev.  The advantage of using udev
> > >> is you can discover the physical device behind it by looking at DEVPATH,
> > >> ID_PATH, etc, but you may not have that installed on an embedded device.
> > >>
> > >> However, as I say, just looking for /dev/mmcblk*boot* is sufficient to
> > >> find the eMMC boot partitions where there is just one eMMC device
> > >> present (which seems to be the standard setup.)
> > >>
> > >>> > I don't care the slightest what the numbering is, as long as it is
> > >>> > stable.  On some hardware, with an unpatched kernel, the mmc device
> > >>> > numbering changes depending on whether or not an SD card is inserted on
> > >>> > boot.  Getting rid of that behaviour is really all I want.
> > >>>
> > >>> Agreed, that would be an improvement.
> > >>
> > >> The mmc device numbering was tied to the mmc host numbering a while back
> > >> and the order that the hosts are probed should be completely independent
> > >> of whether a card is inserted or not:
> > >>
> > >>         snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
> > >>                  "mmcblk%u%s", card->host->index, subname ? subname : "");
> > >>
> > >>         snprintf(rpmb_name, sizeof(rpmb_name),
> > >>                  "mmcblk%u%s", card->host->index, subname ? subname : "");
> > >>
> > >> I suspect that Mans is quoting something from the dim and distant past
> > >> to confuse the issue - as shown above, it is now dependent on the host
> > >> numbering order not the order in which cards are inserted.
> > >
> > > Commit 9aaf3437aa72 ("mmc: block: Use the mmc host device index as the
> > > mmcblk device index") which came in with v4.6 enables constant mmc block
> > > device numbering. I can confirm that it works nicely, and it improved
> > > the situation a lot.
> >
> > That's the answer I was looking for.  I guess we can drop these patches
> > from our kernels then.
> >
> > > That being said, we still use a patch downstream which allows
> > > renumbering using an alias. We deal with a bunch of different boards
> > > with different SoC's. I have a couple of SD cards with various rootfs
> > > and use internal eMMC boot quite often as well. Remembering which board
> > > uses which numbering is a pain. Maintaining a patch is just easier...
> > > Furthermore, U-Boot allows reordering and all boards I deal with use mmc
> > > 0 for the internal eMMC. The aliases allow consistency.
> >
> > Since pretty much every other device type supports renumbering with DT
> > aliases, it would make sense to do this for mmc as well.
>
> SATA does not.  SCSI devices, whether they are disks, cdroms, tape
> drives or whatever have always been allocated dynamically in the
> order that they are discovered.
>
> Ethernet also does not, and davem remains opposed the idea of fixed
> allocation in the kernel.
>
> It's only a minority that demand fixed enumeration of devices.
>

Russell,

How does this case differ form defining a 'stdout-path' in the chosen
node of the device-tree [1] purposed to provide a path to the boot
console device among multiple UART's a board may have.

Again, I'm merely trying to overcome the fact that on one of my IMX6
boards usdhc2 registers as 'mmcblk0' and is an SDIO radio while usdhc3
registers as 'mmcblk1' and is the only 'bootable' device. I'm not all
that familiar with SDIO drivers... perhaps its completely wrong that
the IMX6 MMC driver is registering usdhc2 as a 'block device'?

Tim
[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt

Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Russell King - ARM Linux admin]

On Wed, Mar 27, 2019 at 10:37:19AM -0700, Tim Harvey wrote:
> On Sun, Mar 17, 2019 at 10:00 AM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Sun, Mar 17, 2019 at 04:48:24PM +0000, Måns Rullgård wrote:
> > > Stefan Agner <stefan@agner.ch> writes:
> > >
> > > > On 16.03.2019 16:39, Russell King - ARM Linux admin wrote:
> > > >> On Sat, Mar 16, 2019 at 01:33:58PM +0100, Marek Vasut wrote:
> > > >>> If you have a FS or partition table there, it does.
> > > >>> If you don't, I agree ... that's a problem.
> > > >>
> > > >> eMMC boot partitions are called mmcblkXbootY, and unless you have more
> > > >> than one eMMC device on the system, they can be found either by looking
> > > >> for /dev/mmcblk*boot* or by querying udev.  The advantage of using udev
> > > >> is you can discover the physical device behind it by looking at DEVPATH,
> > > >> ID_PATH, etc, but you may not have that installed on an embedded device.
> > > >>
> > > >> However, as I say, just looking for /dev/mmcblk*boot* is sufficient to
> > > >> find the eMMC boot partitions where there is just one eMMC device
> > > >> present (which seems to be the standard setup.)
> > > >>
> > > >>> > I don't care the slightest what the numbering is, as long as it is
> > > >>> > stable.  On some hardware, with an unpatched kernel, the mmc device
> > > >>> > numbering changes depending on whether or not an SD card is inserted on
> > > >>> > boot.  Getting rid of that behaviour is really all I want.
> > > >>>
> > > >>> Agreed, that would be an improvement.
> > > >>
> > > >> The mmc device numbering was tied to the mmc host numbering a while back
> > > >> and the order that the hosts are probed should be completely independent
> > > >> of whether a card is inserted or not:
> > > >>
> > > >>         snprintf(md->disk->disk_name, sizeof(md->disk->disk_name),
> > > >>                  "mmcblk%u%s", card->host->index, subname ? subname : "");
> > > >>
> > > >>         snprintf(rpmb_name, sizeof(rpmb_name),
> > > >>                  "mmcblk%u%s", card->host->index, subname ? subname : "");
> > > >>
> > > >> I suspect that Mans is quoting something from the dim and distant past
> > > >> to confuse the issue - as shown above, it is now dependent on the host
> > > >> numbering order not the order in which cards are inserted.
> > > >
> > > > Commit 9aaf3437aa72 ("mmc: block: Use the mmc host device index as the
> > > > mmcblk device index") which came in with v4.6 enables constant mmc block
> > > > device numbering. I can confirm that it works nicely, and it improved
> > > > the situation a lot.
> > >
> > > That's the answer I was looking for.  I guess we can drop these patches
> > > from our kernels then.
> > >
> > > > That being said, we still use a patch downstream which allows
> > > > renumbering using an alias. We deal with a bunch of different boards
> > > > with different SoC's. I have a couple of SD cards with various rootfs
> > > > and use internal eMMC boot quite often as well. Remembering which board
> > > > uses which numbering is a pain. Maintaining a patch is just easier...
> > > > Furthermore, U-Boot allows reordering and all boards I deal with use mmc
> > > > 0 for the internal eMMC. The aliases allow consistency.
> > >
> > > Since pretty much every other device type supports renumbering with DT
> > > aliases, it would make sense to do this for mmc as well.
> >
> > SATA does not.  SCSI devices, whether they are disks, cdroms, tape
> > drives or whatever have always been allocated dynamically in the
> > order that they are discovered.
> >
> > Ethernet also does not, and davem remains opposed the idea of fixed
> > allocation in the kernel.
> >
> > It's only a minority that demand fixed enumeration of devices.
> >
> 
> Russell,
> 
> How does this case differ form defining a 'stdout-path' in the chosen
> node of the device-tree [1] purposed to provide a path to the boot
> console device among multiple UART's a board may have.

You are comparing apples and oranges.

stdout-path defines which output device is the "standard output", but
it doesn't define that it shall be called "output device number zero".

So, stdout-path has nothing to do with device naming.

> Again, I'm merely trying to overcome the fact that on one of my IMX6
> boards usdhc2 registers as 'mmcblk0' and is an SDIO radio while usdhc3
> registers as 'mmcblk1' and is the only 'bootable' device. I'm not all
> that familiar with SDIO drivers... perhaps its completely wrong that
> the IMX6 MMC driver is registering usdhc2 as a 'block device'?

Right, you probably only have the usdhc2 and usdhc3 devices enabled
in device tree, and usdhc2 gets probed first (and allocated the first
MMC host index) followed by usdhc3.

Prior to the commit I mentioned, your case would have been quite sane
in that the SD card would always show up as mmcblk0 irrespective of
the order that the two SD host interfaces were discovered.  However,
the commit that ties the MMC/SD host number to the MMC block device
number has two effects:

1. the MMC block device numbers are equal to the MMC/SD host numbers.
2. the MMC standard supports multiple cards attached to a single host
   which became unsupportable.  (This is why MMC block device numbers
   were dynamic - the MMC code was written in the days when MMC cards
   were popular and SD was "new".  There is no way to really know how
   many MMC block devices there could be showing up per host.)  That
   became obsolete with SD, and I don't believe anyone ever produced
   a multi-MMC card setup.

I had realised that setups such as yours (SDIO in first host, SD in
second host) would result in a sane numbering becoming weird, but the
voices demanding (and I use demand, because that's exactly the tone
of the discussion) that MMC block devices not be dynamic were very
loud and strong - and remains so, as you can see from the tone of
Mans message bring this subject back up.

I should point out that as a result of this, MMC block devices follow
different behaviour from other devices in Linux.  For example:

- ATA HDDs devices get allocated SCSI disk numbers starting at zero
  according to the order they are detected.  The same goes for all
  other devices such as scanners, tape drives, optical drives, etc.
- Ethernet devices get allocated ethX numbers starting at zero
  according to the order that the drivers register the devices.
- USB devices are exactly the same - entirely dynamic device names.

For all of these, there are solutions in userspace.  For block devices
with partitions, there is PARTUUID, which is an identifier from the
partition table plus a partition number which the kernel can interpret.
There are filesystem labels and UUIDs which an initramfs can probe to
locate the root filesystem.  These can also be used with udev to
create persistent device names in /dev - see /dev/disk/by-* for
example.

Ethernet devices in modern distros have udev rules to rename them to
a name that somehow represents their location - eg, enp1s0.

USB devices, such as serial ports, do not have static names, but if
you have a lot of them (like I do) udev really helps - I have custom
udev rules which create symlinks to the USB serial devices I care
about in /dev/serial, so for example:

lrwxrwxrwx 1 root root 10 Mar 20 00:43 /dev/serial/usb-cubox-es -> ../ttyUSB0
...
lrwxrwxrwx 1 root root 11 Mar 20 00:43 /dev/serial/usb-mcbin-ds-es -> ../ttyUSB10
lrwxrwxrwx 1 root root 11 Mar 20 00:43 /dev/serial/usb-mcbin-ss -> ../ttyUSB11
...
lrwxrwxrwx 1 root root 10 Mar 20 00:43 /dev/serial/usb-ttl -> ../ttyUSB1
...
lrwxrwxrwx 1 root root 10 Mar 20 00:43 /dev/serial/usb-zii-b -> ../ttyUSB8

so I no longer need to worry about which order these are discovered,
which bus they're connected to, which hub, or anything, which is
kind of important when you consider that this machine is laptop on a
docking station, and all these devices are connected via hubs on
four USB ports on the docking station.

In the absence of such custom rules, there are persistent names by
both the device name/serial number (/dev/serial/by-id) and by the
bus path (/dev/serial/by-path).  Both of these are created by udev
using the policy set in its rules database.

The kernel really does not set the userspace device name policy,
although it has a "default" policy.  Userspace has, for many years,
been at liberty to change the policy in any way it sees fit, even if
devtmpfs is being used.

devtmpfs is just a tmpfs filesystem which the kernel adds devices
to using the kernel's naming policy, and will remove its own 
devices when they disappear.  Userspace is at liberty to create
additional names, rename the devices, even delete them if it so
wishes.

Sure, some people may not wish to run udev, which is fine.  In the
absence of udev, it is entirely possible to find out the device
names by looking in /sys/class or /sys/devices.  For example, on
my Armada 8040 platform (where I have eMMC and a SD card), I can
look at all the block devices present using the default kernel
device name:

$ ls -al /sys/class/block

and each one is a symlink (that can be read using readlink in shell
code) to discover where it is on the system.  For example, in bash:

for dev in /sys/class/block/mmcblk*; do
  path=`readlink -f $dev`
  if [[ $path =~ /f06e0000.sdhci/ ]]; then
     basename $dev
  fi
done

yields:

mmcblk0
mmcblk0boot0
mmcblk0boot1

which are found under /dev:

brw-rw---- 1 root disk 179,  0 Mar 26 19:30 /dev/mmcblk0
brw-rw---- 1 root disk 179,  8 Mar 26 19:30 /dev/mmcblk0boot0
brw-rw---- 1 root disk 179, 16 Mar 26 19:30 /dev/mmcblk0boot1

Here's another way, which is simpler if you have the path of the
device in DT, which will always be constant:

$ basename
/sys/devices/platform/ap806/ap806\:config-space@f0000000/f06e0000.sdhci/mmc_host/mmc*/mmc*/block/mmcblk*
mmcblk0

or if you prefer:

$ find /sys/devices/platform/ap806/ap806\:config-space@f0000000/f06e0000.sdhci -name 'mmcblk?' -printf '%f\n'
mmcblk0

or:

$ find /sys/devices/platform/ap806 -name 'mmcblk*' -printf '%f\n'
mmcblk0rpmb
mmcblk0
mmcblk0boot0
mmcblk0boot1
$ find /sys/devices/platform/cp0 -name 'mmcblk*' -printf '%f\n'
mmcblk1
mmcblk1p3
mmcblk1p1
mmcblk1p2

There are many ways to solve the "what name is my device using" problem
in userspace that does not require coding policy into the kernel.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up