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
