linux-kernel - Re: [RFC PATCH v3 2/3] PCI: rockchip-host: Retry link training on failure without PERST#

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aHj_ue-eFQu_NgHd@geday>
Date: Thu, 17 Jul 2025 10:50:49 -0300
From: Geraldo Nascimento <geraldogabriel@...il.com>
To: Manivannan Sadhasivam <mani@...nel.org>
Cc: Shawn Lin <shawn.lin@...k-chips.com>,
	linux-rockchip@...ts.infradead.org,
	Hugh Cole-Baker <sigmaris@...il.com>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof Wilczyński <kw@...ux.com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
	Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
	Heiko Stuebner <heiko@...ech.de>, linux-pci@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v3 2/3] PCI: rockchip-host: Retry link training on
 failure without PERST#

On Thu, Jul 17, 2025 at 05:59:32PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Jun 23, 2025 at 08:44:49AM GMT, Geraldo Nascimento wrote:
> > On Mon, Jun 23, 2025 at 05:29:46AM -0600, Manivannan Sadhasivam wrote:
> > > On Tue, Jun 10, 2025 at 04:05:40PM -0300, Geraldo Nascimento wrote:
> > > > +reinit:
> > > 
> > > So this reinit part only skips the PERST# assert, but calls
> > > rockchip_pcie_init_port() which resets the Root Port including PHY. I don't
> > > think it is safe to do it if PERST# is wired.
> > 
> > I don't understand, could you be a bit more verbose on why do you
> > think this is dangerous?
> > 
> 
> When the Root Port and PHY gets reset, there is a good chance that the refclk
> would also be cutoff. So if that happens without PERST# assert, then the device
> has no chance to clean its state machine. If the device gets its own refclk,
> then it is a different story, but we should not make assumptions.

Hi Mani, thank you for your time spent looking into this!

I'm not sure if the following information helps, but patch 2 of this
series disables the PCIe 3.3V always-on/boot-on through DT. That was
not incidental, and in fact it is required for patch 1 to work.

Then, if you follow the proposed code change, you will see that power
is effectively cut via disabling the power regulators, even before
disabling the clocks. So there's effectively zero chance of corrupting
the endpoint device state machine, since the device is power-cycled.

While I understand we should not make assumptions on kernel work, and
that the patch is unmergeable on its current form (it's a goddamn hack),
it does empirically alleviate a very real report, that of known-good
working devices refusing to cooperate with Rockchip-IP PCIe.

I agree we should wait on Shawn Lin's feedback.

Thank you,
Geraldo Nascimento

> 
> - Mani
> 
> -- 
> மணிவண்ணன் சதாசிவம்