Hi, On 05/28/2014 06:43 PM, Mark Brown wrote: > On Wed, May 28, 2014 at 01:47:50PM +0200, Tomasz Figa wrote: <snip> >> IMHO, all we need here is a way to tell the MMC (or HSIC) core when to >> look for a new device and when not (e.g. power down the host controller >> completely). Anything else, including proper power sequencing is up to >> the platform driver of such non-discoverable device - it's only its host >> interface that is discoverable when enabled. I believe this simplistic >> approach would lead to much less new code added, better reusability of >> code (power sequencing independent of host interface) and no need to >> create overly generic code, which usually turns out to be not generic >> enough. > > We then have the problem of working out where that platform driver comes > from, for many of these buses the device can be completely described as > just a device on the parent bus with some resources connected. Right, I think what we should do is focus on the DT description for this first and then worry about the implementation later. I believe that at the DT level this all should be represented as a child-node under the host controller. Following that reasoning it makes perfect sense to just focus on mmc for now, while keeping in mind that it would be nice if what comes out of this will be re-usable. I've done a detailed, updated proposal for the mmc case (with admittedly some implementation comments in there) in my last mail, but unfortunately I've seen little response to that. Can people please reply to my proposal where we've 2 levels of child nodes, one per mmc slot, and then the slot nodes has card / sdio-func child nodes, see my last mail. 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
