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
From: Stefan Agner <[email protected]>
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 <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
[dianders: rebase + roll in http://crosreview.com/259916]
Signed-off-by: Douglas Anderson <[email protected]>
---
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
From: Stefan Agner <[email protected]>
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 <[email protected]>
Signed-off-by: Douglas Anderson <[email protected]>
---
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
From: Jaehoon Chung <[email protected]>
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 <[email protected]>
[dianders: just bindings now; mention mmc not just mmcblk]
Signed-off-by: Douglas Anderson <[email protected]>
---
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
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(-)
>
On 29 April 2016 at 01:06, Douglas Anderson <[email protected]> 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
Ulf,
On Fri, Apr 29, 2016 at 12:21 AM, Ulf Hansson <[email protected]> wrote:
> On 29 April 2016 at 01:06, Douglas Anderson <[email protected]> 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.