From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49]) (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 DDC81256C84 for ; Wed, 25 Feb 2026 01:41:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771983689; cv=none; b=g/bX5x9SPir0gnZjJbRsNIyIrVLWufce8L3hIJdY1boS2W6eULmEBtFnuZf3VQdHQDp/WpxJh8Klx62NSQH9nmUZPI3Xnc6WMpOaT6y/24mrxycLYLPPt/V9bOxRNvgfrIX4MHMEDOp4eAlT7kaVNVlQU9rxcN/2A5rzIq+y4M8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771983689; c=relaxed/simple; bh=HBEYlcIc7GnTW+YvomdTIW6EpchdhjkgOCxL0C09iL4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=H+7SoyVFp900aucfwdZd4CRtyvjixU+vO78hRjqh/HUtt7P6LFZ5jSx6cz8AUyNJ2j09z1+l26NkbNzCVPd9TV54iuu7IUzbWwHaJ/BU6Y6a0wKQgmf8hInf2CQL7sJl++xt9D3ZLvxxwtgHSaw6Zgw6W9NcUnnO2WaTAJkuXXM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=purestorage.com; spf=fail smtp.mailfrom=purestorage.com; dkim=pass (2048-bit key) header.d=purestorage.com header.i=@purestorage.com header.b=Yj7z40Lh; arc=none smtp.client-ip=209.85.219.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=purestorage.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=purestorage.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=purestorage.com header.i=@purestorage.com header.b="Yj7z40Lh" Received: by mail-qv1-f49.google.com with SMTP id 6a1803df08f44-89577f866d6so6129056d6.0 for ; Tue, 24 Feb 2026 17:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1771983687; x=1772588487; 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; bh=o6MLMChCRx+KMQSVhypR0LNDXIFTtxCcdGqYANLUR40=; b=Yj7z40Lh8YvvI0HY/SjXM+yzmUSthKZ2bWjOwb1BR8IXrZg7AJlCrGMsDp6OVa+6yi jwFc7mv1YXh/e+LzqoUiIbC+H6NMU2aFbChHXiJFNKLu7AFxJWGipaHlyB93maVAOsqQ Pg6XhYBTlfQGLonvWW6Ygy7R4o9JJyMy4SObpzo/kwLtwhR7hoT2iKYtrH9gOxq9zjKx XjxaV4HMlR9TS/c5RV41IbwswK6oOvsqVJji36wg6PaG9FjBlyMvgG/vtQIxwRVStDZw kpwfiOuKJMKGskDWqor7IsmSPBZkH9BdHd5mLEGgFktfesz+oszuQ56xRZQk7NM4FRHZ o+rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771983687; x=1772588487; 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; bh=o6MLMChCRx+KMQSVhypR0LNDXIFTtxCcdGqYANLUR40=; b=sQidGpo5z4JpDmj4HXmX/ooea6puv5lMMMHodEqugDqhusUQu+64ksjTTuqZOjOkDJ FJth+zPjmjzI7+0RTA15yPlmYrKk6r1maU0uK1I/2UQ6LnZu8QUSU/g1r3ywqK0oif26 aJLniynR0atqJScIj6ZbU1JQQTk5rKnjNm2Bxoh2F+fpp/8/8C8a8eRWkIFRuhYV0aeW JNwFGigaoqDQoa1X5tYCUAHnI1EfYMY/U6vRXbqHu/nKWkgtFKHAfwarOOtR703XClCC CTNjK2AGqpndsS4XK0V+Zu+CMS886aB/tscvg6H3/EL52lVPARrW/HGcFLx12RZiOqiH OuzA== X-Forwarded-Encrypted: i=1; AJvYcCWQiAXhaxHjgZTx/6b0tmAglwNt0YZmbGyG0zN6/R+sPLThrPhW8NnuQ6cSBQUmHoRPlOFTFSPcPivszOM=@vger.kernel.org X-Gm-Message-State: AOJu0YzYLZvDQjJPgKTunb1IruN1TPelh+BRI8jK73kQuMqiNKqTeRxl 46QQ+4oVx0x7ZJET96py45LmJu9SVoD/yz0GMsoJ4UfzsSkwhjfEdUt79hVDTWj0e8I= X-Gm-Gg: ATEYQzw5UVca9ddED0fGepVeBkHDchU6U13slfmZwUHYuZbqTm8meAnO8scvGRJR5Hl +pzRy+14ZxmlAgRv2dcasZQgh3rs0Uz8iAqdVpTveuRmZj5Vh+c5H7werO7XtAjByEu1Aqg2g48 hI3ltEpsU2tE7oi98KzMC7uKmMF1RGe44yMOfvYlpNFMrWoY7kXz08FsZi0F+49oogCEm+cNxVc tZxu6pds+62ZELQIXfLSWh/OnZXourKih2IqG7L/urnu36Ygiy+0DBSOH+aMn8vxAT10V3WQxPv yQvdJZAm+cNqHYjNR4cQkRxyNI3+GOC/ofHIdOPfalfLKddHBP/yST1HmJKO6b7d436QX+7od2S oihDuNNkH62Kg3+JNKHqICnKA/jg3CVlEKzWOSvp8wtWr+LE5A6gxeWFh3AUwlkBJeQQrEmpp3c aoddL8q8xXT8Nd4T1hH8v1dsySMsbaeH5R4XyOf1SyYg2O1dIKTK9E5+ymEUMPhbCaLWu1xnm5O YUxnpyyudANLAXZ9R/PezkP2NQLOiZOp5zEZP7cmLBrKxgYtDc= X-Received: by 2002:ad4:5f09:0:b0:895:46be:2983 with SMTP id 6a1803df08f44-899b34c5bafmr32547266d6.12.1771983686726; Tue, 24 Feb 2026 17:41:26 -0800 (PST) Received: from dev-mattc2.dev.purestorage.com ([208.88.159.129]) by smtp.googlemail.com with ESMTPSA id 6a1803df08f44-899a617f875sm30942756d6.40.2026.02.24.17.41.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Feb 2026 17:41:26 -0800 (PST) From: Matthew W Carlis To: macro@orcam.me.uk Cc: ahuang12@lenovo.com, alok.a.tiwari@oracle.com, ashishk@purestorage.com, bhelgaas@google.com, guojinhui.liam@bytedance.com, helgaas@kernel.org, ilpo.jarvinen@linux.intel.com, jiwei.sun.bj@qq.com, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, lukas@wunner.de, mattc@purestorage.com, msaggi@purestorage.com, sconnor@purestorage.com, sunjw10@lenovo.com Subject: Re: [PATCH] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining Date: Tue, 24 Feb 2026 18:41:19 -0700 Message-ID: <20260225014119.10047-1-mattc@purestorage.com> X-Mailer: git-send-email 2.46.0 In-Reply-To: References: 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 Mon, 23 Feb 2026 23:14:37 +0000, Maciej W. Rozycki wrote: > I argue that by applying this change the issues with NVMe hot-plug will > be sorted while keeping the configuration working that > pcie_failed_link_retrain() is needed for. Win-win. I don't think that what you are saying is true there is invariably going to be some other consequence of this change.. Its hard to believe there can be any changes to the pci drivers that won't break something. > I note that active links are unaffected, so to say it's meddling with the > link on every device is I think a bit of an overstatement, and reports of > issues are from a few people only... There is no discrimination about which device it can be invoked on.. I'm looking at a fleet of millions of hot-plug'able devices.... I don't really know if it matters how many people report an issue, I think what probably matters is making the right change. Initially was there any other reports of the quirk helping with other devices besides the delock 41433? > What outcome would you envisage had I taken the approach from this update > right away with the original change? My only fault was I have no use(*) > for PCIe hot-plug and did not predict the impact there. What I'm seeing now is an overall confusion about whether a link failed to train to gen 1 or was recovered by the quirk or recovered on its own etc... In my systems I would prefer to NEVER invoke the quirk under any circumstances because I expect my devices to work. With the quirk it becomes more unclear about what the cause of a link issue might have been or whether it was even a real link issue in the first place or some weird timing.. -Matt