On Thu, Jul 27, 2023 at 08:35:06AM +0100, John Garry wrote: > On 27/07/2023 02:15, Ming Lei wrote: > > > > hisi_sas_v3_hw.c > > > > +++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c > > > > @@ -2550,6 +2550,9 @@ static int interrupt_preinit_v3_hw(struct hisi_hba *hisi_hba) > > > > hisi_hba->cq_nvecs = vectors - BASE_VECTORS_V3_HW - hisi_hba->iopoll_q_cnt; > > > > + if (hisi_hba->cq_nvecs > scsi_max_nr_hw_queues()) > > > > + hisi_hba->cq_nvecs = scsi_max_nr_hw_queues(); > > > > + > > > > shost->nr_hw_queues = hisi_hba->cq_nvecs + hisi_hba->iopoll_q_cnt; > > > For other drivers you limit the max MSI vectors which we try to allocate > > > according to scsi_max_nr_hw_queues(), but here you continue to alloc the > > > same max vectors but then limit the driver's completion queue count. Why not > > > limit the max MSI vectors also here? > > Ah, checking again, I think that this driver always allocates maximum > possible MSI due to arm interrupt controller driver bug - see comment at top > of function interrupt_preinit_v3_hw(). IIRC, there was a problem if we > remove and re-insert the device driver that the GIC ITS fails to allocate > MSI unless all MSI were previously allocated. My question is actually why hisi_hba->iopoll_q_cnt is subtracted from allocated vectors since io poll queues does _not_ use msi vector. So it isn't related with driver's msi vector allocation bug, is it? Thanks, Ming
