Re: Clear CLKREQ# override breaks functionality

[Franz Schnyder]

On Thu, Mar 26, 2026 at 08:17:29AM +0000, Hongxing Zhu wrote:
> > -----Original Message-----
> > From: Franz Schnyder <fra.schnyder@xxxxxxxxx>
> > Sent: 2026年3月26日 16:00
> > To: Hongxing Zhu <hongxing.zhu@xxxxxxx>
> > Cc: Franz Schnyder <franz.schnyder@xxxxxxxxxxx>;
> > linux-pci@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx;
> > imx@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Francesco Dolcini
> > <francesco@xxxxxxxxxx>; Manivannan Sadhasivam <mani@xxxxxxxxxx>; Frank
> > Li <frank.li@xxxxxxx>
> > Subject: Clear CLKREQ# override breaks functionality
> > 
> > Hi Richard,
> > 
> > While integrating the `supports-clkreq` DT property on our iMX95-based
> > SoM, we had failures in our CI on one of the two M.2 PCIe slots on our
> > development board.
> > The failing slot uses a card that does not advertise L1 PM substates.
> > This issue comes from commit a152a90f5390 ("PCI: imx6: Clear CLKREQ#
> > override if 'supports-clkreq' DT property is available"), which clears the
> > CLKREQ# override based only on the DT property.
> > 
> > It seems that clearing the CLKREQ# override should happen only when the
> > driver knows that the downstream device advertises L1 PM Substates.
> > Otherwise CLKREQ# should remain asserted to keep compatibility with cards
> > that do not support L1 PM Substates.
> > 
> > Thoughts?
> Hi Franz:
> No, CLKREQ# is not dependent on L1 PM Substates capabilities.
> 
> According to the PCI Express Card Electromechanical Specification r6.0,
> Section 2 (Auxiliary Signals):
> 
> "CLKREQ# (optional) signal is an open drain, active low signal that is driven
> low by the card to request that the PCI Express reference clock be available
> (active clock state) to allow the PCI Express interface to send/receive data."
> 
> When the 'supports-clkreq' property is present, it indicates that the endpoint
> device supports CLKREQ# signaling and will actively drive the signal low when
> it needs the reference clock.
> 
> Therefore, the RC (Root Complex) controller can safely clear any CLKREQ#
> active-low override settings, allowing the endpoint to control the clock
> request through proper CLKREQ# signaling.
> 
> If the endpoint devices on your platform can't drive the CLKREQ# signal to
> low, remove 'supports-clkreq' property from your board's device tree file.
> 
> Best Regards
> Richard Zhu
> > 
> > Kind Regards
> > 
> > Franz
Hi Richard,

Thanks for the explanation. I managed to find a PCIe specification, and
I can now see that my assumption was wrong. The L1 PM Substates mechanism
requires CLKREQ#, but not vice versa. To be safe with cards which lack
support, we'll just remove the 'supports-clkreq' property for now.

Kind regards

Franz