Re: [PATCH v4 0/8] PCI/pwrctrl: Major rework to integrate pwrctrl devices with controller drivers

[Chen-Yu Tsai]

On Wed, Jan 14, 2026 at 4:48 PM Manivannan Sadhasivam <mani@xxxxxxxxxx> wrote:

[...]

> > > The original design aimed to avoid modifying controller drivers for pwrctrl
> > > integration. However, this approach lacked scalability because different
> > > controllers have varying requirements for when devices should be powered on. For
> > > example, controller drivers require devices to be powered on early for
> > > successful PHY initialization.
> >
> > Can you elaborate on this? Previously you said
> >
> > | Some platforms do LTSSM during phy_init(), so they will fail if the
> > | device is not powered ON at that time.
> >
> > What do you mean by "do LTSSM during phy_init()"? Do you have a specific
> > driver in mind?
> >
>
> I believe the Mediatek PCIe controller driver used in Chromebooks exhibit this
> behavior. Chen talked about it in his LPC session:
> https://lpc.events/event/19/contributions/2023/

I don't remember all the details off the top of my head, but at least the
MediaTek and old (non-DesignWare) Rockchip drivers both did this:

    Wait for link up during the probe function; if it times out then
    nothing is there, and just fail the probe.

And this probably makes sense if the controller does not support hotplug,
and you want to keep unused devices / interfaces disabled to save power.

> > I would expect that the LTSSM would remain in the Detect state until the
> > pwrseq driver is being probed.
> >
>
> True, but if the API (phy_init()) expects the LTSSM to move to L0, then it will
> fail, right? It might be what's happening with above mentioned platform.

I can't remember if any drivers expected this. IIRC they waited for link up
in the probe function before registering the PCI host.

[...]


ChenYu