Hi, On 05/28/2014 12:12 PM, Arend van Spriel wrote: <snip> >>>> Yes, although I must admit that have not thought about how to deal with >>>> slots, I've no experience with the mmc slots concept at all, or is slot >>>> just a different name for sdio function ? >>> >>> Some mmc hosts may support more than one slot. Thus they can operate >>> on more than one card. >>> >>> Currently, there are no support for this in the mmc core. There can >>> only be one card per host, but that's due to software limitation of >>> the mmc stack. Following your suggestion; modelling the card as child >>> node under the mmc host, can easily be extended to support more than >>> one slot. >> >> Actually what I'm suggesting is based on Sascha Hauer's >> "mmc: Add SDIO function devicetree subnode parsing" >> >> Patch, which models the sdio functions as child nodes, (with the >> one with reg =<0> being the card itself) this also makes sense since each >> sdio-function gets its own device representing it, so having one child node >> per sdio-functions leads to one child node per device which seems sensible. > > To complicate thing, for brcmfmac the sdio functions are not considered individual devices. This means that brcmfmac creates one driver instance which claims multiple sdio functions. Right, but that is not really important for the overall device tree model we can just put all the info brcmfmac needs in the child-node for sdio-func 1, and then the driver can get to it since it claims both functions anyways, that is actually what the oob irq support patchset I posted a few days ago does. But that patch-set is missing the extra slot level in the child-nodes, so if we agree we want that extra level in the hierarchy I'll need to fix that for v2 of the set. Regards, Hans -- 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
