On 25 April 2017 at 09:57, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > On 25/04/17 10:52, Ulf Hansson wrote: >> +Grygorii Strashko >> >> On 25 April 2017 at 08:21, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: >>> On 24/04/17 23:33, Ulf Hansson wrote: >>>> On 21 April 2017 at 12:08, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: >>>>> The SDIO card state might be being preserved during hibernation, for >>>>> example a SDIO wifi card supporting WOWLAN. That state will be lost if an >>>>> SDIO reset is done. One way to avoid that would be to build mmc core as a >>>>> module and simply not load it until after attempting to restore the >>>>> hibernation image. However that won't work if the hibernation image is >>>>> stored on eMMC which, of course, requires mmc core. >>>> >>>> I don't follow here. Are you saying the SDIO card is kept powered in >>>> hibernation, as to be able to support WOWLAN, right? >>> >>> Yes >> >> Okay, makes sense! >> >>> >>>> >>>> Then, it feels plain wrong the mmc_rescan() tries to re-initialize it. >>>> That should never happen, unless something is broken of course. >>> >>> The thing to note about hibernation is that there is a regular boot in >>> between saving the hibernation image and restoring it again. At boot time, >>> the kernel knows almost nothing about whether there is a hibernation image >>> and whether or not it will be restored. Consequently it becomes difficult >>> to avoid mmc_rescan(). As mentioned above, we need mmc_rescan() to >>> initialize the eMMC so that the hibernation image can be read. >> >> What's wrong with using the hibernation callbacks in the struct >> dev_pm_ops? We already do this. > > Here is the scenario. The kernel has just booted. User space wants to try > to restore a hibernation image, if there is one. So user space loads the > mmc core because the hibernation image is on eMMC. Mmc core does an SDIO > reset on the SDIO card and the state is lost. It has little to do with pm > callbacks AFAICS. Ah, now I see what you mean. I thought the problem was during the actual restoring of the hibernation image. Alright, when a boot is triggered by WOWLAN , you want to avoid sending the reset command for the SDIO card before the re-initialization of the SDIO card starts. The problem with this approach is that you can't differentiate between a cold boot and a boot triggered by WOWLAN, right!? In other words, in some cases the reset command may be needed while in other it won't. Maybe you can elaborate more on what exactly what the problem is with sending the reset command when the boot is triggered from WOWLAN? Yes, the SDIO card loses its context, but how is that a problem? [...] Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
