linux-kernel - Re: [PATCH v5 2/2] PCI: imx6: Add a method to handle CLKREQ# override active low

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: <aNcaeGOEvDsSOFYM@lizhi-Precision-Tower-5810>
Date: Fri, 26 Sep 2025 18:58:00 -0400
From: Frank Li <Frank.li@....com>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Hongxing Zhu <hongxing.zhu@....com>,
	"jingoohan1@...il.com" <jingoohan1@...il.com>,
	"l.stach@...gutronix.de" <l.stach@...gutronix.de>,
	"lpieralisi@...nel.org" <lpieralisi@...nel.org>,
	"kwilczynski@...nel.org" <kwilczynski@...nel.org>,
	"mani@...nel.org" <mani@...nel.org>,
	"robh@...nel.org" <robh@...nel.org>,
	"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"shawnguo@...nel.org" <shawnguo@...nel.org>,
	"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>,
	"festevam@...il.com" <festevam@...il.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 2/2] PCI: imx6: Add a method to handle CLKREQ#
 override active low

On Fri, Sep 26, 2025 at 03:24:31PM -0500, Bjorn Helgaas wrote:
> On Fri, Sep 26, 2025 at 03:23:43AM +0000, Hongxing Zhu wrote:
> > > -----Original Message-----
> > > From: Bjorn Helgaas <helgaas@...nel.org>
>
> > > On Fri, Sep 26, 2025 at 02:19:37AM +0000, Hongxing Zhu wrote:
> > > > > -----Original Message-----
> > > > > From: Bjorn Helgaas <helgaas@...nel.org> On Tue, Sep 23, 2025 at
> > > > > 03:39:13PM +0800, Richard Zhu wrote:
> > > > > > The CLKREQ# is an open drain, active low signal that is driven low
> > > > > > by the card to request reference clock. It's an optional signal
> > > > > > added in PCIe CEM r4.0, sec 2. Thus, this signal wouldn't be
> > > > > > driven low if it's reserved.
> > > > > >
> > > > > > Since the reference clock controlled by CLKREQ# may be required by
> > > > > > i.MX PCIe host too. To make sure this clock is ready even when the
> > > > > > CLKREQ# isn't driven low by the card(e.x the scenario described
> > > > > > above), force CLKREQ# override active low for i.MX PCIe host
> > > > > > during initialization.
> > > > > >
> > > > > > The CLKREQ# override can be cleared safely when supports-clkreq is
> > > > > > present and PCIe link is up later. Because the CLKREQ# would be
> > > > > > driven low by the card at this time.
> > > > >
> > > > > What happens if we clear the CLKREQ# override (so the host doesn't
> > > > > assert it), and the link is up but the card never asserts CLKREQ#
> > > > > (since it's an optional signal)?
> > > > >
> > > > > Does the i.MX host still work?
> > > >
> > > > The CLKREQ# override active low only be cleared when link is up
> > > > and supports-clkreq is present. In the other words, there is a
> > > > remote endpoint  device, and the CLKREQ# would be driven active
> > > > low by this endpoint device.
> > >
> > > Assume an endpoint designed to CEM r2.0.  CLKREQ# doesn't exist in
> > > CEM r2.0, so even if the endpoint is present and the link is up,
> > > the endpoint will not assert CLKREQ#.
> > >
> > > Will the i.MX host still work?
> > >
> > > IIUC, CLKREQ# is required for ASPM L1 PM Substates.  Maybe the
> > > CLKREQ# override should only be cleared if the endpoint advertises
> > > L1 PM Substates support?
> >
> > CLKREQ# override active low only be cleared when the endpoint
> > advertises that it has L1 PM Substates support or it always drives
> > CLKREQ# low.
>
> What?  That's not what the patch does.  It calls .clr_clkreq_override()
> whenever the link is up and devicetree contains 'support-clkreq'.
>
> A device advertises L1 PM Substates support by putting the L1 PM
> Substates Capability in its config space.

Regardless L1SS state, EP will pull down CLKREQ# by spec requirement.
'support-clkreq' indicate board design connect this signal, so host needn't
force it to low.

Additional support-clkreq require use open drain to connect both EP and RC's
CLKREQ#, some old board design use OR gate, which should not claim
support-clkreq.

The key point if CLKREQ# is connected. If clkreq# connected between EP
and RC, we can release override.

Frank

>
> > > > > > static void imx_pcie_host_post_init(struct dw_pcie_rp *pp)
> > > > > >  		dw_pcie_writel_dbi(pci, GEN3_RELATED_OFF, val);
> > > > > >  		dw_pcie_dbi_ro_wr_dis(pci);
> > > > > >  	}
> > > > > > +
> > > > > > +	/* Clear CLKREQ# override if supports_clkreq is true and link is up */
> > > > > > +	if (dw_pcie_link_up(pci) && imx_pcie->supports_clkreq) {
> > > > > > +		if (imx_pcie->drvdata->clr_clkreq_override)
> > > > > > +			imx_pcie->drvdata->clr_clkreq_override(imx_pcie);
> > > > > > +	}