Hi,

On 05/28/2014 12:12 PM, Arend van Spriel wrote:

<snip>

quoted

quoted

quoted

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