1. 28 Feb, 2019 1 commit
  2. 17 Dec, 2018 2 commits
    • Ulf Hansson's avatar
      mmc: core: Cleanup BKOPS support · 0c204979
      Ulf Hansson authored
      
      
      It's been ~6 years ago since we introduced the BKOPS support for eMMC
      cards. The current code is a bit messy and primarily that's because it
      prepares to support running BKOPS in an asynchronous mode. However, that
      mode has never been fully implemented/enabled. Instead BKOPS is always
      executed in synchronously, when the card has reported an urgent BKOPS
      level.
      
      For these reasons, let's make the code more readable by dropping the unused
      parts. Let's also rename mmc_start_bkops() to mmc_run_bkops(), as to make
      it more descriptive.
      
      Cc: Jaehoon Chung <jh80.chung@samsung.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      0c204979
    • Ulf Hansson's avatar
      mmc: core: Drop redundant check in mmc_send_hpi_cmd() · 1217e615
      Ulf Hansson authored
      
      
      There is no point checking if HPI is supported in mmc_send_hpi_cmd() as
      mmc_interrupt_hpi(), which is the only caller, already checks if HPI has
      been enabled. Therefore, let's drop the check and the corresponding error
      path.
      
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      1217e615
  3. 16 Jul, 2018 1 commit
    • Shawn Lin's avatar
      mmc: core: Adjust and reuse the macro of R1_STATUS(x) · a94a7483
      Shawn Lin authored
      
      
      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: default avatarShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      a94a7483
  4. 27 Feb, 2018 1 commit
  5. 30 Oct, 2017 2 commits
  6. 30 Aug, 2017 2 commits
  7. 20 Jun, 2017 8 commits
  8. 24 Apr, 2017 2 commits
  9. 13 Feb, 2017 1 commit
    • Masahiro Yamada's avatar
      mmc: use empty initializer list to zero-clear structures · c7836d15
      Masahiro Yamada authored
      
      
      In the MMC subsystem, we see such initializers that only clears the
      first member explicitly.
      
      For example,
      
        struct mmc_request mrq = {NULL};
      
      sets the first member (.sbc) to NULL explicitly.  However, this is
      an unstable form because we may insert a non-pointer member at the
      top of the struct mmc_request in the future. (if we do so, the
      compiler will spit warnings.)
      
      So, using a designated initializer is preferred coding style.  The
      expression above is equivalent to:
      
        struct mmc_request mrq = { .sbc = NULL };
      
      Of course, this does not express our intention.  We want to fill
      all struct members with zeros.  Please note struct members are
      implicitly zero-cleared unless otherwise specified in the initializer.
      
      After all, the most reasonable (and stable) form is:
      
        struct mmc_request mrq = {};
      
      Do likewise for mmc_command, mmc_data as well.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      c7836d15
  10. 16 Jan, 2017 1 commit
  11. 05 Dec, 2016 3 commits
  12. 29 Nov, 2016 9 commits
  13. 25 Jul, 2016 2 commits
  14. 29 Feb, 2016 1 commit
  15. 22 Dec, 2015 1 commit
  16. 27 Oct, 2015 1 commit
    • Chaotian Jing's avatar
      mmc: mmc: extend the mmc_send_tuning() · 9979dbe5
      Chaotian Jing authored
      
      
      The mmc_execute_tuning() has already prepared the opcode,
      there is no need to prepare it again at mmc_send_tuning(),
      and, there is a BUG of mmc_send_tuning() to determine the opcode
      by bus width, assume eMMC was running at HS200, 4bit mode,
      then the mmc_send_tuning() will overwrite the opcode from CMD21
      to CMD19, then got error.
      
      in addition, extend an argument of "cmd_error" to allow getting
      if there was cmd error when tune response.
      
      Signed-off-by: default avatarChaotian Jing <chaotian.jing@mediatek.com>
      [Ulf: Rebased patch]
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      9979dbe5
  17. 26 Oct, 2015 1 commit
  18. 01 Jun, 2015 1 commit