From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793829575; b=q5dmGpQ89cKpF5qZcOfq/nF0XTGgE+zkg80yep8fK/id5A38L8QTXWr8EgAh3yg5r1uW stTFBJmN3firDBj2fPPzgqbg+lGjhFKPoL54LZyueeV9hdceb0Pwrleo2onrnICSR97Mx c65vTTYCUeigKkpD+UVEClfr0JLHQGXsdNlk3h1loWSMjo2cqikJ6ju/KeupnnXvwI0or SE+eK49LFzr8SBBL9hL8ViuDsMqfOCxszpmKakypAqQXXxealFIcGT9FzfpNkxZcOZwCF Erppb1ga+j+W9X71Nl6V51oPiYfAwei9dScSkiO13fKx5AWG2frdhIAknGPjzX2XsyQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793829575; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=wETTdhaRc2JqyP2ItumGgjIb+1SPUW27QuzLleA7XTo=; b=nFPQpORk5EtbrMO6ytzspgmluhbiLEUQWhR0vo++vcUleLe15pO1XeiaOdAbkHNufXrR OFdQ1hJ75IUmX00t5A0RYBmU8y/gYSrqlqSeAOqxY3J1pie+r1wNwrFr7PbdrWq3d3EeS XGgMq5DbVY7zUtksoH3cQSXlk3t18elCd1RRS11FKdOoJme6iFqGaCFqUW8qasEny/XqL wQ41Zdq4ttBMgjtwhNgXq4on1rxEiq6xMrNMizsqDrhCVA1frX89XtdDdlXve1k1B2l57 sYi7B2vsu21u7vWZHTpiUWZAaqtvcRfxxFAX+3LE8R4a2hi0danfstVmC2zkZKPqHig== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b="aEfCT/U+"; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4FB9D606A33E; Wed, 4 Nov 2026 21:59:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=aEfCT/U+ Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5D261F00A02; Wed, 4 Nov 2026 21:59:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1793829575; bh=wETTdhaRc2JqyP2ItumGgjIb+1SPUW27QuzLleA7XTo=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=aEfCT/U+MZxpXYTdH7dxa3qpqdgckSFUllK1rGgAPgbWoOszhQGHShaUYFBjDYi/L /lh2BuuYqId/HRcIkIK8QaOVEV5yRwmFZyHxGag1/CPhdz9Ari6bv3VpyaoRzH4VXw VXl6NsbOrp4i+FC1I+nHJP8KFoct0gmcjflLUnSo= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Lin Mohan , Ali Alaei , Manivannan Sadhasivam , Bjorn Helgaas , Sasha Levin Subject: [PATCH 6.18 0211/1005] PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX Date: Wed, 4 Nov 2026 15:59:04 -0500 Message-ID: <20261104211049.722266497@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261104211043.516122098@linuxfoundation.org> References: <20261104211043.516122098@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: patches@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ali Alaei [ Upstream commit 72b32eccbcd591b9606edacf3bd7c455176d7660 ] On Intel Arrow Lake-HX systems (e.g. Core Ultra 9 275HX on Acer Predator PH16-73), the VMD controller reports BUS_RESTRICT_CFG = 3 in the VMCONFIG register. The existing switch statement only handled values 0, 1, and 2, causing vmd_get_bus_number_start() to return -ENODEV and aborting the entire VMD probe. This leaves NVMe drives behind the VMD controller invisible to the kernel. Hardware registers (VMCAP/VMCONFIG at offsets 0x40/0x44): VMD 0000:00:0e.0 (8086:ad0b): VMCAP=0x000f, VMCONFIG=0x03b8 BUS_RESTRICT_CFG(0x03b8) = (0x03b8 >> 8) & 0x3 = 3 Add cfg=3 as a fallthrough to cfg=2, setting busn_start=224, which is the correct bus number base for this hardware. Also add a PCI_POSSIBLE_ERROR() guard after reading VMCONFIG: a failed config space read returns 0xFFFF, and BUS_RESTRICT_CFG(0xFFFF) = 3, so without this guard a removed or errored device would falsely match the new case 3 instead of being caught as an error. Reported-by: Lin Mohan Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221137 # Arrow-Lake-S Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221136 # Arrow-Lake-S Signed-off-by: Ali Alaei Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260628143450.92492-1-ali.alaei.tabatabaei@gmail.com Signed-off-by: Sasha Levin --- drivers/pci/controller/vmd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c index b4b62b9ccc45a..5d3e6cc7e4feb 100644 --- a/drivers/pci/controller/vmd.c +++ b/drivers/pci/controller/vmd.c @@ -656,6 +656,8 @@ static int vmd_get_bus_number_start(struct vmd_dev *vmd) pci_read_config_word(dev, PCI_REG_VMCAP, ®); if (BUS_RESTRICT_CAP(reg)) { pci_read_config_word(dev, PCI_REG_VMCONFIG, ®); + if (PCI_POSSIBLE_ERROR(reg)) + return -ENODEV; switch (BUS_RESTRICT_CFG(reg)) { case 0: @@ -664,6 +666,7 @@ static int vmd_get_bus_number_start(struct vmd_dev *vmd) case 1: vmd->busn_start = 128; break; + case 3: case 2: vmd->busn_start = 224; break; -- 2.53.0