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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGb2v64FiDObsGx4A3m=HNP4xMKirXCK2PoCNtQci-DG4cU8yA@mail.gmail.com>
Date: Wed, 14 Jan 2026 18:02:32 +0800
From: Chen-Yu Tsai <wens@...nel.org>
To: Manivannan Sadhasivam <mani@...nel.org>
Cc: Sean Anderson <sean.anderson@...o.com>, manivannan.sadhasivam@....qualcomm.com, 
	Lorenzo Pieralisi <lpieralisi@...nel.org>, Krzysztof Wilczyński <kwilczynski@...nel.org>, 
	Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>, 
	Bartosz Golaszewski <brgl@...ev.pl>, linux-pci@...r.kernel.org, linux-arm-msm@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Brian Norris <briannorris@...omium.org>, 
	Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>, Niklas Cassel <cassel@...nel.org>, 
	Alex Elder <elder@...cstar.com>, 
	Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>, Chen-Yu Tsai <wenst@...omium.org>, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [PATCH v4 0/8] PCI/pwrctrl: Major rework to integrate pwrctrl
 devices with controller drivers

On Wed, Jan 14, 2026 at 4:48 PM Manivannan Sadhasivam <mani@...nel.org> 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