blaster4385/linux-IllusionX/drivers/mmc/core, branch v6.12.10

mmc: core: Add SD card quirk for broken poweroff notification

2024-12-14T19:03:40Z

[ Upstream commit cd068d51594d9635bf6688fc78717572b78bce6a ] GIGASTONE Gaming Plus microSD cards manufactured on 02/2022 report that they support poweroff notification and cache, but they are not working correctly. Flush Cache bit never gets cleared in sd_flush_cache() and Poweroff Notification Ready bit also never gets set to 1 within 1 second from the end of busy of CMD49 in sd_poweroff_notify(). This leads to I/O error and runtime PM error state. I observed that the same card manufactured on 01/2024 works as expected. This problem seems similar to the Kingston cards fixed with commit c467c8f08185 ("mmc: Add MMC_QUIRK_BROKEN_SD_CACHE for Kingston Canvas Go Plus from 11/2019") and should be handled using quirks. CID for the problematic card is here. 12345641535443002000000145016200 Manufacturer ID is 0x12 and defined as CID_MANFID_GIGASTONE as of now, but would like comments on what naming is appropriate because MID list is not public and not sure it's right. Signed-off-by: Keita Aihara Link: https://lore.kernel.org/r/20240913094417.GA4191647@sony.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin

mmc: core: Further prevent card detect during shutdown

2024-12-14T19:03:31Z

commit 87a0d90fcd31c0f36da0332428c9e1a1e0f97432 upstream. Disabling card detect from the host's ->shutdown_pre() callback turned out to not be the complete solution. More precisely, beyond the point when the mmc_bus->shutdown() has been called, to gracefully power off the card, we need to prevent card detect. Otherwise the mmc_rescan work may poll for the card with a CMD13, to see if it's still alive, which then will fail and hang as the card has already been powered off. To fix this problem, let's disable mmc_rescan prior to power off the card during shutdown. Reported-by: Anthony Pighin Fixes: 66c915d09b94 ("mmc: core: Disable card detect during shutdown") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Reviewed-by: Adrian Hunter Closes: https://lore.kernel.org/all/BN0PR08MB695133000AF116F04C3A9FFE83212@BN0PR08MB6951.namprd08.prod.outlook.com/ Tested-by: Anthony Pighin Message-ID: <20241125122446.18684-1-ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman

mmc: core: Use GFP_NOIO in ACMD22

2024-12-14T19:03:11Z

[ Upstream commit 869d37475788b0044bec1a33335e24abaf5e8884 ] While reviewing the SDUC series, Adrian made a comment concerning the memory allocation code in mmc_sd_num_wr_blocks() - see [1]. Prevent memory allocations from triggering I/O operations while ACMD22 is in progress. [1] https://lore.kernel.org/linux-mmc/3016fd71-885b-4ef9-97ed-46b4b0cb0e35@intel.com/ Suggested-by: Adrian Hunter Reviewed-by: Adrian Hunter Fixes: 051913dada04 ("mmc_block: do not DMA to stack") Signed-off-by: Avri Altman Cc: stable@vger.kernel.org Message-ID: <20241021153227.493970-1-avri.altman@wdc.com> Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin

mmc: core: Adjust ACMD22 to SDUC

2024-12-14T19:03:11Z

[ Upstream commit 449f34a34088d02457fa0f3216747e8a35bc03ae ] ACMD22 is used to verify the previously write operation. Normally, it returns the number of written sectors as u32. SDUC, however, returns it as u64. This is not a superfluous requirement, because SDUC writes may exceeds 2TB. For Linux mmc however, the previously write operation could not be more than the block layer limits, thus we make room for a u64 and cast the returning value to u32. Reviewed-by: Adrian Hunter Signed-off-by: Avri Altman Link: https://lore.kernel.org/r/20241006051148.160278-8-avri.altman@wdc.com Signed-off-by: Ulf Hansson [Stephen Rothwell: Fix build error when moving to new rc from Linus's tree] Signed-off-by: Stephen Rothwell Stable-dep-of: 869d37475788 ("mmc: core: Use GFP_NOIO in ACMD22") Signed-off-by: Sasha Levin

mmc: sd: SDUC Support Recognition

2024-12-14T19:03:11Z

[ Upstream commit fce2ce78af1e14dc1316aaddb5b3308be05cf452 ] Ultra Capacity SD cards (SDUC) was already introduced in SD7.0. Those cards support capacity larger than 2TB and up to including 128TB. ACMD41 was extended to support the host-card handshake during initialization. The card expects that the HCS & HO2T bits to be set in the command argument, and sets the applicable bits in the R3 returned response. On the contrary, if a SDUC card is inserted to a non-supporting host, it will never respond to this ACMD41 until eventually, the host will timed out and give up. Also, add SD CSD version 3.0 - designated for SDUC, and properly parse the csd register as the c_size field got expanded to 28 bits. Do not enable SDUC for now - leave it to the last patch in the series. Tested-by: Ricky WU Reviewed-by: Adrian Hunter Signed-off-by: Avri Altman Link: https://lore.kernel.org/r/20241006051148.160278-2-avri.altman@wdc.com Signed-off-by: Ulf Hansson Stable-dep-of: 869d37475788 ("mmc: core: Use GFP_NOIO in ACMD22") Signed-off-by: Sasha Levin

mmc: core: Only set maximum DMA segment size if DMA is supported

2024-10-02T23:23:57Z

Since upstream commit 334304ac2bac ("dma-mapping: don't return errors from dma_set_max_seg_size") calling dma_set_max_seg_size() on a device not supporting DMA results in a warning traceback. This is seen when booting the sifive_u machine from SD. The underlying SPI controller (sifive,spi0 compatible) explicitly sets dma_mask to NULL. Avoid the backtrace by only calling dma_set_max_seg_size() if DMA is supported. Signed-off-by: Guenter Roeck Reviewed-by: Christoph Hellwig Reviewed-by: Robin Murphy Tested-by: Geert Uytterhoeven Fixes: 334304ac2bac ("dma-mapping: don't return errors from dma_set_max_seg_size") Link: https://lore.kernel.org/r/20240924210123.2288529-1-linux@roeck-us.net Signed-off-by: Ulf Hansson

[tree-wide] finally take no_llseek out

2024-09-27T15:18:43Z

no_llseek had been defined to NULL two years ago, in commit 868941b14441 ("fs: remove no_llseek") To quote that commit, At -rc1 we'll need do a mechanical removal of no_llseek - git grep -l -w no_llseek | grep -v porting.rst | while read i; do sed -i '/\/d' $i done would do it. Unfortunately, that hadn't been done. Linus, could you do that now, so that we could finally put that thing to rest? All instances are of the form .llseek = no_llseek, so it's obviously safe. Signed-off-by: Al Viro Signed-off-by: Linus Torvalds

mmc: core: Use dev_err_probe for deferred regulators

2024-09-13T12:09:29Z

In case vmmc or vqmmc regulator is not available yet, use dev_err_probe in order to set a deferred probe reason. This is a helpful hint in /sys/kernel/debug/devices_deferred Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20240911090910.3060749-1-alexander.stein@ew.tq-group.com Signed-off-by: Ulf Hansson

mmc: block: add RPMB dependency

2024-09-03T12:34:44Z

Prevent build error when CONFIG_RPMB=m and CONFIG_MMC_BLOCK=y by adding a dependency to CONFIG_RPMB for CONFIG_MMC_BLOCK block so the RPMB subsystem always is reachable if configured. This means that CONFIG_MMC_BLOCK automatically becomes compiled as a module if CONFIG_RPMB is compiled as a module. If CONFIG_RPMB isn't configured or is configured as built-in, CONFIG_MMC_BLOCK will remain unchanged. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202409021448.RSvcBPzt-lkp@intel.com/ Fixes: 7852028a35f0 ("mmc: block: register RPMB partition with the RPMB subsystem") Signed-off-by: Jens Wiklander Acked-by: Arnd Bergmann Link: https://lore.kernel.org/r/20240902151231.3705204-1-jens.wiklander@linaro.org Signed-off-by: Ulf Hansson

mmc: core Convert UNSTUFF_BITS macro to inline function

2024-09-03T12:34:24Z

The UNSTUFF_BITS macro, which is defined in both drivers/mmc/core/mmc.c and drivers/mmc/core/sd.c, has been converted to an inline function to improve readability, maintainability, and type safety. Signed-off-by: Avri Altman Link: https://lore.kernel.org/r/20240902123331.3566447-1-avri.altman@wdc.com Signed-off-by: Ulf Hansson