From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com [209.85.221.181]) (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 45A3B318139 for ; Fri, 27 Feb 2026 22:47:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772232454; cv=none; b=J3aO18hWlbEfAvswlGbeUU5gYJbhsrmZ6LwGyQjAEhNMJUzsPih7WhjI0E2fyPxv8BpFxKR6a9IJAXNCniVXOKDxAYgpknZ+4XsmJSI2jVT+5Yvk2t+yCvzh7vnAP/KaurIvHRMgt35lJqk2rB8WtDSgzS4RynsfGGMJi/kXXw8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772232454; c=relaxed/simple; bh=0OFMgdCGU7B5hBrb8XzSrkdIeEEvEG+dl8cgnT9z9l0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BbjZW7cubZk7FP51IOuPk86ZFZhlH3vUGyueY3xP1DEoMxfczGsnbHijW+25En9zeHRiTscPpqp0zjxSy1+2Ri0E02agRo9UXoeDz8J5nvre+dOQ2J7gI8Rw1LuZoZI7iTB3OkFauaUTCUgsG4jltD8xxLewv0vovPZ/oZVAI2I= 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=YJesD51g; arc=none smtp.client-ip=209.85.221.181 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="YJesD51g" Received: by mail-vk1-f181.google.com with SMTP id 71dfb90a1353d-5675d609621so2399774e0c.2 for ; Fri, 27 Feb 2026 14:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772232452; x=1772837252; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=k+TH6jAGK26TrEc9oITkY4dihAUESin1rX1KN45OKxY=; b=YJesD51gPmXp7QCQaoGa/HLWzj38Qplh+wOreH4d/Fp3SOGCmlAM0wlmvsVY3oKCKb kAEnUWzTbcssVI9j8Yi5nPbD4by7Q6ii1aWt9KsUFnSpbw8LhJ3wa7UvJO/jEvyV3/MI sRXEWnA+Hn10CDUxSj17Okfz+/5l+X0QGlego40WtjEJ921bTHifuShb7XAruyMYWSGd gYSWuOEXT5Tz6zcK2lhJZp0o5Pbo8EQXR8AZWGeXL8H8O5wvHWERsLheFF1FsU+B8JY8 jqLNe+fzJQ9IXgdlmrvhwqawOKjTL1FLbrKF6oBeBO9NWazOE5DajMIKV0MC7VsP0adx MWrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772232452; x=1772837252; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=k+TH6jAGK26TrEc9oITkY4dihAUESin1rX1KN45OKxY=; b=p6g4jF0xYcdejG2VRX+LS3gdoaFLBNu8+60yU7KLr+qGJkhr/V1xMCLm1ibL/l40My 5ts/04dZsIcH1RfLQQs5Q2RjunOzc+rwC/4LTF/hQiNoSW38r2jT/rbjQqZWLFJYVh1g JQHf2Nta7kijlQNovXFkj3eKC57tu0tU4Cz9YS2/VbFnV4wwTdJUknyctuHTzOenkurT PaXzlNubfZItYfrl8jzkZASXnC7vQSP1ticZQoe4nZfQr3qGQUQJZW2jiY7fJDh5kzVm Gr8HDsZNOU861B+Nhp41DsQYf9A0imAoDDkfqTp7XPvkfH0BjRGNAhMYHZOrRTe0PGQW dlIA== X-Forwarded-Encrypted: i=1; AJvYcCUjctPKGKWJ78BsVxXvCa1/z3S2lhNVemEeIlWzzvYpyuBb0uakw7R5SbCofuFkZSenX92M3v/3xwGTIOo=@vger.kernel.org X-Gm-Message-State: AOJu0YwNYcylsvpVKsz2x2ZddCmmieAMdB3zPAeOnd0QCloQry1s3AJz fz1ya4xjzeO/aHpN3Wp6btW3pbOETGuLZyubnXvFQjrpPgY0w+xYJNO+ X-Gm-Gg: ATEYQzx2t6xBEcWAx7Qb8evZGrbUnVk7eomklEABEaXRk8hVt3w+1/J3q4cpJK/oy4F T8sW1aX9nkWkNShJZLcWj0NxOLZzaeJYFt4FtYYH8n+QQiSKs/V5vHVl51OB8nata1BaPL9AfvG VyZZrYRxJcbwVxl0gDT0gDZzIyU3haDhuPo9a9rjNtc6Sjb2YdSBtAEW7TCpU73o84dC5Y1Ny/I dkzp/YFqOTWdfGk/5y+YXwtGgihBE35TearQpYQ6avq0MOdH8Bv96Nu28RNI9+YcsH3T07V+Vw9 bYNwls55mSGrs1Aia9QKs/hIrraHQGJ986f9gDNlTDVZfOkTbi1FNn8/WPfImR3pSBsX8keYmlX 9iJco7rR+tRsyNrjD5+TlBaaUfr2YH5M0IPx5VAG1a+cgCxgVub1AbVoma3cqHhp719bPLPCwhJ 1tFJLnngWiCg== X-Received: by 2002:a05:6122:4b08:b0:566:3c58:efcb with SMTP id 71dfb90a1353d-56aa09ebdcbmr2825977e0c.3.1772232452162; Fri, 27 Feb 2026 14:47:32 -0800 (PST) Received: from geday ([2804:7f2:800b:feb1::dead:c001]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-56a91bd2291sm8103706e0c.9.2026.02.27.14.47.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Feb 2026 14:47:30 -0800 (PST) Date: Fri, 27 Feb 2026 19:47:23 -0300 From: Geraldo Nascimento To: Dragan Simic Cc: Shawn Lin , Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Manivannan Sadhasivam , Rob Herring , Bjorn Helgaas , Heiko Stuebner , linux-rockchip@lists.infradead.org, linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 2/4] PCI: rockchip: drive at 2.5 GT/s only and error out other speeds Message-ID: References: <9e3754ee0d1f5bc8051e28e1a5b8c046440456f5.1772169998.git.geraldogabriel@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Feb 27, 2026 at 06:33:34PM +0100, Dragan Simic wrote: > Hello Geraldo, > Hi Dragan, > On Friday, February 27, 2026 06:36 CET, Geraldo Nascimento wrote: > > Configure the core to be driven at 2.5 GT/s Link Speed and error > > out on any other speed. The reason is that Shawn Lin from Rockchip > > has reiterated that there may be danger of "catastrophic failure" > > in using their PCIe with 5.0 GT/s speeds. > > > > While Rockchip has done so informally without issuing a proper > > errata, and the particulars are thus unknown, this may cause > > data loss or worse. > > > > This change is corroborated by RK3399 official datasheet [1], which > > states maximum link speed for this platform is 2.5 GT/s. > > > > [1] https://opensource.rock-chips.com/images/d/d7/Rockchip_RK3399_Datasheet_V2.1-20200323.pdf > > > > Fixes: 956cd99b35a8 ("PCI: rockchip: Separate common code from RC driver") > > Link: https://lore.kernel.org/all/ffd05070-9879-4468-94e3-b88968b4c21b@rock-chips.com/ > > Cc: stable@vger.kernel.org > > Reported-by: Dragan Simic > > Reported-by: Shawn Lin > > Signed-off-by: Geraldo Nascimento > > --- > > drivers/pci/controller/pcie-rockchip.c | 13 +++++-------- > > 1 file changed, 5 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/pci/controller/pcie-rockchip.c b/drivers/pci/controller/pcie-rockchip.c > > index 0f88da378805..26fc350a66c1 100644 > > --- a/drivers/pci/controller/pcie-rockchip.c > > +++ b/drivers/pci/controller/pcie-rockchip.c > > @@ -66,8 +66,9 @@ int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip) > > } > > > > rockchip->link_gen = of_pci_get_max_link_speed(node); > > - if (rockchip->link_gen < 0 || rockchip->link_gen > 2) > > - rockchip->link_gen = 2; > > + if (rockchip->link_gen < 0 || rockchip->link_gen >= 2) > > + return dev_err_probe(dev, rockchip->link_gen, > > + "Invalid Link Speed\n"); > > I'm quite surprised to see what happened here in the v4? The changes > introduced in this diff block in the v3 were perfectly fine, i.e. we need > to correct any runtime occurrences of Gen2 speed setting in the rockchip_ > pcie_parse_dt() function, together with emitting a warning that urges > the users and the board dtb maintainer to fix the board dtb. I'll get > back to this below. I see what you mean now. Sure, this could be incorporated for v5 without a problem and is the more proper way to solve it. > > > for (i = 0; i < ROCKCHIP_NUM_PM_RSTS; i++) > > rockchip->pm_rsts[i].id = rockchip_pci_pm_rsts[i]; > > @@ -147,12 +148,8 @@ int rockchip_pcie_init_port(struct rockchip_pcie *rockchip) > > goto err_exit_phy; > > } > > > > - if (rockchip->link_gen == 2) > > - rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_2, > > - PCIE_CLIENT_CONFIG); > > - else > > - rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_1, > > - PCIE_CLIENT_CONFIG); > > + rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_1, > > + PCIE_CLIENT_CONFIG); > > > > regs = PCIE_CLIENT_ARI_ENABLE | > > PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes); > > At this point we need to check and bail out if no longer supported Gen2 > speed setting is received, which also applies to the appropriate spot in > the PCIe endpoint driver. Right, it is a bit of a double-check I think but it can't hurt. > > To clarify, it's the responsibility of the rockchip_pcie_parse_dt() > function to validate and possibly correct the speed setting, because it > is what receives that setting as a value from the board dtb, while the > consumers of that validated speed setting should check it, to make sure > the speed is right because they no longer can handle requests for Gen2 > speed, and simply bail out if the received speed isn't right, i.e. if > it differs from Gen1. > Like I said, it ends being a double-check, because we can't let probe progress if link_gen ends up being different than 1. Either we force 2.5 GT/s with a fair warning or we error out on the probe already. Thank you, Geraldo Nascimento