RE: mwifiex card reset

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi Daniel,

> > 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?

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/?

Thanks,
Bing

> 
> 
> Thanks,
> Daniel

��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux