Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1391307 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree Douglas Anderson <dianders@chromium.org> - 2016-04-29 19:40 +0200
    [PATCH v2 1/4] Documentation: mmc: Document mmc aliases Douglas Anderson <dianders@chromium.org> - 2016-04-29 19:40 +0200
    [PATCH v2 2/4] mmc: read mmc alias from device tree Douglas Anderson <dianders@chromium.org> - 2016-04-29 19:40 +0200
    [PATCH v2 4/4] ARM: dts: rockchip: Add mmc aliases for rk3288 platform Douglas Anderson <dianders@chromium.org> - 2016-04-29 19:40 +0200
    Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Rob Herring <robh+dt@kernel.org> - 2016-04-29 20:20 +0200
      Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-29 21:40 +0200
        Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-29 22:00 +0200
          Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-29 22:10 +0200
    Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-29 20:20 +0200
      Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-29 21:50 +0200
        Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-29 22:00 +0200
          Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-29 22:10 +0200
            Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-29 23:20 +0200
              Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-29 23:40 +0200
                Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-30 00:00 +0200
                  Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-30 00:00 +0200
                    Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-30 00:20 +0200
                      Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-30 00:30 +0200
                        Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-30 00:50 +0200
                          Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-30 01:10 +0200
                            Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Peter Hurley <peter@hurleysoftware.com> - 2016-04-30 02:00 +0200
                              Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Peter Hurley <peter@hurleysoftware.com> - 2016-04-30 02:40 +0200
                                Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Doug Anderson <dianders@chromium.org> - 2016-04-30 04:30 +0200
                                Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-30 10:40 +0200
                            Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Rob Herring <robh+dt@kernel.org> - 2016-04-30 15:30 +0200
                      Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Javier Martinez Canillas <javier@dowhile0.org> - 2016-04-30 00:50 +0200
                        Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-30 12:50 +0200
                          Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Trent Piepho <tpiepho@kymetacorp.com> - 2016-05-03 21:30 +0200
              Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-29 23:40 +0200
            Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-04-29 23:20 +0200
      Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Pavel Machek <pavel@ucw.cz> - 2016-05-04 09:20 +0200
        Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering  w/ device tree Rob Herring <robh+dt@kernel.org> - 2016-05-04 14:30 +0200
          Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk  numbering w/ device tree Pavel Machek <pavel@ucw.cz> - 2016-05-04 14:50 +0200

Page 1 of 2  [1] 2  Next page →

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

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

[toc] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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.

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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.

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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.

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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.

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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.

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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.

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web