From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 81876379960 for ; Sat, 8 Aug 2026 06:31:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786170672; cv=none; b=eu5npFSU6Ak7MewXSqdOVdIERryplST/o9Ms4/Wep2rYrZ2LL4lK1PZIHPJOv9c2fiFqFJZV640DhQwG2KnlOFeLPGZJL0MW1V32nwXCjWftIlwYmeKNWDxCHk8DX/hfjwmQuPTXk1EA/fguEEggY3EQh9/dxECSpinO1rlrl1c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786170672; c=relaxed/simple; bh=LA5QlPc4q+6c5UX/OWdNhPZhd+ekRRm7oX/f3Lx3tmk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FRJ1/1quQkjP6Zk0zAGGah1Ztcf4HI+ZE28JCPYGQdjco1b2mIW9D4GnTTSm3h0gVPY/BekBzooNnbyDNCMdGL2zmcy4hKhIHU3wTG0IBMpExFmqLhzMDfIPSBF5Ok2QjKxYfWM6A5SpPg4a4A57x8SRL68wMpHR01aDgUN76eA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=K/98ezge; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="K/98ezge" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4954f5e8020so953205e9.2 for ; Fri, 07 Aug 2026 23:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786170668; x=1786775468; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=cMoo6yfItMXQZdH4h0GQ/fgmLIRHwVqfY6tNNASMxyk=; b=K/98ezgeSNCqFfwDNHZWn0mG8Fpz2DZMPP4T5sn4f7JyCUT76spjpp77jOBUNYB6AT afiqeqPnHC93Kd9nwHswNwE6gLAro/xNLoY0PmC/kKZrFIYH6HiHJ0oaZQ/PRro7FO2s abClCPtFXHt/H881W7izpsVhAOfpqj97lD0a8yjKnfayyLwOfqAw/keAb/N8R0f7rgQk GGLNOrJj4rsTfUq9PgnUyGYRnAKyY/qMcRGTNYjz/HSOcjgbdBQSBamZzsH+SWHrKz3E b6veMbGx0AEdxl+h9EJRRNWK+/zNNlcLX+PWCfSLvkt1W53DKMV6L4WFzUxFOJl1mF3C 8wNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786170668; x=1786775468; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=cMoo6yfItMXQZdH4h0GQ/fgmLIRHwVqfY6tNNASMxyk=; b=E5e3LJ77ZSsHlRcMD2hqteO1s0a/mk+H0OEgzSp4SrqBYCDJk1669AqLfc2rOKQ+r8 cu+zHI/mnqxf5EUmP/cTPw62LsMma16zCBuwDZFLvc4fPr7PqR7ENhGbO7Nc4fJ61aaJ NPDM/wOl15hOI8wKfiEIdS3kYPQZfmK9qQKLskwtYvrjsJFQ/C/6/HQF8bSpS3uLpDps 7LorrGoFJjNcHFKxcoItN/+Ucv1cXll3IRfkrL7SUw1M3nU8GbvZ/yGUXKLw44w9mqzL uX9w6YQswSDjsax5Q7cP4GYuqqNfOPLVAWwaeEdwernT0XGTIsp92lcfj9C9+JXZVVay Ns4Q== X-Forwarded-Encrypted: i=1; AHgh+RpgHt8EOQM0CjDeEAw0TOxWhLrUhzjGTs6YLrUd6uqdnHKTx5v3i41PoNb+oTdBbze35ShO24aBs9XAqms=@vger.kernel.org X-Gm-Message-State: AOJu0Yw8JWh8HHRToYkUV9zeKnTDpVfLd0iCwtiI1sMM6mS1zY4B+5Qe CBK2VsdYDzr5QyT0R9pdBSs5JvXx7cfiN1t/ksROSaVS0/ama/fyE2FLT+QDhMcCh0E= X-Gm-Gg: AR+sD13JTGOnjqiNTIfygESkn7Ka/CXtmdxaJWUJQa2fX0h/Rv30PSjm1tWmFD7Y089 377WpIcrCSBnMuT7dQZ8f+OS0dfppLvVbNQz81I3BYiPAumRUG06369K/nw5xbwHlrA/rWXMA57 vfvVSt+Opj9nZGwXqsNel/ECRI4vX6yutb4Lm7nGplWmdd6ROcXE0aC4pk5oEI19gMS+P0pV5om QV74ZYtP6THv0/gclx/i0/J4YHDp3uwU1NNnOTB2WPG5qm8jc6Q6QKJSmPrEeONkDAeYKXMAM2J 7N5ELl3ysSqEhI050WHhBqODaWJhyppjrDknpjY2ot5exlG81cnj1un4+dLoU4CTVrAGsPw7tdD 7NnJstEswFeyS0haib/cg6EZjy6X9lo4y3SdgfnI2HsB/RgDGoxnTdMlqXjHY8itRkqOdwffrR7 ac4AvasXBpVLrz+PkIYrDFEO/CQkWriZc0XFnNCAr2L9B/Q6+38eBXVDkqIDefyoO3gdur5dPSw YdWBV8k45CmiW/d22gLxofAChjWizK5gkGlBVNiqDv92DGyHAk7XwxuPCefqnxrk26mIliiriyj +4WYriZxmNM8nJd5n4TF X-Received: by 2002:a05:600c:6612:b0:495:4811:7998 with SMTP id 5b1f17b1804b1-4995e0ebf84mr132716055e9.17.1786170667423; Fri, 07 Aug 2026 23:31:07 -0700 (PDT) Received: from corecachy.localdomain (p200300eca72356fc3569cec583d57196.dip0.t-ipconnect.de. [2003:ec:a723:56fc:3569:cec5:83d5:7196]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4995c7a56c5sm127821935e9.3.2026.08.07.23.31.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Aug 2026 23:31:07 -0700 (PDT) From: Andreas Wild To: Aoxtj Cc: linux-pci@vger.kernel.org, Bjorn Helgaas , "Maciej W. Rozycki" , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] PCI: Skip Target Speed quirk on clamped ports with no link Date: Sat, 8 Aug 2026 08:31:02 +0200 Message-ID: <20260808063103.10940-1-andiwild@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <331e97c7-e422-420d-9f3e-5d9f734464b3@axtjblog.cc> References: <20260801201244.4421-1-andiwild@gmail.com> <331e97c7-e422-420d-9f3e-5d9f734464b3@axtjblog.cc> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Sat, 1 Aug 2026, Aoxtj wrote: > - 7.0.14-8 + revert 72780f796468: boots reliably. > - 7.0.14-8 + this v3 patch: only boots sometimes; failed boots lose the > drive the same way. Thanks for testing it. v3 only covers ports with no link at all, so it does not address your case. 72780f796468 removed two guards at once: the Data Link Layer Link Active check, and the device ID match against the ASMedia ASM2824. My regression comes from losing the first; yours looks like it comes from losing the second. v3 only bails out where DLLLA is clear. Your link is up: > LnkSta: Speed 2.5GT/s, Width x2, DLActive+ so the quirk runs past the v3 early return, lifts the restriction and retrains at 8GT/s, exactly as it did before. Reverting works for you because your AMD Renoir Root Port didn't match the ASM2824 ID list that used to gate this. A possible workaround: If your BIOS lets you pin that slot to Gen1, you could try that. With the Root Port advertising only 2.5GT/s the quirk never reaches the retrain at all: on current mainline it returns at speed_cap = pcie_get_speed_cap(dev); if (speed_cap <= PCIE_SPEED_2_5GT) return ret; and on the older code your 7.0.14 backport is based on, the (lnkcap & PCI_EXP_LNKCAP_SLS) != PCI_EXP_LNKCAP_SLS_2_5GB condition is false, so the restriction is never lifted. Since the link already runs at 2.5GT/s x2, that should cost you nothing - it just makes the Root Port advertise what the link can actually do. Something that is different in your case: Your Root Port reports > LnkCtl2: Target Link Speed: 2.5GT/s, SpeedDis+ where mine reports the same clamp with SpeedDis-. SpeedDis is PCI_EXP_LNKCTL2_HASD, and as far as I can tell the quirk never looks at it; the only user in the tree is pcie-designware.c. Firmware setting both the clamp and Hardware Autonomous Speed Disable looks like a deliberate pin rather than an incidental one. I am aware that HASD is specified as disabling *hardware autonomous* speed changes and so does not literally forbid a software-initiated retrain, so this is just a heuristic about firmware intent. About the drive disappearing: The error path is err: pci_info(dev, "retraining failed\n"); pcie_set_target_speed(dev, PCIE_LNKCTL2_TLS2SPEED(oldlnkctl2), true); which reaches pcie_retrain_link(pdev, use_lt=true), whose last wait is rc = pcie_wait_for_link_status(pdev, use_lt, !use_lt); With use_lt set that waits for the Link Training bit to clear (for training to stop) and not for DLLLA to come back. So the restore can return having never confirmed the link recovered. Since the quirk runs from pci_device_add(), before pci_scan_bridge_extend() creates the subordinate bus, a link that comes up shortly afterwards is never scanned and the device behind it is simply not there. That would fit only booting sometimes better than anything about speed policy does. I could easily be wrong about this - I am just reading the code, and I came to the PCI core a few days ago via this one bug. Since you offered to test a diagnostic, here is one. It only touches the err: block, which is identical in mainline and in the 7.0.14 code your backport is based on, so it should apply to your tree (it applied to v7.1.5 here with a -2 line offset): diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index b09f27f..e4fcdfb 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -126,7 +126,32 @@ int pcie_failed_link_retrain(struct pci_dev *dev) return ret; err: pci_info(dev, "retraining failed\n"); + { + /* DIAGNOSTIC ONLY -- not for merging */ + u16 sta = 0, ctl2 = 0; + + pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &sta); + pcie_capability_read_word(dev, PCI_EXP_LNKCTL2, &ctl2); + pci_info(dev, "diag: pre ret=%d DLLLA=%d sta=%#06x ctl2=%#06x\n", + ret, !!(sta & PCI_EXP_LNKSTA_DLLLA), sta, ctl2); + } pcie_set_target_speed(dev, PCIE_LNKCTL2_TLS2SPEED(oldlnkctl2), true); + { + /* DIAGNOSTIC ONLY -- not for merging */ + u16 sta = 0, ctl2 = 0; + int i; + + for (i = 0; i <= 100; i++) { + pcie_capability_read_word(dev, PCI_EXP_LNKSTA, &sta); + if (sta & PCI_EXP_LNKSTA_DLLLA) + break; + msleep(10); + } + pcie_capability_read_word(dev, PCI_EXP_LNKCTL2, &ctl2); + pci_info(dev, "diag: post DLLLA=%d after %dms sta=%#06x\n", + !!(sta & PCI_EXP_LNKSTA_DLLLA), i * 10, sta); + pci_info(dev, "diag: post ctl2=%#06x\n", ctl2); + } return ret; } Expected output: - "diag: pre" gives the error the retrain returned and whether the link was already down at that point. - "diag: post DLLLA=1 after ms" would mean the link does come back, just not before pci_device_add() returns and the bus below is scanned. That would point at the error path needing to wait for DLLLA rather than only for the Link Training bit to clear. - "diag: post DLLLA=0 after 1000ms" would mean the link is genuinely down and staying down, which is a different problem and probably a worse one. One caveat: the poll loop waits up to a second in the error path, so it changes timing. If the diagnostic build happens to boot reliably where the plain v3 build did not, that is also worth reporting. Best regards, Andreas Wild