Hi,
On 14-04-18 17:57, Quentin Schulz wrote:
Hi Hans,
On Sat, Apr 14, 2018 at 04:41:24PM +0200, Hans de Goede wrote:
Hi,
On 14-04-18 13:25, Quentin Schulz wrote:
Hi Ulf and Hans,
On Fri, Apr 06, 2018 at 10:41:10AM +0200, Hans de Goede wrote:
Hi Ulf,
On 05-04-18 22:19, Ulf Hansson wrote:
It's rather common that SDIO func devices becomes loaded with a new firmware as
a part of the SDIO func driver being probed. However, in some special scenarios
the SDIO func device needs a SW reset, as to start running the new firmware.
More importantly, a full power cycle doesn't work, as that would reset also the
firmware, thus the existing mmc_hw_reset() API can't be used to deal with these
scenarios.
Therefore this series suggest to add a new API, mmc_sw_reset(), which resets
and re-initialize the SDIO card. A couple of the patches in the series are
mostly re-factorings making generic improvements to the related code.
For more background to this series, feel free to digest the discussions from
the submitted patch: https://patchwork.kernel.org/patch/9857175/
It should be noted, at this point this series has only be compile tested. Help
with tests and deployment of using the new API is greatly appreciated.
Thank you for this series, I've taken a quick look and it looks good,
but the proof is in the pudding. Quentin can you test this on an ARM
board with an ESP8089 sometime the coming week?
I applied your patches on top of next-20180406.
I may need some help to get the ESP8089 driver to work. Note that I'm
very new to MMC and SDIO, just so you know (and so you can adapt your
answer).
It's filling my kernel log buffer with a lot of these[1]. I've basically
replaced Hans's mmc_force_detect_change() by your mmc_sw_reset() in
esp_sdio_probe() of the ESP8089 driver and that's it. Here is my old
patch series for ESP8089[2].
Previously, after my mmc_force_detect_change() the driver would
see a disconnect/remove and then a new connect/probe, this will
no longer happen, now after the mmc_sw_reset() you should let
probe continue at there point where previously the second probe
call would start.
It's what I understood of it so I moved pieces specific to the second
probe and put it after mmc_sw_reset(). I forgot to mention this
modification in my previous mail.
Ah ok, yes that is how it should be used, so if it does not work then,
then we need some more work on this.
Anyway, the trace happens before reaching the second part of the probe
is what I understood from the log attached in the previous mail.
It looks like it's happening in mmc_sw_reset(). Am I wrongly assuming?
I have not looked into this at all, I just wanted to point out how
the new function should be used. I'm sorry but I'm currently totally
swamped with other stuff, so I don't have time to look into this.
Hopefully Ulf can make some time to look at the errors you are getting.
Regards,
Hans
--
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
