On Mon, Jan 22, 2024 at 10:26 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > 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. For sh_mmcif I just added dma_mask and coherent_dma_mask as DMA_BIT_MASK(32) in the boardfile and I consider doing it for pretty much all of them: If they - Run without HIGHMEM enabled and - With highmem are bouncing buffers around to PKMAP (right?) when BLK_BOUNCE_HIGH is set That kind of indicates that they are probably 32bit DMA capable, pretty much as the device trees assumes in most cases. This avoids doing Kconfig trickery, make it runtime handled and we can delete BLK_BOUNCE_HIGH as that branch is never taken and just refuse to probe if dma_mask == 0. Yours, Linus Walleij
