1. 14 11月, 2019 2 次提交
    • 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
    • U
      mwifiex: Re-work support for SDIO HW reset · cdb2256f
      Ulf Hansson 提交于
      The SDIO HW reset procedure in mwifiex_sdio_card_reset_work() is broken,
      when the SDIO card is shared with another SDIO func driver. This is the
      case when the Bluetooth btmrvl driver is being used in combination with
      mwifiex. More precisely, when mwifiex_sdio_card_reset_work() runs to resets
      the SDIO card, the btmrvl driver doesn't get notified about it. Beyond that
      point, the btmrvl driver will fail to communicate with the SDIO card.
      
      This is a generic problem for SDIO func drivers sharing an SDIO card, which
      are about to be addressed in subsequent changes to the mmc core and the
      mmc_hw_reset() interface. In principle, these changes means the
      mmc_hw_reset() interface starts to return 1 if the are multiple drivers for
      the SDIO card, as to indicate to the caller that the reset needed to be
      scheduled asynchronously through a hotplug mechanism of the SDIO card.
      
      Let's prepare the mwifiex driver to support the upcoming new behaviour of
      mmc_hw_reset(), which means extending the mwifiex_sdio_card_reset_work() to
      support the asynchronous SDIO HW reset path. This also means, we need to
      allow the ->remove() callback to run, without waiting for the FW to be
      loaded. Additionally, during system suspend, mwifiex_sdio_suspend() may be
      called when a reset has been scheduled, but waiting to be executed. In this
      scenario let's simply return -EBUSY to abort the suspend process, as to
      allow the reset to be completed first.
      Reviewed-by: NDouglas Anderson <dianders@chromium.org>
      Tested-by: NDouglas Anderson <dianders@chromium.org>
      Cc: stable@vger.kernel.org # v5.4+
      Acked-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      cdb2256f
  2. 13 11月, 2019 37 次提交
  3. 11 11月, 2019 1 次提交