All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ali Alaei" <ali.alaei.tabatabaei@gmail.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX
Date: Thu, 04 Jun 2026 19:12:05 +0000	[thread overview]
Message-ID: <20260604191205.905A81F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260604185953.17177-1-ali.alaei.tabatabaei@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unchecked PCI configuration reads can cause device removal or read failures to be treated as a valid configuration (case 3), falsely continuing probe.
--

commit fde973a5965da08fe76816c224c875b5ef1e4a2e
Author: Ali Alaei <ali.alaei.tabatabaei@gmail.com>

PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX

This commit adds support for Intel Arrow Lake-HX platforms where the VMD
controller's VMCONFIG register returns 3 for the BUS_RESTRICT_CFG field,
mapping it to a bus number start of 224.

> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index d4ae250d4bc6d..9cf5ea2e1e20f 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c

[ ... ]

> @@ -648,6 +648,7 @@ static int vmd_get_bus_number_start(struct vmd_dev *vmd)
>  		case 1:
>  			vmd->busn_start = 128;
>  			break;
> +		case 3:

[Severity: Medium]
Does this change unintentionally mask device removal errors?

If the device is removed during probe, pci_read_config_word() does not
necessarily return an error code and the hardware typically returns 0xFFFF.
Because BUS_RESTRICT_CFG(0xFFFF) evaluates to 3, the driver will now treat a
read failure as a valid configuration instead of aborting the probe.

Before this patch, the value 3 hit the default case and safely returned
-ENODEV. Should there be a check to ensure the register value is not 0xFFFF
before evaluating the configuration?

>  		case 2:
>  			vmd->busn_start = 224;
>  			break;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604185953.17177-1-ali.alaei.tabatabaei@gmail.com?part=1

  reply	other threads:[~2026-06-04 19:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-04 18:59 [PATCH] PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX Ali Alaei
2026-06-04 19:12 ` sashiko-bot [this message]
2026-06-04 21:40 ` [PATCH v2] " Ali Alaei
2026-06-22 14:46   ` Manivannan Sadhasivam
2026-06-28 14:34   ` [PATCH v3] " Ali Alaei
2026-06-28 14:46     ` sashiko-bot
2026-07-13 17:16     ` Ali Alaei
2026-07-15  5:56     ` Manivannan Sadhasivam
2026-07-20 22:47     ` Bjorn Helgaas
2026-07-21 12:47       ` Lin Mohan
2026-07-21 12:50       ` Lin Mohan

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=20260604191205.905A81F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=ali.alaei.tabatabaei@gmail.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.