On Mon, Jan 22, 2024, at 15:57, Arnd Bergmann wrote:
> On Mon, Jan 22, 2024, at 14:39, Christoph Hellwig wrote:
>> On Mon, Jan 22, 2024 at 10:26:30AM +0100, Arnd Bergmann wrote:
>
>> and then kill the bounce setup in
>> mmc. It turn out in addition to the one legacy ISA SCSI driver and the
>> two parport SCSI driver usb-storage actually also sets this flag,
>> which might be a road blocker, but at this point I'm getting ready
>> to just pull the plug if it doesn't break using embedded platforms
>> using mmc entirely.
>
> Agreed. I've added the maintainers for the Marvell Armada
> platform to Cc, maybe one of them can look into this, see
> the thread at [1] for this. The problem in the mvsdio.c
> is the sg_virt(data->sg) in mvsd_setup_data(), which will
> stop working when the MMC layer stops using bounce buffers
> for highmem pages.
I talked to Linus Walleij about this driver, as he's already
looking at highmem related issues in Arm kernels. Here is
some updated information about what I think is going on:
- The driver is used on kirkwood, dove, armadaxp/370, and
armada375, but not on armada380 and later, as those use
sdhci instead.
- Most of the boards with those chips have the sdio controller
disabled. In particular for the later chips it is only
enabled in the reference design but not in products like the
Armada XP based NAS boxes.
- Products that actually use it and have at least 1GB of RAM
are the Globalscale Mirabox/D3Plug and Solidrun Cubox.
- All of the machines using this driver have a valid DMA mask
set, so the BLK_BOUNCE_HIGH hack is never actually active
here.
- The reason I think the driver still works is that the
PIO mode using the broken sg_virt() call is only used
for unaligned data, and all data sent to the controller is
either fully aligned (mmc block data) or in lowmem (sdio
data structures filled in the kernel).
- The hack for non-caheline-aligned DMA in commit 3c583f70a8e2
("mmc: mvsdio: Work around broken TX DMA") specifically
mentions small data structures. I wonder if this is instead
a bug with dma_mapping stack variables or similar instead of
an actual hardware bug. The only sdio_writesb() I see in the
mwifiex driver mentioned here is for network data buffers,
which I think don't ever share cache lines though.
Arnd
