kernel/linux.git/drivers/mmc/core, branch linux-4.20.y

mmc: core: Fix NULL ptr crash from mmc_should_fail_request

2019-03-05T16:59:43+00:00

commit e5723f95d6b493dd437f1199cacb41459713b32f upstream. In case of CQHCI, mrq->cmd may be NULL for data requests (non DCMD). In such case mmc_should_fail_request is directly dereferencing mrq->cmd while cmd is NULL. Fix this by checking for mrq->cmd pointer. Fixes: 72a5af554df8 ("mmc: core: Add support for handling CQE requests") Signed-off-by: Ritesh Harjani Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: block: handle complete_work on separate workqueue

2019-02-20T09:29:11+00:00

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

mmc: core: Use a minimum 1600ms timeout when enabling CACHE ctrl

2018-12-17T07:59:42+00:00

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 Reported-by: Andreas Dannenberg Reported-by: Faiz Abbas Cc: Signed-off-by: Ulf Hansson

mmc: core: Allow BKOPS and CACHE ctrl even if no HPI support

2018-12-17T07:57:18+00:00

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

mmc: core: Reset HPI enabled state during re-init and in case of errors

2018-12-17T07:56:54+00:00

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

mmc: core: use mrq->sbc when sending CMD23 for RPMB

2018-12-04T09:12:12+00:00

When sending out CMD23 in the blk preparation, the comment there rightfully says: * However, it is not sufficient to just send CMD23, * and avoid the final CMD12, as on an error condition * CMD12 (stop) needs to be sent anyway. This, coupled * with Auto-CMD23 enhancements provided by some * hosts, means that the complexity of dealing * with this is best left to the host. If CMD23 is * supported by card and host, we'll fill sbc in and let * the host deal with handling it correctly. Let's do this behaviour for RPMB as well, and not send CMD23 independently. Otherwise IP cores (like Renesas SDHI) may timeout because of automatic CMD23/CMD12 handling. Reported-by: Masaharu Hayakawa Signed-off-by: Wolfram Sang Tested-by: Clément Péron Reviewed-by: Avri Altman Reviewed-by: Niklas Söderlund Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson

Merge tag 'gpio-v4.20-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio

2018-10-23T07:45:05+00:00

Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO changes for the v4.20 series: Core changes: - A patch series from Hans Verkuil to make it possible to enable/disable IRQs on a GPIO line at runtime and drive GPIO lines as output without having to put/get them from scratch. The irqchip callbacks have been improved so that they can use only the fastpatch callbacks to enable/disable irqs like any normal irqchip, especially the gpiod_lock_as_irq() has been improved to be callable in fastpath context. A bunch of rework had to be done to achieve this but it is a big win since I never liked to restrict this to slowpath. The only call requireing slowpath was try_module_get() and this is kept at the .request_resources() slowpath callback. In the GPIO CEC driver this is a big win sine a single line is used for both outgoing and incoming traffic, and this needs to use IRQs for incoming traffic while actively driving the line for outgoing traffic. - Janusz Krzysztofik improved the GPIO array API to pass a "cookie" (struct gpio_array) and a bitmap for setting or getting multiple GPIO lines at once. This improvement orginated in a specific need to speed up an OMAP1 driver and has led to a much better API and real performance gains when the state of the array can be used to bypass a lot of checks and code when we want things to go really fast. The previous code would minimize the number of calls down to the driver callbacks assuming the CPU speed was orders of magnitude faster than the I/O latency, but this assumption was wrong on several platforms: what we needed to do was to profile and improve the speed on the hot path of the array functions and this change is now completed. - Clean out the painful and hard to grasp BNF experiments from the device tree bindings. Future approaches are looking into using JSON schema for this purpose. (Rob Herring is floating a patch series.) New drivers: - The RCAR driver now supports r8a774a1 (RZ/G2M). - Synopsys GPIO via CREGs driver. Major improvements: - Modernization of the EP93xx driver to use irqdomain and other contemporary concepts. - The ingenic driver has been merged into the Ingenic pin control driver and removed from the GPIO subsystem. - Debounce support in the ftgpio010 driver" * tag 'gpio-v4.20-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (116 commits) gpio: Clarify kerneldoc on gpiochip_set_chained_irqchip() gpio: Remove unused 'irqchip' argument to gpiochip_set_cascaded_irqchip() gpio: Drop parent irq assignment during cascade setup mmc: pwrseq_simple: Fix incorrect handling of GPIO bitmap gpio: fix SNPS_CREG kconfig dependency warning gpiolib: Initialize gdev field before is used gpio: fix kernel-doc after devres.c file rename gpio: fix doc string for devm_gpiochip_add_data() to not talk about irq_chip gpio: syscon: Fix possible NULL ptr usage gpiolib: Show correct direction from the beginning pinctrl: msm: Use init_valid_mask exported function gpiolib: Add init_valid_mask exported function GPIO: add single-register GPIO via CREG driver dt-bindings: Document the Synopsys GPIO via CREG bindings gpio: mockup: use device properties instead of platform_data gpio: Slightly more helpful debugfs gpio: omap: Remove set but not used variable 'dev' gpio: omap: drop omap_gpio_list Accept partial 'gpio-line-names' property. gpio: omap: get rid of the conditional PM runtime calls ...

Merge tag 'mmc-v4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc

2018-10-23T07:36:15+00:00

Pull MMC updates from Ulf Hansson: "MMC core: - Introduce a host helper function to share re-tuning progress MMC host: - sdhci: Add support for v4 host mode - sdhci-of-arasan: Add Support for AM654 MMC and PHY - sdhci-sprd: Add support for Spreadtrum's host controller - sdhci-tegra: Add support for HS400 enhanced strobe - sdhci-tegra: Enable UHS/HS200 modes for Tegra186/210 - sdhci-tegra: Add support for HS400 delay line calibration - sdhci-tegra: Add support for pad calibration - sdhci-of-dwcmshc: Address 128MB DMA boundary limitation - sdhci-of-esdhc: Add support for tuning erratum A008171 - sdhci-iproc: Add ACPI support - mediatek: Add support for MT8183 - mediatek: Improve the support for tuning - mediatek: Add bus clock control for MT2712 - jz4740: Add support for the JZ4725B - mmci: Add support for the stm32 sdmmc variant - mmci: Add support for an optional reset control - mmci: Add some new variant specific properties/callbacks - mmci: Re-structure DMA code to prepare for new variants - renesas_sdhi: Add support for r8a77470, r8a7744 and r8a774a1 - renesas_sdhi_internal_dmac: Whitelist r8a77970 and r8a774a1 - tmio/uniphier-sd: Add new UniPhier SD/eMMC controller driver - tmio/renesas_sdhi: Deal properly with SCC detection during re-tune - tmio/renesas_sdhi: Refactor/consolidate clock management - omap_hsmmc: Drop cover detection and some unused platform data - dw_mmc-exynos: Enable tuning for more speed modes - sunxi: Clarify the new timing mode and enable it for the A64 controller - various: Convert to slot GPIO descriptors" * tag 'mmc-v4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: (129 commits) mmc: mediatek: drop too much code of tuning method mmc: mediatek: add MT8183 MMC driver support mmc: mediatek: tune CMD/DATA together mmc: mediatek: fix cannot receive new request when msdc_cmd_is_ready fail mmc: mediatek: fill the actual clock for mmc debugfs mmc: dt-bindings: add support for MT8183 SoC mmc: uniphier-sd: avoid using broken DMA RX channel mmc: uniphier-sd: fix DMA disabling mmc: tmio: simplify the DMA mode test mmc: tmio: remove TMIO_MMC_HAVE_HIGH_REG flag mmc: tmio: move MFD variant reset to a platform hook mmc: renesas_sdhi: Add r8a77470 SDHI1 support dt-bindings: mmc: renesas_sdhi: Add r8a77470 support mmc: mmci: add stm32 sdmmc variant dt-bindings: mmci: add stm32 sdmmc variant mmc: mmci: add stm32 sdmmc registers mmc: mmci: add clock divider for stm32 sdmmc mmc: mmci: add optional reset property dt-bindings: mmci: add optional reset property mmc: mmci: add variant property to not read datacnt ...

Merge tag 'for-4.20/block-20181021' of git://git.kernel.dk/linux-block

2018-10-22T16:46:08+00:00

Pull block layer updates from Jens Axboe: "This is the main pull request for block changes for 4.20. This contains: - Series enabling runtime PM for blk-mq (Bart). - Two pull requests from Christoph for NVMe, with items such as; - Better AEN tracking - Multipath improvements - RDMA fixes - Rework of FC for target removal - Fixes for issues identified by static checkers - Fabric cleanups, as prep for TCP transport - Various cleanups and bug fixes - Block merging cleanups (Christoph) - Conversion of drivers to generic DMA mapping API (Christoph) - Series fixing ref count issues with blkcg (Dennis) - Series improving BFQ heuristics (Paolo, et al) - Series improving heuristics for the Kyber IO scheduler (Omar) - Removal of dangerous bio_rewind_iter() API (Ming) - Apply single queue IPI redirection logic to blk-mq (Ming) - Set of fixes and improvements for bcache (Coly et al) - Series closing a hotplug race with sysfs group attributes (Hannes) - Set of patches for lightnvm: - pblk trace support (Hans) - SPDX license header update (Javier) - Tons of refactoring patches to cleanly abstract the 1.2 and 2.0 specs behind a common core interface. (Javier, Matias) - Enable pblk to use a common interface to retrieve chunk metadata (Matias) - Bug fixes (Various) - Set of fixes and updates to the blk IO latency target (Josef) - blk-mq queue number updates fixes (Jianchao) - Convert a bunch of drivers from the old legacy IO interface to blk-mq. This will conclude with the removal of the legacy IO interface itself in 4.21, with the rest of the drivers (me, Omar) - Removal of the DAC960 driver. The SCSI tree will introduce two replacement drivers for this (Hannes)" * tag 'for-4.20/block-20181021' of git://git.kernel.dk/linux-block: (204 commits) block: setup bounce bio_sets properly blkcg: reassociate bios when make_request() is called recursively blkcg: fix edge case for blk_get_rl() under memory pressure nvme-fabrics: move controller options matching to fabrics nvme-rdma: always have a valid trsvcid mtip32xx: fully switch to the generic DMA API rsxx: switch to the generic DMA API umem: switch to the generic DMA API sx8: switch to the generic DMA API sx8: remove dead IF_64BIT_DMA_IS_POSSIBLE code skd: switch to the generic DMA API ubd: remove use of blk_rq_map_sg nvme-pci: remove duplicate check drivers/block: Remove DAC960 driver nvme-pci: fix hot removal during error handling nvmet-fcloop: suppress a compiler warning nvme-core: make implicit seed truncation explicit nvmet-fc: fix kernel-doc headers nvme-fc: rework the request initialization code nvme-fc: introduce struct nvme_fcp_op_w_sgl ...

mmc: pwrseq_simple: Fix incorrect handling of GPIO bitmap

2018-10-15T14:26:00+00:00

Commit b9762bebc633 ("gpiolib: Pass bitmaps, not integer arrays, to get/set array") changed the way GPIO values are passed to gpiod_get/set_array_value() and friends. The new code introduced into mmc_pwrseq_simple_set_gpios_value() incorrectly interpretes the 'value' argument as a bitmap of GPIO values and assigns it directly to the 'values' bitmap variable passed to gpiod_set_array_value_cansleep() instead of filling that bitmap with bits equal to the 'value' argument. As a result, only member 0 of the array is handled correctly. Moreover, wrong assumption is taken about the 'values' bitmap size not exceding the number of bits of the 'value' argument type. Fix it. Signed-off-by: Janusz Krzysztofik Tested-by: Marek Szyprowski Acked-by: Ulf Hansson Signed-off-by: Linus Walleij