Hi, On Fri, Mar 15, 2019 at 4:00 PM Marek Vasut <marex@xxxxxxx> wrote: > > > Completely agree here - we need a dt solution that allows us to > > specify ordering. > > Nope, ordering would be a policy and does not describe hardware, thus it > shouldn't be in the DT. Use UUID or PARTUUID, they apply both to raw FS > (fsuuid) and to partitions (part uuid). Linux kernel can mount FS using > PARTUUID, to support UUID you need initramfs. Two thoughts about that: 1. Some amount of policy is allowed in device tree. At some point in time there was a big discussion about the need for a separate "config tree" that was totally parallel to the device tree so we could put policy stuff in that. Nobody wanted that and (as I recall) it was agreed that in some cases policy could go there if that policy expressed policy that was the generic intent of how the board ought to be run. I believe this is how things like the assigned-clocks is justified. 2. In some cases this number does describe the hardware. You look at the hardware reference manual and see that there are 3 MMC controllers: 0, 1, and 2. In such cases it seems like it's an OK description of the hardware to encode this info into the DTS. ...from what I recall, one big objection is for SoCs that didn't just have numbers for their controllers. AKA I think some SoCs might call their controllers the "eMMC" controller, the "SD" controller, and the "SDIO" controller. They may be nearly the same hardware, but perhaps the SoC allows for a GPIO interrupt on the SDIO controller and perhaps the eMMC controller exposes the strobe line or has an 8-bit wide datapath. In this case making up numbers does become a bit more arbitrary and folks didn't like it. IIRC there was general consensus that it'd be OK to somehow specify a string (AKA non-numeric) name for different SD controllers. I don't have pointers to that conversation offhand and it's possible I imagined it. -Doug
