1. 03 Sep, 2019 1 commit
    • Jan Kaisrlik's avatar
      Revert "mmc: core: do not retry CMD6 in __mmc_switch()" · 8ad8e02c
      Jan Kaisrlik authored
      Turns out the commit 3a0681c7 ("mmc: core: do not retry CMD6 in
      __mmc_switch()") breaks initialization of a Toshiba THGBMNG5 eMMC card,
      when using the meson-gx-mmc.c driver on a custom board based on Amlogic
      A113D.
      
      The CMD6 that switches the card into HS200 mode is then one that fails and
      according to the below printed messages from the log:
      
      [    1.648951] mmc0: mmc_select_hs200 failed, error -84
      [    1.648988] mmc0: error -84 whilst initialising MMC card
      
      After some analyze, it turns out that adding a delay of ~5ms inside
      mmc_select_bus_width() but after mmc_compare_ext_csds() has been executed,
      also fixes the problem. Adding yet some more debug code, trying to figure
      out if potentially the card could be in a busy state, both by using CMD13
      and ->card_busy() ops concluded that this was not the case.
      
      Therefore, let's simply revert the commit that dropped support for retrying
      of CMD6, as this also fixes the problem.
      
      Fixes: 3a0681c7 ("mmc: core: do not retry CMD6 in __mmc_switch()")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJan Kaisrlik <ja.kaisrlik@gmail.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      8ad8e02c
  2. 30 Aug, 2019 1 commit
  3. 22 Jul, 2019 1 commit
    • Andreas Koop's avatar
      mmc: mmc_spi: Enable stable writes · 3a6ffb3c
      Andreas Koop authored
      While using the mmc_spi driver occasionally errors like this popped up:
      
      mmcblk0: error -84 transferring data end_request: I/O error, dev mmcblk0, sector 581756
      
      I looked on the Internet for occurrences of the same problem and came
      across a helpful post [1]. It includes source code to reproduce the bug.
      There is also an analysis about the cause. During transmission data in the
      supplied buffer is being modified. Thus the previously calculated checksum
      is not correct anymore.
      
      After some digging I found out that device drivers are supposed to report
      they need stable writes. To fix this I set the appropriate flag at queue
      initialization if CRC checksumming is enabled for that SPI host.
      
      [1]
      https://groups.google.com/forum/#!msg/sim1/gLlzWeXGFr8/KevXinUXfc8JSigned-off-by: default avatarAndreas Koop <andreas.koop@zf.com>
      [shihpo: Rebase on top of v5.3-rc1]
      Signed-off-by: default avatarShihPo Hung <shihpo.hung@sifive.com>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      3a6ffb3c
  4. 10 Jul, 2019 7 commits
  5. 20 Jun, 2019 1 commit
  6. 19 Jun, 2019 1 commit
  7. 18 Jun, 2019 3 commits
    • Ulf Hansson's avatar
      mmc: core: Prevent processing SDIO IRQs when the card is suspended · 83293386
      Ulf Hansson authored
      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: default avatarDouglas Anderson <dianders@chromium.org>
      Tested-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      83293386
    • Douglas Anderson's avatar
      mmc: core: Add sdio_retune_hold_now() and sdio_retune_release() · b4c9f938
      Douglas Anderson authored
      We want SDIO drivers to be able to temporarily stop retuning when the
      driver knows that the SDIO card is not in a state where retuning will
      work (maybe because the card is asleep).  We'll move the relevant
      functions to a place where drivers can call them.
      
      Cc: stable@vger.kernel.org #v4.18+
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Acked-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      b4c9f938
    • Douglas Anderson's avatar
      mmc: core: API to temporarily disable retuning for SDIO CRC errors · 0a55f4ab
      Douglas Anderson authored
      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: default avatarDouglas Anderson <dianders@chromium.org>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Acked-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      0a55f4ab
  8. 17 Jun, 2019 2 commits
  9. 05 Jun, 2019 1 commit
  10. 30 May, 2019 3 commits
  11. 21 May, 2019 1 commit
  12. 06 May, 2019 3 commits
    • Raul E Rangel's avatar
      mmc: core: Fix tag set memory leak · 43d8dabb
      Raul E Rangel authored
      The tag set is allocated in mmc_init_queue but never freed. This results
      in a memory leak. This change makes sure we free the tag set when the
      queue is also freed.
      Signed-off-by: default avatarRaul E Rangel <rrangel@chromium.org>
      Reviewed-by: default avatarJens Axboe <axboe@kernel.dk>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Fixes: 81196976 ("mmc: block: Add blk-mq support")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      43d8dabb
    • Raul E Rangel's avatar
      mmc: core: Verify SD bus width · 9e4be8d0
      Raul E Rangel authored
      The SD Physical Layer Spec says the following: Since the SD Memory Card
      shall support at least the two bus modes 1-bit or 4-bit width, then any SD
      Card shall set at least bits 0 and 2 (SD_BUS_WIDTH="0101").
      
      This change verifies the card has specified a bus width.
      
      AMD SDHC Device 7806 can get into a bad state after a card disconnect
      where anything transferred via the DATA lines will always result in a
      zero filled buffer. Currently the driver will continue without error if
      the HC is in this condition. A block device will be created, but reading
      from it will result in a zero buffer. This makes it seem like the SD
      device has been erased, when in actuality the data is never getting
      copied from the DATA lines to the data buffer.
      
      SCR is the first command in the SD initialization sequence that uses the
      DATA lines. By checking that the response was invalid, we can abort
      mounting the card.
      Reviewed-by: default avatarAvri Altman <avri.altman@wdc.com>
      Signed-off-by: default avatarRaul E Rangel <rrangel@chromium.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      9e4be8d0
    • Pan Bian's avatar
      mmc: core: fix possible use after free of host · 8e1943af
      Pan Bian authored
      In the function mmc_alloc_host, the function put_device is called to
      release allocated resources when mmc_gpio_alloc fails. Finally, the
      function pointed by host->class_dev.class->dev_release (i.e.,
      mmc_host_classdev_release) is used to release resources including the
      host structure. However, after put_device, host is used and released
      again. Resulting in a use-after-free bug.
      
      Fixes: 1ed21719 ("mmc: core: fix error path in mmc_host_alloc")
      Signed-off-by: default avatarPan Bian <bianpan2016@163.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      8e1943af
  13. 29 Apr, 2019 2 commits
  14. 15 Apr, 2019 1 commit
    • Andrea Merello's avatar
      mmc: core: make pwrseq_emmc (partially) support sleepy GPIO controllers · 002ee28e
      Andrea Merello authored
      pwrseq_emmc.c implements a HW reset procedure for eMMC chip by driving a
      GPIO line.
      
      It registers the .reset() cb on mmc_pwrseq_ops and it registers a system
      restart notification handler; both of them perform reset by unconditionally
      calling gpiod_set_value().
      
      If the eMMC reset line is tied to a GPIO controller whose driver can sleep
      (i.e. I2C GPIO controller), then the kernel would spit warnings when trying
      to reset the eMMC chip by means of .reset() mmc_pwrseq_ops cb (that is
      exactly what I'm seeing during boot).
      
      Furthermore, on system reset we would gets to the system restart
      notification handler with disabled interrupts - local_irq_disable() is
      called in machine_restart() at least on ARM/ARM64 - and we would be in
      trouble when the GPIO driver tries to sleep (which indeed doesn't happen
      here, likely because in my case the machine specific code doesn't call
      do_kernel_restart(), I guess..).
      
      This patch fixes the .reset() cb to make use of gpiod_set_value_cansleep(),
      so that the eMMC gets reset on boot without complaints, while, since there
      isn't that much we can do, we avoid register the restart handler if the
      GPIO controller has a sleepy driver (and we spit a dev_notice() message to
      let people know)..
      
      This had been tested on a downstream 4.9 kernel with backported
      commit 83f37ee7ba33 ("mmc: pwrseq: Add reset callback to the struct
      mmc_pwrseq_ops") and commit ae60fb031cf2 ("mmc: core: Don't do eMMC HW
      reset when resuming the eMMC card"), because I couldn't boot my board
      otherwise. Maybe worth to RFT.
      Signed-off-by: default avatarAndrea Merello <andrea.merello@gmail.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      002ee28e
  15. 09 Apr, 2019 1 commit
    • Sakari Ailus's avatar
      treewide: Switch printk users from %pf and %pF to %ps and %pS, respectively · d75f773c
      Sakari Ailus authored
      %pF and %pf are functionally equivalent to %pS and %ps conversion
      specifiers. The former are deprecated, therefore switch the current users
      to use the preferred variant.
      
      The changes have been produced by the following command:
      
      	git grep -l '%p[fF]' | grep -v '^\(tools\|Documentation\)/' | \
      	while read i; do perl -i -pe 's/%pf/%ps/g; s/%pF/%pS/g;' $i; done
      
      And verifying the result.
      
      Link: http://lkml.kernel.org/r/20190325193229.23390-1-sakari.ailus@linux.intel.com
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: sparclinux@vger.kernel.org
      Cc: linux-um@lists.infradead.org
      Cc: xen-devel@lists.xenproject.org
      Cc: linux-acpi@vger.kernel.org
      Cc: linux-pm@vger.kernel.org
      Cc: drbd-dev@lists.linbit.com
      Cc: linux-block@vger.kernel.org
      Cc: linux-mmc@vger.kernel.org
      Cc: linux-nvdimm@lists.01.org
      Cc: linux-pci@vger.kernel.org
      Cc: linux-scsi@vger.kernel.org
      Cc: linux-btrfs@vger.kernel.org
      Cc: linux-f2fs-devel@lists.sourceforge.net
      Cc: linux-mm@kvack.org
      Cc: ceph-devel@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Acked-by: David Sterba <dsterba@suse.com> (for btrfs)
      Acked-by: Mike Rapoport <rppt@linux.ibm.com> (for mm/memblock.c)
      Acked-by: Bjorn Helgaas <bhelgaas@google.com> (for drivers/pci)
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      d75f773c
  16. 01 Mar, 2019 1 commit
    • Jiong Wu's avatar
      mmc:fix a bug when max_discard is 0 · d4721339
      Jiong Wu authored
      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: default avatarJiong Wu <Lohengrin1024@gmail.com>
      Fixes: b305882f (mmc: core: optimize mmc_calc_max_discard)
      Cc: stable@vger.kernel.org # v4.17+
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      d4721339
  17. 28 Feb, 2019 4 commits
  18. 27 Feb, 2019 2 commits
  19. 25 Feb, 2019 4 commits