summaryrefslogtreecommitdiff
path: root/drivers/mmc/core
AgeCommit message (Collapse)AuthorFilesLines
2023-11-20Revert "mmc: core: Capture correct oemid-bits for eMMC cards"Dominique Martinet1-1/+1
commit 421b605edb1ce611dee06cf6fd9a1c1f2fd85ad0 upstream. This reverts commit 84ee19bffc9306128cd0f1c650e89767079efeff. The commit above made quirks with an OEMID fail to be applied, as they were checking card->cid.oemid for the full 16 bits defined in MMC_FIXUP macros but the field would only contain the bottom 8 bits. eMMC v5.1A might have bogus values in OEMID's higher bits so another fix will be made, but it has been decided to revert this until that is ready. Fixes: 84ee19bffc93 ("mmc: core: Capture correct oemid-bits for eMMC cards") Link: https://lkml.kernel.org/r/ZToJsSLHr8RnuTHz@codewreck.org Link: https://lkml.kernel.org/r/CAPDyKFqkKibcXnwjnhc3+W1iJBHLeqQ9BpcZrSwhW2u9K2oUtg@mail.gmail.com Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com> Cc: stable@vger.kernel.org Cc: Alex Fetters <Alex.Fetters@garmin.com> Reviewed-by: Avri Altman <avri.altman@wdc.com> Link: https://lore.kernel.org/r/20231103004220.1666641-1-asmadeus@codewreck.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-25mmc: core: Capture correct oemid-bits for eMMC cardsAvri Altman1-1/+1
commit 84ee19bffc9306128cd0f1c650e89767079efeff upstream. The OEMID is an 8-bit binary number rather than 16-bit as the current code parses for. The OEMID occupies bits [111:104] in the CID register, see the eMMC spec JESD84-B51 paragraph 7.2.3. It seems that the 16-bit comes from the legacy MMC specs (v3.31 and before). Let's fix the parsing by simply move to use 8-bit instead of 16-bit. This means we ignore the impact on some of those old MMC cards that may be out there, but on the other hand this shouldn't be a problem as the OEMID seems not be an important feature for these cards. Signed-off-by: Avri Altman <avri.altman@wdc.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230927071500.1791882-1-avri.altman@wdc.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-11mmc: core: disable TRIM on Micron MTFC4GACAJCN-1MRobert Marko1-0/+7
commit dbfbddcddcebc9ce8a08757708d4e4a99d238e44 upstream. It seems that Micron MTFC4GACAJCN-1M despite advertising TRIM support does not work when the core is trying to use REQ_OP_WRITE_ZEROES. We are seeing the following errors in OpenWrt under 6.1 on Qnap Qhora 301W that we did not previously have and tracked it down to REQ_OP_WRITE_ZEROES: [ 18.085950] I/O error, dev loop0, sector 596 op 0x9:(WRITE_ZEROES) flags 0x800 phys_seg 0 prio class 2 Disabling TRIM makes the error go away, so lets add a quirk for this eMMC to disable TRIM. Signed-off-by: Robert Marko <robimarko@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230530213259.1776512-1-robimarko@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-11mmc: core: disable TRIM on Kingston EMMC04G-M627Robert Marko1-0/+7
commit f1738a1f816233e6dfc2407f24a31d596643fd90 upstream. It seems that Kingston EMMC04G-M627 despite advertising TRIM support does not work when the core is trying to use REQ_OP_WRITE_ZEROES. We are seeing I/O errors in OpenWrt under 6.1 on Zyxel NBG7815 that we did not previously have and tracked it down to REQ_OP_WRITE_ZEROES. Trying to use fstrim seems to also throw errors like: [93010.835112] I/O error, dev loop0, sector 16902 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 2 Disabling TRIM makes the error go away, so lets add a quirk for this eMMC to disable TRIM. Signed-off-by: Robert Marko <robimarko@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230619193621.437358-1-robimarko@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-21mmc: block: ensure error propagation for non-blkChristian Loehle1-0/+5
commit 003fb0a51162d940f25fc35e70b0996a12c9e08a upstream. Requests to the mmc layer usually come through a block device IO. The exceptions are the ioctl interface, RPMB chardev ioctl and debugfs, which issue their own blk_mq requests through blk_execute_rq and do not query the BLK_STS error but the mmcblk-internal drv_op_result. This patch ensures that drv_op_result defaults to an error and has to be overwritten by the operation to be considered successful. The behavior leads to a bug where the request never propagates the error, e.g. by directly erroring out at mmc_blk_mq_issue_rq if mmc_blk_part_switch fails. The ioctl caller of the rpmb chardev then can never see an error (BLK_STS_IOERR, but drv_op_result is unchanged) and thus may assume that their call executed successfully when it did not. While always checking the blk_execute_rq return value would be advised, let's eliminate the error by always setting drv_op_result as -EIO to be overwritten on success (or other error) Fixes: 614f0388f580 ("mmc: block: move single ioctl() commands to block requests") Signed-off-by: Christian Loehle <cloehle@hyperstone.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/59c17ada35664b818b7bd83752119b2d@hyperstone.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Christian Loehle <cloehle@hyperstone.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-22mmc: sdio: fix possible resource leaks in some error pathsYang Yingliang2-15/+14
commit 605d9fb9556f8f5fb4566f4df1480f280f308ded upstream. If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can not release the resources, because the sdio function is not presented in these two cases, it won't call of_node_put() or put_device(). To fix these leaks, make sdio_func_present() only control whether device_del() needs to be called or not, then always call of_node_put() and put_device(). In error case in sdio_init_func(), the reference of 'card->dev' is not get, to avoid redundant put in sdio_free_func_cis(), move the get_device() to sdio_alloc_func() and put_device() to sdio_release_func(), it can keep the get/put function be balanced. Without this patch, while doing fault inject test, it can get the following leak reports, after this fix, the leak is gone. unreferenced object 0xffff888112514000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s) hex dump (first 32 bytes): 00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X...... 10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core] [<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core] [<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core] unreferenced object 0xffff888112511000 (size 2048): comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s) hex dump (first 32 bytes): 00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X...... 10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q..... backtrace: [<000000009e5931da>] kmalloc_trace+0x21/0x110 [<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core] [<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core] [<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core] Fixes: 3d10a1ba0d37 ("sdio: fix reference counting in sdio_remove_func()") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230130125808.3471254-1-yangyingliang@huawei.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-11-25mmc: core: properly select voltage range without power cycleYann Gautier1-1/+7
commit 39a72dbfe188291b156dd6523511e3d5761ce775 upstream. In mmc_select_voltage(), if there is no full power cycle, the voltage range selected at the end of the function will be on a single range (e.g. 3.3V/3.4V). To keep a range around the selected voltage (3.2V/3.4V), the mask shift should be reduced by 1. This issue was triggered by using a specific SD-card (Verbatim Premium 16GB UHS-1) on an STM32MP157C-DK2 board. This board cannot do UHS modes and there is no power cycle. And the card was failing to switch to high-speed mode. When adding the range 3.2V/3.3V for this card with the proposed shift change, the card can switch to high-speed mode. Fixes: ce69d37b7d8f ("mmc: core: Prevent violation of specs while initializing cards") Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221028073740.7259-1-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-11-03mmc: core: Fix kernel panic when remove non-standard SDIO cardMatthew Ma1-1/+2
commit 9972e6b404884adae9eec7463e30d9b3c9a70b18 upstream. SDIO tuple is only allocated for standard SDIO card, especially it causes memory corruption issues when the non-standard SDIO card has removed, which is because the card device's reference counter does not increase for it at sdio_init_func(), but all SDIO card device reference counter gets decreased at sdio_release_func(). Fixes: 6f51be3d37df ("sdio: allow non-standard SDIO cards") Signed-off-by: Matthew Ma <mahongwei@zeku.com> Reviewed-by: Weizhao Ouyang <ouyangweizhao@zeku.com> Reviewed-by: John Wang <wangdayu@zeku.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221014034951.2300386-1-ouyangweizhao@zeku.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-26mmc: core: Terminate infinite loop in SD-UHS voltage switchBrian Norris1-1/+2
commit e9233917a7e53980664efbc565888163c0a33c3f upstream. This loop intends to retry a max of 10 times, with some implicit termination based on the SD_{R,}OCR_S18A bit. Unfortunately, the termination condition depends on the value reported by the SD card (*rocr), which may or may not correctly reflect what we asked it to do. Needless to say, it's not wise to rely on the card doing what we expect; we should at least terminate the loop regardless. So, check both the input and output values, so we ensure we will terminate regardless of the SD card behavior. Note that SDIO learned a similar retry loop in commit 0797e5f1453b ("mmc: core: Fixup signal voltage switch"), but that used the 'ocr' result, and so the current pre-terminating condition looks like: rocr & ocr & R4_18V_PRESENT (i.e., it doesn't have the same bug.) This addresses a number of crash reports seen on ChromeOS that look like the following: ... // lots of repeated: ... <4>[13142.846061] mmc1: Skipping voltage switch <4>[13143.406087] mmc1: Skipping voltage switch <4>[13143.964724] mmc1: Skipping voltage switch <4>[13144.526089] mmc1: Skipping voltage switch <4>[13145.086088] mmc1: Skipping voltage switch <4>[13145.645941] mmc1: Skipping voltage switch <3>[13146.153969] INFO: task halt:30352 blocked for more than 122 seconds. ... Fixes: f2119df6b764 ("mmc: sd: add support for signal voltage switch procedure") Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20220914014010.2076169-1-briannorris@chromium.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-10-26mmc: core: Replace with already defined values for readabilityChanWoo Lee1-1/+1
commit e427266460826bea21b70f9b2bb29decfb2c2620 upstream. SD_ROCR_S18A is already defined and is used to check the rocr value, so let's replace with already defined values for readability. Signed-off-by: ChanWoo Lee <cw9316.lee@samsung.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220706004840.24812-1-cw9316.lee@samsung.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-25mmc: core: Default to generic_cmd6_time as timeout in __mmc_switch()Ulf Hansson1-10/+8
commit 533a6cfe08f96a7b5c65e06d20916d552c11b256 upstream All callers of __mmc_switch() should now be specifying a valid timeout for the CMD6 command. However, just to be sure, let's print a warning and default to use the generic_cmd6_time in case the provided timeout_ms argument is zero. In this context, let's also simplify some of the corresponding code and clarify some related comments. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200122142747.5690-4-ulf.hansson@linaro.org Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-25mmc: block: Use generic_cmd6_time when modifying INAND_CMD38_ARG_EXT_CSDUlf Hansson1-3/+3
commit ad91619aa9d78ab1c6d4a969c3db68bc331ae76c upstream The INAND_CMD38_ARG_EXT_CSD is a vendor specific EXT_CSD register, which is used to prepare an erase/trim operation. However, it doesn't make sense to use a timeout of 10 minutes while updating the register, which becomes the case when the timeout_ms argument for mmc_switch() is set to zero. Instead, let's use the generic_cmd6_time, as that seems like a reasonable timeout to use for these cases. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200122142747.5690-3-ulf.hansson@linaro.org Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-05-25mmc: core: Specify timeouts for BKOPS and CACHE_FLUSH for eMMCUlf Hansson1-3/+6
commit 24ed3bd01d6a844fd5e8a75f48d0a3d10ed71bf9 upstream The timeout values used while waiting for a CMD6 for BKOPS or a CACHE_FLUSH to complete, are not defined by the eMMC spec. However, a timeout of 10 minutes as is currently being used, is just silly for both of these cases. Instead, let's specify more reasonable timeouts, 120s for BKOPS and 30s for CACHE_FLUSH. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200122142747.5690-2-ulf.hansson@linaro.org Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-20mmc: host: Return an error when ->enable_sdio_irq() ops is missingUlf Hansson1-2/+13
[ Upstream commit d6c9219ca1139b74541b2a98cee47a3426d754a9 ] Even if the current WARN() notifies the user that something is severely wrong, we can still end up in a PANIC() when trying to invoke the missing ->enable_sdio_irq() ops. Therefore, let's also return an error code and prevent the host from being added. While at it, move the code into a separate function to prepare for subsequent changes and for further host caps validations. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20220303165142.129745-1-ulf.hansson@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27mmc: core: Fixup storing of OCR for MMC_QUIRK_NONSTD_SDIOUlf Hansson1-1/+3
[ Upstream commit 8c3e5b74b9e2146f564905e50ca716591c76d4f1 ] The mmc core takes a specific path to support initializing of a non-standard SDIO card. This is triggered by looking for the card-quirk, MMC_QUIRK_NONSTD_SDIO. In mmc_sdio_init_card() this gets rather messy, as it causes the code to bail out earlier, compared to the usual path. This leads to that the OCR doesn't get saved properly in card->ocr. Fortunately, only omap_hsmmc has been using the MMC_QUIRK_NONSTD_SDIO and is dealing with the issue, by assigning a hardcoded value (0x80) to card->ocr from an ->init_card() ops. To make the behaviour consistent, let's instead rely on the core to save the OCR in card->ocr during initialization. Reported-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Link: https://lore.kernel.org/r/e7936cff7fc24d187ef2680d3b4edb0ade58f293.1636564631.git.hns@goldelico.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20mmc: core: Allow UHS-I voltage switch for SDSC cards if supportedChristian Löhle1-4/+6
commit 09247e110b2efce3a104e57e887c373e0a57a412 upstream. While initializing an UHS-I SD card, the mmc core first tries to switch to 1.8V I/O voltage, before it continues to change the settings for the bus speed mode. However, the current behaviour in the mmc core is inconsistent and doesn't conform to the SD spec. More precisely, an SD card that supports UHS-I must set both the SD_OCR_CCS bit and the SD_OCR_S18R bit in the OCR register response. When switching to 1.8V I/O the mmc core correctly checks both of the bits, but only the SD_OCR_S18R bit when changing the settings for bus speed mode. Rather than actually fixing the code to confirm to the SD spec, let's deliberately deviate from it by requiring only the SD_OCR_S18R bit for both parts. This enables us to support UHS-I for SDSC cards (outside spec), which is actually being supported by some existing SDSC cards. Moreover, this fixes the inconsistent behaviour. Signed-off-by: Christian Loehle <cloehle@hyperstone.com> Link: https://lore.kernel.org/r/CWXP265MB26803AE79E0AD5ED083BF2A6C4529@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM Cc: stable@vger.kernel.org [Ulf: Rewrote commit message and comments to clarify the changes] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-20mmc: core: clear flags before allowing to retuneWolfram Sang1-2/+5
commit 77347eda64ed5c9383961d1de9165f9d0b7d8df6 upstream. It might be that something goes wrong during tuning so the MMC core will immediately trigger a retune. In our case it was: - we sent a tuning block - there was an error so we need to send an abort cmd to the eMMC - the abort cmd had a CRC error - retune was set by the MMC core This lead to a vicious circle causing a performance regression of 75%. So, clear retuning flags before we enable retuning to start with a known cleared state. Reported-by Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Suggested-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210624151616.38770-2-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-22mmc: core: Set read only for SD cards with permanent write protect bitSeunghui Lee1-0/+6
commit 917a5336f2c27928be270226ab374ed0cbf3805d upstream. Some of SD cards sets permanent write protection bit in their CSD register, due to lifespan or internal problem. To avoid unnecessary I/O write operations, let's parse the bits in the CSD during initialization and mark the card as read only for this case. Signed-off-by: Seunghui Lee <sh043.lee@samsung.com> Link: https://lore.kernel.org/r/20210222083156.19158-1-sh043.lee@samsung.com Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-22mmc: core: Do a power cycle when the CMD11 failsDooHyun Hwang1-1/+1
commit 147186f531ae49c18b7a9091a2c40e83b3d95649 upstream. A CMD11 is sent to the SD/SDIO card to start the voltage switch procedure into 1.8V I/O. According to the SD spec a power cycle is needed of the card, if it turns out that the CMD11 fails. Let's fix this, to allow a retry of the initialization without the voltage switch, to succeed. Note that, whether it makes sense to also retry with the voltage switch after the power cycle is a bit more difficult to know. At this point, we treat it like the CMD11 isn't supported and therefore we skip it when retrying. Signed-off-by: DooHyun Hwang <dh0421.hwang@samsung.com> Link: https://lore.kernel.org/r/20210210045936.7809-1-dh0421.hwang@samsung.com Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-22mmc: block: Update ext_csd.cache_ctrl if it was writtenAvri Altman1-0/+12
commit aea0440ad023ab0662299326f941214b0d7480bd upstream. The cache function can be turned ON and OFF by writing to the CACHE_CTRL byte (EXT_CSD byte [33]). However, card->ext_csd.cache_ctrl is only set on init if cache size > 0. Fix that by explicitly setting ext_csd.cache_ctrl on ext-csd write. Signed-off-by: Avri Altman <avri.altman@wdc.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210420134641.57343-3-avri.altman@wdc.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17mmc: core: Fix partition switch time for eMMCAdrian Hunter1-4/+11
commit 66fbacccbab91e6e55d9c8f1fc0910a8eb6c81f7 upstream. Avoid the following warning by always defining partition switch time: [ 3.209874] mmc1: unspecified timeout for CMD6 - use generic [ 3.222780] ------------[ cut here ]------------ [ 3.233363] WARNING: CPU: 1 PID: 111 at drivers/mmc/core/mmc_ops.c:575 __mmc_switch+0x200/0x204 Reported-by: Paul Fertser <fercerpav@gmail.com> Fixes: 1c447116d017 ("mmc: mmc: Fix partition switch timeout for some eMMCs") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/168bbfd6-0c5b-5ace-ab41-402e7937c46e@intel.com Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-10mmc: core: Limit retries when analyse of SDIO tuples failsFengnan Chang1-0/+6
commit f92e04f764b86e55e522988e6f4b6082d19a2721 upstream. When analysing tuples fails we may loop indefinitely to retry. Let's avoid this by using a 10s timeout and bail if not completed earlier. Signed-off-by: Fengnan Chang <fengnanchang@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210123033230.36442-1-fengnanchang@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-29mmc: sdio: Check for CISTPL_VERS_1 buffer sizePali Rohár1-0/+3
[ Upstream commit 8ebe2607965d3e2dc02029e8c7dd35fbe508ffd0 ] Before parsing CISTPL_VERS_1 structure check that its size is at least two bytes to prevent buffer overflow. Signed-off-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20200727133837.19086-2-pali@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-14mmc: core: don't set limits.discard_granularity as 0Coly Li1-1/+1
[ Upstream commit 4243219141b67d7c2fdb2d8073c17c539b9263eb ] In mmc_queue_setup_discard() the mmc driver queue's discard_granularity might be set as 0 (when card->pref_erase > max_discard) while the mmc device still declares to support discard operation. This is buggy and triggered the following kernel warning message, WARNING: CPU: 0 PID: 135 at __blkdev_issue_discard+0x200/0x294 CPU: 0 PID: 135 Comm: f2fs_discard-17 Not tainted 5.9.0-rc6 #1 Hardware name: Google Kevin (DT) pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--) pc : __blkdev_issue_discard+0x200/0x294 lr : __blkdev_issue_discard+0x54/0x294 sp : ffff800011dd3b10 x29: ffff800011dd3b10 x28: 0000000000000000 x27: ffff800011dd3cc4 x26: ffff800011dd3e18 x25: 000000000004e69b x24: 0000000000000c40 x23: ffff0000f1deaaf0 x22: ffff0000f2849200 x21: 00000000002734d8 x20: 0000000000000008 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000394 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 00000000000008b0 x9 : ffff800011dd3cb0 x8 : 000000000004e69b x7 : 0000000000000000 x6 : ffff0000f1926400 x5 : ffff0000f1940800 x4 : 0000000000000000 x3 : 0000000000000c40 x2 : 0000000000000008 x1 : 00000000002734d8 x0 : 0000000000000000 Call trace: __blkdev_issue_discard+0x200/0x294 __submit_discard_cmd+0x128/0x374 __issue_discard_cmd_orderly+0x188/0x244 __issue_discard_cmd+0x2e8/0x33c issue_discard_thread+0xe8/0x2f0 kthread+0x11c/0x120 ret_from_fork+0x10/0x1c ---[ end trace e4c8023d33dfe77a ]--- This patch fixes the issue by setting discard_granularity as SECTOR_SIZE instead of 0 when (card->pref_erase > max_discard) is true. Now no more complain from __blkdev_issue_discard() for the improper value of discard granularity. This issue is exposed after commit b35fd7422c2f ("block: check queue's limits.discard_granularity in __blkdev_issue_discard()"), a "Fixes:" tag is also added for the commit to make sure people won't miss this patch after applying the change of __blkdev_issue_discard(). Fixes: e056a1b5b67b ("mmc: queue: let host controllers specify maximum discard timeout") Fixes: b35fd7422c2f ("block: check queue's limits.discard_granularity in __blkdev_issue_discard()"). Reported-and-tested-by: Vicente Bergas <vicencb@gmail.com> Signed-off-by: Coly Li <colyli@suse.de> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20201002013852.51968-1-colyli@suse.de Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01mmc: core: Fix size overflow for mmc partitionsBradley Bolen1-5/+4
[ 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 <bradleybolen@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-20mmc: sdio: Fix potential NULL pointer error in mmc_sdio_init_card()Ulf Hansson1-2/+1
commit f04086c225da11ad16d7f9a2fbca6483ab16dded upstream. During some scenarios mmc_sdio_init_card() runs a retry path for the UHS-I specific initialization, which leads to removal of the previously allocated card. A new card is then re-allocated while retrying. However, in one of the corresponding error paths we may end up to remove an already removed card, which likely leads to a NULL pointer exception. So, let's fix this. Fixes: 5fc3d80ef496 ("mmc: sdio: don't use rocr to check if the card could support UHS mode") Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200430091640.455-2-ulf.hansson@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-03mmc: block: Fix use-after-free issue for rpmbPeng Hao1-1/+1
[ Upstream commit 202500d21654874aa03243e91f96de153ec61860 ] The data structure member “rpmb->md” was passed to a call of the function “mmc_blk_put” after a call of the function “put_device”. Reorder these function calls to keep the data accesses consistent. Fixes: 1c87f7357849 ("mmc: block: Fix bug when removing RPMB chardev ") Signed-off-by: Peng Hao <richard.peng@oppo.com> Cc: stable@vger.kernel.org [Uffe: Fixed up mangled patch and updated commit message] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-27mmc: core: fix wl1251 sdio quirksH. Nikolaus Schaller1-0/+7
[ Upstream commit 16568b4a4f0c34bd35cfadac63303c7af7812764 ] wl1251 and wl1271 have different vendor id and device id. So we need to handle both with sdio quirks. Fixes: 884f38607897 ("mmc: core: move some sdio IDs out of quirks file") Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Cc: <stable@vger.kernel.org> # v4.11+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-27mmc: core: fix possible use after free of hostPan Bian1-2/+0
[ Upstream commit 8e1943af2986db42bee2b8dddf49a36cdb2e9219 ] 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: 1ed217194488 ("mmc: core: fix error path in mmc_host_alloc") Signed-off-by: Pan Bian <bianpan2016@163.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-12mmc: block: propagate correct returned value in mmc_rpmb_ioctlMathieu Malaterre1-1/+1
commit b25b750df99bcba29317d3f9d9f93c4ec58890e6 upstream. In commit 97548575bef3 ("mmc: block: Convert RPMB to a character device") a new function `mmc_rpmb_ioctl` was added. The final return is simply returning a value of `0` instead of propagating the correct return code. Discovered during a compilation with W=1, silence the following gcc warning drivers/mmc/core/block.c:2470:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] Signed-off-by: Mathieu Malaterre <malat@debian.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Fixes: 97548575bef3 ("mmc: block: Convert RPMB to a character device") Cc: stable@vger.kernel.org # v4.15+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-12mmc: core: Prevent bus reference leak in mmc_blk_init()Alexander Kappner1-0/+1
commit d0a0852b9f81cf5f793bf2eae7336ed40a1a1815 upstream. Upon module load, mmc_block allocates a bus with bus_registeri() in mmc_blk_init(). This reference never gets freed during module unload, which leads to subsequent re-insertions of the module fails and a WARN() splat is triggered. Fix the bug by dropping the reference for the bus in mmc_blk_exit(). Signed-off-by: Alexander Kappner <agk@godking.net> Fixes: 97548575bef3 ("mmc: block: Convert RPMB to a character device") Cc: <stable@vger.kernel.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-12mmc: block: Fix bug when removing RPMB chardevLinus Walleij1-14/+18
commit 1c87f73578497a6c3cc77bcbfd2e5bf15fe753c7 upstream. I forgot to account for the fact that the device core holds a reference to a device added with device_initialize() that need to be released with a corresponding put_device() to reach a 0 refcount at the end of the lifecycle. This led to a NULL pointer reference when freeing the device when e.g. unbidning the host device in sysfs. Fix this and use the device .release() callback to free the IDA and free:ing the memory used by the RPMB device. Before this patch: /sys/bus/amba/drivers/mmci-pl18x$ echo 80114000.sdi4_per2 > unbind [ 29.797332] mmc3: card 0001 removed [ 29.810791] Unable to handle kernel NULL pointer dereference at virtual address 00000050 [ 29.818878] pgd = de70c000 [ 29.821624] [00000050] *pgd=1e70a831, *pte=00000000, *ppte=00000000 [ 29.827911] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [ 29.833282] Modules linked in: [ 29.836334] CPU: 1 PID: 154 Comm: sh Not tainted 4.14.0-rc3-00039-g83318e309566-dirty #736 [ 29.844604] Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support) [ 29.851562] task: de572700 task.stack: de742000 [ 29.856079] PC is at kernfs_find_ns+0x8/0x100 [ 29.860443] LR is at kernfs_find_and_get_ns+0x30/0x48 After this patch: /sys/bus/amba/drivers/mmci-pl18x$ echo 80005000.sdi4_per2 > unbind [ 20.623382] mmc3: card 0001 removed Fixes: 97548575bef3 ("mmc: block: Convert RPMB to a character device") Reported-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-12mmc: block: Delete mmc_access_rpmb()Linus Walleij3-15/+1
commit 14f4ca7e4d2825f9f71e22905ae177b899959f1d upstream. This function is used by the block layer queue to bail out of requests if the current request is towards an RPMB "block device". This was done to avoid boot time scanning of this "block device" which was never really a block device, thus duct-taping over the fact that it was badly engineered. This problem is now gone as we removed the offending RPMB block device in another patch and replaced it with a character device. Cc: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-12mmc: block: Convert RPMB to a character deviceLinus Walleij2-22/+263
commit 97548575bef38abd06690a5a6f6816200c7e77f7 upstream. The RPMB partition on the eMMC devices is a special area used for storing cryptographically safe information signed by a special secret key. To write and read records from this special area, authentication is needed. The RPMB area is *only* and *exclusively* accessed using ioctl():s from userspace. It is not really a block device, as blocks cannot be read or written from the device, also the signed chunks that can be stored on the RPMB are actually 256 bytes, not 512 making a block device a real bad fit. Currently the RPMB partition spawns a separate block device named /dev/mmcblkNrpmb for each device with an RPMB partition, including the creation of a block queue with its own kernel thread and all overhead associated with this. On the Ux500 HREFv60 platform, for example, the two eMMCs means that two block queues with separate threads are created for no use whatsoever. I have concluded that this block device design for RPMB is actually pretty wrong. The RPMB area should have been designed to be accessed from /dev/mmcblkN directly, using ioctl()s on the main block device. It is however way too late to change that, since userspace expects to open an RPMB device in /dev/mmcblkNrpmb and we cannot break userspace. This patch tries to amend the situation using the following strategy: - Stop creating a block device for the RPMB partition/area - Instead create a custom, dynamic character device with the same name. - Make this new character device support exactly the same set of ioctl()s as the old block device. - Wrap the requests back to the same ioctl() handlers, but issue them on the block queue of the main partition/area, i.e. /dev/mmcblkN We need to create a special "rpmb" bus type in order to get udev and/or busybox hot/coldplug to instantiate the device node properly. Before the patch, this appears in 'ps aux': 101 root 0:00 [mmcqd/2rpmb] 123 root 0:00 [mmcqd/3rpmb] After applying the patch these surplus block queue threads are gone, but RPMB is as usable as ever using the userspace MMC tools, such as 'mmc rpmb read-counter'. We get instead those dynamice devices in /dev: brw-rw---- 1 root root 179, 0 Jan 1 2000 mmcblk0 brw-rw---- 1 root root 179, 1 Jan 1 2000 mmcblk0p1 brw-rw---- 1 root root 179, 2 Jan 1 2000 mmcblk0p2 brw-rw---- 1 root root 179, 5 Jan 1 2000 mmcblk0p5 brw-rw---- 1 root root 179, 8 Jan 1 2000 mmcblk2 brw-rw---- 1 root root 179, 16 Jan 1 2000 mmcblk2boot0 brw-rw---- 1 root root 179, 24 Jan 1 2000 mmcblk2boot1 crw-rw---- 1 root root 248, 0 Jan 1 2000 mmcblk2rpmb brw-rw---- 1 root root 179, 32 Jan 1 2000 mmcblk3 brw-rw---- 1 root root 179, 40 Jan 1 2000 mmcblk3boot0 brw-rw---- 1 root root 179, 48 Jan 1 2000 mmcblk3boot1 brw-rw---- 1 root root 179, 33 Jan 1 2000 mmcblk3p1 crw-rw---- 1 root root 248, 1 Jan 1 2000 mmcblk3rpmb Notice the (248,0) and (248,1) character devices for RPMB. Cc: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-10-05mmc: core: Clarify sdio_irq_pending flag for MMC_CAP2_SDIO_IRQ_NOTHREADUlf Hansson1-3/+6
[ Upstream commit 36d57efb4af534dd6b442ea0b9a04aa6dfa37abe ] The sdio_irq_pending flag is used to let host drivers indicate that it has signaled an IRQ. If that is the case and we only have a single SDIO func that have claimed an SDIO IRQ, our assumption is that we can avoid reading the SDIO_CCCR_INTx register and just call the SDIO func irq handler immediately. This makes sense, but the flag is set/cleared in a somewhat messy order, let's fix that up according to below. First, the flag is currently set in sdio_run_irqs(), which is executed as a work that was scheduled from sdio_signal_irq(). To make it more implicit that the host have signaled an IRQ, let's instead immediately set the flag in sdio_signal_irq(). This also makes the behavior consistent with host drivers that uses the legacy, mmc_signal_sdio_irq() API. This have no functional impact, because we don't expect host drivers to call sdio_signal_irq() until after the work (sdio_run_irqs()) have been executed anyways. Second, currently we never clears the flag when using the sdio_run_irqs() work, but only when using the sdio_irq_thread(). Let make the behavior consistent, by moving the flag to be cleared inside the common process_sdio_pending_irqs() function. Additionally, tweak the behavior of the flag slightly, by avoiding to clear it unless we processed the SDIO IRQ. The purpose with this at this point, is to keep the information about whether there have been an SDIO IRQ signaled by the host, so at system resume we can decide to process it without reading the SDIO_CCCR_INTx register. Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-09-06mmc: core: Fix init of SD cards reporting an invalid VDD rangeUlf Hansson1-0/+6
commit 72741084d903e65e121c27bd29494d941729d4a1 upstream. The OCR register defines the supported range of VDD voltages for SD cards. However, it has turned out that some SD cards reports an invalid voltage range, for example having bit7 set. When a host supports MMC_CAP2_FULL_PWR_CYCLE and some of the voltages from the invalid VDD range, this triggers the core to run a power cycle of the card to try to initialize it at the lowest common supported voltage. Obviously this fails, since the card can't support it. Let's fix this problem, by clearing invalid bits from the read OCR register for SD cards, before proceeding with the VDD voltage negotiation. Cc: stable@vger.kernel.org Reported-by: Philip Langdale <philipl@overt.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Philip Langdale <philipl@overt.org> Tested-by: Philip Langdale <philipl@overt.org> Tested-by: Manuel Presnitz <mail@mpy.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-25mmc: core: Prevent processing SDIO IRQs when the card is suspendedUlf Hansson2-1/+16
commit 83293386bc95cf5e9f0c0175794455835bd1cb4a upstream. 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: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-31mmc: core: make pwrseq_emmc (partially) support sleepy GPIO controllersAndrea Merello1-18/+20
[ Upstream commit 002ee28e8b322d4d4b7b83234b5d0f4ebd428eda ] 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: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-05-31mmc: core: Verify SD bus widthRaul E Rangel1-0/+8
[ Upstream commit 9e4be8d03f50d1b25c38e2b59e73b194c130df7d ] 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: Avri Altman <avri.altman@wdc.com> Signed-off-by: Raul E Rangel <rrangel@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2018-12-29mmc: core: Use a minimum 1600ms timeout when enabling CACHE ctrlUlf Hansson1-4/+10
commit e3ae3401aa19432ee4943eb0bbc2ec704d07d793 upstream. Some eMMCs from Micron have been reported to need ~800 ms timeout, while enabling the CACHE ctrl after running sudden power failure tests. The needed timeout is greater than what the card specifies as its generic CMD6 timeout, through the EXT_CSD register, hence the problem. Normally we would introduce a card quirk to extend the timeout for these specific Micron cards. However, due to the rather complicated debug process needed to find out the error, let's simply use a minimum timeout of 1600ms, the double of what has been reported, for all cards when enabling CACHE ctrl. Reported-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk> Reported-by: Andreas Dannenberg <dannenberg@ti.com> Reported-by: Faiz Abbas <faiz_abbas@ti.com> Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-29mmc: core: Allow BKOPS and CACHE ctrl even if no HPI supportUlf Hansson1-4/+2
commit ba9f39a785a9977e72233000711ef1eb48203551 upstream. In commit 5320226a0512 ("mmc: core: Disable HPI for certain Hynix eMMC cards"), then intent was to prevent HPI from being used for some eMMC cards, which didn't properly support it. However, that went too far, as even BKOPS and CACHE ctrl became prevented. Let's restore those parts and allow BKOPS and CACHE ctrl even if HPI isn't supported. Fixes: 5320226a0512 ("mmc: core: Disable HPI for certain Hynix eMMC cards") Cc: Pratibhasagar V <pratibha@codeaurora.org> Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-29mmc: core: Reset HPI enabled state during re-init and in case of errorsUlf Hansson1-1/+3
commit a0741ba40a009f97c019ae7541dc61c1fdf41efb upstream. During a re-initialization of the eMMC card, we may fail to re-enable HPI. In these cases, that isn't properly reflected in the card->ext_csd.hpi_en bit, as it keeps being set. This may cause following attempts to use HPI, even if's not enabled. Let's fix this! Fixes: eb0d8f135b67 ("mmc: core: support HPI send command") Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-10-18mmc: block: avoid multiblock reads for the last sector in SPI modeChris Boot1-0/+10
commit 41591b38f5f8f78344954b68582b5f00e56ffe61 upstream. On some SD cards over SPI, reading with the multiblock read command the last sector will leave the card in a bad state. Remove last sectors from the multiblock reading cmd. Signed-off-by: Chris Boot <bootc@bootc.net> Signed-off-by: Clément Péron <peron.clem@gmail.com> Cc: stable@vger.kernel.org # v4.10+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-03mmc: pwrseq: Use kmalloc_array instead of stack VLATobin C. Harding1-5/+9
[ Upstream commit 486e6661367b40f927aadbed73237693396cbf94 ] The use of stack Variable Length Arrays needs to be avoided, as they can be a vector for stack exhaustion, which can be both a runtime bug (kernel Oops) or a security flaw (overwriting memory beyond the stack). Also, in general, as code evolves it is easy to lose track of how big a VLA can get. Thus, we can end up having runtime failures that are hard to debug. As part of the directive[1] to remove all VLAs from the kernel, and build with -Wvla. Currently driver is using a VLA declared using the number of descriptors. This array is used to store integer values and is later used as an argument to `gpiod_set_array_value_cansleep()` This can be avoided by using `kmalloc_array()` to allocate memory for the array of integer values. Memory is free'd before return from function. >From the code it appears that it is safe to sleep so we can use GFP_KERNEL (based _cansleep() suffix of function `gpiod_set_array_value_cansleep()`. It can be expected that this patch will result in a small increase in overhead due to the use of `kmalloc_array()` [1] https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Tobin C. Harding <me@tobin.cc> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-28mmc: block: fix updating ext_csd caches on ioctl callBastian Stender1-0/+19
commit e74ef2194b41ba5e511fab29fe5ff00e72d2f42a upstream. PARTITION_CONFIG is cached in mmc_card->ext_csd.part_config and the currently active partition in mmc_blk_data->part_curr. These caches do not always reflect changes if the ioctl call modifies the PARTITION_CONFIG registers, e.g. by changing BOOT_PARTITION_ENABLE. Write the PARTITION_CONFIG value extracted from the ioctl call to the cache and update the currently active partition accordingly. This ensures that the user space cannot change the values behind the kernel's back. The next call to mmc_blk_part_switch() will operate on the data set by the ioctl and reflect the changes appropriately. Signed-off-by: Bastian Stender <bst@pengutronix.de> Signed-off-by: Jan Luebbe <jlu@pengutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-28mmc: core: Disable HPI for certain Micron (Numonyx) eMMC cardsDirk Behme2-0/+7
commit dbe7dc6b9b28f5b012b0bedc372aa0c52521f3e4 upstream. Certain Micron eMMC v4.5 cards might get broken when HPI feature is used and hence this patch disables the HPI feature for such buggy cards. In U-Boot, these cards are reported as Manufacturer: Micron (ID: 0xFE) OEM: 0x4E Name: MMC32G Revision: 19 (0x13) Serial: 959241022 Manufact. date: 8/2015 (0x82) CRC: 0x00 Tran Speed: 52000000 Rd Block Len: 512 MMC version 4.5 High Capacity: Yes Capacity: 29.1 GiB Boot Partition Size: 16 MiB Bus Width: 8-bit According to JEDEC JEP106 manufacturer 0xFE is Numonyx, which was bought by Micron. Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> Signed-off-by: Mark Craske <Mark_Craske@mentor.com> Cc: <stable@vger.kernel.org> # 4.8+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-24mmc: block: fix logical error to avoid memory leakLiu, Changcheng1-0/+1
[ Upstream commit 0be55579a127916ebe39db2a74d906a2dfceed42 ] If the MMC_DRV_OP_GET_EXT_CSD request completes successfully, then ext_csd must be freed, but in one case it was not. Fix that. Signed-off-by: Liu Changcheng <changcheng.liu@intel.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-24mmc: avoid removing non-removable hosts during suspendDaniel Drake1-0/+8
[ Upstream commit de8dcc3d2c0e08e5068ee1e26fc46415c15e3637 ] 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: Daniel Drake <drake@endlessm.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-03-19mmc: mmc_test: Ensure command queue is disabled for testingAdrian Hunter1-2/+9
[ Upstream commit 23a185254ace8e63dc4ca36e0315aed9440ae749 ] mmc_test disables the command queue because none of the tests use the command queue. However the Reset Test will re-enable it, so disable it in that case too. Fixes: 9d4579a85c84 ("mmc: mmc_test: Disable Command Queue while mmc_test is used") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-12-20mmc: core: apply NO_CMD23 quirk to some specific cardsChristoph Fritz2-0/+10
commit 91516a2a4734614d62ee3ed921f8f88acc67c000 upstream. To get an usdhc Apacer and some ATP SD cards work reliable, CMD23 needs to be disabled. This has been tested on i.MX6 (sdhci-esdhc) and rk3288 (dw_mmc-rockchip). Without this patch on i.MX6 (sdhci-esdhc): $ dd if=/dev/urandom of=/mnt/test bs=1M count=10 conv=fsync | <mmc0: starting CMD23 arg 00000400 flags 00000015> | mmc0: starting CMD25 arg 00a71f00 flags 000000b5 | mmc0: blksz 512 blocks 1024 flags 00000100 tsac 3000 ms nsac 0 | mmc0: CMD12 arg 00000000 flags 0000049d | sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001 | mmc0: Timeout waiting for hardware interrupt. Without this patch on rk3288 (dw_mmc-rockchip): | mmc1: Card stuck in programming state! mmcblk1 card_busy_detect | dwmmc_rockchip ff0c0000.dwmmc: Busy; trying anyway | mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, | actual 400000HZ div = 0) | mmc1: card never left busy state | mmc1: tried to reset card, got error -110 | blk_update_request: I/O error, dev mmcblk1, sector 139778 | Buffer I/O error on dev mmcblk1p1, logical block 131586, lost async | page write Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-18 00:29:16 +0300