| Message ID | 20220606084109.4108188-1-arnd@kernel.org |
|---|---|
| Headers | show |
| Series | phase out CONFIG_VIRT_TO_BUS | expand |
On Mon, 6 Jun 2022, Arnd Bergmann wrote: > This was in turn fixed in commit 56f396146af2 ("scsi: BusLogic: Fix > 64-bit system enumeration error for Buslogic"), 8 years later. > > The fact that this was found at all is an indication that there are > users, and it seems that Maciej, Matt and Khalid all have access to > this hardware, but if it took eight years to find the problem, > it's likely that nobody actually relies on it. Umm, I use it with a 32-bit system, so it would be quite an issue for me to discover a problem with 64-bit configurations. And I quite rely on this system for various stuff too! > Remove it as part of the global virt_to_bus()/bus_to_virt() removal. > If anyone is still interested in keeping this driver, the alternative > is to stop it from using bus_to_virt(), possibly along the lines of > how dpt_i2o gets around the same issue. Thanks for the pointer and for cc-ing me. Please refrain from removing the driver at least for this release cycle and let me fix it. It should be easy to mimic what I did for the defza driver: all bus addresses in the DMA API come associated with virtual addresses, so it is just a matter of recording those somewhere for later use rather than trying to mess up with bus addresses to figure out a reverse mapping. Maciej
On Mon, Jun 6, 2022 at 12:40 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote: > > On Mon, 6 Jun 2022, Arnd Bergmann wrote: > > > This was in turn fixed in commit 56f396146af2 ("scsi: BusLogic: Fix > > 64-bit system enumeration error for Buslogic"), 8 years later. > > > > The fact that this was found at all is an indication that there are > > users, and it seems that Maciej, Matt and Khalid all have access to > > this hardware, but if it took eight years to find the problem, > > it's likely that nobody actually relies on it. > > Umm, I use it with a 32-bit system, so it would be quite an issue for me > to discover a problem with 64-bit configurations. And I quite rely on > this system for various stuff too! Ok, good to know. > > Remove it as part of the global virt_to_bus()/bus_to_virt() removal. > > If anyone is still interested in keeping this driver, the alternative > > is to stop it from using bus_to_virt(), possibly along the lines of > > how dpt_i2o gets around the same issue. > > Thanks for the pointer and for cc-ing me. Please refrain from removing > the driver at least for this release cycle and let me fix it. Sure, no problem. It looks like I forgot to actually Cc you on the series as I had meant to, glad it reached you anyway. > It should be easy to mimic what I did for the defza driver: all bus addresses in > the DMA API come associated with virtual addresses, so it is just a matter of > recording those somewhere for later use rather than trying to mess up with > bus addresses to figure out a reverse mapping. I looked at the defza driver and that one appears simpler to me, as you can look up the virtual address from an index, but it's possible I missed what you do here. I meant specifically the calculation added by commit 67af2b060e02 ("[SCSI] dpt_i2o: move from virt_to_bus/bus_to_virt to dma_alloc_coherent") in the dpt_i2o driver that can be used to compute the virtual address. If something simpler works as well, that is of course better. Arnd
On 6/6/22 02:41, Arnd Bergmann wrote: > From: Arnd Bergmann<arnd@arndb.de> > > The BusLogic driver is the last remaining driver that relies on the > deprecated bus_to_virt() function, which in turn only works on a few > architectures, and is incompatible with both swiotlb and iommu support. > > Before commit 391e2f25601e ("[SCSI] BusLogic: Port driver to 64-bit."), > the driver had a dependency on x86-32, presumably because of this > problem. However, the change introduced another bug that made it still > impossible to use the driver on any 64-bit machine. > > This was in turn fixed in commit 56f396146af2 ("scsi: BusLogic: Fix > 64-bit system enumeration error for Buslogic"), 8 years later. > > The fact that this was found at all is an indication that there are > users, and it seems that Maciej, Matt and Khalid all have access to > this hardware, but if it took eight years to find the problem, > it's likely that nobody actually relies on it. > > Remove it as part of the global virt_to_bus()/bus_to_virt() removal. > If anyone is still interested in keeping this driver, the alternative > is to stop it from using bus_to_virt(), possibly along the lines of > how dpt_i2o gets around the same issue. > > Cc: Maciej W. Rozycki<macro@orcam.me.uk> > Cc: Matt Wang<wwentao@vmware.com> > Cc: Khalid Aziz<khalid@gonehiking.org> > Signed-off-by: Arnd Bergmann<arnd@arndb.de> > --- > Documentation/scsi/BusLogic.rst | 581 --- > Documentation/scsi/FlashPoint.rst | 176 - > MAINTAINERS | 7 - > drivers/scsi/BusLogic.c | 3727 -------------- > drivers/scsi/BusLogic.h | 1284 ----- > drivers/scsi/FlashPoint.c | 7560 ----------------------------- > drivers/scsi/Kconfig | 24 - > 7 files changed, 13359 deletions(-) > delete mode 100644 Documentation/scsi/BusLogic.rst > delete mode 100644 Documentation/scsi/FlashPoint.rst > delete mode 100644 drivers/scsi/BusLogic.c > delete mode 100644 drivers/scsi/BusLogic.h > delete mode 100644 drivers/scsi/FlashPoint.c I would say no to removing BusLogic driver. Virtualbox is another consumer of this driver. This driver is very old but I would rather fix the issues than remove it until we do not have any users. Thanks, Khalid
On Mon, 6 Jun 2022 at 10:25, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > On Mon, Jun 06, 2022 at 10:41:03AM +0200, Arnd Bergmann wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > > > The virt_to_bus/bus_to_virt interface has been deprecated for > > decades. After Jakub Kicinski put a lot of work into cleaning out the > > network drivers using them, there are only a couple of other drivers > > left, which can all be removed or otherwise cleaned up, to remove the > > old interface for good. > > > > Any out of tree drivers using virt_to_bus() should be converted to > > using the dma-mapping interfaces, typically dma_alloc_coherent() > > or dma_map_single()). > > > > There are a few m68k and ppc32 specific drivers that keep using the > > interfaces, but these are all guarded with architecture-specific > > Kconfig dependencies, and are not actually broken. > > > > There are still a number of drivers that are using virt_to_phys() > > and phys_to_virt() in place of dma-mapping operations, and these > > are often broken, but they are out of scope for this series. > > I'll take patches 1 and 2 right now through my staging tree if that's > ok. > Hi, I'd love to say that I could fix this stuff up, however I've lacked access to suitable hardware for a long time now and don't foresee that changing any time soon... Martyn > thanks, > > greg k-h >
On Mon, Jun 6, 2022 at 6:35 PM Khalid Aziz <khalid@gonehiking.org> wrote: > On 6/6/22 02:41, Arnd Bergmann wrote: From: Arnd Bergmann<arnd@arndb.de> > > I would say no to removing BusLogic driver. Virtualbox is another > consumer of this driver. This driver is very old but I would rather fix > the issues than remove it until we do not have any users. Maciej already offered to help fix the driver, so I think it will be ok. On the other hand, it sounds like VirtualBox users should not actually try to use the BusLogic driver with modern Linux guests. From what I can tell from the documentation [1], VirtualBox only provides this emulation because it was shipped with early versions of VMware and is supported by Windows 2000 and earlier, but not actually on any modern Windows guest. The VMware documentation in turn explicitly says that BusLogic does not work with 64-bit guests [2], presumably this applies to both Windows and Linux guests. Arnd [1] https://www.virtualbox.org/manual/ch05.html#harddiskcontrollers [2] https://kb.vmware.com/s/article/2010470
From: Arnd Bergmann <arnd@arndb.de> The virt_to_bus/bus_to_virt interface has been deprecated for decades. After Jakub Kicinski put a lot of work into cleaning out the network drivers using them, there are only a couple of other drivers left, which can all be removed or otherwise cleaned up, to remove the old interface for good. Any out of tree drivers using virt_to_bus() should be converted to using the dma-mapping interfaces, typically dma_alloc_coherent() or dma_map_single()). There are a few m68k and ppc32 specific drivers that keep using the interfaces, but these are all guarded with architecture-specific Kconfig dependencies, and are not actually broken. There are still a number of drivers that are using virt_to_phys() and phys_to_virt() in place of dma-mapping operations, and these are often broken, but they are out of scope for this series. Arnd Cc: Jakub Kicinski <kuba@kernel.org> Cc: Christoph Hellwig <hch@infradead.org> # dma-mapping Cc: Marek Szyprowski <m.szyprowski@samsung.com> # dma-mapping Cc: Robin Murphy <robin.murphy@arm.com> # dma-mapping Cc: iommu@lists.linux-foundation.org Cc: Khalid Aziz <khalid@gonehiking.org> # buslogic Cc: linux-scsi@vger.kernel.org Cc: Manohar Vanga <manohar.vanga@gmail.com> # vme Cc: Martyn Welch <martyn@welchs.me.uk> # vme Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> # vme Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-arch@vger.kernel.org Cc: linux-alpha@vger.kernel.org Cc: linux-m68k@lists.linux-m68k.org Cc: linux-parisc@vger.kernel.org Cc: Denis Efremov <efremov@linux.com> # floppy Arnd Bergmann (6): vme: remove ca91cx42 Universe-II support vme: move back to staging media: sta2x11: remove VIRT_TO_BUS dependency scsi: dpt_i2o: drop stale VIRT_TO_BUS dependency scsi: remove stale BusLogic driver arch/*/: remove CONFIG_VIRT_TO_BUS .../core-api/bus-virt-phys-mapping.rst | 220 - Documentation/core-api/dma-api-howto.rst | 14 - Documentation/core-api/index.rst | 1 - Documentation/driver-api/vme.rst | 4 +- Documentation/scsi/BusLogic.rst | 581 -- Documentation/scsi/FlashPoint.rst | 176 - .../translations/zh_CN/core-api/index.rst | 1 - MAINTAINERS | 11 +- arch/alpha/Kconfig | 1 - arch/alpha/include/asm/floppy.h | 2 +- arch/alpha/include/asm/io.h | 8 +- arch/ia64/Kconfig | 1 - arch/ia64/include/asm/io.h | 8 - arch/m68k/Kconfig | 1 - arch/m68k/include/asm/virtconvert.h | 4 +- arch/microblaze/Kconfig | 1 - arch/microblaze/include/asm/io.h | 2 - arch/mips/Kconfig | 1 - arch/mips/include/asm/io.h | 9 - arch/parisc/Kconfig | 1 - arch/parisc/include/asm/floppy.h | 4 +- arch/parisc/include/asm/io.h | 2 - arch/powerpc/Kconfig | 1 - arch/powerpc/include/asm/io.h | 2 - arch/riscv/include/asm/page.h | 1 - arch/x86/Kconfig | 1 - arch/x86/include/asm/io.h | 9 - arch/xtensa/Kconfig | 1 - arch/xtensa/include/asm/io.h | 3 - drivers/Kconfig | 2 - drivers/Makefile | 1 - drivers/media/pci/sta2x11/Kconfig | 2 +- drivers/scsi/BusLogic.c | 3727 -------- drivers/scsi/BusLogic.h | 1284 --- drivers/scsi/FlashPoint.c | 7560 ----------------- drivers/scsi/Kconfig | 26 +- drivers/scsi/dpt_i2o.c | 4 +- drivers/staging/vme_user/Kconfig | 27 + drivers/staging/vme_user/Makefile | 3 + drivers/{vme => staging/vme_user}/vme.c | 2 +- .../linux => drivers/staging/vme_user}/vme.h | 0 .../{vme => staging/vme_user}/vme_bridge.h | 2 +- .../bridges => staging/vme_user}/vme_fake.c | 4 +- .../bridges => staging/vme_user}/vme_tsi148.c | 4 +- .../bridges => staging/vme_user}/vme_tsi148.h | 0 drivers/staging/vme_user/vme_user.c | 2 +- drivers/vme/Kconfig | 18 - drivers/vme/Makefile | 8 - drivers/vme/boards/Kconfig | 10 - drivers/vme/boards/Makefile | 6 - drivers/vme/boards/vme_vmivme7805.c | 106 - drivers/vme/boards/vme_vmivme7805.h | 33 - drivers/vme/bridges/Kconfig | 24 - drivers/vme/bridges/Makefile | 4 - drivers/vme/bridges/vme_ca91cx42.c | 1928 ----- drivers/vme/bridges/vme_ca91cx42.h | 579 -- include/asm-generic/io.h | 14 - mm/Kconfig | 8 - 58 files changed, 54 insertions(+), 16405 deletions(-) delete mode 100644 Documentation/core-api/bus-virt-phys-mapping.rst delete mode 100644 Documentation/scsi/BusLogic.rst delete mode 100644 Documentation/scsi/FlashPoint.rst delete mode 100644 drivers/scsi/BusLogic.c delete mode 100644 drivers/scsi/BusLogic.h delete mode 100644 drivers/scsi/FlashPoint.c rename drivers/{vme => staging/vme_user}/vme.c (99%) rename {include/linux => drivers/staging/vme_user}/vme.h (100%) rename drivers/{vme => staging/vme_user}/vme_bridge.h (99%) rename drivers/{vme/bridges => staging/vme_user}/vme_fake.c (99%) rename drivers/{vme/bridges => staging/vme_user}/vme_tsi148.c (99%) rename drivers/{vme/bridges => staging/vme_user}/vme_tsi148.h (100%) delete mode 100644 drivers/vme/Kconfig delete mode 100644 drivers/vme/Makefile delete mode 100644 drivers/vme/boards/Kconfig delete mode 100644 drivers/vme/boards/Makefile delete mode 100644 drivers/vme/boards/vme_vmivme7805.c delete mode 100644 drivers/vme/boards/vme_vmivme7805.h delete mode 100644 drivers/vme/bridges/Kconfig delete mode 100644 drivers/vme/bridges/Makefile delete mode 100644 drivers/vme/bridges/vme_ca91cx42.c delete mode 100644 drivers/vme/bridges/vme_ca91cx42.h