On Mon, Jun 6, 2022 at 12:40 PM Maciej W. Rozycki <macro@xxxxxxxxxxx> 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
