RFC: representing sdio devices oob interrupt, clks, etc. in device tree

[Ulf Hansson]

[snip]

>>
>> We don't typically actually bind multiple compatibles for a single
>> device.  We've got a bunch of options we can choose from but we
>> generally pick the one that matches best and ignore the others.
>>
>>> Where as what you're suggesting is to always pick driver foo, unless
>>> driver bar is available and has a special flag saying to not use foo, this
>>> is a whole new way to use compatibles really, and not one which I think
>>> we want to introduce.
>>
>> I'm not sure I'm buying the idea that we have a powerup driver that's
>> meaningfully not part of the main device driver.

I am having a bit hard to follow the terminology here. :-) What is a
"powerup driver" and what is a "main device driver" in this context?

I had a slide which I used at a mmc subsystem crash course recently,
please have a look - hopefully this will help us to sort out this.

https://drive.google.com/file/d/0B2ePGK-iqMupbDQ2S0o5b3Bhek0/edit?usp=sharing

>
> Well, if we merge some variant of Olof's code, we will have a powerup driver
> that is part of the mmc core, and thus not of the sdio function driver.
>
>>>> Well, if things aren't going to work either way for these devices
>>>> without extra stuff it seems it doesn't much matter but it helps the
>>>> simple case to have things default to working.
>>
>>> The simple case still needs a child node describing the needed resources,
>>> adding a compatible = "simple-sdio-powerup" to that at the same as creating
>>> the child node in the first place really is no extra effort at all.
>>
>> From where I'm sitting it's more effort since instead of just putting
>> the device in there (and possibly also some other devices that are
>> software compatible) we have to put in another compatible string which
>> is really just a boolean flag to be used in conjunction with the others.
>> That's harder to think about and we clearly don't want to go through the
>> compatible list, decide that we don't know how to handle the device
>> except power it up so go and do that.
>>
>> If it were done as something like "set boolean property X or
>> powerup-method = Y in the card description" or whatever it'd seem a bit
>> annoying but not a big deal, I think it's the fact that it's getting put
>> into the compatible list that's really concerning me.
>
> Ok, so lets switch it over to a boolean, options for the name I see are:
>
> linux,mmc-host-powerup  (opt in to powerup being dealt with by the mmc core, implementation specific)
> simple-powerup          (platform neutral opt in to say just enable all resources and be done with it)
> custom-powerup          (platform neutral opt out version of simple-powerup)
> linux,custom-powerup    (same, but consider this something linux specific)

This seems reasonable to me.

Well, I don't like the "simple-powerup", because I think a simple
powerup sequence is to me already supported by the mmc core, through
the regular host interface (->set_ios()).

If I understand correctly, this binding is supposed to be configured
per host device and thus also per host device slots?

Kind regards
Ulf Hansson