From nobody Sat Oct 24 20:42:54 2026 Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F7F9390600; Sun, 11 Oct 2026 19:02:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791745340; cv=none; b=NyegxG0Li+gfqnlJKeWTfijTY8Rl+pXwVj/Go0/4LxsX071TLfgd5TyjQoK+6+kMuc17gMnaJyx8zlg0isFui673jO6ZMoYSZQc6flmHRAEWm3vhCGM1hxBSpVdG1Hlu9uwaZHToanBbUSx8NmF9M8QA5+SuAuKxHkRCFsfi6ss= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791745340; c=relaxed/simple; bh=GXMxAQ0oomRQDquDMHM5zq4YEEzq94Rnx+YqZoolgEI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=u8rsfLENcob0i0eKgVlR1Rl10FZZBeoyX8mBDh5KmvHpDOZmUcRig9KmIpsgg/093jAK52EzCxMcCzH9Epi6c68s4Z39DnUazrgMW4xXTkWZfn/SMSXRUOQdnlzaaHUqU6XnjUu0TBm3qZIE9nApCoaQi4TwJSKPcdEaUWvHuDc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org; spf=pass smtp.mailfrom=mailbox.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b=qLvfDEKO; arc=none smtp.client-ip=80.241.56.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mailbox.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b="qLvfDEKO" Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519MLKEM768 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4j2qhy0FWfzMlPN; Sun, 11 Oct 2026 21:02:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1791745330; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Q/Hn6xj3FRPjQ3cFYoHb+hNfCUOuBV5bvsCl69uhV4c=; b=qLvfDEKOK+AHaTfh3/jiDOhW9Q2Z2BZ/ZZcBqcfGgoolSfHRCCOpDTxnLJH7nImAxJhxuo ZWVhY77QB0LanZArB5y0sIdJlkufa6G1IaVsZeL9g+T1io/pklT4OeS9Uzozr6ioTO3rYe 4WyUATOMrdzoxl8EsA3Do1A2Tzx2h0j2xlo08Yf58UlFTvYoVXtpGamQdsUxShJ6FFiXWx KZBPi/cosAj7kgPHZU+nmG5Fpolo/v5nm1JQY6senNXcRvvdxfSyAwp+bSOknMLtdE4zG7 u+o+jVStYU1vg4jecKL84Vq9l6IvHosX1WtO9MmNmrIBnPFLs7f6oJBTdMXvRw== From: Alexander Gruhlke To: Bjorn Helgaas Cc: Lukas Wunner , "Rafael J . Wysocki" , Alex Williamson , Hui Wang , Linux-Fan , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, regressions@lists.linux.dev, Alexander Gruhlke Subject: [PATCH v3 1/2] PCI: Ignore Immediate Readiness on Samsung 990 PRO NVMe Date: Sun, 11 Oct 2026 21:01:44 +0200 Message-ID: <20261011190145.23621-2-gruhlke@mailbox.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261011190145.23621-1-gruhlke@mailbox.org> References: <20261011190145.23621-1-gruhlke@mailbox.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-MBO-RS-META: a49y3m7m95iqyjub9wjbwwdcb3jb1k3p X-MBO-RS-ID: 63c636e6d683b28b9df Content-Type: text/plain; charset="utf-8" The Samsung 990 PRO [144d:a80c] advertises Immediate Readiness, so pcie_flr() doesn't wait after FLR, but the drive returns ~0 for up to 7 ms. Since commit 10baa9b4df40 ("PCI: Drop unnecessary retries when restoring BARs"), the config restore after FLR is lost, which breaks VFIO passthrough of the drive. Firmware 8B2QJXD7 responds right after FLR, but older firmware such as 1B2QJXD7 doesn't, and the firmware version isn't visible here. Ignore Immediate Readiness on this device, so pcie_flr() waits. Fixes: 10baa9b4df40 ("PCI: Drop unnecessary retries when restoring BARs") Link: https://bbs.archlinux.org/viewtopic.php?id=3D314833 Link: https://lore.kernel.org/r/20261010160529.27974-1-gruhlke@mailbox.org Suggested-by: Lukas Wunner Assisted-by: Claude:claude-opus-5-5 Reviewed-by: Lukas Wunner Signed-off-by: Alexander Gruhlke --- drivers/pci/quirks.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 0500d5fd4f..e8597d1209 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -5623,6 +5623,17 @@ static void quirk_no_flr_snet(struct pci_dev *dev) } DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SOLIDRUN, 0x1000, quirk_no_flr_snet); =20 +/* Samsung 990 PRO advertises Immediate Readiness, but isn't ready after F= LR */ +static void quirk_no_imm_ready(struct pci_dev *dev) +{ + if (!dev->imm_ready) + return; + + pci_info(dev, "Ignoring incorrectly advertised Immediate Readiness suppor= t\n"); + dev->imm_ready =3D 0; +} +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SAMSUNG, 0xa80c, quirk_no_imm_ready); + static void quirk_no_ext_tags(struct pci_dev *pdev) { struct pci_host_bridge *bridge =3D pci_find_host_bridge(pdev->bus); --=20 2.56.0 From nobody Sat Oct 24 20:42:54 2026 Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4FE86451982; Sun, 11 Oct 2026 19:02:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791745337; cv=none; b=rVpi7h6tulj7p+gMhnO8Ef28hgUqvp4CUifdfrQRkm39uUtYG+o2T3Md0rHVfRgL4mrCtce03xkMnoMzhTZUhRgjkVRO060AJwn+lzrbTY5W4vZH0gXWmE9vAmzddjVJIQ/CYWlqKY8+YEMkxEEnJNFABcYI+SveDWaBvtOsF54= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791745337; c=relaxed/simple; bh=MHxlrs8yNHN8FujBwBQKjzVgs3IhjQN55tOEKo1WdHQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Mj98xV74S5NdCqF/5nYybuAvHTVwKsYmpjuOqrVoGtQU3u69Mx4UepeEiV2fhYIjI10CnW+dOs8hkUn5REBmLAEA3wS9Wghhdc5XNcpmZf/k+CTOxBhlAeSgLZOcBKWnjbB/ptip9NEHj94WGCdbF5LpMq5ceTeMZfwTeouryv4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org; spf=pass smtp.mailfrom=mailbox.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b=xi5FHoHA; arc=none smtp.client-ip=80.241.56.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mailbox.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b="xi5FHoHA" Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519MLKEM768 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4j2qhz60qCzMlQ3; Sun, 11 Oct 2026 21:02:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1791745331; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KQOotMRD1xTxlw0GzaibAnBuTjzP2tVA00ijOKzUXWs=; b=xi5FHoHA2VFJFM/8nsH7ry4JFBrdfSf7EhebScVzj86qD/YZYPB0SqcxXjJVvwJyoKyYlE dYW4NQD3tsey/+2gadTrI973d3OflOBM1V18Npk1tNPqyZkAps+5kxDXHfjTnDovodDcXl v6NDsME4HHlXntEe0y/CahSKI0roX5kqU2GAimS08cy8jPT3rxe/Law2QmBdWmwLu50aT1 VUMEz2QDHeGofSE5TTw5sPWeW+/+SLlaHmlD9mWrB0RcItgNWbU93L+zeRkeNdBObfghFS RX4X+OtnQPrEb3lUJFbI95tq6ETsHYQ81B6Pe/QY3bo3ppqezilC8z95b4P7fg== From: Alexander Gruhlke To: Bjorn Helgaas Cc: Lukas Wunner , "Rafael J . Wysocki" , Alex Williamson , Hui Wang , Linux-Fan , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, regressions@lists.linux.dev, Alexander Gruhlke Subject: [PATCH v3 2/2] PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV Date: Sun, 11 Oct 2026 21:01:45 +0200 Message-ID: <20261011190145.23621-3-gruhlke@mailbox.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261011190145.23621-1-gruhlke@mailbox.org> References: <20261011190145.23621-1-gruhlke@mailbox.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-MBO-RS-ID: a3c6aca1851649ec033 X-MBO-RS-META: yrf7ponqutpkw93pknpe466wk4gmzqhz Content-Type: text/plain; charset="utf-8" With RRS Software Visibility, pci_dev_wait() considers a device ready as soon as reading the Vendor ID doesn't return the RRS value. Devices aren't required to respond with RRS while they aren't ready, so the read may return ~0 and pci_dev_wait() stops waiting too early. This was seen with Intel [8086:0a54] and Samsung [144d:a80c] NVMe SSDs. Also wait while the Vendor ID reads ~0. A VF's Vendor ID always reads ~0, so check its Command register instead, as is done without RRS SV. Fixes: d591f6804e7e ("PCI: Wait for device readiness with Configuration RRS= ") Link: https://lore.kernel.org/r/20250611101442.387378-1-hui.wang@canonical.= com Suggested-by: Lukas Wunner Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Alexander Gruhlke Reviewed-by: Lukas Wunner --- drivers/pci/pci.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 350bae907e..d3d6e682fd 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1213,9 +1213,11 @@ static int pci_dev_wait(struct pci_dev *dev, char *r= eset_type, int timeout) * initialize. * * If the device is below a Root Port with Configuration RRS - * Software Visibility enabled, reading the Vendor ID returns a + * Software Visibility enabled, reading the Vendor ID may return a * special data value if the device responded with RRS. Read the - * Vendor ID until we get non-RRS status. + * Vendor ID until we get non-RRS status and something other than + * ~0. The Vendor ID of VFs reads ~0, so check their Command + * register instead. * * If there's no Root Port or Configuration RRS Software Visibility * is not enabled, the device may still respond with RRS, but @@ -1235,8 +1237,12 @@ static int pci_dev_wait(struct pci_dev *dev, char *r= eset_type, int timeout) =20 if (root && root->config_rrs_sv) { pci_read_config_dword(dev, PCI_VENDOR_ID, &id); - if (!pci_bus_rrs_vendor_id(id)) - break; + if (!pci_bus_rrs_vendor_id(id)) { + if (PCI_POSSIBLE_ERROR(id) && dev->is_virtfn) + pci_read_config_dword(dev, PCI_COMMAND, &id); + if (!PCI_POSSIBLE_ERROR(id)) + break; + } } else { pci_read_config_dword(dev, PCI_COMMAND, &id); if (!PCI_POSSIBLE_ERROR(id)) --=20 2.56.0