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

Groups > linux.kernel > #1390612 > unrolled thread

[PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering Douglas Anderson <dianders@chromium.org> - 2016-04-29 01:10 +0200
    [PATCH 1/3] Documentation: mmc: Document mmc aliases Douglas Anderson <dianders@chromium.org> - 2016-04-29 01:10 +0200
    Re: [PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering Jisheng Zhang <jszhang@marvell.com> - 2016-04-29 04:30 +0200
    Re: [PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering Ulf Hansson <ulf.hansson@linaro.org> - 2016-04-29 09:30 +0200
      Re: [PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering Doug Anderson <dianders@chromium.org> - 2016-04-29 19:40 +0200
    Re: [PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering Arnd Bergmann <arnd@arndb.de> - 2016-05-04 21:30 +0200
      Re: [PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering Ulf Hansson <ulf.hansson@linaro.org> - 2016-05-10 13:10 +0200

#1390612 — [PATCH 0/3] Patches to allow consistent mmc / mmcblk numbering

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.


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 +++++++++++
 drivers/mmc/card/block.c                      |  3 ++-
 drivers/mmc/core/host.c                       | 25 ++++++++++++++++++++-----
 3 files changed, 33 insertions(+), 6 deletions(-)

-- 
2.8.0.rc3.226.g39d4020

[toc] | [next] | [standalone]

#1390613 — [PATCH 1/3] 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>
---
 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 a1ed9c4e7235..d225a7fb3849 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -72,6 +72,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:
 --------------------
@@ -146,3 +150,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]

#1390699

Dear Douglas,

On Thu, 28 Apr 2016 16:06:42 -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:
> 
> 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.
> 
> 
> 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

We also need this feature.

Thanks so much for upstreaming the series.
Jisheng

> 
>  Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++++++++++
>  drivers/mmc/card/block.c                      |  3 ++-
>  drivers/mmc/core/host.c                       | 25 ++++++++++++++++++++-----
>  3 files changed, 33 insertions(+), 6 deletions(-)
> 

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

#1390822

On 29 April 2016 at 01:06, 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.
>
>
> 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 +++++++++++
>  drivers/mmc/card/block.c                      |  3 ++-
>  drivers/mmc/core/host.c                       | 25 ++++++++++++++++++++-----
>  3 files changed, 33 insertions(+), 6 deletions(-)
>
> --
> 2.8.0.rc3.226.g39d4020
>

I believe you need to re-base this patchset as things have changed.

Currently the mmc host index that gets picked at host registration
point, will also be given to the corresponding mmc block device index.
That's probably solving most of your concerns, but I am open to extend
this to cover aliases as well, as to allow it to be *really*
deterministic.

Kind regards
Uffe

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

#1391306

Ulf,

On Fri, Apr 29, 2016 at 12:21 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 29 April 2016 at 01:06, 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.
>>
>>
>> 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 +++++++++++
>>  drivers/mmc/card/block.c                      |  3 ++-
>>  drivers/mmc/core/host.c                       | 25 ++++++++++++++++++++-----
>>  3 files changed, 33 insertions(+), 6 deletions(-)
>>
>> --
>> 2.8.0.rc3.226.g39d4020
>>
>
> I believe you need to re-base this patchset as things have changed.
>
> Currently the mmc host index that gets picked at host registration
> point, will also be given to the corresponding mmc block device index.
> That's probably solving most of your concerns, but I am open to extend
> this to cover aliases as well, as to allow it to be *really*
> deterministic.

OK, got it.  Send new patch now.  :)  PTAL.

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

#1394655

On Thursday 28 April 2016 16:06:42 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:
> 
> 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.
> 
> 
> 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 +++++++++++
>  drivers/mmc/card/block.c                      |  3 ++-
>  drivers/mmc/core/host.c                       | 25 ++++++++++++++++++++-----
>  3 files changed, 33 insertions(+), 6 deletions(-)


Does this mean we can revert 9aaf343 ("mmc: block: Use the mmc host
device index as the mmcblk device index") for now and wait until this
is in as well?

The commit I mention here breaks a significant number of boots
on Olof's test build setup, and it would be nice to avoid breaking
them again when we get yet another device numbering system.

	Arnd

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

#1397989

On 29 April 2016 at 19:39, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 28 April 2016 16:06:42 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:
>>
>> 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.
>>
>>
>> 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 +++++++++++
>>  drivers/mmc/card/block.c                      |  3 ++-
>>  drivers/mmc/core/host.c                       | 25 ++++++++++++++++++++-----
>>  3 files changed, 33 insertions(+), 6 deletions(-)
>
>
> Does this mean we can revert 9aaf343 ("mmc: block: Use the mmc host
> device index as the mmcblk device index") for now and wait until this
> is in as well?

No, as that one fixes an issue for a widely deployed product (family).

>
> The commit I mention here breaks a significant number of boots
> on Olof's test build setup, and it would be nice to avoid breaking
> them again when we get yet another device numbering system.

They don't have to break *again*. He just have to convert *once* to
use UUID/PARTID which is really what most should be doing.

Kind regards
Uffe

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web