Message-ID: <72e23e5a-6fdb-42c1-8d09-70a4d0890307@rock-chips.com>
Date: Fri, 16 Jan 2026 22:48:12 +0800
From: Shawn Lin <shawn.lin@...k-chips.com>
To: Niklas Cassel <cassel@...nel.org>, Manivannan Sadhasivam <mani@...nel.org>
Cc: shawn.lin@...k-chips.com, 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,
 Chen-Yu Tsai <wens@...nel.org>, Brian Norris <briannorris@...omium.org>,
 Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>,
 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

在 2026/01/16 星期五 21:40, Niklas Cassel 写道:
> On Fri, Jan 16, 2026 at 11:54:26AM +0530, Manivannan Sadhasivam wrote:
>> On Thu, Jan 15, 2026 at 02:26:32PM -0500, Sean Anderson wrote:
>>>>
>>>> Not at all. We cannot model PERST# as a GPIO in all the cases. Some drivers
>>>> implement PERST# as a set of MMIO operations in the Root Complex MMIO space and
>>>> that space belongs to the controller driver.
>>>
>>> That's what I mean. Implement a GPIO driver with one GPIO and perform
>>> the MMIO operations as requested.
>>>
>>> Or we can invert things and add a reset op to pci_ops. If present then
>>> call it, and if absent use the PERST GPIO on the bridge.
>>>
>>
>> Having a callback for controlling the PERST# will work for the addressing the
>> PERST# issue, but it won't solve the PCIe switch issue we were talking above.
>> And this API design will fix both the problems.
>>
>> But even in this callback design, you need to have modifications in the existing
>> controller drivers to integrate pwrctrl. So how that is different from calling
>> just two (or one unified API for create/power_on)?
> 
> FWIW, I do think that it is a good idea to create a reset op to pci_ops
> that will implement PERST# assertion/deassertion.
> 

That's exactly what I had in mind when looking at different PCIe host
drivers that why individual drivers should implement their own powering
up sequence, regarding to the face that bringing devices up should
always follow the timing defined PCI Express Card Electromechanical
Specification R6.0.1, section 2.2.1 "Initial Power Up(G3 to S0)"


> Right now, it is a mess, with various drivers doing this at various
> different places.
> 
> Having a specific callback, the driver implement it however they want
> GPIO, MMIO, whatever, and it could even be called by (in case of DWC,
> the host_init, by pwrctrl, or potentially by the PCI core itself before
> enumerating the bus.
> 
> If we don't do something about it now, the problem will just get worse
> with time. Yes, it will take time before all drivers have migrated and
> been tested to have a dedicated PERST# reset op, but for the long term
> maintainability, I think it is something that we should do.

Ack. That will also consolidate more timing relate improvements
together. For instance, almost all drivers holds PERST# for 100ms
Tpvperl before release it, but 100ms is the minimal value defined by
spec. I have to say it's broken for several EP cards I have debugged in 
practice these years. With holding all powering up timing together into
pwrctrl design could really helpful in the future.


> 
> I also know that some drivers have some loops with retry logic, where
> they might go down in link speed, but right now I don't see why those
> drivers shouldn't be able to keep that retry logic just because we
> add a dedicated PERST# callback.
> 
> 
> All that said, that would be a separate endeavor and can be implemented
> later.
> 
> 
> Kind regards,
> Niklas
> 
> 

Powered by blists - more mailing lists