From nobody Sat Oct 24 20:12:50 2026 Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) (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 EDFC433A9F3; Sun, 11 Oct 2026 16:32:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.151 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791736382; cv=none; b=i3FNULrxqaM7Gu7NpwD8rrN3/BhDhHxh+Fk2zr6gADjsMOPAfjDtpNupZey5oBPAKTLY+knehjAui5WfkCOxh0NaDhZk+cOrRsubkElOV2M60q4RE4BG7X+t/MkSjjFtOynLyYM/s+ZMoC30PW/K/tLEOiD2gf4o/reiKVATnzQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791736382; c=relaxed/simple; bh=dUo2m5gk+GlS5pV3bYwmC3MVOWrIbj2LnwDi2wkGG8M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rYifb0EyCLBWyX3lS/jDW3uHMtKnTyT0+wcLn8TfeuQY4s7wP7QfOmII/SgAvJsZxJDaSv9xVp8jfhF4DwMZuZrTkxiUJ1uh79MpW+Yf8GSYfz1zMAJJ0lv8yC7JXZAiSMSE9yCVHSDtU3NPT2z5JS8gPJbLJiagh6SzG5MCVC0= 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=ZiU/1/kf; arc=none smtp.client-ip=80.241.56.151 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="ZiU/1/kf" Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (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-101.mailbox.org (Postfix) with ESMTPS id 4j2mNl6sQSz8t5N; Sun, 11 Oct 2026 18:32:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1791736375; 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=tXkjnXUU+A8iMJWWfiXN7NNTGFPmHduyaxMXTJYmC1Q=; b=ZiU/1/kffm3NfmA+qzU/aawv1VislbMysnPADU2W8mxnrNPNwnDmMR7Ln4bZapDIGZvDuk xmEopPKOvE0qoYzLoeyr5ociVMOBF1T3a/6D7iN2eYtp8cqmEl8oESu4GGuv249oZ3cCwT cu0U1rHrIHg9cuW8icdX9Av9P/fOBkXWeOTYMzkx65aDx5CmwA+Qn1zL9Q7KgCo1FOz9QW WvGhntCzOkRn2t+k0oboS2koOkgJDDo8ACgxJd4FdzZSEVr1QZkBZRFMYU38lB7I28TN/M b22xSVCmMNSgzVBq8f1lD3D4TXwZsTZCLsjDV2tNbjRTZHCTgc3To3lFMTeWjA== 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 v2 1/2] PCI: Ignore Immediate Readiness on Samsung 990 PRO NVMe Date: Sun, 11 Oct 2026 18:32:48 +0200 Message-ID: <20261011163249.18479-2-gruhlke@mailbox.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261011163249.18479-1-gruhlke@mailbox.org> References: <20261011163249.18479-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: h4uup36wf164mdpgbgmumet5of5wae55 X-MBO-RS-ID: ae8421e972b8714a85c 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 Signed-off-by: Alexander Gruhlke Reviewed-by: Lukas Wunner --- 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:12:50 2026 Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (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 96902335BDB; Sun, 11 Oct 2026 16:33:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.152 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791736387; cv=none; b=CdFOSAycKl6K/I5JcAtXzufNjFIkmJRmDCPunBQqpyjkmJ9fyLmdwJUDZyxOjGiRnNP0khU2WSB+r2Ahz/9OhYTm9snmbZ/mI3AWhHvUmcCbYgb7o9RPMBqiADz/aUUrXHt5NyfLTPcBwcCCUn+0I+O+YTYOeXh2KLQ8+ZjGxFk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791736387; c=relaxed/simple; bh=fMafDQIFWPaE7spjh6pRwedU15wzqygRH9nYU8fJPpw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Izpp0jOTFXePndQmdj5VUq1p6jGShbyDpdfpu+u/5pX3TVMe2k2EsXwfsl8EFo/ugZ1DDXm7S0MOKM4ZkDsUlhJ6BLNFPemxtvFIisbuFGOcGneVkAzqWWBxCAxpcovd9uzSiMWEBpjMrzZ0sMOfbIKdNZORtX8WtuOxGm/clAg= 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=hlJK/jXe; arc=none smtp.client-ip=80.241.56.152 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="hlJK/jXe" Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (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-102.mailbox.org (Postfix) with ESMTPS id 4j2mNn3lMzzKp4f; Sun, 11 Oct 2026 18:32:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1791736377; 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=zG5W5tU4hitsYMAYjfqimE9j+s84hGDNovLwBuNU7co=; b=hlJK/jXeyeIrAJjZaEOQpwlY3rWg56UsXPydS1f845/sbN/koa5TEIT7Jxyh0zEs46mD6d s0zGtZwKJgKeAVQHiR8e0KfzllLeVmlY91ka7B7GKPDOXNXONy46gSvCKfSqqH2To3Vo/t Q2h0k8Y0DLChuxC6ZfFzj8IjZIs65ISftKF0Xwhh50NZlRtty1pu8JV0bp41rFl2z9ObO7 bfoV1f43LePsyovLYVL3NxCxgvwObW/H27EUC4w7iPgK3bUOL9q5GiMspXvbUGPKKd8lnu VJmHkZBwilvNULCAqQBh7QKt7E7eMCJ/mW3qV9RdC0FwGq8gD9mrgA/3nFgHiw== 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 v2 2/2] PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV Date: Sun, 11 Oct 2026 18:32:49 +0200 Message-ID: <20261011163249.18479-3-gruhlke@mailbox.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261011163249.18479-1-gruhlke@mailbox.org> References: <20261011163249.18479-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: cemfi3pmh9mm4uzax7w7uung5wp46exh X-MBO-RS-ID: 3e4afb7381bff1ab49d 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 for a Vendor ID other than ~0, except on VFs, whose Vendor ID normally reads ~0. 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 --- drivers/pci/pci.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 350bae907e..fef8a799c1 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1213,9 +1213,10 @@ 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, unless it's a VF, + * something other than ~0. * * If there's no Root Port or Configuration RRS Software Visibility * is not enabled, the device may still respond with RRS, but @@ -1235,7 +1236,8 @@ static int pci_dev_wait(struct pci_dev *dev, char *re= set_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)) + if (!pci_bus_rrs_vendor_id(id) && + (!PCI_POSSIBLE_ERROR(id) || dev->is_virtfn)) break; } else { pci_read_config_dword(dev, PCI_COMMAND, &id); --=20 2.56.0