Re: [PATCH v2 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Arnd,

Am 24.06.2022 um 21:10 schrieb Arnd Bergmann:
On Sat, Jun 18, 2022 at 3:06 AM Michael Schmitz <schmitzmic@xxxxxxxxx> wrote:
Am 18.06.2022 um 00:57 schrieb Arnd Bergmann:

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.

Ok, thanks for taking a look here.

drivers/vme/bridges/vme_ca91cx42.c hasn't been used at all on m68k (it
is a PCI-to-VME bridge chipset driver that would be needed on
architectures that natively use a PCI bus). I haven't found anything
that selects that driver, so not sure it is even still in use??

It's gone now, Greg has already taken my patches for this through
the staging tree.

One less to worry about, thanks.

That would allow you to drop the remaining virt_to_bus define from
arch/m68k/include/asm/virtconvert.h.

I could submit a patch to convert the Amiga SCSI drivers to use
virt_to_phys if Geert and the SCSI maintainers think it's worth the churn.

I don't think using virt_to_phys() is an improvement here, as
virt_to_bus() was originally meant as a better abstraction to
replace the use of virt_to_phys() to make drivers portable, before
it got replaced by the dma-mapping interface in turn.

It looks like the Amiga SCSI drivers have an open-coded version of
what dma_map_single() does, to do bounce buffering and cache
management. The ideal solution would be to convert the drivers
actually use the appropriate dma-mapping interfaces and remove
this custom code.

I've taken another look at these drivers' dma_setup() functions and they all look much more complex than the Amiga ESP drivers (which do use the dma-mapping interface for parts of the DMA setup). From my limited understanding, the difference between the ESP and WD33C93 drivers is that the former are used on 040/060 accelerator boards only (where the processor does do bus snooping and DMA can access all of RAM). The latter ones would need cache management, could only use non-coherent mappings and would require special case handling for DMA-inaccessible RAM inside a device-specific dma ops' map_page() function.

That's several bridges too far for me ... I have no Amiga hardware whatsoever, and know no one who could test changes to WD33C93 drivers for me.

What I have is a NCR5380 with the proverbial 'pathological DMA' integration example (and its driver was never changed to even use virt_to_bus()!). I might learn enough about using the dma-mapping API on that one eventually (though the requirement for at least 1 MB swiotlb bounce buffers looks hard to meet), and use that to convert the WD33C93 drivers, but it would still remain untested.

> The same could be done for the two vme drivers (scsi/mvme147.c
and ethernet/82596.c), which do the cache management but
apparently don't need swiotlb bounce buffering.

Rewriting the drivers to modern APIs is of course non-trivial,
and if you want a shortcut here, I would suggest introducing
platform specific helpers similar to isa_virt_to_bus() and call
them amiga_virt_to_bus() and vme_virt_to_bus, respectively.

I don't think Amiga and m68k VME differ at all in that respect, so might just call it m68k_virt_to_bus() for now.

Putting these into a platform specific header file at least helps
clarify that both the helper functions and the drivers using them
are non-portable.

There are no platform specific header files other than asm/amigahw.h and asm/mvme147hw.h, currently only holding register address definitions. Would it be OK to add m68k_virt_to_bus() in there if it can't remain in asm/virtconvert.h, Geert?


32bit powerpc is a different matter though.

It's similar, but unrelated. The two apple ethernet drivers
(bmac and mace) can again either get changed to use the
dma-mapping interfaces, or get a custom pmac_virt_to_bus()/
pmac_bus_to_virt() helper.

Hmmm - I see Finn had done the DMA API conversion on macmace.c which might give some hints on what to do about mace.c ... no idea about bmac.c though. And again, haven't got hardware to test, so custom helpers is it, then.

Cheers,

	Michael

There is also drivers/tty/serial/cpm_uart/cpm_uart_cpm2.c,
which I think just needs a trivial change, but I'm not sure
how to do it correctly.

      Arnd




[Index of Archives]     [Linux SoC]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux