summaryrefslogtreecommitdiff
path: root/drivers/mmc/core
AgeCommit message (Collapse)AuthorFilesLines
2021-12-29mmc: core: Disable card detect during shutdownUlf Hansson3-1/+16
commit 66c915d09b942fb3b2b0cb2f56562180901fba17 upstream. It's seems prone to problems by allowing card detect and its corresponding mmc_rescan() work to run, during platform shutdown. For example, we may end up turning off the power while initializing a card, which potentially could damage it. To avoid this scenario, let's add ->shutdown_pre() callback for the mmc host class device and then turn of the card detect from there. Reported-by: Al Cooper <alcooperx@gmail.com> Suggested-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211203141555.105351-1-ulf.hansson@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-18mmc: core: Return correct emmc response in case of ioctl errorNishad Kamdar1-2/+1
[ Upstream commit e72a55f2e5ddcfb3dce0701caf925ce435b87682 ] When a read/write command is sent via ioctl to the kernel, and the command fails, the actual error response of the emmc is not sent to the user. IOCTL read/write tests are carried out using commands 17 (Single BLock Read), 24 (Single Block Write), 18 (Multi Block Read), 25 (Multi Block Write) The tests are carried out on a 64Gb emmc device. All of these tests try to access an "out of range" sector address (0x09B2FFFF). It is seen that without the patch the response received by the user is not OUT_OF_RANGE error (R1 response 31st bit is not set) as per JEDEC specification. After applying the patch proper response is seen. This is because the function returns without copying the response to the user in case of failure. This patch fixes the issue. Hence, this memcpy is required whether we get an error response or not. Therefor it is moved up from the current position up to immediately after we have called mmc_wait_for_req(). The test code and the output of only the CMD17 is included in the commit to limit the message length. CMD17 (Test Code Snippet): ========================== printf("Forming CMD%d\n", opt_idx); /* single block read */ cmd.blksz = 512; cmd.blocks = 1; cmd.write_flag = 0; cmd.opcode = 17; //cmd.arg = atoi(argv[3]); cmd.arg = 0x09B2FFFF; /* Expecting response R1B */ cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_ADTC; memset(data, 0, sizeof(__u8) * 512); mmc_ioc_cmd_set_data(cmd, data); printf("Sending CMD%d: ARG[0x%08x]\n", opt_idx, cmd.arg); if(ioctl(fd, MMC_IOC_CMD, &cmd)) perror("Error"); printf("\nResponse: %08x\n", cmd.response[0]); CMD17 (Output without patch): ============================= test@test-LIVA-Z:~$ sudo ./mmc cmd_test /dev/mmcblk0 17 Entering the do_mmc_commands:Device: /dev/mmcblk0 nargs:4 Entering the do_mmc_commands:Device: /dev/mmcblk0 options[17, 0x09B2FFF] Forming CMD17 Sending CMD17: ARG[0x09b2ffff] Error: Connection timed out Response: 00000000 (Incorrect response) CMD17 (Output with patch): ========================== test@test-LIVA-Z:~$ sudo ./mmc cmd_test /dev/mmcblk0 17 [sudo] password for test: Entering the do_mmc_commands:Device: /dev/mmcblk0 nargs:4 Entering the do_mmc_commands:Device: /dev/mmcblk0 options[17, 09B2FFFF] Forming CMD17 Sending CMD17: ARG[0x09b2ffff] Error: Connection timed out Response: 80000900 (Correct OUT_OF_ERROR response as per JEDEC specification) Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com> Reviewed-by: Avri Altman <avri.altman@wdc.com> Link: https://lore.kernel.org/r/20210824191726.8296-1-nishadkamdar@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-28mmc: core: Don't allocate IDA for OF aliasesStephen Boyd1-10/+10
commit 10252bae863d09b9648bed2e035572d207200ca1 upstream. There's a chance that the IDA allocated in mmc_alloc_host() is not freed for some time because it's freed as part of a class' release function (see mmc_host_classdev_release() where the IDA is freed). If another thread is holding a reference to the class, then only once all balancing device_put() calls (in turn calling kobject_put()) have been made will the IDA be released and usable again. Normally this isn't a problem because the kobject is released before anything else that may want to use the same number tries to again, but with CONFIG_DEBUG_KOBJECT_RELEASE=y and OF aliases it becomes pretty easy to try to allocate an alias from the IDA twice while the first time it was allocated is still pending a call to ida_simple_remove(). It's also possible to trigger it by using CONFIG_DEBUG_KOBJECT_RELEASE and probe defering a driver at boot that calls mmc_alloc_host() before trying to get resources that may defer likes clks or regulators. Instead of allocating from the IDA in this scenario, let's just skip it if we know this is an OF alias. The number is already "claimed" and devices that aren't using OF aliases won't try to use the claimed numbers anyway (see mmc_first_nonreserved_index()). This should avoid any issues with mmc_alloc_host() returning failures from the ida_simple_get() in the case that we're using an OF alias. Cc: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Cc: Sujit Kautkar <sujitka@chromium.org> Reported-by: Zubin Mithra <zsm@chromium.org> Fixes: fa2d0aa96941 ("mmc: core: Allow setting slot index via device tree alias") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210623075002.1746924-3-swboyd@chromium.org Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-19mmc: 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-19mmc: 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-07-14mmc: block: Disable CMDQ on the ioctl pathBean Huo1-0/+8
commit 70b52f09080565030a530a784f1c9948a7f48ca3 upstream. According to the eMMC Spec: "When command queuing is enabled (CMDQ Mode En bit in CMDQ_MODE_EN field is set to ‘1’) class 11 commands are the only method through which data transfer tasks can be issued. Existing data transfer commands, namely CMD18/CMD17 and CMD25/CMD24, are not supported when command queuing is enabled." which means if CMDQ is enabled, the FFU commands will not be supported. To fix this issue, just simply disable CMDQ on the ioctl path, and re-enable CMDQ once ioctl request is completed. Tested-by: Michael Brunner <Michael.Brunner@kontron.com> Signed-off-by: Bean Huo <beanhuo@micron.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Fixes: 1e8e55b67030 (mmc: block: Add CQE support) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210504203209.361597-1-huobean@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-11mmc: core: Fix hanging on I/O during system suspend for removable cardsUlf Hansson4-91/+59
commit 17a17bf50612e6048a9975450cf1bd30f93815b5 upstream. The mmc core uses a PM notifier to temporarily during system suspend, turn off the card detection mechanism for removal/insertion of (e)MMC/SD/SDIO cards. Additionally, the notifier may be used to remove an SDIO card entirely, if a corresponding SDIO functional driver don't have the system suspend/resume callbacks assigned. This behaviour has been around for a very long time. However, a recent bug report tells us there are problems with this approach. More precisely, when receiving the PM_SUSPEND_PREPARE notification, we may end up hanging on I/O to be completed, thus also preventing the system from getting suspended. In the end what happens, is that the cancel_delayed_work_sync() in mmc_pm_notify() ends up waiting for mmc_rescan() to complete - and since mmc_rescan() wants to claim the host, it needs to wait for the I/O to be completed first. Typically, this problem is triggered in Android, if there is ongoing I/O while the user decides to suspend, resume and then suspend the system again. This due to that after the resume, an mmc_rescan() work gets punted to the workqueue, which job is to verify that the card remains inserted after the system has resumed. To fix this problem, userspace needs to become frozen to suspend the I/O, prior to turning off the card detection mechanism. Therefore, let's drop the PM notifiers for mmc subsystem altogether and rely on the card detection to be turned off/on as a part of the system_freezable_wq, that we are already using. Moreover, to allow and SDIO card to be removed during system suspend, let's manage this from a ->prepare() callback, assigned at the mmc_host_class level. In this way, we can use the parent device (the mmc_host_class device), to remove the card device that is the child, in the device_prepare() phase. Reported-by: Kiwoong Kim <kwmad.kim@samsung.com> Cc: stable@vger.kernel.org # v4.5+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210310152900.149380-1-ulf.hansson@linaro.org Reviewed-by: Kiwoong Kim <kwmad.kim@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-11mmc: 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-11mmc: 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-11mmc: block: Issue a cache flush only when it's enabledAvri Altman4-3/+21
commit 97fce126e279690105ee15be652b465fd96f9997 upstream. In command queueing mode, the cache isn't flushed via the mmc_flush_cache() function, but instead by issuing a CMDQ_TASK_MGMT (CMD48) with a FLUSH_CACHE opcode. In this path, we need to check if cache has been enabled, before deciding to flush the cache, along the lines of what's being done in mmc_flush_cache(). To fix this problem, let's add a new bus ops callback ->cache_enabled() and implement it for the mmc bus type. In this way, the mmc block device driver can call it to know whether cache flushing should be done. Fixes: 1e8e55b67030 (mmc: block: Add CQE support) Cc: stable@vger.kernel.org Reported-by: Brendan Peter <bpeter@lytx.com> Signed-off-by: Avri Altman <avri.altman@wdc.com> Tested-by: Brendan Peter <bpeter@lytx.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20210425060207.2591-2-avri.altman@wdc.com Link: https://lore.kernel.org/r/20210425060207.2591-3-avri.altman@wdc.com [Ulf: Squashed the two patches and made some minor updates] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-11mmc: 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: cqhci: Fix random crash when remove mmc module/cardFrank Li1-6/+5
commit f06391c45e83f9a731045deb23df7cc3814fd795 upstream. [ 6684.493350] Unable to handle kernel paging request at virtual address ffff800011c5b0f0 [ 6684.498531] mmc0: card 0001 removed [ 6684.501556] Mem abort info: [ 6684.509681] ESR = 0x96000047 [ 6684.512786] EC = 0x25: DABT (current EL), IL = 32 bits [ 6684.518394] SET = 0, FnV = 0 [ 6684.521707] EA = 0, S1PTW = 0 [ 6684.524998] Data abort info: [ 6684.528236] ISV = 0, ISS = 0x00000047 [ 6684.532986] CM = 0, WnR = 1 [ 6684.536129] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000081b22000 [ 6684.543923] [ffff800011c5b0f0] pgd=00000000bffff003, p4d=00000000bffff003, pud=00000000bfffe003, pmd=00000000900e1003, pte=0000000000000000 [ 6684.557915] Internal error: Oops: 96000047 [#1] PREEMPT SMP [ 6684.564240] Modules linked in: sdhci_esdhc_imx(-) sdhci_pltfm sdhci cqhci mmc_block mmc_core fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine rng_core authenc libdes crct10dif_ce flexcan can_dev caam error [last unloaded: mmc_core] [ 6684.587281] CPU: 0 PID: 79138 Comm: kworker/0:3H Not tainted 5.10.9-01410-g3ba33182767b-dirty #10 [ 6684.596160] Hardware name: Freescale i.MX8DXL EVK (DT) [ 6684.601320] Workqueue: kblockd blk_mq_run_work_fn [ 6684.606094] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--) [ 6684.612286] pc : cqhci_request+0x148/0x4e8 [cqhci] ^GMessage from syslogd@ at Thu Jan 1 01:51:24 1970 ...[ 6684.617085] lr : cqhci_request+0x314/0x4e8 [cqhci] [ 6684.626734] sp : ffff80001243b9f0 [ 6684.630049] x29: ffff80001243b9f0 x28: ffff00002c3dd000 [ 6684.635367] x27: 0000000000000001 x26: 0000000000000001 [ 6684.640690] x25: ffff00002c451000 x24: 000000000000000f [ 6684.646007] x23: ffff000017e71c80 x22: ffff00002c451000 [ 6684.651326] x21: ffff00002c0f3550 x20: ffff00002c0f3550 [ 6684.656651] x19: ffff000017d46880 x18: ffff00002cea1500 [ 6684.661977] x17: 0000000000000000 x16: 0000000000000000 [ 6684.667294] x15: 000001ee628e3ed1 x14: 0000000000000278 [ 6684.672610] x13: 0000000000000001 x12: 0000000000000001 [ 6684.677927] x11: 0000000000000000 x10: 0000000000000000 [ 6684.683243] x9 : 000000000000002b x8 : 0000000000001000 [ 6684.688560] x7 : 0000000000000010 x6 : ffff00002c0f3678 [ 6684.693886] x5 : 000000000000000f x4 : ffff800011c5b000 [ 6684.699211] x3 : 000000000002d988 x2 : 0000000000000008 [ 6684.704537] x1 : 00000000000000f0 x0 : 0002d9880008102f [ 6684.709854] Call trace: [ 6684.712313] cqhci_request+0x148/0x4e8 [cqhci] [ 6684.716803] mmc_cqe_start_req+0x58/0x68 [mmc_core] [ 6684.721698] mmc_blk_mq_issue_rq+0x460/0x810 [mmc_block] [ 6684.727018] mmc_mq_queue_rq+0x118/0x2b0 [mmc_block] The problem occurs when cqhci_request() get called after cqhci_disable() as it leads to access of allocated memory that has already been freed. Let's fix the problem by calling cqhci_disable() a bit later in the remove path. Signed-off-by: Frank Li <Frank.Li@nxp.com> Diagnosed-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20210303174248.542175-1-Frank.Li@nxp.com Fixes: f690f4409ddd ("mmc: mmc: Enable CQE's") Cc: stable@vger.kernel.org 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>
2021-01-27mmc: core: don't initialize block size from ext_csd if not presentPeter Collingbourne1-1/+3
commit b503087445ce7e45fabdee87ca9e460d5b5b5168 upstream. If extended CSD was not available, the eMMC driver would incorrectly set the block size to 0, as the data_sector_size field of ext_csd was never initialized. This issue was exposed by commit 817046ecddbc ("block: Align max_hw_sectors to logical blocksize") which caused max_sectors and max_hw_sectors to be set to 0 after setting the block size to 0, resulting in a kernel panic in bio_split when attempting to read from the device. Fix it by only reading the block size from ext_csd if it is available. Fixes: a5075eb94837 ("mmc: block: Allow disabling 512B sector size emulation") Signed-off-by: Peter Collingbourne <pcc@google.com> Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com> Link: https://linux-review.googlesource.com/id/If244d178da4d86b52034459438fec295b02d6e60 Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210114201405.2934886-1-pcc@google.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-04mmc: block: Fixup condition for CMD13 polling for RPMB requestsBean Huo1-1/+1
The CMD13 polling is needed for commands with R1B responses. In commit a0d4c7eb71dd ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B response"), the intent was to introduce this for requests targeted to the RPMB partition. However, the condition to trigger the polling loop became wrong, leading to unnecessary polling. Let's fix the condition to avoid this. Fixes: a0d4c7eb71dd ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B response") Cc: stable@vger.kernel.org Reported-by: Zhan Liu <zliua@micron.com> Signed-off-by: Zhan Liu <zliua@micron.com> Signed-off-by: Bean Huo <beanhuo@micron.com> Link: https://lore.kernel.org/r/20201202202320.22165-1-huobean@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-10-13Merge tag 'block-5.10-2020-10-12' of git://git.kernel.dk/linux-blockLinus Torvalds2-3/+2
Pull block updates from Jens Axboe: - Series of merge handling cleanups (Baolin, Christoph) - Series of blk-throttle fixes and cleanups (Baolin) - Series cleaning up BDI, seperating the block device from the backing_dev_info (Christoph) - Removal of bdget() as a generic API (Christoph) - Removal of blkdev_get() as a generic API (Christoph) - Cleanup of is-partition checks (Christoph) - Series reworking disk revalidation (Christoph) - Series cleaning up bio flags (Christoph) - bio crypt fixes (Eric) - IO stats inflight tweak (Gabriel) - blk-mq tags fixes (Hannes) - Buffer invalidation fixes (Jan) - Allow soft limits for zone append (Johannes) - Shared tag set improvements (John, Kashyap) - Allow IOPRIO_CLASS_RT for CAP_SYS_NICE (Khazhismel) - DM no-wait support (Mike, Konstantin) - Request allocation improvements (Ming) - Allow md/dm/bcache to use IO stat helpers (Song) - Series improving blk-iocost (Tejun) - Various cleanups (Geert, Damien, Danny, Julia, Tetsuo, Tian, Wang, Xianting, Yang, Yufen, yangerkun) * tag 'block-5.10-2020-10-12' of git://git.kernel.dk/linux-block: (191 commits) block: fix uapi blkzoned.h comments blk-mq: move cancel of hctx->run_work to the front of blk_exit_queue blk-mq: get rid of the dead flush handle code path block: get rid of unnecessary local variable block: fix comment and add lockdep assert blk-mq: use helper function to test hw stopped block: use helper function to test queue register block: remove redundant mq check block: invoke blk_mq_exit_sched no matter whether have .exit_sched percpu_ref: don't refer to ref->data if it isn't allocated block: ratelimit handle_bad_sector() message blk-throttle: Re-use the throtl_set_slice_end() blk-throttle: Open code __throtl_de/enqueue_tg() blk-throttle: Move service tree validation out of the throtl_rb_first() blk-throttle: Move the list operation after list validation blk-throttle: Fix IO hang for a corner case blk-throttle: Avoid tracking latency if low limit is invalid blk-throttle: Avoid getting the current time if tg->last_finish_time is 0 blk-throttle: Remove a meaningless parameter for throtl_downgrade_state() block: Remove redundant 'return' statement ...
2020-10-09Merge branch 'fixes' into nextUlf Hansson1-1/+1
2020-10-09mmc: core: don't set limits.discard_granularity as 0Coly Li1-1/+1
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>
2020-09-25block: add a bdev_is_partition helperChristoph Hellwig1-1/+1
Add a littler helper to make the somewhat arcane bd_contains checks a little more obvious. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-09-25mmc: core: document mmc_hw_reset()Wolfram Sang1-0/+10
Add documentation for mmc_hw_reset to make sure the intended use case is clear. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20200918215446.65654-1-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-09-24bdi: replace BDI_CAP_STABLE_WRITES with a queue and a sb flagChristoph Hellwig1-2/+1
The BDI_CAP_STABLE_WRITES is one of the few bits of information in the backing_dev_info shared between the block drivers and the writeback code. To help untangling the dependency replace it with a queue flag and a superblock flag derived from it. This also helps with the case of e.g. a file system requiring stable writes due to its own checksumming, but not forcing it on other users of the block device like the swap code. One downside is that we an't support the stable_pages_required bdi attribute in sysfs anymore. It is replaced with a queue attribute which also is writable for easier testing. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-09-14mmc: core: clear 'doing_init_tune' also after failuresWolfram Sang1-4/+4
Reorganize the code, so that the flag is always cleared independently of a good or bad case. Fixes: 97a7d87e96b0 ("mmc: core: add a 'doing_init_tune' flag and a 'mmc_doing_tune' helper") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20200914112845.21855-1-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-09-07Merge branch 'fixes' into nextUlf Hansson1-17/+22
2020-09-07mmc: core: simplify an expressionWolfram Sang1-1/+1
We already have 'host' as a variable, so use it. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20200901150250.26236-5-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-09-07mmc: core: add a 'doing_init_tune' flag and a 'mmc_doing_tune' helperWolfram Sang1-0/+4
Our driver needs to know when tuning is in progress. 'doing_retune' only covers re-tuning, not the initial tuning. Add another flag to detect the initial tuning state and add a helper which tells us if any kind of tuning is going on. Only implemented for MMC currently because that's where we need it. SD can be added later if it becomes necessary. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20200901150250.26236-3-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-09-07mmc: core: when downgrading HS400, callback into drivers earlierWolfram Sang1-6/+6
The driver specific downgrade function makes more sense if we run it before we set the timing to something lower, not after. Otherwise some non-HS400 communication has already happened. No need to convert users. There is only one currently which needs this change in a following patch. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20200901150250.26236-2-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-09-07mmc: core: Allow setting slot index via device tree aliasMatthias Schiffer1-1/+25
As with GPIO, UART and others, allow specifying the device index via the aliases node in the device tree. On embedded devices, there is often a combination of removable (e.g. SD card) and non-removable MMC devices (e.g. eMMC). Therefore the index might change depending on * host of removable device * removable card present or not This makes it difficult to hardcode the root device, if it is on the non-removable device. E.g. if SD card is present eMMC will be mmcblk1, if SD card is not present at boot, eMMC will be mmcblk0. Alternative solutions like PARTUUIDs do not cover the case where multiple mmcblk devices contain the same image. This is a common issue on devices that can boot both from eMMC (for regular boot) and SD cards (as a temporary boot medium for development). When a firmware image is installed to eMMC after a test boot via SD card, there will be no reliable way to refer to a specific device using (PART)UUIDs oder LABELs. The demand for this feature has led to multiple attempts to implement it, dating back at least to 2012 (see https://www.spinics.net/lists/linux-mmc/msg26586.html for a previous discussion from 2014). All indices defined in the aliases node will be reserved for use by the respective MMC device, moving the indices of devices that don't have an alias up into the non-reserved range. If the aliases node is not found, the driver will act as before. This is a rebased and cleaned up version of https://www.spinics.net/lists/linux-mmc/msg26588.html . Based-on-patch-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://lkml.org/lkml/2020/8/5/194 Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Link: https://lore.kernel.org/r/20200901085004.2512-2-matthias.schiffer@ew.tq-group.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-09-07mmc: sd: Use kobj_to_dev() instead of container_of()Tian Tao1-1/+1
Use kobj_to_dev() instead of container_of() Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Link: https://lore.kernel.org/r/1598230956-58523-1-git-send-email-tiantao6@hisilicon.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-09-07mmc: test: remove ambiguity in test descriptionWolfram Sang1-4/+4
When reading the test description, I thought a correction of the xfer_size was tested, which is not the case. It is tested that the xfer_size is correct. Use 'proper xfer_size' to remove this ambiguity. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20200817115838.2981-1-wsa@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-09-07mmc: sdio: Export SDIO revision and info strings to userspacePali Rohár4-3/+103
For SDIO functions, SDIO cards and SD COMBO cards are exported revision number and info strings from CISTPL_VERS_1 structure. Revision number should indicate compliance of standard and info strings should contain product information in same format as product information for PCMCIA cards. Product information for PCMCIA cards should contain following strings in this order: Manufacturer, Product Name, Lot number, Programming Conditions. Note that not all SDIO cards export all those info strings in that order as described in PCMCIA Metaformat Specification. Signed-off-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20200727133837.19086-5-pali@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-09-07mmc: sdio: Extend sdio_config_attr macro and use it also for modaliasPali Rohár1-14/+6
This simplify code for generating sdio config attributes and allows easily define new sdio attributes. Signed-off-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20200727133837.19086-4-pali@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-09-07mmc: sdio: Parse CISTPL_VERS_1 major and minor revision numbersPali Rohár1-0/+8
They should indicate compliance of standard. Signed-off-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20200727133837.19086-3-pali@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-09-07mmc: sdio: Check for CISTPL_VERS_1 buffer sizePali Rohár1-0/+3
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>
2020-09-07mmc: sdio: Use mmc_pre_req() / mmc_post_req()Adrian Hunter1-17/+22
SDHCI changed from using a tasklet to finish requests, to using an IRQ thread i.e. commit c07a48c2651965 ("mmc: sdhci: Remove finish_tasklet"). Because this increased the latency to complete requests, a preparatory change was made to complete the request from the IRQ handler if possible i.e. commit 19d2f695f4e827 ("mmc: sdhci: Call mmc_request_done() from IRQ handler if possible"). That alleviated the situation for MMC block devices because the MMC block driver makes use of mmc_pre_req() and mmc_post_req() so that successful requests are completed in the IRQ handler and any DMA unmapping is handled separately in mmc_post_req(). However SDIO was still affected, and an example has been reported with up to 20% degradation in performance. Looking at SDIO I/O helper functions, sdio_io_rw_ext_helper() appeared to be a possible candidate for making use of asynchronous requests within its I/O loops, but analysis revealed that these loops almost never iterate more than once, so the complexity of the change would not be warrented. Instead, mmc_pre_req() and mmc_post_req() are added before and after I/O submission (mmc_wait_for_req) in mmc_io_rw_extended(). This still has the potential benefit of reducing the duration of interrupt handlers, as well as addressing the latency issue for SDHCI. It also seems a more reasonable solution than forcing drivers to do everything in the IRQ handler. Reported-by: Dmitry Osipenko <digetx@gmail.com> Fixes: c07a48c2651965 ("mmc: sdhci: Remove finish_tasklet") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200903082007.18715-1-adrian.hunter@intel.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-08-24treewide: Use fallthrough pseudo-keywordGustavo A. R. Silva1-1/+1
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-08-06Merge tag 'sched-fifo-2020-08-04' of ↵Linus Torvalds1-2/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull sched/fifo updates from Ingo Molnar: "This adds the sched_set_fifo*() encapsulation APIs to remove static priority level knowledge from non-scheduler code. The three APIs for non-scheduler code to set SCHED_FIFO are: - sched_set_fifo() - sched_set_fifo_low() - sched_set_normal() These are two FIFO priority levels: default (high), and a 'low' priority level, plus sched_set_normal() to set the policy back to non-SCHED_FIFO. Since the changes affect a lot of non-scheduler code, we kept this in a separate tree" * tag 'sched-fifo-2020-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (24 commits) sched,tracing: Convert to sched_set_fifo() sched: Remove sched_set_*() return value sched: Remove sched_setscheduler*() EXPORTs sched,psi: Convert to sched_set_fifo_low() sched,rcutorture: Convert to sched_set_fifo_low() sched,rcuperf: Convert to sched_set_fifo_low() sched,locktorture: Convert to sched_set_fifo() sched,irq: Convert to sched_set_fifo() sched,watchdog: Convert to sched_set_fifo() sched,serial: Convert to sched_set_fifo() sched,powerclamp: Convert to sched_set_fifo() sched,ion: Convert to sched_set_normal() sched,powercap: Convert to sched_set_fifo*() sched,spi: Convert to sched_set_fifo*() sched,mmc: Convert to sched_set_fifo*() sched,ivtv: Convert to sched_set_fifo*() sched,drm/scheduler: Convert to sched_set_fifo*() sched,msm: Convert to sched_set_fifo*() sched,psci: Convert to sched_set_fifo*() sched,drbd: Convert to sched_set_fifo*() ...
2020-08-05Merge tag 'mmc-v5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmcLinus Torvalds8-34/+63
Pull MMC updates from Ulf Hansson: "MMC core: - Add a new host cap bit and a corresponding DT property, to support power cycling of the card by FW at system suspend/resume. - Fix clock rate setting for SDIO in SDR12/SDR25 speed-mode - Fix switch to 1/4-bit mode at system suspend/resume for SD-combo cards - Convert the mmc-pwrseq DT bindings to the json-schema - Always allow the card detect uevent to be consumed by userspace MMC host controllers: - Convert a few DT bindings to the json-schema - mtk-sd: - Add support for command queue through cqhci - Add support for the MT6779 variant - renesas_sdhi_internal_dmac: - Fix dma unmapping in the error path - sdhci_am654: - Add support for the AM65x PG2.0 variant - Extend support for phys/clocks - sdhci-cadence: - Drop incorrect HW tuning for SD mode - sdhci-msm: - Add support for interconnect bandwidth scaling - Enable internal voltage control - Enable low power state for pinctrls - sdhci-of-at91: - Ludovic Desroches handovers maintenance to Eugen Hristev - sdhci-pci-gli: - Improve clock handling for GL975x - sdhci-pci-o2micro: - Add HW tuning for SDR104 mode - Fix support for O2 host controller Seabird1" * tag 'mmc-v5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: (66 commits) mmc: mediatek: make function msdc_cqe_disable() static MAINTAINERS: mmc: sdhci-of-at91: handover maintenance to Eugen Hristev dt-bindings: mmc: mediatek: Add document for mt6779 mmc: mediatek: command queue support mmc: mediatek: refine msdc timeout api mmc: mediatek: add MT6779 MMC driver support mmc: sdhci-pci-o2micro: Add HW tuning for SDR104 mode mmc: sdhci-pci-o2micro: Bug fix for O2 host controller Seabird1 mmc: via-sdmmc: use generic power management memstick: jmb38x_ms: use generic power management mmc: sdhci-cadence: do not use hardware tuning for SD mode mmc: sdhci-pci-gli: Set SDR104's clock to 205MHz and enable SSC for GL975x mmc: cqhci: Fix a print format for the task descriptor mmc: sdhci-of-arasan: fix timings allocation code mmc: sdhci: Fix a potential uninitialized variable dt-bindings: mmc: renesas,sdhi: convert to YAML dt-bindings: mmc: convert arasan sdhci bindings to yaml mmc: sdhci: Fix potential null pointer access while accessing vqmmc mmc: core: Add MMC_CAP2_FULL_PWR_CYCLE_IN_SUSPEND dt-bindings: mmc: Add full-pwr-cycle-in-suspend property ...
2020-07-13mmc: core: Add MMC_CAP2_FULL_PWR_CYCLE_IN_SUSPENDYoshihiro Shimoda2-1/+4
The commit 5a36d6bcdf23 ("mmc: core: Add DT-bindings for MMC_CAP2_FULL_PWR_CYCLE") added the "full-pwr-cycle" property which is possible to perform a full power cycle of the card at any time. However, some environment (like r8a77951-salvator-xs) is possible to perform a full power cycle of the card in suspend via firmware (PSCI on arm-trusted-firmware). So, in worst case, since we are not doing a graceful shutdown of the eMMC device (just cut VCCQ while the eMMC is "sleeping") in suspend, it could lead to internal data corruptions. So, add MMC_CAP2_FULL_PWR_CYCLE_IN_SUSPEND to do a graceful shutdown which issues Power Off notification before entering system suspend. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/1594123122-13156-3-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-07-13mmc: core: Correct misspelling of 'mq' in mmc_init_request()'s docsLee Jones1-1/+1
Correcting this misspelling squashes the following W=1 build warning(s): mmc/core/queue.c:212: warning: Function parameter or member 'mq' not described in '__mmc_init_request' mmc/core/queue.c:212: warning: Excess function parameter 'q' description in '__mmc_init_request' Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20200701124702.908713-8-lee.jones@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-07-13mmc: core: Add missing documetation for 'mmc' and 'ios'Lee Jones1-0/+2
Remainder of the kerneldoc descriptions look present and correct. Fixes the following W=1 kernel build warnings: drivers/mmc/core/regulator.c:178: warning: Function parameter or member 'mmc' not described in 'mmc_regulator_set_vqmmc' drivers/mmc/core/regulator.c:178: warning: Function parameter or member 'ios' not described in 'mmc_regulator_set_vqmmc' Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20200701124702.908713-4-lee.jones@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-07-13mmc: core: Provide description for sdio_set_host_pm_flags()'s 'flag' argLee Jones1-0/+1
Add missing kerneldoc entry for sdio_set_host_pm_flags()'s 'flag' function argument. Fixes the following W=1 kernel build warning: kernel/drivers/mmc/core/sdio_io.c:722: warning: Function parameter or member 'flags' not described in 'sdio_set_host_pm_flags' Cc: Pierre Ossman <drzeus@drzeus.cx> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20200701124702.908713-3-lee.jones@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-07-13mmc: core: Mark fixups as __maybe_unusedLee Jones1-3/+3
Not all source files which include quirks.h make use of the all of the available fixup information. When this happens the compiler complains that some constant variables are defined by never used. We can fix this by telling the compiler that this intentional by simply marking them as __maybe_unused. Fixes the following W=1 kernel build warnings: In file included from drivers/mmc/core/sdio.c:22: drivers/mmc/core/quirks.h:105:31: warning: ‘mmc_ext_csd_fixups’ defined but not used [-Wunused-const-variable=] 105 | static const struct mmc_fixup mmc_ext_csd_fixups[] = { | ^~~~~~~~~~~~~~~~~~ drivers/mmc/core/quirks.h:17:31: warning: ‘mmc_blk_fixups’ defined but not used [-Wunused-const-variable=] 17 | static const struct mmc_fixup mmc_blk_fixups[] = { | ^~~~~~~~~~~~~~ In file included from drivers/mmc/core/mmc.c:25: drivers/mmc/core/quirks.h:123:31: warning: ‘sdio_fixup_methods’ defined but not used [-Wunused-const-variable=] 123 | static const struct mmc_fixup sdio_fixup_methods[] = { | ^~~~~~~~~~~~~~~~~~ drivers/mmc/core/quirks.h:17:31: warning: ‘mmc_blk_fixups’ defined but not used [-Wunused-const-variable=] 17 | static const struct mmc_fixup mmc_blk_fixups[] = { | ^~~~~~~~~~~~~~ Cc: Andrei Warkentin <andreiw@motorola.com> Cc: Martin Mares <mj@ucw.cz> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20200701124702.908713-2-lee.jones@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-07-13mmc: core: Set default power mode in mmc_alloc_host()Veerabhadrarao Badiganti2-1/+1
Set the default power mode, MMC_POWER_UNDEFINED, in mmc_alloc_host() rather than in mmc_start_host(). This enables host drivers to make use of the initial state during ->probe(). Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Link: https://lore.kernel.org/r/1592919288-1020-3-git-send-email-vbadigan@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-07-13mmc: sdio: fix clock rate setting for SDR12/SDR25 modeHaibo Chen1-7/+8
In current code logic, when work in SDR12/SDR25 mode, the final clock rate is incorrect, just the legancy 400KHz, because the card->sw_caps.sd3_bus_mode do not has the flag SD_MODE_UHS_SDR12 or SD_MODE_UHS_SDR25. Besides, SDIO_SPEED_SDR12 is actually value 0, and every mode need to config the timing and clock rate, so remove the ‘if’ operator. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Tested-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/1592813959-5914-1-git-send-email-haibo.chen@nxp.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-07-13mmc: sdio: Fix 1-bit mode for SD-combo cards during suspendYue Hu1-1/+22
Commit 6b5eda369ac3 ("sdio: put active devices into 1-bit mode during suspend") disabled 4-bit mode during system suspend. After this patch, commit 7310ece86ad7 ("mmc: implement SD-combo (IO+mem) support") used new sdio_enable_4bit_bus() instead of sdio_enable_wide() to support SD-combo cards, also for card resume. However, no corresponding support added during suspend. That is not correct. Let's fix it. Signed-off-by: Yue Hu <huyue2@yulong.com> Link: https://lore.kernel.org/r/20200609081431.6376-1-zbestahu@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-07-13mmc: sdio: Enable SDIO 4-bit bus if not support SD_SCR_BUS_WIDTH_4 for SD ↵Yue Hu1-14/+12
combo card If the card type is SD combo(MMC_TYPE_SD_COMBO) and the memory part does not support wider bus(SD_SCR_BUS_WIDTH_4), nothing will be done except return 0. However, we should check whether IO part support wider bus or not. We should use available IO ability if supported. In addition, there's a duplicated check to MMC_CAP_4_BIT_DATA since sdio_enable_wide() will include that check. And we can also save one call site to sdio_enable_wide() after this change. Signed-off-by: Yue Hu <huyue2@yulong.com> Link: https://lore.kernel.org/r/20200608103009.5000-1-zbestahu@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-07-13mmc: sdio: Return ret if sdio_disable_func() failsYue Hu1-1/+1
We should return any possible error returned by mmc_io_rw_direct() rather than only -EIO in sdio_disable_func() failure path. Signed-off-by: Yue Hu <huyue2@yulong.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200604100102.13572-1-zbestahu@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-07-13mmc: core: Always allow the card detect uevent to be consumedUlf Hansson2-5/+8
The approach to allow userspace ~5s to consume the uevent, which is triggered when a new card is inserted/initialized, currently requires the mmc host to support system wakeup. This is unnecessary limiting, especially for an mmc host that relies on a GPIO IRQ for card detect. More precisely, the mmc host may not support system wakeup for its corresponding struct device, while the GPIO IRQ still could be configured as a wakeup IRQ via enable_irq_wake(). To support all various cases, let's simply drop the need for the wakeup support. Instead let's always register a wakeup source and activate it for all card detect IRQs by calling __pm_wakeup_event(). Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200529102341.12529-1-ulf.hansson@linaro.org
2020-07-09mmc: remove the call to check_disk_changeChristoph Hellwig1-3/+0
The mmc driver doesn't support event notifications, which means that check_disk_change is a no-op. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
generated by cgit v1.2.3 (git 2.39.0) at 2025-03-05 09:58:55 +0300