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 _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
