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. 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 can't say if it's an error in your patch series or me using it the > > wrong way. > > Well if you just replaced my mmc_force_detect_change() with > mmc_sw_reset() that is not enough, see above. After that it might > very well be that mc_sw_reset() needs some work too... Best regards, Quentin
Attachment:
signature.asc
Description: PGP signature
