1. 08 5月, 2018 3 次提交
  2. 05 3月, 2018 2 次提交
  3. 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
  4. 11 12月, 2017 5 次提交
  5. 30 10月, 2017 5 次提交
  6. 30 8月, 2017 7 次提交
  7. 20 6月, 2017 6 次提交
  8. 25 4月, 2017 7 次提交
  9. 14 2月, 2017 1 次提交
  10. 13 2月, 2017 3 次提交
    • L
      mmc: core: rename mmc_start_req() to *areq() · c3399ef5
      Linus Walleij 提交于
      With the coexisting __mmc_start_request(), mmc_start_request()
      and __mmc_start_req() it is a bit confusing that mmc_start_req()
      actually does not start a normal request, but an asynchronous
      request.
      
      Rename it to mmc_start_areq() to make it explicit what the
      function is doing, also fix the kerneldoc for this function
      while we're at it.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      c3399ef5
    • L
      mmc: core/mmci: restore pre/post_req behaviour · e13934bd
      Linus Walleij 提交于
      commit 64b12a68
      "mmc: core: fix prepared requests while doing bkops"
      is fixing a bug in the wrong way. A bug in the MMCI
      device driver is fixed by amending the MMC core.
      
      Thinking about it: what the pre- and post-callbacks
      are doing is to essentially map and unmap SG lists
      for DMA transfers. Why would we not be able to do that
      just because a BKOPS command is sent inbetween?
      Having to unprepare/prepare the next asynchronous
      request for DMA seems wrong.
      
      Looking the backtrace in that commit we can see what
      the real problem actually is:
      
      mmci_data_irq() is calling mmci_dma_unmap() twice
      which is goung to call arm_dma_unmap_sg() twice
      and v7_dma_inv_range() twice for the same sglist
      and that will crash.
      
      This happens because a request is prepared, then
      a BKOPS is sent. The IRQ completing the BKOPS command
      goes through mmci_data_irq() and thinks that a DMA
      operation has just been completed because
      dma_inprogress() reports true. It then proceeds to
      unmap the sglist.
      
      But that was wrong! dma_inprogress() should NOT be
      true because no DMA was actually in progress! We had
      just prepared the sglist, and the DMA channel
      dma_current has been configured, but NOT started!
      
      Because of this, the sglist is already unmapped when
      we get our actual data completion IRQ, and we are
      unmapping the sglist once more, and we get this crash.
      
      Therefore, we need to revert this solution pushing
      the problem to the core and causing problems, and
      instead augment the implementation such that
      dma_inprogress() only reports true if some DMA has
      actually been started.
      
      After this we can keep the request prepared during the
      BKOPS and we need not unprepare/reprepare it.
      
      Fixes: 64b12a68 ("mmc: core: fix prepared requests while doing bkops")
      Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Tested-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      e13934bd
    • U
      mmc: core: Rename __mmc_set_signal_voltage() to mmc_set_signal_voltage() · 4e74b6b3
      Ulf Hansson 提交于
      Earlier the mmc_set_signal_voltage() existed, but since it has been renamed
      to mmc_set_uhs_voltage(), we can now use that name instead.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
      Tested-by: NJan Glauber <jglauber@cavium.com>
      Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
      4e74b6b3