Message-ID: <CAGb2v65acHoO5025ZN7DhX0xVQf6JyHmUK3CB9UhnmTDDHq6vg@mail.gmail.com>
Date: Wed, 22 Oct 2025 00:39:41 +0800
From: Chen-Yu Tsai <wens@...nel.org>
To: Manivannan Sadhasivam <mani@...nel.org>
Cc: Bartosz Golaszewski <brgl@...ev.pl>, Bjorn Helgaas <bhelgaas@...gle.com>, 
	linux-kernel <linux-kernel@...r.kernel.org>, 
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>, PCI <linux-pci@...r.kernel.org>, 
	"open list:THERMAL" <linux-pm@...r.kernel.org>
Subject: PCIe link training and pwrctrl sequence

(recipient list trimmed down and added PCI & pwrctrl maintainers and lists)

On Tue, Oct 21, 2025 at 8:54 PM Manivannan Sadhasivam <mani@...nel.org> wrote:
>
> On Tue, Oct 21, 2025 at 02:22:46PM +0200, Bartosz Golaszewski wrote:
> > On Tue, Oct 21, 2025 at 2:20 PM Manivannan Sadhasivam <mani@...nel.org> wrote:
> > >
> > > >
> > > > And with the implementation this series proposes it would mean that
> > > > the perst signal will go high after the first endpoint pwrctl driver
> > > > sets it to high and only go down once the last driver sets it to low.
> > > > The only thing I'm not sure about is the synchronization between the
> > > > endpoints - how do we wait for all of them to be powered-up before
> > > > calling the last gpiod_set_value()?
> > > >
> > >
> > > That will be handled by the pwrctrl core. Not today, but in the coming days.
> > >
> >
> > But is this the right approach or are you doing it this way *because*
> > there's no support for enable-counted GPIOs as of yet?
> >
>
> This is the right approach since as of today, pwrctrl core scans the bus, tries
> to probe the pwrctrl driver (if one exists for the device to be scanned), powers
> it ON, and deasserts the PERST#. If the device is a PCI bridge/switch, then the
> devices underneath the downstream bus will only be powered ON after the further
> rescan of the downstream bus. But the pwrctrl drivers for those devices might
> get loaded at any time (even after the bus rescan).
>
> This causes several issues with the PCI core as this behavior sort of emulates
> the PCI hot-plug (devices showing up at random times after bus scan). If the
> upstream PCI bridge/switch is not hot-plug capable, then the devices that were
> showing up later will fail to enumerate due to lack of resources. The failure
> is due to PCI core limiting the resources for non hot-plug PCI bridges as it
> doesn't expect the devices to show up later in the downstream port.

Side note:

Today I was looking into how the PCI core does slot pwrctrl, and it doesn't
really work for some of the PCI controller drivers.

The pwrctrl stuff happens after the driver adds the host bus bridge.
However drivers are doing link training before that. If the power is
not on, link training will fail, and the driver errors out. It never
has a chance to get to pwrctrl.

I wonder if some bits should be split out so they could be interleaved with
link management on the host side. AFAICT only dwc and qcom will rescan the
bus when an interrupt says the link is up. Other controllers might not have
such an interrupt notification. I was looking at the MediaTek gen3 driver
specifically.

Otherwise I think the DT representation for the PCIe slot power is great.


Thanks
ChenYu

> One way to fix this issue is by making sure all the pwrctrl capable devices
> underneath a PCI bridge getting probed, powered ON, and finally deasserting the
> PERST# for each one of them. If the PERST# happens to be shared, it will be
> deasserted once at the last. And this order has to be ensured by the pwrctrl
> core irrespective of the shared PERST#.
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
>

Powered by blists - more mailing lists