kernel/linux.git/drivers/mmc/core/queue.c, branch v6.12.80

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

2024-10-02T23:23:57+00:00

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

block: move the stable_writes flag to queue_limits

2024-06-19T13:58:28+00:00

Move the stable_writes flag into the queue_limits feature field so that it can be set atomically with the queue frozen. The flag is now inherited by blk_stack_limits, which greatly simplifies the code in dm, and fixed md which previously did not pass on the flag set on lower devices. Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal Reviewed-by: Hannes Reinecke Link: https://lore.kernel.org/r/20240617060532.127975-18-hch@lst.de Signed-off-by: Jens Axboe

block: move the add_random flag to queue_limits

2024-06-19T13:58:28+00:00

Move the add_random flag into the queue_limits feature field so that it can be set atomically with the queue frozen. Note that this also removes code from dm to clear the flag based on the underlying devices, which can't be reached as dm devices will always start out without the flag set. Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal Reviewed-by: Hannes Reinecke Link: https://lore.kernel.org/r/20240617060532.127975-16-hch@lst.de Signed-off-by: Jens Axboe

block: move the nonrot flag to queue_limits

2024-06-19T13:58:28+00:00

Move the nonrot flag into the queue_limits feature field so that it can be set atomically with the queue frozen. Use the chance to switch to defaulting to non-rotational and require the driver to opt into rotational, which matches the polarity of the sysfs interface. For the z2ram, ps3vram, 2x memstick, ubiblock and dcssblk the new rotational flag is not set as they clearly are not rotational despite this being a behavior change. There are some other drivers that unconditionally set the rotational flag to keep the existing behavior as they arguably can be used on rotational devices even if that is probably not their main use today (e.g. virtio_blk and drbd). The flag is automatically inherited in blk_stack_limits matching the existing behavior in dm and md. Signed-off-by: Christoph Hellwig Reviewed-by: Damien Le Moal Reviewed-by: Hannes Reinecke Link: https://lore.kernel.org/r/20240617060532.127975-15-hch@lst.de Signed-off-by: Jens Axboe

block: move cache control settings out of queue->flags

2024-06-19T13:58:28+00:00

Move the cache control settings into the queue_limits so that the flags can be set atomically with the device queue frozen. Add new features and flags field for the driver set flags, and internal (usually sysfs-controlled) flags in the block layer. Note that we'll eventually remove enough field from queue_limits to bring it back to the previous size. The disable flag is inverted compared to the previous meaning, which means it now survives a rescan, similar to the max_sectors and max_discard_sectors user limits. The FLUSH and FUA flags are now inherited by blk_stack_limits, which simplified the code in dm a lot, but also causes a slight behavior change in that dm-switch and dm-unstripe now advertise a write cache despite setting num_flush_bios to 0. The I/O path will handle this gracefully, but as far as I can tell the lack of num_flush_bios and thus flush support is a pre-existing data integrity bug in those targets that really needs fixing, after which a non-zero num_flush_bios should be required in dm for targets that map to underlying devices. Signed-off-by: Christoph Hellwig Acked-by: Ulf Hansson Reviewed-by: Damien Le Moal Reviewed-by: Hannes Reinecke Link: https://lore.kernel.org/r/20240617060532.127975-14-hch@lst.de Signed-off-by: Jens Axboe

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

2024-03-13T17:59:28+00:00

Pull MMC updates from Ulf Hansson: "MMC core: - Drop the use of BLK_BOUNCE_HIGH - Fix partition switch for GP3 - Remove usage of the deprecated ida_simple API MMC host: - cqhci: Update bouncing email-addresses in MAINTAINERS - davinci_mmc: Use sg_miter for PIO - dw_mmc-hi3798cv200: Convert the DT bindings to YAML - dw_mmc-hi3798mv200: Add driver for the new dw_mmc variant - fsl-imx-esdhc: A couple of corrections/updates to the DT bindings - meson-mx-sdhc: Drop use of the ->card_hw_reset() callback - moxart-mmc: Use sg_miter for PIO - moxart-mmc: Fix accounting for DMA transfers - mvsdio: Use sg_miter for PIO - mxcmmc: Use sg_miter for PIO - omap: Use sg_miter for PIO - renesas,sdhi: Add support for R-Car V4M variant - sdhci-esdhc-mcf: Use sg_miter for swapping - sdhci-of-dwcmshc: Add support for Sophgo CV1800B and SG2002 variants - sh_mmcif: Use sg_miter for PIO - tmio: Avoid concurrent runs of mmc_request_done()" * tag 'mmc-v6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: (44 commits) mmc: core: make mmc_host_class constant mmc: core: Fix switch on gp3 partition mmc: tmio: comment the ERR_PTR usage in this driver mmc: mmc_spi: Don't mention DMA direction mmc: dw_mmc: Remove unused of_gpio.h mmc: dw_mmc: add support for hi3798mv200 dt-bindings: mmc: hisilicon,hi3798cv200-dw-mshc: add Hi3798MV200 binding dt-bindings: mmc: dw-mshc-hi3798cv200: convert to YAML mmc: dw_mmc-hi3798cv200: remove MODULE_ALIAS() mmc: core: Use a struct device* as in-param to mmc_of_parse_clk_phase() mmc: wmt-sdmmc: remove an incorrect release_mem_region() call in the .remove function mmc: tmio: avoid concurrent runs of mmc_request_done() dt-bindings: mmc: fsl-imx-mmc: Document the required clocks mmc: sh_mmcif: Advance sg_miter before reading blocks mmc: sh_mmcif: sg_miter must not be atomic mmc: sdhci-esdhc-mcf: Flag the sg_miter as atomic dt-bindings: mmc: fsl-imx-esdhc: add default and 100mhz state mmc: core: constify the struct device_type usage mmc: sdhci-of-dwcmshc: Add support for Sophgo CV1800B and SG2002 dt-bindings: mmc: sdhci-of-dwcmhsc: Add Sophgo CV1800B and SG2002 support ...

mmc: pass queue_limits to blk_mq_alloc_disk

2024-02-20T00:00:29+00:00

Pass the queue limit set at initialization time directly to blk_mq_alloc_disk instead of updating it right after the allocation. This requires refactoring the code a bit so that what was mmc_setup_queue before also allocates the gendisk now and actually sets all limits. Signed-off-by: Christoph Hellwig Acked-by: Ulf Hansson Link: https://lore.kernel.org/r/20240215070300.2200308-18-hch@lst.de Signed-off-by: Jens Axboe

block: pass a queue_limits argument to blk_mq_alloc_disk

2024-02-13T15:56:59+00:00

Pass a queue_limits to blk_mq_alloc_disk and apply it if non-NULL. This will allow allocating queues with valid queue limits instead of setting the values one at a time later. Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Reviewed-by: John Garry Reviewed-by: Chaitanya Kulkarni Reviewed-by: Ming Lei Reviewed-by: Damien Le Moal Reviewed-by: Martin K. Petersen Reviewed-by: Hannes Reinecke Link: https://lore.kernel.org/r/20240213073425.1621680-11-hch@lst.de Signed-off-by: Jens Axboe

mmc: core Drop BLK_BOUNCE_HIGH

2024-02-13T12:37:28+00:00

The MMC core sets BLK_BOUNCE_HIGH for devices where dma_mask is unassigned. For the majority of MMC hosts this path is never taken: the OF core will unconditionally assign a 32-bit mask to any OF device, and most MMC hosts are probed from device tree, see drivers/of/platform.c: of_platform_device_create_pdata() dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); if (!dev->dev.dma_mask) dev->dev.dma_mask = &dev->dev.coherent_dma_mask; of_amba_device_create() dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); dev->dev.dma_mask = &dev->dev.coherent_dma_mask; MMC devices that are probed from ACPI or PCI will likewise have a proper dma_mask assigned. The only remaining devices that could have a blank dma_mask are platform devices instantiated from board files. These are mostly used on systems without CONFIG_HIGHMEM enabled which means the block layer will not bounce, and in the few cases where it is enabled it is not used anyway: for example some OMAP2 systems such as Nokia n800/n810 will create a platform_device and not assign a dma_mask, however they do not have any highmem, so no bouncing will happen anyway: the block core checks if max_low_pfn >= max_pfn and this will always be false. Should it turn out there is a platform_device with blank DMA mask actually using CONFIG_HIGHMEM somewhere out there we should set dma_mask for it, not do this trickery. Signed-off-by: Linus Walleij Acked-by: Arnd Bergmann Acked-by: Christoph Hellwig Link: https://lore.kernel.org/r/20240125-mmc-no-blk-bounce-high-v1-1-d0f92a30e085@linaro.org Signed-off-by: Ulf Hansson

mmc: core: Allow dynamical updates of the number of requests for hsq

2023-09-27T10:13:18+00:00

To allow dynamical updates of the current number of used in-flight requests, let's move away from using a hard-coded value to a use a corresponding variable in the struct mmc_host. This can be valuable when optimizing for certain I/O request sequences, as shown by subsequent changes. Signed-off-by: Wenchao Chen Link: https://lore.kernel.org/r/20230919074707.25517-2-wenchao.chen@unisoc.com [Ulf: Re-wrote the commitmsg to clarify the change] Signed-off-by: Ulf Hansson