Re: [PATCH v2 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2022-06-28 07:12:34
Also in:
linux-alpha, linux-arch, linux-iommu, linux-m68k, linux-scsi, lkml
Hi Michael, On Tue, Jun 28, 2022 at 5:26 AM Michael Schmitz [off-list ref] wrote:
Am 28.06.2022 um 09:12 schrieb Michael Schmitz:quoted
On 27/06/22 20:26, Geert Uytterhoeven wrote:quoted
On Sat, Jun 18, 2022 at 3:06 AM Michael Schmitz [off-list ref] wrote:quoted
Am 18.06.2022 um 00:57 schrieb Arnd Bergmann:quoted
From: Arnd Bergmann <arnd@arndb.de> All architecture-independent users of virt_to_bus() and bus_to_virt() have been fixed to use the dma mapping interfaces or have been removed now. This means the definitions on most architectures, and the CONFIG_VIRT_TO_BUS symbol are now obsolete and can be removed. The only exceptions to this are a few network and scsi drivers for m68k Amiga and VME machines and ppc32 Macintosh. These drivers work correctly with the old interfaces and are probably not worth changing.The Amiga SCSI drivers are all old WD33C93 ones, and replacing virt_to_bus by virt_to_phys in the dma_setup() function there would cause no functional change at all.FTR, the sgiwd93 driver use dma_map_single().Thanks! From what I see, it doesn't have to deal with bounce buffers though?Leaving the bounce buffer handling in place, and taking a few other liberties - this is what converting the easiest case (a3000 SCSI) might look like. Any obvious mistakes? The mvme147 driver would be very similar to handle (after conversion to a platform device).
Thanks, looks reasonable.
The driver allocates bounce buffers using kmalloc if it hits an unaligned data buffer - can such buffers still even happen these days?
No idea.
If I understand dma_map_single() correctly, the resulting dma handle would be equally misaligned? To allocate a bounce buffer, would it be OK to use dma_alloc_coherent() even though AFAIU memory used for DMA buffers generally isn't consistent on m68k? Thinking ahead to the other two Amiga drivers - I wonder whether allocating a static bounce buffer or a DMA pool at driver init is likely to succeed if the kernel runs from the low 16 MB RAM chunk? It certainly won't succeed if the kernel runs from a higher memory address, so the present bounce buffer logic around amiga_chip_alloc() might still need to be used here. Leaves the question whether converting the gvp11 and a2091 drivers is actually worth it, if bounce buffers still have to be handled explicitly.
A2091 should be straight-forward, as A3000 is basically A2091 on the
motherboard (comparing the two drivers, looks like someone's been
sprinkling mb()s over the A3000 driver).
I don't have any of these SCSI host adapters (not counting the A590
(~A2091) expansion of the old A500, which is not Linux-capable, and
hasn't been powered on for 20 years).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds