Hi Shawn, On Mon, May 07, 2018 at 03:29:31PM +0800, Shawn Lin wrote: > On 2018/5/6 22:01, Quentin Schulz wrote: > > Hi Ulf, > > > > On Wed, May 02, 2018 at 11:26:30AM +0200, Ulf Hansson wrote: > > > On 23 April 2018 at 11:50, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > > > On 14 April 2018 at 13:25, Quentin Schulz <quentin.schulz@xxxxxxxxxxx> 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]. > > > > > > > > > > I can't say if it's an error in your patch series or me using it the > > > > > wrong way. > > > > > > > > > > Could you help me debug this so that we can make the "weird" SDIO > > > > > devices such as the ESP8089 work in the kernel :)? > > > > > > > > > > I'll try to mount my rootfs from something else than an initramfs so > > > > > that it may solve my problem of dmesg not showing the whole log. > > > > > > > > > > [1] http://code.bulix.org/eechlb-318686 > > > > > > > > Unless I am misstaken, it looks like the messages comes from a > > > > WARN_ON(!host->claimed); in mmc_wait_for_cmd(). > > > > > > > > Did you call sdio_claim_host() before calling mmc_sw_reset()? And then > > > > of course you need to release the host when you are ready executing > > > > the required operations, sdio_release_host(). > > > > > > > > That was it, thanks. > > > > Now, I go pass mmc_sw_reset and the init of the driver can continue but > > I'm now hitting a timeout waiting for a completion. > > > > I'll need definitely to put more time into it to debug it now. Next week > > has two holidays in France though, I'll try my best to find time to work > > on it next week but can't promise much work will be done. > > > > If anyone wants to help meanwhile, here is the code: > > https://github.com/QSchulz/linux/tree/mmc_sw_reset/esp8089 > > > > This is the bootlog of the tablet: > > http://code.bulix.org/t7iken-328962 > > Could you try: > > drivers/net/wireless/espressif/esp8089/sdio_sif_esp.c > -543,21 +530,61 @@ static int esp_sdio_probe(struct sdio_func *func, > sdio_claim_host(func); > + sdio_release_irq(func); > mmc_sw_reset(host); > sdio_release_host(func); > I don't have the tablet with me at work, I'll let you know the output of this modification in about 9 hours. I think you're offering this patch because of the "sif sif_enable_irq failed" debug message which calls sdio_claim_irq and fails. Here sdio_claim_irq() fails at https://elixir.bootlin.com/linux/latest/source/drivers/mmc/core/sdio_irq.c#L294 In the code of the ESP8089 driver, failing to claim the IRQ isn't blocking and I don't think it was disabled or something was done in SDIO subsystem on this IRQ or its handler. Anyway, anything's worth trying :) I'll let you know, thanks, Quentin > > > > Hope we can get this sorted out somehow quickly so we can just put this > > issue of weird SDIO devices behind us once and for all :) (well, until > > the next weird ones :D). > > > > Thanks, > > Quentin > > > > > > > [2] https://lkml.org/lkml/2017/7/21/386 > > > > > > > > > > Let me know how I can be helpful, > > > > > Thanks, > > > > > Quentin > > > > > > Quentin, ping! > > > > > > Just tell me if there is anything else I can help out with! > > > > > > Kind regards > > > Uffe >
Attachment:
signature.asc
Description: PGP signature
