lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAEsQvct-AyhdOU9xhP0HnN8be+ut=tDBgUt0n3D4TT9ZMXnTbA@mail.gmail.com>
Date: Wed, 24 Dec 2025 18:57:46 -0300
From: Geraldo Nascimento <geraldogabriel@...il.com>
To: Dragan Simic <dsimic@...jaro.org>
Cc: Anand Moon <linux.amoon@...il.com>, Shawn Lin <shawn.lin@...k-chips.com>, 
	Lorenzo Pieralisi <lpieralisi@...nel.org>, Krzysztof Wilczyński <kwilczynski@...nel.org>, 
	Manivannan Sadhasivam <mani@...nel.org>, Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>, 
	Heiko Stuebner <heiko@...ech.de>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Johan Jonker <jbx6244@...il.com>, linux-rockchip@...ts.infradead.org, 
	linux-pci@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 1/4] PCI: rockchip: limit RK3399 to 2.5 GT/s to prevent damage

On Wed, Dec 24, 2025 at 1:52 PM Dragan Simic <dsimic@...jaro.org> wrote:
>
> On Wednesday, December 24, 2025 17:11 CET, Anand Moon <linux.amoon@...il.com> wrote:
> > On Wed, 24 Dec 2025 at 18:25, Dragan Simic <dsimic@...jaro.org> wrote:
> > > On Wednesday, December 24, 2025 09:04 CET, Anand Moon <linux.amoon@...il.com> wrote:
> > > > On Wed, 24 Dec 2025 at 11:08, Geraldo Nascimento
> > > > <geraldogabriel@...il.com> wrote:
> > > > > On Wed, Dec 24, 2025 at 2:18 AM Anand Moon <linux.amoon@...il.com> wrote:
> > > > > > On Tue, 18 Nov 2025 at 03:17, Geraldo Nascimento
> > > > > > <geraldogabriel@...il.com> wrote:
> > > > > > > Shawn Lin from Rockchip has reiterated that there may be danger in using
> > > > > > > their PCIe with 5.0 GT/s speeds. Warn the user if they make a DT change
> > > > > > > from the default and drive at 2.5 GT/s only, even if the DT
> > > > > > > max-link-speed property is invalid or inexistent.
> > > > > > >
> > > > > > > This change is corroborated by RK3399 official datasheet [1], which
> > > > > > > says 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
> > > > > > >
> > > > > > To accurately determine the operating speed, we can leverage the
> > > > > > PCIE_CLIENT_BASIC_STATUS0/1 fields.
> > > > > > This provides a dynamic mechanism to resolve the issue.
> > > > > >
> > > > > > [1] https://github.com/torvalds/linux/blob/master/drivers/pci/controller/pcie-rockchip-ep.c#L533-L595
> > > > >
> > > > > not to put you down but I think your approach adds unnecessary complexity.
> > > > >
> > > > > All I care really is that the Kernel Project isn't blamed in the
> > > > > future if someone happens to lose their data.
> > > > >
> > > > Allow the hardware to negotiate the link speed based on the
> > > > available number of lanes.
> > > > I don’t anticipate any data loss, since PCIe will automatically
> > > > configure the device speed with link training..
> > >
> > > Please, note that this isn't about performing auto negotiation
> > > and following its results, but about "artificially" limiting the
> > > PCIe link speed to 2.5 GT/s on RK3399, because it's well known
> > > by Rockchip that 5 GT/s on RK3399's PCIe interface may cause
> > > issues and data corruption in certain corner cases.
> > >
> > It’s possible the link speed wasn’t properly tuned. On my older
> > development board,
> > which supports this configuration, I haven’t observed any data loss.
> >
> > sudo lspci -vvv | grep Speed
> >                 LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L1, Exit
> > Latency L1 <8us
> >                 LnkSta: Speed 5GT/s, Width x1
> >                 LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
> >                 LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1,
> > Exit Latency L0s unlimited, L1 <2us
> >                 LnkSta: Speed 5GT/s, Width x1
> >                 LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
>
> Let me clarify, please...  This limitation to 2.5 GT/s came straight from
> Rockchip a few years ago, described back then as an undisclosed errata.
> Recently, we got some more details from Rockchip that confirmed 5 GT/s
> as having issues in certain corner cases that cannot be validated by
> performing some field tests or by observing the PCIe behavior under load.
> Those corner cases with 5 GT/s, as described by Rockchip, are quite hard
> to reach, but the possibility is still real.
>
> To sum it up, yes, multiple people have reported 5 GT/s as "working for me"
> on their RK3399-based boards and devices, but that unfortunately means
> nothing in this case, due to the specific nature of the underlying issue.
>

Not only that but the bandwidth actually earned is very small due to the
inherent limited interrupt processing capability of a single core, meaning
the 5 GT/s bandwidth / transfer speed is never fully utilized.

It's better than to force a slightly lower actual transfer speed than to risk
the liability of someone losing their data, period.

Regards,
Geraldo Nascimento

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ