Hi Arnd, On jeu., nov. 24 2016, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Thursday, November 24, 2016 10:05:45 AM CET Ulf Hansson wrote: >> > You also mentioned other bindings using child nodes, but for this one >> > we have one controller with only one set of register with multiple slots >> > (Atmel is an example). Here each slot have it own set of register. >> > >> > Actually giving the fact that each slot is controlled by a different set >> > of register I wonder why the hardware can't also deduce the slot number >> > from the address register. For me it looks like an hardware bug but we >> > have to deal with it. >> > >> > Do you still think we needchild node here? >> >> Using child-nodes for slots like what's done in the atmel case, is >> currently broken. I would recommend to avoid using child-nodes for >> slots, if possible. >> >> To give you some more background, currently the mmc core treats child >> nodes as embedded non-removable cards or SDIO funcs. However, we can >> change to make child-nodes also allowed to describe slots, but it >> requires a specific compatible for "slots" and of course then we also >> need to update the DT parsing of the child-nodes in the mmc core. >> >> Documentation/devicetree/bindings/mmc/mmc.txt >> Documentation/devicetree/bindings/mmc/mmc-card.txt > > I don't see anything wrong with having child nodes for the slots > even with the current binding, under one condition: > > The mmc.txt binding above must refer only to the child node, while > the parent node conceptually becomes a plain bus or MFD that > happens to encapsulate multiple MMC host controllers, and possibly > provides some shared registers to them. I don't have an option for mmc in general, but using child node do not fit at all the xenon controller. For this controller each slot has its own set of register, so there is no common ressource to share so no advantage to use it. Using child node in our case will just make the code more complex for no benefit. Gregory > > Arnd -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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
