From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com [209.85.222.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 469861A4F3C for ; Thu, 5 Mar 2026 04:19:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772684365; cv=none; b=A9MTbqbv+ghA23nydl/Hz8YwH5aedyUdn0Ne/7dYIpYNFqwf16u4Rk18epFZ1IuhhgCxMsXWeoa+86owvkvO9M9mQm60Q/h4s0KQ1mSV3c1r9ptANACHtQ4dXaiPuK8e7ZClqa/HTOQE29RbqMQG3o7GavbR4IMiorxes/uo/GU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772684365; c=relaxed/simple; bh=YLMX93OqrPLVPWJSCEb4hxhP3JLrjkjT+PELt9gAHVE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=obK8aZp+BkUZV8aEAQWjC0tPPyIE5DRGObUIdKE+1mg03zbQnmYfAVe0vEK345V7kw+Y3ScaYCq5ajhOAVpbcGbbeTxhXBa4y9QEG1eZUdvtXuRJGw+XpLnAyENEy/lrWlWJcWqBWtg0VRgEQIlrbhYcbZhub/k9xxgzqXCx+yM= 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=OaIfmz0p; arc=none smtp.client-ip=209.85.222.49 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="OaIfmz0p" Received: by mail-ua1-f49.google.com with SMTP id a1e0cc1a2514c-94dd06a96easo4807325241.2 for ; Wed, 04 Mar 2026 20:19:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772684362; x=1773289162; 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=dcwLPgCuX5qGk1VO8dlUrj59t6r//UFI20kbYxyl5TI=; b=OaIfmz0pr/GOJnZ6UrTlAZlyZ84zmHR5mibsTnGDmjD3tieI3UCGpTrajeCLx2bkcs SOofoITN4oTEfjZQAyq44GzwYMogydLMmEbZHEnVjEAAFN0gK8W6nefXIBSbo5A901fP TmKsZ4/4WwNS/+azt5jNSjGMaUM4NGjTZx0oMieimIdi8wnDZMRPctSVmwE8L0c8R6wm teRap4imXUD/v3wiovjSFcs1OAdYISBrWIJfKlSB+D3/rKzhSVzUqq4EB9Zm24Up4P/g GYcjRK06IK+fD13R7WtrhF0y+we/vKFtUB1/1ZYlru/J5ZpjyDOJxHAySdc65R4nV2V1 UR5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772684362; x=1773289162; 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=dcwLPgCuX5qGk1VO8dlUrj59t6r//UFI20kbYxyl5TI=; b=ZoITDBYNLvFBJoYj+836DZ0PUwFJB2AGyrpvwavQfFPuyNhGePgLq9Uh+MCjv69y4Q AqhMo/6TSlko7CJykTVqndMgg6MTt52U6MuAqiy6MDmkR7OqEVcG51i9fm+cRRH+7KaY 8Eh0/CKZroy2KeEw6G/XDMHqA7Q39pVsSt3MjWln4LHWdCoPMDuVP4n4ZW3bK6hboFvR pfeVAYVg3y29aEt/XsaNSBiwOzMSmzocuUV6xrUHZ8eH2sU6xHI2l4BewnquH71sYVBb T1ITsN/2ReIAAUxaOPLSG4Leq6VGQ0tmMnDq0znDoxfeFpiZhr3mw/DiCyPpvy5UNKZo o31w== X-Forwarded-Encrypted: i=1; AJvYcCXwSRgaCi3YY3QwD5JkDcDwI/s6ZdZth/sFJDbgCbUJ/yDhYCLUhCdMYNsvYL66NaDfvbIf4baSU8vKfN8=@vger.kernel.org X-Gm-Message-State: AOJu0YwPWmg90tJpqZHawKihrUNMOqd4wq4OJ4+c/2TfSXGHPoiuCdGS xW9ibaOmCuFy5di8hKwUBzq3dhXrtLKsWesyPOr7d9finwJ09rtxzBG7XhzRzp2y X-Gm-Gg: ATEYQzz6YOc4QM/SY6SawKhrujtpgr7ck9CtJcP+LJ8qW9Fn0v3+BRwwy8MMDi+3zpM BA7gt0uz/u5uy/jjE0Do/+ZIfGYkIGZdrSrhVsFq8q0G3Bu6fJ7MtOBOXdMIU7iU7mfsyOVBqGD zOWe6kInlfIuXQBQpdBEpDmqNLM4ITgozeDUo6oQQx0D8WYfqrWfKsQlle6W42o2Pk1sToREgcu zpI7L7NTSSMJuMibSUIzPhD4wYbc9PYWFb193sY+lyu7GyI/eAQIZ23G6JvpkMjln8tEoFiXo0X YgAVA8KM80AJUVYXm8JdZORp2e9yTl1Cvdj1YysVkjcHWJ6u8gXQ17caKScnYq3Pwuq4Jp3B2Cb SU+gP3Pmehal1rOOGBhcUAL5KSaruaLOsp/gX6D8ZsoBBgTdYiuX61zmFhMfy1Gi5QYLGxv/pwp s= X-Received: by 2002:a67:fbce:0:b0:5ff:b8d8:b40d with SMTP id ada2fe7eead31-5ffb8d8d44bmr1248639137.21.1772684362172; Wed, 04 Mar 2026 20:19:22 -0800 (PST) Received: from geday ([2804:7f2:8080:fd2e::1]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-94df6577a4fsm21273560241.10.2026.03.04.20.19.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Mar 2026 20:19:21 -0800 (PST) Date: Thu, 5 Mar 2026 01:19:15 -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 v5 3/4] PCI: rockchip: drive at 2.5 GT/s, error other speeds Message-ID: References: <2a0a4aa97bb8b0cb511cb651c5d66c9ec8bab97a.1772239598.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 Sat, Feb 28, 2026 at 07:16:41AM +0100, Dragan Simic wrote: > Hello Geraldo, Hi Dragan, > > On Saturday, February 28, 2026 01:55 CET, Geraldo Nascimento wrote: > > Configure the core to be driven at 2.5 GT/s Link Speed and ignore > > any other speed with a warning. 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 | 15 +++++++++------ > > 1 file changed, 9 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/pci/controller/pcie-rockchip.c b/drivers/pci/controller/pcie-rockchip.c > > index 0f88da378805..2f211d1f4c7c 100644 > > --- a/drivers/pci/controller/pcie-rockchip.c > > +++ b/drivers/pci/controller/pcie-rockchip.c > > @@ -66,8 +66,10 @@ 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) { > > + rockchip->link_gen = 1; > > + dev_warn(dev, "invalid max-link-speed, fix your DT\n"); > > + } > > I'd suggest using a bit more formal message here, like the one below, > which would also avoid addressing the user directly: > > "Invalid max-link-speed found, limited to Gen1 to avoid data corruption" We really should spare on characters here, but I see your point and will try to cook up a better way. > > > for (i = 0; i < ROCKCHIP_NUM_PM_RSTS; i++) > > rockchip->pm_rsts[i].id = rockchip_pci_pm_rsts[i]; > > @@ -147,12 +149,13 @@ 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 > > + if (rockchip->link_gen == 2) { > > + /* 5.0 GT/s may cause catastrophic failure for this core */ > > + dev_warn(dev, "5.0 GT/s may cause data loss or worse\n"); > > + } else { > > rockchip_pcie_write(rockchip, PCIE_CLIENT_GEN_SEL_1, > > PCIE_CLIENT_CONFIG); > > + } > > I don't think we need to emit a warning here, because, as we've already > established through earlier discussions, the rockchip_pcie_init_port() > function should never receive an invalid speed value. Just as a lame excuse, those messages were everywhere in the mid of my development, this is one that escaped deletion, will drop. > > > regs = PCIE_CLIENT_ARI_ENABLE | > > PCIE_CLIENT_CONF_LANE_NUM(rockchip->lanes); > > It would make most sense to squash all three patches in this series > into a single patch, because they all form a single logical unit, which > introduces changes that are just going to be harder to track down later > if it's all scattered into multiple separate patches. I agree, having all drops in one big patch is the better tactic here. > > The only possible issue with the squashing comes from the inability to > have different patch subject prefixes for different driver changes, but > I think that's actually not an issue. The long-term benefits of having > everything as a single patch outweighs the benefits of having different > patch subjects with separate patches. > Sure, will do so for v6. Many thanks, Geraldo Nascimento