Messages in this thread | | | Date | Tue, 21 Jun 2022 10:45:52 +0200 | Subject | Re: [PATCH v2 2/3] scsi: BusLogic remove bus_to_virt | From | Hannes Reinecke <> |
| |
On 6/17/22 14:57, 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, which > shows that there are not a lot of users. > > Maciej is still using the driver on 32-bit hardware, and Khalid mentioned > that the driver works with the device emulation used in VirtualBox > and VMware. Both of those only emulate it for Windows 2000 and older > operating systems that did not ship with the better LSI logic driver. > > Do a minimum fix that searches through the list of descriptors to find > one that matches the bus address. This is clearly as inefficient as > was indicated in the code comment about the lack of a bus_to_virt() > replacement. A better fix would likely involve changing out the entire > descriptor allocation for a simpler one, but that would be much > more invasive. > > 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> > --- > drivers/scsi/BusLogic.c | 27 ++++++++++++++++----------- > drivers/scsi/Kconfig | 2 +- > 2 files changed, 17 insertions(+), 12 deletions(-) > > diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c > index a897c8f914cf..d057abfcdd5c 100644 > --- a/drivers/scsi/BusLogic.c > +++ b/drivers/scsi/BusLogic.c > @@ -2515,12 +2515,26 @@ static int blogic_resultcode(struct blogic_adapter *adapter, > return (hoststatus << 16) | tgt_status; > } > > +/* > + * turn the dma address from an inbox into a ccb pointer > + * This is rather inefficient. > + */ > +static struct blogic_ccb * > +blogic_inbox_to_ccb(struct blogic_adapter *adapter, struct blogic_inbox *inbox) > +{ > + struct blogic_ccb *ccb; > + > + for (ccb = adapter->all_ccbs; ccb; ccb = ccb->next_all) > + if (inbox->ccb == ccb->dma_handle) > + break; > + > + return ccb; > +} > > /* > blogic_scan_inbox scans the Incoming Mailboxes saving any > Incoming Mailbox entries for completion processing. > */ > - > static void blogic_scan_inbox(struct blogic_adapter *adapter) > { > /* > @@ -2540,16 +2554,7 @@ static void blogic_scan_inbox(struct blogic_adapter *adapter) > enum blogic_cmplt_code comp_code; > > while ((comp_code = next_inbox->comp_code) != BLOGIC_INBOX_FREE) { > - /* > - We are only allowed to do this because we limit our > - architectures we run on to machines where bus_to_virt( > - actually works. There *needs* to be a dma_addr_to_virt() > - in the new PCI DMA mapping interface to replace > - bus_to_virt() or else this code is going to become very > - innefficient. > - */ > - struct blogic_ccb *ccb = > - (struct blogic_ccb *) bus_to_virt(next_inbox->ccb); > + struct blogic_ccb *ccb = blogic_inbox_to_ccb(adapter, adapter->next_inbox); > if (comp_code != BLOGIC_CMD_NOTFOUND) { > if (ccb->status == BLOGIC_CCB_ACTIVE || > ccb->status == BLOGIC_CCB_RESET) { > diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig > index cf75588a2587..56bdc08d0b77 100644 > --- a/drivers/scsi/Kconfig > +++ b/drivers/scsi/Kconfig > @@ -513,7 +513,7 @@ config SCSI_HPTIOP > > config SCSI_BUSLOGIC > tristate "BusLogic SCSI support" > - depends on PCI && SCSI && VIRT_TO_BUS > + depends on PCI && SCSI > help > This is support for BusLogic MultiMaster and FlashPoint SCSI Host > Adapters. Consult the SCSI-HOWTO, available from
CCB handling in the driver is ugly anyway, so that'll be good enough.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Cheers,
Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@suse.de +49 911 74053 688 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
| |