Linux PCI subsystem development
 help / color / mirror / Atom feed
From: "Dragan Simic" <dsimic@manjaro.org>
To: "Anand Moon" <linux.amoon@gmail.com>
Cc: "Geraldo Nascimento" <geraldogabriel@gmail.com>,
	"Shawn Lin" <shawn.lin@rock-chips.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Johan Jonker" <jbx6244@gmail.com>,
	linux-rockchip@lists.infradead.org, linux-pci@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 1/4] PCI: rockchip:  limit RK3399 to 2.5 GT/s to prevent damage
Date: Wed, 24 Dec 2025 17:52:03 +0100	[thread overview]
Message-ID: <648aa5c0-9e58-2404-4250-e83b8a748601@manjaro.org> (raw)
In-Reply-To: <CANAwSgS6UeR4PJnWDxxcQbdH8u_4uNiQxCTugQS35LcPvpiwMQ@mail.gmail.com>

On Wednesday, December 24, 2025 17:11 CET, Anand Moon <linux.amoon@gmail.com> wrote:
> On Wed, 24 Dec 2025 at 18:25, Dragan Simic <dsimic@manjaro.org> wrote:
> > On Wednesday, December 24, 2025 09:04 CET, Anand Moon <linux.amoon@gmail.com> wrote:
> > > On Wed, 24 Dec 2025 at 11:08, Geraldo Nascimento
> > > <geraldogabriel@gmail.com> wrote:
> > > > On Wed, Dec 24, 2025 at 2:18 AM Anand Moon <linux.amoon@gmail.com> wrote:
> > > > > On Tue, 18 Nov 2025 at 03:17, Geraldo Nascimento
> > > > > <geraldogabriel@gmail.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.


  reply	other threads:[~2025-12-24 16:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-17 21:46 [PATCH v2 0/4] PCI: rockchip: 5.0 GT/s speed may be dangerous Geraldo Nascimento
2025-11-17 21:47 ` [PATCH v2 1/4] PCI: rockchip: limit RK3399 to 2.5 GT/s to prevent damage Geraldo Nascimento
2025-12-18  8:05   ` Manivannan Sadhasivam
2025-12-18  9:47     ` Dragan Simic
2025-12-18 10:01       ` Diederik de Haas
2025-12-18 10:13         ` Dragan Simic
2025-12-24  2:24           ` Geraldo Nascimento
2025-12-24  5:18   ` Anand Moon
2025-12-24  5:38     ` Geraldo Nascimento
2025-12-24  8:04       ` Anand Moon
2025-12-24 12:55         ` Dragan Simic
2025-12-24 16:11           ` Anand Moon
2025-12-24 16:52             ` Dragan Simic [this message]
2025-12-24 21:57               ` Geraldo Nascimento
2025-11-17 21:47 ` [PATCH v2 2/4] PCI: rockchip-host: comment danger of 5.0 GT/s speed Geraldo Nascimento
2025-11-17 21:47 ` [PATCH v2 3/4] arm64: dts: rockchip: remove dangerous max-link-speed from helios64 Geraldo Nascimento
2025-11-17 21:47 ` [PATCH v2 4/4] arm64: dts: rockchip: remove redundant max-link-speed from nanopi-r4s Geraldo Nascimento
2025-11-18  0:43 ` [PATCH v2 0/4] PCI: rockchip: 5.0 GT/s speed may be dangerous Shawn Lin
2025-12-22 13:38 ` (subset) " Heiko Stuebner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=648aa5c0-9e58-2404-4250-e83b8a748601@manjaro.org \
    --to=dsimic@manjaro.org \
    --cc=bhelgaas@google.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=geraldogabriel@gmail.com \
    --cc=heiko@sntech.de \
    --cc=jbx6244@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux.amoon@gmail.com \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=robh@kernel.org \
    --cc=shawn.lin@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox