1. 27 8月, 2015 1 次提交
  2. 17 8月, 2015 2 次提交
  3. 24 7月, 2015 1 次提交
  4. 16 6月, 2015 1 次提交
    • D
      mmc: card: Fixup request missing in mmc_blk_issue_rw_rq · 29535f7b
      Ding Wang 提交于
      The current handler of MMC_BLK_CMD_ERR in mmc_blk_issue_rw_rq function
      may cause new coming request permanent missing when the ongoing
      request (previoulsy started) complete end.
      
      The problem scenario is as follows:
      (1) Request A is ongoing;
      (2) Request B arrived, and finally mmc_blk_issue_rw_rq() is called;
      (3) Request A encounters the MMC_BLK_CMD_ERR error;
      (4) In the error handling of MMC_BLK_CMD_ERR, suppose mmc_blk_cmd_err()
          end request A completed and return zero. Continue the error handling,
          suppose mmc_blk_reset() reset device success;
      (5) Continue the execution, while loop completed because variable ret
          is zero now;
      (6) Finally, mmc_blk_issue_rw_rq() return without processing request B.
      
      The process related to the missing request may wait that IO request
      complete forever, possibly crashing the application or hanging the system.
      
      Fix this issue by starting new request when reset success.
      Signed-off-by: NDing Wang <justin.wang@spreadtrum.com>
      Fixes: 67716327 ("mmc: block: add eMMC hardware reset support")
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      29535f7b
  5. 01 6月, 2015 3 次提交
  6. 06 5月, 2015 1 次提交
    • C
      mmc: card: Don't access RPMB partitions for normal read/write · 4e93b9a6
      Chuanxiao Dong 提交于
      During kernel boot, it will try to read some logical sectors
      of each block device node for the possible partition table.
      
      But since RPMB partition is special and can not be accessed
      by normal eMMC read / write CMDs, it will cause below error
      messages during kernel boot:
      ...
       mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
       mmcblk0rpmb: error -110 transferring data, sector 0, nr 32, cmd response 0x900, card status 0xb00
       mmcblk0rpmb: retrying using single block read
       mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
       mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
       mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
       mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
       mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
       mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
       end_request: I/O error, dev mmcblk0rpmb, sector 0
       Buffer I/O error on device mmcblk0rpmb, logical block 0
       end_request: I/O error, dev mmcblk0rpmb, sector 8
       Buffer I/O error on device mmcblk0rpmb, logical block 1
       end_request: I/O error, dev mmcblk0rpmb, sector 16
       Buffer I/O error on device mmcblk0rpmb, logical block 2
       end_request: I/O error, dev mmcblk0rpmb, sector 24
       Buffer I/O error on device mmcblk0rpmb, logical block 3
      ...
      
      This patch will discard the access request in eMMC queue if
      it is RPMB partition access request. By this way, it avoids
      trigger above error messages.
      
      Fixes: 090d25fe ("mmc: core: Expose access to RPMB partition")
      Signed-off-by: NYunpeng Gao <yunpeng.gao@intel.com>
      Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
      Tested-by: NMichael Shigorin <mike@altlinux.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      4e93b9a6
  7. 17 4月, 2015 1 次提交
    • U
      Revert "mmc: core: Convert mmc_driver to device_driver" · 96541bac
      Ulf Hansson 提交于
      This reverts commit 6685ac62 ("mmc: core: Convert mmc_driver to
      device_driver")
      
      The reverted commit went too far in simplifing the device driver parts
      for mmc.
      
      Let's restore the old mmc_driver to enable driver core to sooner
      or later to remove the ->probe(), ->remove() and ->shutdown() callbacks
      from the struct device_driver.
      
      Note that, the old ->suspend|resume() callbacks in the struct
      mmc_driver don't need to be restored, since the mmc block layer has
      converted to the modern system PM ops.
      
      Fixes: 6685ac62 ("mmc: core: Convert mmc_driver to device_driver")
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
      96541bac
  8. 11 4月, 2015 1 次提交
    • J
      sd, mmc, virtio_blk, string_helpers: fix block size units · b9f28d86
      James Bottomley 提交于
      The current string_get_size() overflows when the device size goes over
      2^64 bytes because the string helper routine computes the suffix from
      the size in bytes.  However, the entirety of Linux thinks in terms of
      blocks, not bytes, so this will artificially induce an overflow on very
      large devices.  Fix this by making the function string_get_size() take
      blocks and the block size instead of bytes.  This should allow us to
      keep working until the current SCSI standard overflows.
      
      Also fix virtio_blk and mmc (both of which were also artificially
      multiplying by the block size to pass a byte side to string_get_size()).
      
      The mathematics of this is pretty simple:  we're taking a product of
      size in blocks (S) and block size (B) and trying to re-express this in
      exponential form: S*B = R*N^E (where N, the exponent is either 1000 or
      1024) and R < N.  Mathematically, S = RS*N^ES and B=RB*N^EB, so if RS*RB
      < N it's easy to see that S*B = RS*RB*N^(ES+EB).  However, if RS*BS > N,
      we can see that this can be re-expressed as RS*BS = R*N (where R =
      RS*BS/N < N) so the whole exponent becomes R*N^(ES+EB+1)
      
      [jejb: fix incorrect 32 bit do_div spotted by kbuild test robot <fengguang.wu@intel.com>]
      Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJames Bottomley <JBottomley@Odin.com>
      b9f28d86
  9. 28 1月, 2015 1 次提交
  10. 21 1月, 2015 1 次提交
  11. 26 11月, 2014 1 次提交
    • B
      mmc: block: Increase max_devices · a26eba61
      Ben Hutchings 提交于
      Currently the driver imposes a limit of 256 total minor numbers,
      apparently based on the historic Unix/Linux limit.  This is quite
      restrictive, particularly if we raise the maximum number of
      partitions per card to 256 to match sd.
      
      In order to make the full minor number space available we would
      have to replace the static dev_use and name_use arrays with struct
      ida.  But we can at least allow use of 256 cards rather than just
      256 minors, with only a small change.
      Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      a26eba61
  12. 10 11月, 2014 5 次提交
  13. 24 9月, 2014 1 次提交
  14. 19 9月, 2014 1 次提交
  15. 09 9月, 2014 3 次提交
  16. 26 7月, 2014 1 次提交
  17. 23 2月, 2014 4 次提交
  18. 14 2月, 2014 1 次提交
  19. 14 1月, 2014 1 次提交
  20. 31 10月, 2013 1 次提交
    • U
      mmc: Don't force card to active state when entering suspend/shutdown · 9ec775f7
      Ulf Hansson 提交于
      By adding a card state that records if it is suspended or resumed, we
      can accept asyncronus suspend/resume requests for the mmc and sd
      bus_ops.
      
      MMC_CAP_AGGRESSIVE_PM, will at request inactivity through the runtime
      bus_ops callbacks, execute a suspend of the the card. In the state were
      this has been done, we can receive a suspend request for the mmc bus,
      which for sd and mmc forced the card to active state by a
      pm_runtime_get_sync. In other words, the card was resumed and then
      immediately suspended again, completely unnecessary.
      
      Since the suspend/resume bus_ops callbacks for sd and mmc are now
      capable of handling asynchronous requests, we no longer need to force
      the card to active state before executing suspend. Evidently preventing
      the above sequence for MMC_CAP_AGGRESSIVE_PM.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      9ec775f7
  21. 25 8月, 2013 2 次提交
  22. 28 6月, 2013 1 次提交
  23. 27 6月, 2013 2 次提交
    • Y
      mmc: card: fixing an false identification of SANITIZE command · a82e484e
      Yaniv Gardi 提交于
      Inside the routine mmc_blk_ioctl_cmd() the sanitize command is
      identified according to the value of bits 16-23 of the argument.
      
      but what happens if a different command is sent, and only by
      chance, bits 16-23 contain the value of SANITIZE command ?
      In that case a SANITIZE command will be falsely identified.
      In order to prevent such a case, the condition is expanded and
      now it also checks the opcode itself, and verifies that it is an
      MMC_SWITCH opcode.
      Signed-off-by: NYaniv Gardi <ygardi@codeaurora.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      a82e484e
    • P
      mmc: reordered shutdown sequence in mmc_bld_remove_req · fdfa20c1
      Paul Taysom 提交于
      We had a multi-partition SD-Card with two ext2 file systems. The partition
      table was getting overwritten by a race between the card removal and
      the unmount of the 2nd ext2 partition.
      
      What was observed:
      1. Suspend/resume would call to remove the device. The clearing
         of the device information is done asynchronously.
      2. A request is made to unmount the file system (this is called
         after the removal has started).
      3. The remapping table was cleared by the asynchronous part of
         the device removal.
      4. A write request to the super block (block 0 of the partition)
         was sent down and instead of being remapped to the partition
         offset, it was remapped to block 0 of the device which is where
         the partition table is located.
      5. Write was queued and written resulting in the overwriting
         of the partition table with the ext2 super block.
      6. The mmc_queue is cleaned up.
      
      The mmc card device driver used to access SD cards, was calling del_gendisk
      before calling mmc_cleanup-queue. The comment in the mmc_blk_remove_req
      code indicated that it expected del_gendisk to block all further requests
      from being queued but it doesn't. The mmc driver uses the presences of the
      mmc_queue to determine if the request should be queued.
      
      The fix was to clean up the mmc_queue before the rest of the
      the delete partition code is called.
      
      This prevents the overwriting of the partition table.
      
      However, the umount gets an error trying to write the super block.
      The umount should be issued before the device is removed but that
      is not always possible. The umount is still needed to cleanup other
      data structures.
      
      Addresses the problem described in http://crbug.com/240815Signed-off-by: NPaul Taysom <taysom@chromium.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      fdfa20c1
  24. 27 5月, 2013 2 次提交
    • U
      mmc: block: Enable runtime pm for mmc blkdevice · e94cfef6
      Ulf Hansson 提交于
      Once the mmc blkdevice is being probed, runtime pm will be enabled.
      By using runtime autosuspend, the power save operations can be done
      when request inactivity occurs for a certain time. Right now the
      selected timeout value is set to 3 s. Obviously this value will likely
      need to be configurable somehow since it needs to be trimmed depending
      on the power save algorithm.
      
      For SD-combo cards, we are still leaving the enablement of runtime PM
      to the SDIO init sequence since it depends on the capabilities of the
      SDIO func driver.
      
      Moreover, when the blk device is being suspended, we make sure the device
      will be runtime resumed. The reason for doing this is that we want the
      host suspend sequence to be unaware of any runtime power save operations
      done for the card in this phase. Thus it can just handle the suspend as
      the card is fully powered from a runtime perspective.
      
      Finally, this patch prepares to make it possible to move BKOPS handling
      into the runtime callbacks for the mmc bus_ops. Thus IDLE BKOPS can be
      accomplished.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      e94cfef6
    • M
      mmc: card: Adding support for sanitize in eMMC 4.5 · 775a9362
      Maya Erez 提交于
      The sanitize support is added as a user-app ioctl call, and
      was removed from the block-device request, since its purpose is
      to be invoked not via File-System but by a user.
      
      This feature deletes the unmap memory region of the eMMC card,
      by writing to a specific register in the EXT_CSD.
      
      unmap region is the memory region that was previously deleted
      (by erase, trim or discard operation).
      
      In order to avoid timeout when sanitizing large-scale cards,
      the timeout for sanitize operation is 240 seconds.
      Signed-off-by: NYaniv Gardi <ygardi@codeaurora.org>
      Signed-off-by: NMaya Erez <merez@codeaurora.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      775a9362
  25. 07 5月, 2013 1 次提交