- 07 Dec, 2022 35 commits
-
-
Yang Yingliang authored
mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(). Fixes: 1b66e94e ("mmc: moxart: Add MOXA ART SD/MMC driver") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20221101063023.1664968-3-yangyingliang@huawei.comSigned-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Yang Yingliang authored
mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and calling mmc_free_host() in the error path. Fixes: c5413ad8 ("mmc: add new Alcor Micro Cardreader SD/MMC driver") Signed-off-by:
-
Mengqi Zhang authored
Add crypto clock control and ungate it before CQHCI init. Signed-off-by:
Mengqi Zhang <mengqi.zhang@mediatek.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20221106033924.9854-2-mengqi.zhang@mediatek.comSigned-off-by:
-
Mengqi Zhang authored
Add optional crypto clock of the Inline Crypto Engine of Mediatek SoCs. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
AngeloGioacchino Del Regno authored
Document the compatible for the SDHCI controller(s) found on MSM8976. Signed-off-by:
-
Adrian Hunter authored
Remove duplicate words in comments found using the following commands: pcregrep --color=always -n \ '([^a-zA-Z_])([a-zA-Z_]+)[[:space:]]+\2[^a-zA-Z_]' \ drivers/mmc/host/*.[ch] drivers/mmc/core/*.[ch] \ include/linux/mmc/*.h \ include/uapi/linux/mmc/*.h | \ grep -v 'long long' pcregrep --color=always -n -M \ '([^a-zA-Z_])([a-zA-Z_]+)[ \t]*\n[[:space:]*]+\2[^a-zA-Z_]' \ drivers/mmc/host/*.[ch] \ drivers/mmc/core/*.[ch] \ include/linux/mmc/*.h \ include/uapi/linux/mmc/*.h Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20221102120105.5747-1-adrian.hunter@intel.comSigned-off-by:
-
Matthias Schiffer authored
Checking phandle references like mmc-pwrseq can result in -EPROBE_DEFER. Signed-off-by:
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Acked-by:
-
Brian Norris authored
This driver often takes on the order of 10ms to start, but in some cases as much as 190ms. It shouldn't have many cross-device dependencies to race with, nor racy access to shared state with other drivers, so this should be a relatively low risk change. We've done similarly with a variety of other MMC host drivers already. This driver was pinpointed as part of a survey of top slowest initcalls (i.e., are built in, and probing synchronously) on a lab of ChromeOS systems. Signed-off-by:
Brian Norris <briannorris@chromium.org> Acked-by:
-
Haibo Chen authored
For standard tuning method on usdhc, the previous tuning result can impact current tuning result, let current tuning can't set the correct delay cell. And from the logic, this is also reasonable for manual tuning method. So reset the tuning logic before execute tuning. To avoid compile issue, this patch also move the esdhc_reset_tuning() upper. Find this issue when support SDIO WiFi in band wakeup feature. After system resume back, will do re-tuning, but then meet data CRC error. Do not meet this issue on SD/eMMC, because we already call esdhc_reset_tuning() when config the legency ios, and SD/eMMC need to re-init when system resume back, but SDIO device don't do re-init if it has MMC_PM_KEEP_POWER pm_flags. Signed-off-by:
Haibo Chen <haibo.chen@nxp.com> Acked-by:
-
Brian Norris authored
An earlier patch ("mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI") does these operations for us. I keep these as a separate patch, since the earlier patch is a prerequisite to some important bugfixes that need to be backported via linux-stable. Signed-off-by: -
Sai Krishna Potthuri authored
Add dynamic configuration support for Xilinx ZynqMP which takes care of configuring the SD secure space configuration registers using EEMI APIs, performing SD reset assert and deassert. High level sequence: - Check for the PM dynamic configuration support, if no error proceed with SD dynamic configurations(next steps) otherwise skip the dynamic configuration. - Put the SD Controller in reset. - Configure SD Fixed configurations. - Configure the SD Slot Type. - Configure the BASE_CLOCK. - Configure the 8-bit support. - Bring the SD Controller out of reset. - Wait for 1msec delay. Signed-off-by:
Sai Krishna Potthuri <sai.krishna.potthuri@amd.com> Acked-by:
Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20221019054857.8286-1-sai.krishna.potthuri@amd.comSigned-off-by:
-
Sam Shih authored
Adding mt7986 own characteristics and of_device_id to have support of MT7986 SoC. Signed-off-by:
Sam Shih <sam.shih@mediatek.com> Signed-off-by:
Frank Wunderlich <frank-w@public-files.de> Reviewed-by:
-
Sam Shih authored
This commit adds dt-binding documentation of mmc for Mediatek MT7986 SoC Platform. Add SoC specific section for defining clock configuration. Signed-off-by:
-
Nícolas F. R. A. Prado authored
The binding was describing a single clock list for all platforms, but that's not really suitable: Most platforms using at least 2 clocks (source, hclk), some of them a third "source_cg". Mt2712 requires an extra 'bus_clk' on some of its controllers, while mt8192 requires 8 clocks. Move the clock definitions inside if blocks that match on the compatibles. I used Patch from Nícolas F. R. A. Prado and modified it to not using "not" statement. Fixes: 59a23395 ("dt-bindings: mmc: Add support for MT8192 SoC") Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by:
-
wangjianli authored
Delete the redundant word 'the'. Signed-off-by:
wangjianli <wangjianli@cdjrlc.com> Link: https://lore.kernel.org/r/20221022062237.10333-1-wangjianli@cdjrlc.com Link: https://lore.kernel.org/r/20221022062331.11395-1-wangjianli@cdjrlc.com Link: https://lore.kernel.org/r/20221022062505.13155-1-wangjianli@cdjrlc.comSigned-off-by:
-
Giulio Benetti authored
i.MXRT1050 usdhc is not affected by ESDHC_FLAG_ERR004536 so let's remove it. It supports ESDHC_FLAG_STD_TUNING and ESDHC_FLAG_HAVE_CAP1 so let's add them. Signed-off-by:
Giulio Benetti <giulio.benetti@benettiengineering.com> Reviewed-by:
-
Brian Norris authored
This driver is pretty simple, and it can be useful to build it (for validation purposes) without BMIPS or ARCH_BRCMSTB. It technically depends on CONFIG_OF to do anything useful at runtime, but it still works out OK for compile-testing using the !OF stubs. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Acked-by:
-
Adrian Hunter authored
kmap_local_page() is equivalent to kmap_atomic() except that it does not disable page faults or preemption. Where possible kmap_local_page() is preferred to kmap_atomic() - refer kernel highmem documentation. In this case, there is no need to disable page faults or preemption, so replace kmap_atomic() with kmap_local_page(), and, correspondingly, kunmap_atomic() with kunmap_local(). Signed-off-by:
-
Adrian Hunter authored
kmap_local_page() is equivalent to kmap_atomic() except that it does not disable page faults or preemption. Where possible kmap_local_page() is preferred to kmap_atomic() - refer kernel highmem documentation. In this case, there is no need to disable page faults or preemption, so replace kmap_atomic() with kmap_local_page(), and, correspondingly, kunmap_atomic() with kunmap_local(). Signed-off-by:
-
Adrian Hunter authored
kmap_local_page() is equivalent to kmap_atomic() except that it does not disable page faults or preemption. Where possible kmap_local_page() is preferred to kmap_atomic() - refer kernel highmem documentation. In this case, there is no need to disable page faults or preemption, so replace kmap_atomic() with kmap_local_page(), and, correspondingly, kunmap_atomic() with kunmap_local(). Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20221005101951.3165-13-adrian.hunter@intel.comSigned-off-by:
-
Adrian Hunter authored
A long time ago the kmap_atomic API required a slot to be provided which risked the possibility that other code might use the same slot at the same time. Disabling interrupts prevented the possibility of an interrupt handler doing that. However, that went away with commit 3e4d3af5 ("mm: stack based kmap_atomic()"). When the second argument to kmap_atomic was removed by commit 482fce99 ("mmc: remove the second argument of k[un]map_atomic()"), local_irq_{save,restore}() should have been removed also. Remove it now. Signed-off-by:
-
Adrian Hunter authored
kmap_local_page() is equivalent to kmap_atomic() except that it does not disable page faults or preemption. Where possible kmap_local_page() is preferred to kmap_atomic() - refer kernel highmem documentation. In this case, there is no need to disable page faults or preemption, so replace kmap_atomic() with kmap_local_page(), and, correspondingly, kunmap_atomic() with kunmap_local(). Signed-off-by:
-
Adrian Hunter authored
tifm_sd_bounce_block() calls functions that ultimate use kmap_atomic() to map pages. A long time ago the kmap_atomic API required a slot to be provided which risked the possibility that other code might use the same slot at the same time. Disabling interrupts prevented the possibility of an interrupt handler doing that. However, that went away with commit 3e4d3af5 ("mm: stack based kmap_atomic()"). When the second argument to kmap_atomic was removed by commit 482fce99 ("mmc: remove the second argument of k[un]map_atomic()"), local_irq_{save,restore}() should have been removed also. Remove it now. Signed-off-by:
-
Adrian Hunter authored
tifm_sd_transfer_data() calls functions that ultimate use kmap_atomic() to map pages. A long time ago the kmap_atomic API required a slot to be provided which risked the possibility that other code might use the same slot at the same time. Disabling interrupts prevented the possibility of an interrupt handler doing that. However, that went away with commit 3e4d3af5 ("mm: stack based kmap_atomic()"). When the second argument to kmap_atomic was removed by commit 482fce99 ("mmc: remove the second argument of k[un]map_atomic()"), local_irq_{save,restore}() should have been removed also. Remove it now. Signed-off-by:
-
Adrian Hunter authored
sg_copy_{from,to}_buffer() call sg_copy_buffer() which uses an sg_mapping_iter with flag SG_MITER_ATOMIC, so then sg_miter_next() uses kmap_atomic() to map pages. A long time ago the kmap_atomic API required a slot to be provided which risked the possibility that other code might use the same slot at the same time. Disabling interrupts prevented the possibility of an interrupt handler doing that. However, that went away with commit 3e4d3af5 ("mm: stack based kmap_atomic()"). Remove local_irq_{save,restore}() around sg_copy_{from,to}_buffer(). Signed-off-by: -
Adrian Hunter authored
kmap_local_page() is equivalent to kmap_atomic() except that it does not disable page faults or preemption. Where possible kmap_local_page() is preferred to kmap_atomic() - refer kernel highmem documentation. In this case, there is no need to disable page faults or preemption, so replace kmap_atomic() with kmap_local_page(), and, correspondingly, kunmap_atomic() with kunmap_local(). Signed-off-by:
-
Adrian Hunter authored
sg_miter_next() using an sg_mapping_iter with flag SG_MITER_ATOMIC uses kmap_atomic() to map pages. A long time ago the kmap_atomic API required a slot to be provided which risked the possibility that other code might use the same slot at the same time. Disabling interrupts prevented the possibility of an interrupt handler doing that. However, that went away with commit 3e4d3af5 ("mm: stack based kmap_atomic()"). Remove local_irq_{save,restore}() around sg_miter_{next,stop}(). Signed-off-by:
-
Adrian Hunter authored
A long time ago the kmap_atomic API required a slot to be provided which risked the possibility that other code might use the same slot at the same time. Disabling interrupts prevented the possibility of an interrupt handler doing that. However, that went away with commit 3e4d3af5 ("mm: stack based kmap_atomic()"). Unfortunately, that unnecessary pattern of code has been copied since and persists in bcm2385.c. Remove it. Signed-off-by:
-
Adrian Hunter authored
kmap_local_page() is equivalent to kmap_atomic() except that it does not disable page faults or preemption. Where possible kmap_local_page() is preferred to kmap_atomic() - refer kernel highmem documentation. In this case, there is no need to disable page faults or preemption, so replace kmap_atomic() with kmap_local_page(), and, correspondingly, kunmap_atomic() with kunmap_local(). Signed-off-by:
-
Adrian Hunter authored
sg_miter_next() using an sg_mapping_iter with flag SG_MITER_ATOMIC uses kmap_atomic() to map pages. A long time ago the kmap_atomic API required a slot to be provided which risked the possibility that other code might use the same slot at the same time. Disabling interrupts prevented the possibility of an interrupt handler doing that. However, that went away with commit 3e4d3af5 ("mm: stack based kmap_atomic()"). Remove local_irq_{save,restore}() around sg_miter_{next,stop}(). Signed-off-by:
-
Adrian Hunter authored
A long time ago the kmap_atomic API required a slot to be provided which risked the possibility that other code might use the same slot at the same time. Disabling interrupts prevented the possibility of an interrupt handler doing that. However, that went away with commit 3e4d3af5 ("mm: stack based kmap_atomic()"). When the second argument to kmap_atomic was removed by commit 482fce99 ("mmc: remove the second argument of k[un]map_atomic()"), local_irq_{save,restore}() should have been removed also. Remove it now. Signed-off-by:
-
Marek Vasut authored
Due to inconsistency of existing DTs regarding the content of this IP interrupt-names DT property, document this such that interrupt-names is not used by this IP bindings. Signed-off-by:
Marek Vasut <marex@denx.de> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20221013221242.218808-1-marex@denx.deSigned-off-by:
-
Matt Ranostay authored
Add missing ti,itap-del-sel-ddr50 property to schema to clear up the following warnings. mmc@4fb0000: Unevaluated properties are not allowed ('ti,itap-del-sel-ddr50' was unexpected) Signed-off-by:Matt Ranostay <mranostay@ti.com> Reviewed-by:
-
Geert Uytterhoeven authored
Document support for the SD Card/MMC Interface on the Renesas R-Car V4H (R8A779G0) SoC. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
-
Peng Fan authored
i.MX8DXL is compatible with i.MX8QXP, so update binding doc. Signed-off-by:
Peng Fan <peng.fan@nxp.com> Acked-by:
-
- 04 Dec, 2022 5 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
This reverts commit f35b5d7d. It has been reported to cause huge performance regressions on some loads (will-it-scale.per_process_ops, but also building the kernel with clang). The commit did speed up gcc builds by a small amount, so it's not an unambiguous regression, but until the big regressions are understood, let's revert it. Reported-by:
kernel test robot <yujie.liu@intel.com> Link: https://lore.kernel.org/r/202210181535.7144dd15-yujie.liu@intel.comReported-by:
Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/lkml/Y1DNQaoPWxE%2BrGce@dev-arch.thelio-3990X/ Cc: Huang, Ying <ying.huang@intel.com> Cc: Rik van Riel <riel@surriel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Yang Shi <shy828301@gmail.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Jan Dabros authored
Currently tpm transactions are executed unconditionally in tpm_pm_suspend() function, which may lead to races with other tpm accessors in the system. Specifically, the hw_random tpm driver makes use of tpm_get_random(), and this function is called in a loop from a kthread, which means it's not frozen alongside userspace, and so can race with the work done during system suspend: tpm tpm0: tpm_transmit: tpm_recv: error -52 tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Call Trace: tpm_tis_status.cold+0x19/0x20 tpm_transmit+0x13b/0x390 tpm_transmit_cmd+0x20/0x80 tpm1_pm_suspend+0xa6/0x110 tpm_pm_suspend+0x53/0x80 __pnp_bus_suspend+0x35/0xe0 __device_suspend+0x10f/0x350 Fix this by calling tpm_try_get_ops(), which itself is a wrapper around tpm_chip_start(), but takes the appropriate mutex. Signed-off-by:
Jan Dabros <jsd@semihalf.com> Reported-by:
Vlastimil Babka <vbabka@suse.cz> Tested-by:
Jason A. Donenfeld <Jason@zx2c4.com> Tested-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf fix from Borislav Petkov: - Fix a use-after-free case where the perf pending task callback would see an already freed event * tag 'perf_urgent_for_v6.1_rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: Fix perf_pending_task() UaF
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fix from Borislav Petkov: - Revert a fix to RISC-V timers supposed to address an uncertainty whether clock events are received during S3 or not which locks up other RISC-V platforms. The issue will be fixed differently later. * tag 'timers_urgent_for_v6.1_rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: Revert "clocksource/drivers/riscv: Events are stopped during CPU suspend"
-
