Hi, On 05/23/2014 04:54 PM, Arend van Spriel wrote: > On 05/23/14 15:28, Hans de Goede wrote: >> Hi, >> >> On 05/23/2014 03:21 PM, Arend van Spriel wrote: >>> On 05/23/14 13:50, Hans de Goede wrote: >>>> Hi, >>>> >>>> On 05/23/2014 01:22 PM, Mark Brown wrote: >>>>> On Fri, May 23, 2014 at 11:13:44AM +0200, Hans de Goede wrote: >>>>> >>>>>> Thinking more about this, I would like to make one change to my >>>>>> proposal, the mmc-core should only do power up of child-nodes if >>>>>> they have a compatible of: "simple-sdio-powerup". This way >>>>>> when we add something more complex, we can keep the simple powerup >>>>>> code in the mmc core, keeping what we've already using this working >>>>>> and the mmc core won't respond to the child nodes for more complex >>>>>> devices, so it won't conflict with more complex power-up handling >>>>>> handled by some other driver. >>>>> >>>>> Would it not be better to have this be something in the driver struct >>>>> rather than in the device tree? Putting a compatible in there would be >>>>> encoding details of the Linux implementation in the DT which doesn't >>>>> seem right especially since these are details we're thinking of changing >>>>> later on. >>>> >>>> The compatible is not a Linux specific thing, it is a marking saying >>>> that something needs to take care of enabling the clks (and whatever >>>> else we will make part of the binding for this compatible), before >>>> scanning the mmc bus. >>>> >>>>> Something like have the driver set flags saying if it wants >>>>> to do complicated things. >>>> >>>> Chicken<-> egg, we won't know which driver to use before we've probed >>>> the mmc bus, and we cannot probe the bus before enabling the clks, etc. >>> >>> The approach I took with brcmfmac is that upon module init I search the DT for "brcm,bcm43xx-fmac" compatible and get the clock and/or gpio resource and enable them before registering the sdio driver. The difficulty is probably when using the driver built-in as the clocks and gpios may not be available yet and we can not rely on deferred probing in module init stage. >> >> I know, and that approach does not work, by the time the brcmfmac loads, >> the mmc core has long probed the mmc bus and decided no one is home. > > Ok. That is due to the non-removable property, right? I assumed a mmc rescan, which is (supposedly) triggered upon sdio driver registration, would subsequently find the device. That is what I thought, but I tried without the non-removable property and the sdio wifi was still not recognized. 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
