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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
