- 05 Mar, 2024 7 commits
-
-
Yang Xiwen authored
Add binding and an extra property for Hi3798MV200 DWMMC specific extension. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Yang Xiwen <forbidden405@outlook.com> Link: https://lore.kernel.org/r/20240229-b4-mmc-hi3798mv200-v7-4-10c03f316285@outlook.comSigned-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Yang Xiwen authored
convert the legacy txt binding to modern YAML and rename to hisilicon,hi3798cv200-dw-mshc.yaml. No semantic change. Reviewed-by:
-
Yang Xiwen authored
The alias is not used and should be removed. Reviewed-by:
-
Yang Xiwen authored
Parsing dt usually happens very early, sometimes even before the struct mmc_host has been allocated (e.g. dw_mci_probe() and dw_mci_parse_dt() in dw_mmc.c). Looking at the source of mmc_of_parse_clk_phase(), it's actually not needed to have an initialized mmc_host, let's therefore pass a struct device* to it instead. Also update the only current user, sdhci-of-aspeed. Reviewed-by:
Paul Menzel <pmenzel@molgen.mpg.de> Acked-by:
Andrew Jeffery <andrew@codeconstruct.com.au> Signed-off-by:
-
Christophe JAILLET authored
This looks strange to call release_mem_region() in a remove function without any request_mem_region() in the probe or "struct resource" somewhere. So remove the corresponding code. Fixes: 3a96dff0 ("mmc: SD/MMC Host Controller for Wondermedia WM8505/WM8650") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/bb0bb1ed1e18de55e8c0547625bde271e64b8c31.1708983064.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Ulf Hansson authored
Merge the mmc fixes for v6.8-rc[n] into the next branch, to allow them to get tested together with the new mmc changes that are targeted for v6.9. Signed-off-by: -
Wolfram Sang authored
With the to-be-fixed commit, the reset_work handler cleared 'host->mrq' outside of the spinlock protected critical section. That leaves a small race window during execution of 'tmio_mmc_reset()' where the done_work handler could grab a pointer to the now invalid 'host->mrq'. Both would use it to call mmc_request_done() causing problems (see link below). However, 'host->mrq' cannot simply be cleared earlier inside the critical section. That would allow new mrqs to come in asynchronously while the actual reset of the controller still needs to be done. So, like 'tmio_mmc_set_ios()', an ERR_PTR is used to prevent new mrqs from coming in but still avoiding concurrency between work handlers. Reported-by:
Dirk Behme <dirk.behme@de.bosch.com> Closes: https://lore.kernel.org/all/20240220061356.3001761-1-dirk.behme@de.bosch.com/ Fixes: df3ef2d3 ("mmc: protect the tmio_mmc driver against a theoretical race") Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by:
-
- 28 Feb, 2024 8 commits
-
-
Ulf Hansson authored
Merge the mmc fixes for v6.8-rc[n] into the next branch, to allow them to get tested together with the new mmc changes that are targeted for v6.9. Signed-off-by: -
Elad Nachman authored
AC5X spec says PHY init complete bit must be polled until zero. We see cases in which timeout can take longer than the standard calculation on AC5X, which is expected following the spec comment above. According to the spec, we must wait as long as it takes for that bit to toggle on AC5X. Cap that with 100 delay loops so we won't get stuck forever. Fixes: 06c8b667 ("mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC") Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Signed-off-by:
Elad Nachman <enachman@marvell.com> Link: https://lore.kernel.org/r/20240222191714.1216470-3-enachman@marvell.comSigned-off-by:
-
Elad Nachman authored
Each time SD/mmc phy is initialized, at times, in some of the attempts, phy fails to completes its initialization which results into timeout error. Per the HW spec, it is a pre-requisite to ensure a stable SD clock before a phy initialization is attempted. Fixes: 06c8b667 ("mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC") Acked-by:
-
Fabio Estevam authored
The fsl-imx-mmc hardware needs two clocks to operate: ipg and per. Document these required clocks. This fixes the following schema warning: imx27-apf27dev.dtb: mmc@10014000: Unevaluated properties are not allowed ('clock-names', 'clocks' were unexpected) from schema $id: http://devicetree.org/schemas/mmc/fsl-imx-mmc.yaml#Signed-off-by:Fabio Estevam <festevam@denx.de> Acked-by:
-
Linus Walleij authored
The introduction of sg_miter was a bit sloppy as it didn't exactly mimic the semantics of the old code on multiblock reads and writes: these like you to: - Advance to the first sglist entry *before* starting to read any blocks from the card. - Advance and check availability of the next entry *right after* processing one block. Not checking if we have more sglist entries right after reading a block will lead to this not being checked until we return to the callback to read out more blocks, i.e. until the next interrupt arrives. Since the last block is the last one (no more data will arrive) there will not be a next interrupt, and we will be waiting forever resulting in a timeout for command 18 when reading multiple blocks. The same bug was fixed also in the writing of multiple blocks. Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Fixes: 27b57277 ("mmc: sh_mmcif: Use sg_miter for PIO") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Tested-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20240221-fix-sh-mmcif-v2-2-5e521eb25ae4@linaro.orgSigned-off-by:
-
Linus Walleij authored
All the sglist iterations happen in the *threaded* interrupt handler and that context is not atomic, so don't request an atomic sglist miter. Using an atomic miter results in "BUG: scheduling while atomic" splats. Reported-by:
-
Linus Walleij authored
The sg_miter used to loop over the returned sglist from a transfer in the esdhc subdriver for SDHCI can be called from atomic context so the miter needs to be atomic. sdhci_request_done() is always called from process context, either as a work or as part of the threaded interrupt handler, but the one case when we are actually calling .request_done() from an atomic context is in sdhci_irq(). Fix this by flagging the miter atomic so we always use kmap_atomic(). Fixes: e8a167b8 ("mmc: sdhci-esdhc-mcf: Use sg_miter for swapping") Reported-by:
-
Marco Felsch authored
Some devices support only the default and the 100MHz case, add the support for this to the binding to avoid warnings. Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Reviewed-by:
-
- 27 Feb, 2024 5 commits
-
-
Ricardo B. Marliere authored
Since commit aed65af1 ("drivers: make device_type const"), the driver core can properly handle constant struct device_type. Move the sdio_type, sd_type and mmc_type variables to be constant structures as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ricardo B. Marliere <ricardo@marliere.net> Link: https://lore.kernel.org/r/20240219-device_cleanup-mmc-v1-1-1910e283cf5a@marliere.netSigned-off-by:
-
Jisheng Zhang authored
Add support for the mmc controller in the Sophgo CV1800B and SG2002 with corresponding new compatible strings. Implement custom sdhci_ops. Signed-off-by:
Jisheng Zhang <jszhang@kernel.org> Link: https://lore.kernel.org/r/20240217144202.3808-3-jszhang@kernel.orgSigned-off-by:
-
Jisheng Zhang authored
Add compatible value for the dwcmshc controller in Sophgo's CV1800B and SG2002. Signed-off-by:
-
Martin Blumenstingl authored
Commit 32f18e59 ("mmc: improve API to make clear hw_reset callback is for cards") made it clear that the hw_reset callback is intended for resetting the card. Remove the .card_hw_reset callback from the meson-mx-sdhc-mmc driver because it's purpose is to reset the SDHC controller (FIFOs, PHY, DMA interface, ...). While here also rename and change the argument of meson_mx_sdhc_hw_reset so it cannot be called by accident as a replacement for card_hw_reset in the future. Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20240217100200.1494980-3-martin.blumenstingl@googlemail.comSigned-off-by:
-
Martin Blumenstingl authored
Now that devm_clk_hw_get_clk() has been available for a while we can resolve an older TODO where this API did not exist yet. No functional changes intended. Signed-off-by:
-
- 15 Feb, 2024 2 commits
-
-
Linus Walleij authored
The sg_miter conversion left a dangling unused variable. Drop it. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202402142042.vg0lnLdb-lkp@intel.com/ Fixes: ed01d210 ("mmc: davinci_mmc: Use sg_miter for PIO") Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20240215-mmc-fix-davinci-v1-1-a593678ca7bf@linaro.orgSigned-off-by:
-
Geert Uytterhoeven authored
Document support for the SD Card/MMC Interface in the Renesas R-Car V4M (R8A779H0) SoC. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/fffc5a0a73c4cc8e8d7c5d93679531cc24e006ca.1707915511.git.geert+renesas@glider.beSigned-off-by:
-
- 14 Feb, 2024 2 commits
-
-
Ulf Hansson authored
Merge the mmc fixes for v6.8-rc[n] into the next branch, to allow them to get tested together with the new mmc changes that are targeted for v6.9. Signed-off-by: -
Christophe Kerello authored
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning: DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568 add_dma_entry+0x234/0x2f4 Modules linked in: CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1 Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT) Workqueue: events_freezable mmc_rescan Call trace: add_dma_entry+0x234/0x2f4 debug_dma_map_sg+0x198/0x350 __dma_map_sg_attrs+0xa0/0x110 dma_map_sg_attrs+0x10/0x2c sdmmc_idma_prep_data+0x80/0xc0 mmci_prep_data+0x38/0x84 mmci_start_data+0x108/0x2dc mmci_request+0xe4/0x190 __mmc_start_request+0x68/0x140 mmc_start_request+0x94/0xc0 mmc_wait_for_req+0x70/0x100 mmc_send_tuning+0x108/0x1ac sdmmc_execute_tuning+0x14c/0x210 mmc_execute_tuning+0x48/0xec mmc_sd_init_uhs_card.part.0+0x208/0x464 mmc_sd_init_card+0x318/0x89c mmc_attach_sd+0xe4/0x180 mmc_rescan+0x244/0x320 DMA API debug brings to light leaking dma-mappings as dma_map_sg and dma_unmap_sg are not correctly balanced. If an error occurs in mmci_cmd_irq function, only mmci_dma_error function is called and as this API is not managed on stm32 variant, dma_unmap_sg is never called in this error path. Signed-off-by:
Christophe Kerello <christophe.kerello@foss.st.com> Fixes: 46b723dd ("mmc: mmci: add stm32 sdmmc variant") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240207143951.938144-1-christophe.kerello@foss.st.comSigned-off-by:
-
- 13 Feb, 2024 16 commits
-
-
Ulf Hansson authored
Merge the mmc fixes for v6.8-rc[n] into the next branch, to allow them to get tested together with the new mmc changes that are targeted for v6.9. Signed-off-by: -
Ivan Semenov authored
Initializing an eMMC that's connected via a 1-bit bus is current failing, if the HW (DT) informs that 4-bit bus is supported. In fact this is a regression, as we were earlier capable of falling back to 1-bit mode, when switching to 4/8-bit bus failed. Therefore, let's restore the behaviour. Log for Samsung eMMC 5.1 chip connected via 1bit bus (only D0 pin) Before patch: [134509.044225] mmc0: switch to bus width 4 failed [134509.044509] mmc0: new high speed MMC card at address 0001 [134509.054594] mmcblk0: mmc0:0001 BGUF4R 29.1 GiB [134509.281602] mmc0: switch to bus width 4 failed [134509.282638] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [134509.282657] Buffer I/O error on dev mmcblk0, logical block 0, async page read [134509.284598] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [134509.284602] Buffer I/O error on dev mmcblk0, logical block 0, async page read [134509.284609] ldm_validate_partition_table(): Disk read failed. [134509.286495] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [134509.286500] Buffer I/O error on dev mmcblk0, logical block 0, async page read [134509.288303] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [134509.288308] Buffer I/O error on dev mmcblk0, logical block 0, async page read [134509.289540] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [134509.289544] Buffer I/O error on dev mmcblk0, logical block 0, async page read [134509.289553] mmcblk0: unable to read partition table [134509.289728] mmcblk0boot0: mmc0:0001 BGUF4R 31.9 MiB [134509.290283] mmcblk0boot1: mmc0:0001 BGUF4R 31.9 MiB [134509.294577] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2 [134509.295835] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 [134509.295841] Buffer I/O error on dev mmcblk0, logical block 0, async page read After patch: [134551.089613] mmc0: switch to bus width 4 failed [134551.090377] mmc0: new high speed MMC card at address 0001 [134551.102271] mmcblk0: mmc0:0001 BGUF4R 29.1 GiB [134551.113365] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p14 p15 p16 p17 p18 p19 p20 p21 [134551.114262] mmcblk0boot0: mmc0:0001 BGUF4R 31.9 MiB [134551.114925] mmcblk0boot1: mmc0:0001 BGUF4R 31.9 MiB Fixes: 577fb131 ("mmc: rework selection of bus speed mode") Cc: stable@vger.kernel.org Signed-off-by:
Ivan Semenov <ivan@semenov.dev> Link: https://lore.kernel.org/r/20240206172845.34316-1-ivan@semenov.devSigned-off-by:
-
Jeffrey Hugo authored
The @codeaurora email domain's servers have been decommissioned for a long while now, and any emails addressed there will bounce. Asutosh has an entry in .mailmap pointing to a new address, but MAINTAINERS still lists an old @codeaurora address. Update MAINTAINERS to match .mailmap for anyone reading the file directly. Ritesh appears to have changed jobs, but looks to be still active in the community. Update Ritesh's address to the one used in recient community postings. Also Ritesh has indicated their entry should be changed from Maintainer (M:) to Reviewer (R:) so make that update while we are making changes to the entry. Signed-off-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Acked-by:
Ritesh Harjani <ritesh.list@gmail.com> Link: https://lore.kernel.org/r/20240209160934.3866475-1-quic_jhugo@quicinc.comSigned-off-by:
-
Krzysztof Kozlowski authored
Use existing typedef for dma_filter_fn to avoid duplicating type definition. Signed-off-by:
-
Colin Ian King authored
The variable id is being initialized with a value that is never read, it is being re-assigned later on. The initialization is redundant and can be removed. Cleans up clang scan build warning: drivers/mmc/host/wbsd.c:1287:4: warning: Value stored to 'id' is never read [deadcode.DeadStores] Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20240205191310.1848561-1-colin.i.king@gmail.comSigned-off-by:
-
Linus Walleij authored
Use sg_miter iterator instead of sg_virt() and custom code to loop over the scatterlist. The memory iterator will do bounce buffering if the page happens to be located in high memory, which the driver may or may not be using. Suggested-by:
Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/linux-mmc/20240122073423.GA25859@lst.de/Signed-off-by:
-
Linus Walleij authored
Use sg_miter iterator instead of sg_virt() and custom code to loop over the scatterlist. The memory iterator will do bounce buffering if the page happens to be located in high memory, which the driver may or may not be using. Suggested-by:
-
Linus Walleij authored
Use the scatterlist memory iterator instead of just dereferencing virtual memory using sg_virt(). This make highmem references work properly. Suggested-by:
-
Linus Walleij authored
Use the scatterlist memory iterator instead of just dereferencing virtual memory using sg_virt(). This make highmem references work properly. Since this driver is using a worker, no atomic trickery is needed. Suggested-by:
-
Linus Walleij authored
Use the scatterlist memory iterator instead of just dereferencing virtual memory using sg_virt(). This make highmem references work properly. This driver also has a bug in the PIO sglist handling that is fixed as part of the patch: it does not travers the list of scatterbuffers: it will just process the first item in the list. This is fixed by augmenting the logic such that we do not process more than one sgitem per IRQ instead of counting down potentially the whole length of the request. We can suspect that the PIO path is quite untested. Suggested-by:
-
Linus Walleij authored
Use the scatterlist memory iterator instead of just dereferencing virtual memory using sg_virt(). This make highmem references work properly. Suggested-by:
-
Linus Walleij authored
The whole scatterlist chain is submitted to the DMA engine, but the code is written to just account for the length of the first sg entry. When the DMA transfer is finished, all the data in the request has been transferred, account for this instead. This only works because the moxart_request() function isn't checking that all data was transferred and will unconditionally issue mmc_request_done() after returning successfully from moxart_transfer_dma(). Keep the assignment of accounted bytes in .bytes_xfered but move it after the completion where we know it has actually happened. Signed-off-by:
-
Linus Walleij authored
The same code is in two places and we will add a third place. Break this out into its own function. Signed-off-by:
-
Linus Walleij authored
Use the scatterlist memory iterator instead of just dereferencing virtual memory using sg_virt(). This make highmem references work properly. Suggested-by:
-
Frank Li authored
iMX95 and iMX8QM have smmu. Add property "iommus". Signed-off-by:
Frank Li <Frank.Li@nxp.com> Acked-by:
-
Ricardo B. Marliere authored
Now that the driver core can properly handle constant struct bus_type, move the memstick_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Suggested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
