On Fri, Sep 26, 2025 at 03:08:30AM +0000, Hongxing Zhu wrote:

quoted

-----Original Message-----
From: Bjorn Helgaas <helgaas@kernel.org>

quoted

On Fri, Sep 26, 2025 at 02:19:37AM +0000, Hongxing Zhu wrote:

quoted

quoted

-----Original Message-----
From: Bjorn Helgaas <helgaas@kernel.org> On Tue, Sep 23, 2025 at
03:39:13PM +0800, Richard Zhu wrote:

quoted

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?

Yes, i.MX host still work. 
If the endpoint designed to CEM r2.0, and CLKREQ# is reserved. The
property suppots-clkreq wouldn't present in this scenario. Thus, the
CLKREQ# override active low set by host driver wouldn't be cleared
later, although the link is up and an endpoint is present.

Do you mean 'supports-clkreq' describes the *endpoint*, and you need
to change the devicetree depending on which endpoint is connected?

The schema says 'supports-clkreq' tells us whether CLKREQ# signal
routing exists, not whether the downstream device actually supports
CLKREQ#:

  https://github.com/devicetree-org/dt-schema/blob/4b28bc79fdc552f3e0b870ef1362bb711925f4f3/dtschema/schemas/pci/pci-bus-common.yaml#L155

I don't see 'supports-clkreq' in any devicetree related to imx6, so
I'm not sure this patch is needed yet.  Does it fix an existing
problem?

If it enables some future functionality, maybe we should defer it
until we're actually ready to enable that functionality?

Bjorn