[...] >>> + >>> +This controller is present on some members of the Cavium OCTEON SoC >>> +family, provide an interface for eMMC, MMC and SD devices. There is a >>> +single controller that may have several "slots" connected. These >> >> >> Even it it may have several slots, that's not being supported by the >> mmc core from a MMC/SD/SDIO protocol perspective. >> >> We have hade some discussions around this historocally, and I doubt >> that we ever will be adding this. >> >> So, with that in mind I would rather see that you remove the concept >> of "slot" entirely and thus don't do the DT configuration within a >> child node. > > > As you note this is a device tree representation, and thus really has > nothing to do with the capabilities and internal structure of any given > operating system. > > The hardware really is structured as a single controller with a single set > of registers and register fields that can control multiple "slots". There > are not multiple independent slot controllers. > > This device tree representation reflects, with fidelity, the actual > hardware topology. I understand, you have point - but... We can debate whether why you think using a child-node for a slot is reflecting the hardware better, but I rather don't. Everybody else isn't using a child node, so I don't think you should. Moreover in the SDIO case, child nodes of mmc hosts reflects the actual embedded functional SDIO devices. So if child nodes are going to be used for anything, it should be to contain properties of an embedded SD/MMC/SDIO card. At least that's my view. > > But none of this matters, because the device tree bindings train has already > left the station. You should have expressed opposition to this binding back > when it was first discussed: > > http://www.linux-mips.org/archives/linux-mips/2012-05/msg00119.html I don't get it. What happened with the RFC above? It wasn't merged for any release, but the DT-bindings that was proposed was accepted? How is that possible? > > The device tree is deployed in the boot firmware of shipping devices, and we > are merely documenting what is there. That's a problem. :-) [...] Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
