On Tue, Mar 22, 2022 at 12:06 AM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > On Mon, 21 Mar 2022 23:10:32 +0100 Arnd Bergmann wrote: > > On Mon, Mar 21, 2022 at 10:40 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > > The driver for LAN Media WAN interfaces spews build warnings on > > > microblaze. > > > > > > CCing usual suspects and people mentioned as authors in the source code. > > > > > > As far as I can tell it has no maintainer. > > > > > > It has also received not received a single functional change that'd > > > indicate someone owns this HW since the beginning of the git era. > > > > > > Can we remove this driver or should we invest effort into fixing it? > > > > I have not seen the exact error, but I suspect the problem is that > > microblaze selects CONFIG_VIRT_TO_BUS without actually > > providing those interfaces. The easy workaround would be to > > have microblaze not select that symbol. > > FWIW the warning is that virt_to_bus() discards the __iomem qualifier. > I think it's a macro on most platforms but not microblaze. > Anyway, some approximation of "VIRT_TO_BUS on mircoblaze is broken" > sounds right. Ok, I've reproduced it now, and I see that microblaze gets the virt_to_bus() definition from include/asm-generic/io.h. The definition is in fact correct, though arguably microblaze (also h8300 and xtensa, probably more) should not set CONFIG_VIRT_TO_BUS anyway because they do not use PCI hardware from the 1990s. The warning that I get is actually about the descriptor pointers being marked 'volatile' (not '__iomem') and used as normal pointers when passed to virt_to_bus(). Not sure whether the volatile here is correct or not, but either removing it from lmc or adding it to the virt_to_bus() prototype would avoid the warning. > > Drivers using virt_to_bus() are inherently nonportable because > > they don't work on architectures that use an IOMMU or swiotlb, > > or that require cache maintenance for DMA operations. > > > > $ git grep -wl virt_to_bus drivers/ > > drivers/atm/ambassador.c > > drivers/atm/firestream.c > > drivers/atm/horizon.c > > drivers/atm/zatm.c > > drivers/block/swim3.c > > drivers/gpu/drm/mga/mga_dma.c > > drivers/net/appletalk/ltpc.c > > drivers/net/ethernet/amd/au1000_eth.c > > drivers/net/ethernet/amd/ni65.c > > drivers/net/ethernet/apple/bmac.c > > drivers/net/ethernet/apple/mace.c > > drivers/net/ethernet/dec/tulip/de4x5.c > > drivers/net/ethernet/i825xx/82596.c > > drivers/net/ethernet/i825xx/lasi_82596.c > > drivers/net/ethernet/i825xx/lib82596.c > > drivers/net/hamradio/dmascc.c > > drivers/net/wan/cosa.c > > drivers/net/wan/lmc/lmc_main.c > > drivers/net/wan/z85230.c > > drivers/scsi/3w-xxxx.c > > drivers/scsi/a2091.c > > drivers/scsi/a3000.c > > drivers/scsi/dpt_i2o.c > > drivers/scsi/gvp11.c > > drivers/scsi/mvme147.c > > drivers/scsi/qla1280.c > > drivers/tty/serial/cpm_uart/cpm_uart_cpm2.c > > drivers/vme/bridges/vme_ca91cx42.c > > > > Among the drivers/net/wan/ drivers, I think lmc is actually > > one of the newer pieces of hardware, most of the other ones > > appear to even predate PCI. > > You know what's even newer than lmc? Me :S This HW is so old > many of us have never interacted with these technologies directly. > > How do we start getting rid of this stuff? Should we send out patches > to delete anything that's using virt_to_bus() under net|atm and see > which ones don't get shot down? I found the email from Martin Schiller that gives some background on how hdlc/x25 is being used: https://lore.kernel.org/lkml/407acd92c92c3ba04578da89b1a0f191@xxxxxxxxxx/ In short (and confirmed by Krzysztof's reply), most of the hdlc wan hardware has been obsolete, but the subsystem itself is still used with out-of-tree drivers. The situation for ATM is similar IIRC, as nobody uses actual ATM is pretty much obsolete (I don't know how common it is in practice) but DSL is still widely used. I think we can probably come up with a set of atm, wan and appletalk drivers that use either an ISA bus or the virt_to_bus() interface as a starting point for a mass removal. From what I can tell, the majority of the drivers using virt_to_bus() are platform specific already, mostly m68k, and rooting out virt_to_bus() from all platform-independent drivers would be good. Arnd
