Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 08 5月, 2020 3 次提交
  3. 20 4月, 2020 1 次提交
  5. 26 3月, 2020 1 次提交
    • U
      mmc: core: Re-work the code for eMMC sanitize · 55c2b8b9
      由 Ulf Hansson 提交于 
      The error path for sanitize operations that completes with -ETIMEDOUT, is
tightly coupled with the internal request handling code of the core. More
precisely, mmc_wait_for_req_done() checks for specific sanitize errors.
This is not only inefficient as it affects all types of requests, but also
hackish.

Therefore, let's improve the behaviour by moving the error path out of the
mmc core. To do that, retuning needs to be held while running the sanitize
operation.

Moreover, to avoid exporting unnecessary symbols to the mmc block module,
let's move the code into the mmc_ops.c file. While updating the actual
code, let's also take the opportunity to clean up some of the mess around
it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20200316152152.15122-1-ulf.hansson@linaro.org
      55c2b8b9
  7. 24 3月, 2020 15 次提交
  9. 12 3月, 2020 1 次提交
  11. 11 3月, 2020 2 次提交
  13. 24 1月, 2020 3 次提交
  15. 20 1月, 2020 1 次提交
  17. 18 12月, 2019 3 次提交
  19. 18 11月, 2019 1 次提交
  21. 15 11月, 2019 1 次提交
  23. 14 11月, 2019 2 次提交
    • U
      mmc: core: Re-work HW reset for SDIO cards · 2ac55d5e
      由 Ulf Hansson 提交于 
      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: NDouglas Anderson <dianders@chromium.org>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      2ac55d5e
    • U
      mmc: core: Drop check for mmc_card_is_removable() in mmc_rescan() · 99b4ddd8
      由 Ulf Hansson 提交于 
      Upfront in mmc_rescan() we use the host->rescan_entered flag, to allow
scanning only once for non-removable cards. Therefore, it's also not
possible that we can have a corresponding card bus attached (host->bus_ops
is NULL), when we are scanning non-removable cards.

For this reason, let' drop the check for mmc_card_is_removable() as it's
redundant.
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Cc: stable@vger.kernel.org # v5.4+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      99b4ddd8
  25. 13 11月, 2019 2 次提交
  27. 12 9月, 2019 1 次提交
  29. 11 9月, 2019 3 次提交