public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: John Garry <john.g.garry@oracle.com>
To: Marek Vasut <marex@denx.de>, linux-scsi@vger.kernel.org
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Bart Van Assche <bvanassche@acm.org>,
	Damien Le Moal <dlemoal@kernel.org>,
	Jason Yan <yanaijie@huawei.com>
Subject: Re: [PATCH v2] scsi: mvsas: Try to enable MSI
Date: Mon, 6 Nov 2023 11:08:12 +0000	[thread overview]
Message-ID: <6f36e52c-e77c-0695-ff33-c4f737430c13@oracle.com> (raw)
In-Reply-To: <20231105183712.26520-1-marex@denx.de>


> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> Note that the "PCI-E x0, Bandwidth Usage: UnKnown Gbps" is due to QEMU
>       vfio-pci VT-d passthrough, for some reason this is what it reports.
>       The issue with PCI MSI happens on real hardware too, this vfio/VT-d
>       is just debugging convenience.
> Note that this would be nice to have in stable series, but I'm reluctant
>       to ask for that in order to avoid breaking other peoples' machines.
>       Maybe a default-off kernel parameter for the mvsas module would be
>       acceptable for stable?
> ---
> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
> Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
> Cc: Bart Van Assche <bvanassche@acm.org>
> Cc: Damien Le Moal <dlemoal@kernel.org>
> Cc: Jason Yan <yanaijie@huawei.com>
> Cc: John Garry <john.g.garry@oracle.com>
> Cc: linux-scsi@vger.kernel.org
> ---
> V2: - Limit the MSI enablement to OCZ devices only
> ---
>   drivers/scsi/mvsas/mv_init.c | 17 +++++++++++++++++
>   1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
> index 43ebb331e2167..d3b1cee6b3252 100644
> --- a/drivers/scsi/mvsas/mv_init.c
> +++ b/drivers/scsi/mvsas/mv_init.c
> @@ -571,6 +571,17 @@ static int mvs_pci_init(struct pci_dev *pdev, const struct pci_device_id *ent)
>   	rc = sas_register_ha(SHOST_TO_SAS_HA(shost));
>   	if (rc)
>   		goto err_out_shost;
> +
> +	/* Try to enable MSI, this is needed at least on OCZ RevoDrive 3 X2 */
> +	if (pdev->vendor == PCI_VENDOR_ID_OCZ) {

PCI_VENDOR_ID_OCZ means 9485. So how about enable MSI for all PCI device 
IDs which use that, which is all OCZ and MARVELL_EXT? I could not get my 
hands on a datasheet for that SoC (could you?), but since all previous 
generations supported MSI, I think that it's a safe bet.

Then, if we do that, instead of repeating this same vendor check, how 
about add a new member to mvs_chip_info to flag whether we need to try 
MSI? For example, it could be mvs_chip_info.use_msi .

> +		rc = pci_enable_msi(mvi->pdev);
> +		if (rc) {
> +			dev_err(&mvi->pdev->dev,
> +				"mvsas: Failed to enable MSI for OCZ device, attached drives may not be detected. rc=%d\n",
> +				rc);

We should fail to load the driver in this case.

> +		}
> +	}
> +
>   	rc = request_irq(pdev->irq, irq_handler, IRQF_SHARED,
>   		DRV_NAME, SHOST_TO_SAS_HA(shost));
>   	if (rc)
> @@ -583,6 +594,9 @@ static int mvs_pci_init(struct pci_dev *pdev, const struct pci_device_id *ent)
>   	return 0;
>   
>   err_not_sas:
> +	if (pdev->vendor == PCI_VENDOR_ID_OCZ)
> +		pci_disable_msi(mvi->pdev);
> +
>   	sas_unregister_ha(SHOST_TO_SAS_HA(shost));
>   err_out_shost:
>   	scsi_remove_host(mvi->shost);
> @@ -607,6 +621,9 @@ static void mvs_pci_remove(struct pci_dev *pdev)
>   	tasklet_kill(&((struct mvs_prv_info *)sha->lldd_ha)->mv_tasklet);
>   #endif
>   
> +	if (pdev->vendor == PCI_VENDOR_ID_OCZ)
> +		pci_disable_msi(mvi->pdev);
> +
>   	sas_unregister_ha(sha);
>   	sas_remove_host(mvi->shost);
>   


  reply	other threads:[~2023-11-06 11:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-05 18:36 [PATCH v2] scsi: mvsas: Try to enable MSI Marek Vasut
2023-11-06 11:08 ` John Garry [this message]
2023-11-06 12:59   ` Marek Vasut
2023-11-06 14:12     ` John Garry
2023-11-06 22:13       ` Damien Le Moal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6f36e52c-e77c-0695-ff33-c4f737430c13@oracle.com \
    --to=john.g.garry@oracle.com \
    --cc=bvanassche@acm.org \
    --cc=dlemoal@kernel.org \
    --cc=jejb@linux.ibm.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=martin.petersen@oracle.com \
    --cc=yanaijie@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox