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

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

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


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

[PATCH 1/3] 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>
---
 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

[PATCH 2/3] 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>
---
 drivers/mmc/core/host.c | 25 ++++++++++++++++++++-----
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 71bb2372f71d..7ecb6a6351b3 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -321,8 +321,8 @@ EXPORT_SYMBOL(mmc_of_parse);
  */
 struct mmc_host *mmc_alloc_host(int extra, struct device *dev)
 {
-	int err;
 	struct mmc_host *host;
+	int of_id = -1, id = -1;
 
 	host = kzalloc(sizeof(struct mmc_host) + extra, GFP_KERNEL);
 	if (!host)
@@ -330,14 +330,29 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *dev)
 
 	/* scanning will be enabled when we're ready */
 	host->rescan_disable = 1;
+
+	if (dev->of_node)
+		of_id = of_alias_get_id(dev->of_node, "mmc");
+
 	idr_preload(GFP_KERNEL);
 	spin_lock(&mmc_host_lock);
-	err = idr_alloc(&mmc_host_idr, host, 0, 0, GFP_NOWAIT);
-	if (err >= 0)
-		host->index = err;
+
+	if (of_id >= 0) {
+		id = idr_alloc(&mmc_host_idr, host, of_id, of_id + 1,
+			       GFP_NOWAIT);
+		if (id < 0)
+			dev_warn(dev, "/aliases ID %d not available\n", of_id);
+	}
+
+	if (id < 0)
+		id = idr_alloc(&mmc_host_idr, host, 0, 0, GFP_NOWAIT);
+
+	if (id >= 0)
+		host->index = id;
+
 	spin_unlock(&mmc_host_lock);
 	idr_preload_end();
-	if (err < 0) {
+	if (id < 0) {
 		kfree(host);
 		return NULL;
 	}
-- 
2.8.0.rc3.226.g39d4020

[PATCH 3/3] 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>
---
 drivers/mmc/card/block.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 9fef7f04c4e6..bcf4fdbb5221 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -2215,7 +2215,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card,
 	 * index anymore so we keep track of a name index.
 	 */
 	if (!subname) {
-		md->name_idx = find_first_zero_bit(name_use, max_devices);
+		md->name_idx = find_next_zero_bit(name_use, max_devices,
+				card->host->index);
 		__set_bit(md->name_idx, name_use);
 	} else
 		md->name_idx = ((struct mmc_blk_data *)
-- 
2.8.0.rc3.226.g39d4020

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

[Jisheng Zhang]

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(-)
> 

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

[Ulf Hansson]

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

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

[Doug Anderson]

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.

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

[Arnd Bergmann]

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

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

[Ulf Hansson]

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