On Mon, Jan 22, 2024, at 08:34, Christoph Hellwig wrote:
> On Mon, Jan 15, 2024 at 12:20:50PM +0100, Ulf Hansson wrote:
>> Not sure exactly what problem you are trying to solve here, but I am
>> certainly happy to help, if I can.
>>
>> Can you perhaps point me to a couple of drivers that need to be converted?
>
> Sure.
>
> mmc_alloc_disk sets BLK_BOUNCE_HIGH for any mmc host that doesn't have a
> DMA mask set, which is a bit odd as all proper devices should have a
> valid DMA mask. I suspect platform devices might sometimes not have
> one, which historically was the wild west.
I found five drivers that have a legacy platform device
definition without a DMA mask:
arch/m68k/coldfire/device.c: "sdhci-esdhc-mcf"
arch/arm/mach-omap1/devices.c: "mmci-omap" (slave DMA)
arch/sh/boards/board-sh7757lcr.c: "sh_mmcif" (slave DMA)
arch/sh/boards/mach-ecovec24/setup.c: sh_mmcif" (slave DMA)
arch/sh/boards/mach-*/setup.c: "sh_mobile_sdhi" (slave DMA)
drivers/misc/cb710/core.c: "cb710-mmc" (pio-only)
None of these embedded platforms actually have highmem,
though the omap1 machine may run a kernel that has highmem
support enabled.
Most of the others only support DT based probing after we
removed a lot of old board files a year ago, so they will
always have a 32-bit mask set at probe time.
The slave DMA case is interesting,
> A better indicator might be the use of page_address in the I/O path,
> which usually comes in the form of using the sg_virt() helper.
> For drivers/mmc/ that seems to be: davinci_mmc, moxart-mmc, mvsdio,
> mxcmmc, omap, sdhci-esdhc-mcf and sh_mmcif.
Out of these, I think only the mvsdio one is actually use
on boards with highmem: davinci, moxart, mcx (imx3) and omap2
are old enough to never have had more than 256MB or so of RAM,
and mcf (m68k) and sh can't even be built with CONFIG_HIGHMEM.
Arnd
