user/sven/linux.git/include/linux/mmc, branch v4.19.290

mmc: core: Fix size overflow for mmc partitions

2020-10-01T11:14:28Z

[ Upstream commit f3d7c2292d104519195fdb11192daec13229c219 ] With large eMMC cards, it is possible to create general purpose partitions that are bigger than 4GB. The size member of the mmc_part struct is only an unsigned int which overflows for gp partitions larger than 4GB. Change this to a u64 to handle the overflow. Signed-off-by: Bradley Bolen Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin

mmc: core: Allow host controllers to require R1B for CMD6

2020-04-02T13:28:09Z

[ Upstream commit 1292e3efb149ee21d8d33d725eeed4e6b1ade963 ] It has turned out that some host controllers can't use R1B for CMD6 and other commands that have R1B associated with them. Therefore invent a new host cap, MMC_CAP_NEED_RSP_BUSY to let them specify this. In __mmc_switch(), let's check the flag and use it to prevent R1B responses from being converted into R1. Note that, this also means that the host are on its own, when it comes to manage the busy timeout. Suggested-by: Sowjanya Komatineni Cc: Tested-by: Anders Roxell Tested-by: Sowjanya Komatineni Tested-by: Faiz Abbas Tested-By: Peter Geis Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin

mmc: sdio: fix wl1251 vendor id

2020-01-27T13:51:21Z

[ Upstream commit e5db673e7fe2f971ec82039a28dc0811c2100e87 ] v4.11-rc1 did introduce a patch series that rearranged the sdio quirks into a header file. Unfortunately this did forget to handle SDIO_VENDOR_ID_TI differently between wl1251 and wl1271 with the result that although the wl1251 was found on the sdio bus, the firmware did not load any more and there was no interface registration. This patch defines separate constants to be used by sdio quirks and drivers. Fixes: 884f38607897 ("mmc: core: move some sdio IDs out of quirks file") Signed-off-by: H. Nikolaus Schaller Cc: # v4.11+ Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin

mmc: core: Add helper function to indicate if SDIO IRQs is enabled

2019-10-05T11:09:57Z

[ Upstream commit bd880b00697befb73eff7220ee20bdae4fdd487b ] To avoid each host driver supporting SDIO IRQs, from keeping track internally about if SDIO IRQs has been claimed, let's introduce a common helper function, sdio_irq_claimed(). The function returns true if SDIO IRQs are claimed, via using the information about the number of claimed irqs. This is safe, even without any locks, as long as the helper function is called only from runtime/system suspend callbacks of the host driver. Tested-by: Matthias Kaehlcke Signed-off-by: Ulf Hansson Reviewed-by: Douglas Anderson Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin

mmc: core: Add sdio_retune_hold_now() and sdio_retune_release()

2019-06-25T03:35:53Z

commit b4c9f938d542d5f88c501744d2d12fad4fd2915f upstream. 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: Douglas Anderson Acked-by: Adrian Hunter Acked-by: Kalle Valo Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: core: API to temporarily disable retuning for SDIO CRC errors

2019-06-25T03:35:53Z

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: Douglas Anderson Acked-by: Adrian Hunter Acked-by: Kalle Valo Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: block: handle complete_work on separate workqueue

2019-02-20T09:25:46Z

commit dcf6e2e38a1c7ccbc535de5e1d9b14998847499d upstream. The kblockd workqueue is created with the WQ_MEM_RECLAIM flag set. This generates a rescuer thread for that queue that will trigger when the CPU is under heavy load and collect the uncompleted work. In the case of mmc, this creates the possibility of a deadlock when there are multiple partitions on the device as other blk-mq work is also run on the same queue. For example: - worker 0 claims the mmc host to work on partition 1 - worker 1 attempts to claim the host for partition 2 but has to wait for worker 0 to finish - worker 0 schedules complete_work to release the host - rescuer thread is triggered after time-out and collects the dangling work - rescuer thread attempts to complete the work in order starting with claim host - the task to release host is now blocked by a task to claim it and will never be called The above results in multiple hung tasks that lead to failures to mount partitions. Handling complete_work on a separate workqueue avoids this by keeping the work completion tasks separate from the other blk-mq work. This allows the host to be released without getting blocked by other tasks attempting to claim the host. Signed-off-by: Zachary Hays Fixes: 81196976ed94 ("mmc: block: Add blk-mq support") Cc: Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: core: Drop the unused mmc_power_save|restore_host()

2018-07-16T09:21:45Z

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 Cc: Eyal Reizer Signed-off-by: Ulf Hansson

mmc: core: more fine-grained hooks for HS400 tuning

2018-07-16T09:21:45Z

This adds two new HS400 tuning operations: * hs400_downgrade * hs400_complete These supplement the existing HS400 operation: * prepare_hs400_tuning This is motivated by a requirement of Renesas SDHI for the following: 1. Disabling SCC before selecting to HS if selection of HS400 has occurred. This can be done in an implementation of prepare_hs400_tuning_downgrade 2. Updating registers after switching to HS400 This can be done in an implementation of complete_hs400_tuning If hs400_downgrade or hs400_complete are not implemented then they are not called. Thus means there should be no affect for existing drivers as none implemt these ops. Signed-off-by: Simon Horman Signed-off-by: Ulf Hansson

mmc: core: Adjust and reuse the macro of R1_STATUS(x)

2018-07-16T09:21:45Z

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: Shawn Lin Signed-off-by: Ulf Hansson