wireguard-linux/drivers/mmc/core/sdio.c, branch jd/unified-crypt-queue

mmc: core: Re-work HW reset for SDIO cards

2019-11-14T15:28:56Z

It have turned out that it's not a good idea to unconditionally do a power cycle and then to re-initialize the SDIO card, as currently done through mmc_hw_reset() -> mmc_sdio_hw_reset(). This because there may be multiple SDIO func drivers probed, who also shares the same SDIO card. To address these scenarios, one may be tempted to use a notification mechanism, as to allow the core to inform each of the probed func drivers, about an ongoing HW reset. However, supporting such an operation from the func driver point of view, may not be entirely trivial. Therefore, let's use a more simplistic approach to solve the problem, by instead forcing the card to be removed and re-detected, via scheduling a rescan-work. In this way, we can rely on existing infrastructure, as the func driver's ->remove() and ->probe() callbacks, becomes invoked to deal with the cleanup and the re-initialization. This solution may be considered as rather heavy, especially if a func driver doesn't share its card with other func drivers. To address this, let's keep the current immediate HW reset option as well, but run it only when there is one func driver probed for the card. Finally, to allow the caller of mmc_hw_reset(), to understand if the reset is being asynchronously managed from a scheduled work, it returns 1 (propagated from mmc_sdio_hw_reset()). If the HW reset is executed successfully and synchronously it returns 0, which maintains the existing behaviour. Reviewed-by: Douglas Anderson Tested-by: Douglas Anderson Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Ulf Hansson

mmc: core: Fixup processing of SDIO IRQs during system suspend/resume

2019-09-11T14:10:19Z

System suspend/resume of SDIO cards, with SDIO IRQs enabled and when using MMC_CAP2_SDIO_IRQ_NOTHREAD is unfortunate still suffering from a fragile behaviour. Some problems have been taken care of so far, but more issues remains. For example, calling the ->ack_sdio_irq() callback to let host drivers re-enable the SDIO IRQs is a bad idea, unless the IRQ have been consumed, which may not be the case during system suspend/resume. This may lead to that a host driver re-signals the same SDIO IRQ over and over again, causing a storm of IRQs and gives a ping-pong effect towards the sdio_irq_work(). Moreover, calling the ->enable_sdio_irq() callback at system resume to re-enable already enabled SDIO IRQs for the host, causes the runtime PM count for some host drivers to become in-balanced. This then leads to the host to remain runtime resumed, no matter if it's needed or not. To fix these problems, let's check if process_sdio_pending_irqs() actually consumed the SDIO IRQ, before we continue to ack the IRQ by invoking the ->ack_sdio_irq() callback. Additionally, there should be no need to re-enable SDIO IRQs as the host driver already knows if they were enabled at system suspend, thus also whether it needs to re-enable them at system resume. For this reason, drop the call to ->enable_sdio_irq() during system resume. In regards to these changes there is yet another issue, which is when there is an SDIO IRQ being signaled by the host driver, but after the SDIO card has been system suspended. Currently these IRQs are just thrown away, while we should at least make sure to try to consume them when the SDIO card has been system resumed. Fix this by queueing a sdio_irq_work() after we system resumed the SDIO card. Tested-by: Matthias Kaehlcke Reviewed-by: Matthias Kaehlcke Signed-off-by: Ulf Hansson Reviewed-by: Douglas Anderson Signed-off-by: Ulf Hansson

mmc: core: WARN if SDIO IRQs are enabled for non-powered card in suspend

2019-09-11T14:10:18Z

To make sure SDIO func drivers behaves correctly during system suspend/resume, let add a WARN_ON in case the condition is a non-powered SDIO card and there are some SDIO IRQs still being claimed. Tested-by: Matthias Kaehlcke Reviewed-by: Matthias Kaehlcke Signed-off-by: Ulf Hansson

mmc: sdio: Drop unused in-parameter from mmc_sdio_init_card()

2019-07-10T11:20:17Z

The "powered_resume" in-parameter to mmc_sdio_init_card() has now become redundant as all callers set it to 0. Therefore let's just drop it. Signed-off-by: Ulf Hansson Reviewed-by: Douglas Anderson Tested-by: Douglas Anderson

mmc: sdio: Drop unused in-parameter to mmc_sdio_reinit_card()

2019-07-10T11:19:57Z

The "powered_resume" in-parameter to mmc_sdio_reinit_card() has now become redundant as all callers set it to 0. Therefore let's just drop it. Signed-off-by: Ulf Hansson Reviewed-by: Douglas Anderson Tested-by: Douglas Anderson

mmc: sdio: Don't re-initialize powered-on removable SDIO cards at resume

2019-07-10T11:19:31Z

It looks like the original idea behind always doing a re-initialization of a removable SDIO card during system resume in mmc_sdio_resume(), is to try to play safe to detect whether the card has been removed. However, this seems like a really a bad idea as it will most likely screw things up, especially when the card is expected to remain powered on during system suspend by the SDIO func driver. Let's fix this, simply by trusting that the detect work checks if the card is alive and inserted, which is being scheduled at the PM_POST_SUSPEND notification anyway. Signed-off-by: Ulf Hansson Tested-by: Douglas Anderson Reviewed-by: Douglas Anderson

mmc: sdio: Drop powered-on re-init at runtime resume and HW reset

2019-07-10T11:18:56Z

To use the so called powered-on re-initialization of an SDIO card, the power to the card must obviously have stayed on. If not, the initialization will simply fail. In the runtime suspend case, the card is always powered off. Hence, let's drop the support for powered-on re-initialization during runtime resume, as it doesn't make sense. Moreover, during a HW reset, the point is to cut the power to the card and then do fresh re-initialization. Therefore drop the support for powered-on re-initialization during HW reset. Signed-off-by: Ulf Hansson Fixes: ca8971ca5753 ("mmc: dw_mmc: Prevent runtime PM suspend when SDIO IRQs are enabled") Tested-by: Douglas Anderson

mmc: sdio: Move comment about re-initialization to mmc_sdio_reinit_card()

2019-07-10T11:18:29Z

The comment in mmc_sdio_power_restore() belongs in mmc_sdio_reinit_card(), which was created during a previous commit that re-factored some code. Fix this by moving the comment into mmc_sdio_reinit_card(). Signed-off-by: Ulf Hansson Reviewed-by: Douglas Anderson

mmc: sdio: Drop mmc_claim|release_host() in mmc_sdio_power_restore()

2019-07-10T11:17:30Z

The function mmc_sdio_power_restore() is called either from mmc_sdio_runtime_resume() or from mmc_sdio_hw_reset(). Both callers either claims/releases the host or require its callers to do so. Therefore let's drop the redundant calls to mmc_claim|release_host() in mmc_sdio_power_restore(). Signed-off-by: Ulf Hansson Reviewed-by: Douglas Anderson Tested-by: Douglas Anderson

mmc: core: Prevent processing SDIO IRQs when the card is suspended

2019-06-18T12:06:32Z

Processing of SDIO IRQs must obviously be prevented while the card is system suspended, otherwise we may end up trying to communicate with an uninitialized SDIO card. Reports throughout the years shows that this is not only a theoretical problem, but a real issue. So, let's finally fix this problem, by keeping track of the state for the card and bail out before processing the SDIO IRQ, in case the card is suspended. Cc: stable@vger.kernel.org Reported-by: Douglas Anderson Tested-by: Douglas Anderson Signed-off-by: Ulf Hansson