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);
>
next prev parent 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