linux-kernel - Re: [PATCH v2 0/7] Introduce SpacemiT K1 PCIe phy and host controller

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: <ywr66wfkfay3xse77mb7ddbga5nced4yg7dapiybj3p2yp2an2@7zsaj5one5in>
Date: Fri, 31 Oct 2025 11:40:20 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Aurelien Jarno <aurelien@...el32.net>
Cc: Johannes Erdfelt <johannes@...felt.com>, 
	Alex Elder <elder@...cstar.com>, robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org, 
	bhelgaas@...gle.com, lpieralisi@...nel.org, kwilczynski@...nel.org, vkoul@...nel.org, 
	kishon@...nel.org, dlan@...too.org, guodong@...cstar.com, pjw@...nel.org, 
	palmer@...belt.com, aou@...s.berkeley.edu, alex@...ti.fr, p.zabel@...gutronix.de, 
	christian.bruel@...s.st.com, shradha.t@...sung.com, krishna.chundru@....qualcomm.com, 
	qiang.yu@....qualcomm.com, namcao@...utronix.de, thippeswamy.havalige@....com, 
	inochiama@...il.com, devicetree@...r.kernel.org, linux-pci@...r.kernel.org, 
	linux-phy@...ts.infradead.org, spacemit@...ts.linux.dev, linux-riscv@...ts.infradead.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/7] Introduce SpacemiT K1 PCIe phy and host controller

On Thu, Oct 30, 2025 at 06:49:37PM +0100, Aurelien Jarno wrote:
> Hi Mani,
> 
> On 2025-10-30 22:11, Manivannan Sadhasivam wrote:
> > + Aurelien
> > 
> > On Tue, Oct 28, 2025 at 01:48:32PM -0700, Johannes Erdfelt wrote:
> > > On Tue, Oct 28, 2025, Alex Elder <elder@...cstar.com> wrote:
> > > > On 10/28/25 1:42 PM, Johannes Erdfelt wrote:
> > > > > I have been testing this patchset recently as well, but on an Orange Pi
> > > > > RV2 board instead (and an extra RV2 specific patch to enable power to
> > > > > the M.2 slot).
> > > > > 
> > > > > I ran into the same symptoms you had ("QID 0 timeout" after about 60
> > > > > seconds). However, I'm using an Intel 600p. I can confirm my NVME drive
> > > > > seems to work fine with the "pcie_aspm=off" workaround as well.
> > > > 
> > > > I don't see this problem, and haven't tried to reproduce it yet.
> > > > 
> > > > Mani told me I needed to add these lines to ensure the "runtime
> > > > PM hierarchy of PCIe chain" won't be "broken":
> > > > 
> > > > 	pm_runtime_set_active()
> > > > 	pm_runtime_no_callbacks()
> > > > 	devm_pm_runtime_enable()
> > > > 
> > > > Just out of curiosity, could you try with those lines added
> > > > just before these assignments in k1_pcie_probe()?
> > > > 
> > > > 	k1->pci.dev = dev;
> > > > 	k1->pci.ops = &k1_pcie_ops;
> > > > 	dw_pcie_cap_set(&k1->pci, REQ_RES);
> > > > 
> > > > I doubt it will fix what you're seeing, but at the moment I'm
> > > > working on something else.
> > > 
> > > Unfortunately there is no difference with the runtime PM hierarchy
> > > additions.
> > > 
> > 
> > These are not supposed to fix the issues you were facing. I discussed with Alex
> > offline and figured out that L1 works fine on his BPI-F3 board with a NVMe SSD.
> > 
> > And I believe, Aurelien is also using that same board, but with different
> > SSDs. But what is puzzling me is, L1 is breaking Aurelien's setup with 3 SSDs
> > from different vendors. It apparently works fine on Alex's setup. So it somehow
> > confirms that Root Port supports and behaves correctly with L1. But at the same
> > time, I cannot just say without evidence that L1 is broken on all these SSDs
> > that you and Aurelien tested with.
> 
> It could be that we have different revision of the BPI-F3 board, it's 
> not impossible that I got an early-ish version. That said I just 
> visually checked the PCB against the schematics, and the devices on the 
> CLKREQN line appear to be installed.
> 

CLKREQ# is only needed for L1 PM Substates (L1.1 and L1.2). In other ASPM states
(L0s and L1), REFCLK is supposed to be ON. So those don't need CLKREQ# assertion
by the endpoint.

The L1 issue you are facing could be due to the board routing issue also. I'm
just speculating here.

> If someone has contacts to check what changes have been done between the 
> different board revision, that could help. Or same if there are 
> different revisions of the SpacemiT K1 chip.
> 

I hope Alex can get this information.

- Mani

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