Re: mwifiex card reset

[Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]

* James Cameron <quozl-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org> [140701 10:05]:
> On Tue, Jul 01, 2014 at 12:02:25AM -0700, Bing Zhao wrote:
> > Hi James,
> > 
> > > On Mon, Jun 30, 2014 at 11:44:29PM -0700, Bing Zhao wrote:
> > > > 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/?
> > > 
> > > Wouldn't device tree for mmc be better?
> > 
> > Yes, device tree is better for defining clocks/GPIO/regulators, etc.
> > But I guess the reset logic (making use of these definitions) cannot
> > be device tree?
> 
> I think the reset logic can exist, but does nothing unless the device
> tree definitions are present.

It might be possible to support the SDIO card specific
clocks/GPIOs/regulators the MMC bus driver. But that may not
work well in the long run as those pins are not connected to
the MMC bus at all. If we wanted to explore adding card
specific features to the MMC bus, I guess we should have:

- Card reset-gpios

- Card specific regulators on the card controlled by
  a GPIO

- External card specific regulators

- Card specific idle status pin (no idea what these pins
  do on some of the mwifiex cards though?)

And then these would have to be configured to get the
SDIO card to probe. And they should be controllable also
from user space to reset a card or to power it off.

Then if we get a device that muxes two different SDIO cards
on the same bus, then what do we do? They may both have
their own regulators and reset GPIO pins.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html