Re: [PATCH 5/6] scsi: remove stale BusLogic driver
On Mon, Jun 6, 2022 at 6:35 PM Khalid Aziz wrote: > On 6/6/22 02:41, Arnd Bergmann wrote: From: Arnd Bergmann > > 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 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/6] scsi: remove stale BusLogic driver
On 6/6/22 02:41, Arnd Bergmann wrote: From: Arnd Bergmann 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 Cc: Matt Wang Cc: Khalid Aziz Signed-off-by: Arnd Bergmann --- 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 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/6] scsi: remove stale BusLogic driver
On Mon, Jun 6, 2022 at 12:40 PM Maciej W. Rozycki 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 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/6] scsi: remove stale BusLogic driver
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 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu