1. 02 9月, 2020 1 次提交
  2. 17 4月, 2020 1 次提交
  3. 27 12月, 2019 3 次提交
    • D
      mmc: core: API to temporarily disable retuning for SDIO CRC errors · abda6d58
      Douglas Anderson 提交于
      commit 0a55f4ab9678413a01e740c86e9367ba0c612b36 upstream.
      
      Normally when the MMC core sees an "-EILSEQ" error returned by a host
      controller then it will trigger a retuning of the card.  This is
      generally a good idea.
      
      However, if a command is expected to sometimes cause transfer errors
      then these transfer errors shouldn't cause a re-tuning.  This
      re-tuning will be a needless waste of time.  One example case where a
      transfer is expected to cause errors is when transitioning between
      idle (sometimes referred to as "sleep" in Broadcom code) and active
      state on certain Broadcom WiFi SDIO cards.  Specifically if the card
      was already transitioning between states when the command was sent it
      could cause an error on the SDIO bus.
      
      Let's add an API that the SDIO function drivers can call that will
      temporarily disable the auto-tuning functionality.  Then we can add a
      call to this in the Broadcom WiFi driver and any other driver that
      might have similar needs.
      
      NOTE: this makes the assumption that the card is already tuned well
      enough that it's OK to disable the auto-retuning during one of these
      error-prone situations.  Presumably the driver code performing the
      error-prone transfer knows how to recover / retry from errors.  ...and
      after we can get back to a state where transfers are no longer
      error-prone then we can enable the auto-retuning again.  If we truly
      find ourselves in a case where the card needs to be retuned sometimes
      to handle one of these error-prone transfers then we can always try a
      few transfers first without auto-retuning and then re-try with
      auto-retuning if the first few fail.
      
      Without this change on rk3288-veyron-minnie I periodically see this in
      the logs of a machine just sitting there idle:
        dwmmc_rockchip ff0d0000.dwmmc: Successfully tuned phase to XYZ
      
      Cc: stable@vger.kernel.org #v4.18+
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Acked-by: NKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      abda6d58
    • J
      mmc:fix a bug when max_discard is 0 · 6d189d0d
      Jiong Wu 提交于
      commit d4721339dcca7def04909a8e60da43c19a24d8bf upstream.
      
      The original purpose of the code I fix is to replace max_discard with
      max_trim if max_trim is less than max_discard. When max_discard is 0
      we should replace max_discard with max_trim as well, because
      max_discard equals 0 happens only when the max_do_calc_max_discard
      process is overflowed, so if mmc_can_trim(card) is true, max_discard
      should be replaced by an available max_trim.
      However, in the original code, there are two lines of code interfere
      the right process.
      1) if (max_discard && mmc_can_trim(card))
      when max_discard is 0, it skips the process checking if max_discard
      needs to be replaced with max_trim.
      2) if (max_trim < max_discard)
      the condition is false when max_discard is 0. it also skips the process
      that replaces max_discard with max_trim, in fact, we should replace the
      0-valued max_discard with max_trim.
      Signed-off-by: NJiong Wu <Lohengrin1024@gmail.com>
      Fixes: b305882f (mmc: core: optimize mmc_calc_max_discard)
      Cc: stable@vger.kernel.org # v4.17+
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      6d189d0d
    • R
      mmc: core: Fix NULL ptr crash from mmc_should_fail_request · 658988db
      Ritesh Harjani 提交于
      commit e5723f95d6b493dd437f1199cacb41459713b32f upstream.
      
      In case of CQHCI, mrq->cmd may be NULL for data requests (non DCMD).
      In such case mmc_should_fail_request is directly dereferencing
      mrq->cmd while cmd is NULL.
      Fix this by checking for mrq->cmd pointer.
      
      Fixes: 72a5af55 ("mmc: core: Add support for handling CQE requests")
      Signed-off-by: NRitesh Harjani <riteshh@codeaurora.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      658988db
  4. 16 7月, 2018 2 次提交
    • U
      mmc: core: Drop the unused mmc_power_save|restore_host() · 29772f8a
      Ulf Hansson 提交于
      The last user of mmc_power_save|restore_host() APIs is gone, hence let's
      drop them. Drop also the corresponding bus_ops callback,
      ->power_save|restore() as those becomes redundant.
      
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Eyal Reizer <eyalreizer@gmail.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      29772f8a
    • S
      mmc: core: Adjust and reuse the macro of R1_STATUS(x) · a94a7483
      Shawn Lin 提交于
      R1_STATUS(x) now is only used by ioctl_rpmb_card_status_poll(),
      which checks all bits as possible. But according to the spec,
      bit 17 and bit 18 should be ignored, as well bit 14 which is
      reserved(must be set to 0) quoting from the spec and these rule
      apply to all places checking the device status. So change
      its checking from 0xFFFFE000 to 0xFFF9A000.
      
      As a bonus, we reuse it for mmc_do_erase() as well as
      mmc_switch_status_error().
      (1) Currently mmc_switch_status_error() doesn't check bit 25, but
      it means device is locked but not unlocked by CMD42 prior to any
      operations which need check busy, which is also not allowed.
      (2) mmc_do_erase() also forgot to to check bit 15, WP_ERASE_SKIP.
      The spec says "Only partial address space was erased due to existing
      write protected blocks.", which obviously means we should fail this I/O.
      Otherwise, the partial erased data stored in nonvalatile flash violates
      the data integrity from the view of I/O owner, which probably confuse
      it when further used.
      
      So reusing R1_STATUS for them not only improve the readability but also
      slove real problems.
      Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      a94a7483
  5. 29 5月, 2018 1 次提交
    • M
      mmc: Throttle calls to MMC_SEND_STATUS during mmc_do_erase() · 833b5117
      Martin Hicks 提交于
      This drastically reduces the rate at which the MMC_SEND_STATUS cmd polls
      for completion of the MMC Erase operation.  The patch does this by adding
      a backoff sleep that starts by sleeping for short intervals (128-256us),
      and ramps up to sleeping for 32-64ms.
      
      Even on very quickly completing erase operations, the loop iterates a few
      times, so not too much extra latency is added to these commands.
      
      For long running discard operarations, like a full-device secure discard,
      this change drops the interrupt rates on my single-core NXP I.MX6UL from
      45000/s to about 20/s, and greatly improves system responsiveness.
      Signed-off-by: NMartin Hicks <mort@bork.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      833b5117
  6. 21 5月, 2018 1 次提交
    • S
      mmc: core: add tunable delay waiting for power to be stable · 6d796c68
      Shawn Lin 提交于
      The hard-coded 10ms delay in mmc_power_up came from
      commit 79bccc5a ("mmc: increase power up delay"), which said "The TI
      controller on Toshiba Tecra M5 needs more time to power up or the cards
      will init incorrectly or not at all." But it's too engineering solution
      for a special board but force all platforms to wait for that long time,
      especially painful for mmc_power_up for eMMC when booting.
      
      However, it's added since 2009, and we can't tell if other platforms
      benefit from it. But in practise, the modern hardware are most likely to
      have a stable power supply with 1ms after setting it for no matter PMIC
      or discrete power. And more importnatly, most regulators implement the
      callback of ->set_voltage_time_sel() for regulator core to wait for
      specific period of time for the power supply to be stable, which means
      once regulator_set_voltage_* return, the power should reach the the
      minimum voltage that works for initialization. Of course, if there
      are some other ways for host to power the card, we should allow them
      to argue a suitable delay as well.
      
      With this patch, we could assign the delay from firmware, or we could
      assigne it via ->set_ios() callback from host drivers.
      Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      6d796c68
  7. 08 5月, 2018 4 次提交
  8. 05 3月, 2018 2 次提交
  9. 18 12月, 2017 1 次提交
    • D
      mmc: avoid removing non-removable hosts during suspend · de8dcc3d
      Daniel Drake 提交于
      The Weibu F3C MiniPC has an onboard AP6255 module, presenting
      two SDIO functions on a single MMC host (Bluetooth/btsdio and
      WiFi/brcmfmac), and the mmc layer correctly detects this as
      non-removable.
      
      After suspend/resume, the wifi and bluetooth interfaces disappear
      and do not get probed again.
      
      The conditions here are:
      
       1. During suspend, we reach mmc_pm_notify()
      
       2. mmc_pm_notify() calls mmc_sdio_pre_suspend() to see if we can
          suspend the SDIO host. However, mmc_sdio_pre_suspend() returns
          -ENOSYS because btsdio_driver does not have a suspend method.
      
       3. mmc_pm_notify() proceeds to remove the card
      
       4. Upon resume, mmc_rescan() does nothing with this host, because of
          the rescan_entered check which aims to only scan a non-removable
          device a single time (i.e. during boot).
      
      Fix the loss of functionality by detecting that we are unable to
      suspend a non-removable host, so avoid the forced removal in that
      case. The comment above this function already indicates that this
      code was only intended for removable devices.
      Signed-off-by: NDaniel Drake <drake@endlessm.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      de8dcc3d
  10. 11 12月, 2017 5 次提交
  11. 30 10月, 2017 5 次提交
  12. 30 8月, 2017 7 次提交
  13. 20 6月, 2017 6 次提交
  14. 25 4月, 2017 1 次提交