From: Chen-Yu Tsai <wens@kernel.org>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
PCI <linux-pci@vger.kernel.org>,
"open list:THERMAL" <linux-pm@vger.kernel.org>
Subject: PCIe link training and pwrctrl sequence
Date: Wed, 22 Oct 2025 00:39:41 +0800 [thread overview]
Message-ID: <CAGb2v65acHoO5025ZN7DhX0xVQf6JyHmUK3CB9UhnmTDDHq6vg@mail.gmail.com> (raw)
In-Reply-To: <ibdmghl5dg3oda2j5ejp35ydky4xkazewhdvskm7p32vstdegr@36pj32b6dt44>
(recipient list trimmed down and added PCI & pwrctrl maintainers and lists)
On Tue, Oct 21, 2025 at 8:54 PM Manivannan Sadhasivam <mani@kernel.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@kernel.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
>
> --
> மணிவண்ணன் சதாசிவம்
>
next parent reply other threads:[~2025-10-21 16:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250924-gpio-shared-v1-0-775e7efeb1a3@linaro.org>
[not found] ` <hyzzrjn7jzo3tt3oyg7azijouawe3zopfjzq6zfhoo6e6z2m4t@ssl5vl4g557e>
[not found] ` <zk4ea5cibrkp4vttuy4evrqybf76b3nop5lnyck4ws4nyf2yc4@ghj2eyswsoow>
[not found] ` <CAMRc=MdWmO4wvX6zpzN0-LZF1pF5Y2=sS8fBwr=CKMGWHg+shA@mail.gmail.com>
[not found] ` <rfr5cou6jr7wmtxixfgjxhnda6yywlsxsei7md7ne3qge7r3gk@xv6n5pvcjzrm>
[not found] ` <CAMRc=Me9Td5G9qZV8A98XkGROKw1D2UeQHpFzt8uApF8995MZw@mail.gmail.com>
[not found] ` <rvsyll4u6v4tpaxs4z3k4pbusoktkaocq4o3g6rjt6d2zrzqst@raiuch3hu3ce>
[not found] ` <CAMRc=Me+4H6G+-Qj_Gz2cv2MgRHOmrjMyNwJr+ardDR1ndYHvQ@mail.gmail.com>
[not found] ` <fydmplp5z4hjic2wlmvcy6yr3s5t5u4qsgo7yzbqq3xu2g6hdk@v4tzjj3ww4s6>
[not found] ` <CAMRc=McGuNX42k_HdV20zW+buACBTmTZEHWgS-ddRYsvnfwDSg@mail.gmail.com>
[not found] ` <ibdmghl5dg3oda2j5ejp35ydky4xkazewhdvskm7p32vstdegr@36pj32b6dt44>
2025-10-21 16:39 ` Chen-Yu Tsai [this message]
2025-11-05 9:31 ` PCIe link training and pwrctrl sequence Manivannan Sadhasivam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGb2v65acHoO5025ZN7DhX0xVQf6JyHmUK3CB9UhnmTDDHq6vg@mail.gmail.com \
--to=wens@kernel.org \
--cc=bhelgaas@google.com \
--cc=brgl@bgdev.pl \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mani@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).