Hi Bing, On 07/01/2014 08:44 AM, Bing Zhao wrote: >> Hence, we'll need some sort of internal API for this, and a phandle >> in dts. I wonder whether that glue logic might be better off living >> in the mmc core, as mwifiex might well be interfaced to other >> hosts? > > I may have missed something, but doesn't the MMC_POWER_OFF and > MMC_POWER_ON|UP handling in controller driver help? Anyway the > clocks/GPIOs/regulators are sort of platform dependent. Would it be > better putting it in /arch/arm/mach-xxxxx/? Regulators are not platform specific, they never were. For GPIOs and clocks, we can simply depend on CONFIG_GPIO_GENERIC and CONFIG_COMMON_CLK. I wouldn't even bother to care for anything else. This way, we also get a way of referencing the resources in dts through phandles for free. What I was talking about above was that conducting the actual reset from the helper must be something that either the mmc core or individual host implementations can trigger. We need to repeat this action every time mwifiex decides to call its reset routine, which is currently implemented like this: mmc_remove_host(target); mdelay(20); mmc_add_host(target); But I haven't looked into possible ways of implementation yet. MMC_POWER_* might well be a suitable thing to hook into. Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
