SDHCI enumeration order, dynamic mmcblkN IDs, and devicetree

[Stephen Warren]

The SDHCI driver assigns dynamic device numbers (mmcblk0/1/...) to
devices based on when they get probed, which IDs are free at that time,
etc. Many boards have e.g. 1 fixed MMC soldered onto the board, and 1
SD slot. There may or may not be a card in the SD slot at probe time,
which can then cause the numbering of the fixed MMC to differ.

Developers (even boot scripts) want to create simple hard-coded command-
lines based on static device IDs, e.g. root=/dev/mmcblk1p3.

To reconcile these two somewhat conflicting requirements, the order in
which the SDHCI controllers are passed to platform_add_devices has been
varied, so that all soldered-down storage is registered first (which
synchronously probes the device and assigns the block device ID, which
is therefore pseudo-static), followed by socketed storage, which then
get a dynamic ID. When there is only 1 socketed controller, this dynamic
ID ends up being pseudo-static too.

The Tegra board files have been doing this for a little while, and the
changes to do so were inspired by similar changes to some (IIRC) OMAP
board files.

Now to the devicetree specific issue:

In the model where the board file registers all the platform devices,
which then get matched to OF DT nodes, there is only a single board file,
and hence only a single order of registration of SDHCI controllers. The
order required to achieve pseudo-static numbering may not be the same
for all boards; it depends on which SDHCI controllers are used for which
purpose. Hence, this workaround essentially doesn't always work anymore.

Is there a way in DT to influence the platform device probe order? If not,
should there be? Or, are there other ways to work around this? (root=UUID
would work, but it's a pain for me to type and set up if I'm constantly
rebuilding filesystem images)

Thanks for any hints!

-- 
nvpublic