I'm following this discussion continuously, but (un)fortunately I'm on vacation right now and don't have much time to work on this, so sorry for a very selective reply. On 28.05.2014 11:42, Hans de Goede wrote: > Hi, > > On 05/27/2014 03:50 PM, Ulf Hansson wrote: >> [snip] >> >> Powerup driver's ->probe(): >> Typically the "powerup driver" will need to register a few callback >> functions towards the mmc core. Typically at mmc_of_parse(), those >> callbacks will have to be connected to a particular mmc host. >> >> I would like to see three different callbacks, mirroring each of the >> mmc_ios power_mode states MMC_POWER_OFF|UP|ON. > > Hmm, can't we do something with runtime pm here instead? I would be > nice if we could use the platform bus for this instead of inventing > a new bus for this. Both from not needing to add extra count pov, but > also from the pov of having a solution which other subsystems can > later easily copy. I can even envision the parts of mmc_of_parse > dealing with this being a separate function taking a child node as > argument from day one, which can then hopefully later be moved out > of the mmc subsys and be used elsewhere too (*). This is actually a real use case, because we already have HSIC (USB with heavily stripped down physical layer) modems on certain Samsung boards and similarly to the kind of SDIO devices being discussed here they can't be discovered until a certain power up sequence is done. Analogically, the modem chip uses OOB interrupts and certain GPIO lines for various purposes and they need to be provided by DT. Moreover, there are already WLAN chips available that can use HSIC as their host interface and I'm not talking here about some exotic products, but rather widely recognized products of Broadcom (BCM4335), Marvell (88W8797) or Qualcomm Atheros (AR6004). My conclusion is that I see the discussion here being too much focused on MMC, especially considering the fact that the whole problem doesn't have anything to do with MMC, which is just used as (one of possible) host interface. 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. Best regards, Tomasz -- 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
