Hi Tony, everyone, Thanks Andreas for addressing this issue! So far, we've been using a terrible hack in the hsmmc in order to bring the card into a workable state, and we're looking for a nicer solution for awhile. On 06/30/2014 08:19 AM, Tony Lindgren wrote: > * Andreas Fenkart <afenkart@xxxxxxxxx> [140629 12:43]: >> 2014-06-28 9:23 GMT+02:00 Tony Lindgren <tony@xxxxxxxxxxx>: >>> * James Cameron <quozl@xxxxxxxxxx> [140628 08:24]: >>> Wouldn't it be best to have the mwifiex properly handle the >>> reset GPIOs and idle status pins? >> >> doesn't work see ref 1) above > > OK so we can't do much anything at mwifiex probe time on SDIO bus because > it won't probe unless the pins are configured. > > Maybe we should have a separate mwifiex-power helper module that just > manages the reset/idle/regulator pins? Then mwifiex-reset can be always > loaded and configure things so mwifiex-sdio can probe properly. > > And mwifiex-reset helper can also provide the user space interfaces > for the reset/idle/regulator pins. Yes, a helper might be the best solution. It could even be a generic one, that just takes any number of clocks, reset GPIOs and regulators and takes care for sequencing them. However, we need to reference that helper from the mwifiex driver, for two reasons. a) we need to make sure the reset helper gets to do its job before the mwifiex driver scans the SDIO bus, and b) the reset helper needs to be called when the mmc host controller wants to do a card reset. 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? Thanks, Daniel -- 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
