[PATCH v2 1/4] PCI: dwc: Advertise L1 PM Substates only if driver requests it

Shawn Lin shawn.lin at rock-chips.com
Wed Nov 19 16:53:38 PST 2025


在 2025/11/19 星期三 23:58, Frank Li 写道:
> On Wed, Nov 19, 2025 at 12:08:41PM +0100, Niklas Cassel wrote:
>> On Tue, Nov 18, 2025 at 05:34:18PM -0500, Frank Li wrote:
>>> On Tue, Nov 18, 2025 at 03:42:15PM -0600, Bjorn Helgaas wrote:
>>>> From: Bjorn Helgaas <bhelgaas at google.com>
>>>>
>>>> L1 PM Substates require the CLKREQ# signal and may also require
>>>> device-specific support.  If CLKREQ# is not supported or driver support is
>>>> lacking, enabling L1.1 or L1.2 may cause errors when accessing devices,
>>>> e.g.,
>>>>
>>>>    nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10
>>>>
>>>> If the kernel is built with CONFIG_PCIEASPM_POWER_SUPERSAVE=y or users
>>>> enable L1.x via sysfs, users may trip over these errors even if L1
>>>> Substates haven't been enabled by firmware or the driver.
>>>>
>>>> To prevent such errors, disable advertising the L1 PM Substates unless the
>>>> driver sets "dw_pcie.l1ss_support" to indicate that it knows CLKREQ# is
>>>> present and any device-specific configuration has been done.
>>>>
>>>> Set "dw_pcie.l1ss_support" in tegra194 (if DT includes the
>>>> "supports-clkreq' property) and qcom (for cfg_2_7_0, cfg_1_9_0, cfg_1_34_0,
>>>> and cfg_sc8280xp controllers) so they can continue to use L1 Substates.
>>>>
>>>> Based on Niklas's patch:
>>>> https://patch.msgid.link/20251017163252.598812-2-cassel@kernel.org
>>>>
>>>> Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
>>>> ---
>>>>   .../pci/controller/dwc/pcie-designware-ep.c   |  2 ++
>>>>   .../pci/controller/dwc/pcie-designware-host.c |  2 ++
>>>>   drivers/pci/controller/dwc/pcie-designware.c  | 24 +++++++++++++++++++
>>>>   drivers/pci/controller/dwc/pcie-designware.h  |  2 ++
>>>>   drivers/pci/controller/dwc/pcie-qcom.c        |  2 ++
>>>>   drivers/pci/controller/dwc/pcie-tegra194.c    |  3 +++
>>>>   6 files changed, 35 insertions(+)
>>>>
>>>> diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
>>>> index 7f2112c2fb21..ad6c0fd67a65 100644
>>>> --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
>>>> +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
>>>> @@ -966,6 +966,8 @@ int dw_pcie_ep_init_registers(struct dw_pcie_ep *ep)
>>>>   	if (ep->ops->init)
>>>>   		ep->ops->init(ep);
>>>>
>>>> +	dw_pcie_hide_unsupported_l1ss(pci);
>>>> +
>>>
>>> And, I don't think EP need clean L1SS CAP flags. If EP don't support L1SS,
>>> it should be force pull down #clkreq.
>>
>> I think the problem is that we cannot force pull down CLKREQ# in a generic
>> DWC function. That would have to be done in glue driver specific callbacks.
>>
>> Bjorn, perhaps we should simply drop the dw_pcie_hide_unsupported_l1ss()
>> call from dw_pcie_ep_init_registers(), and consider hiding L1ss for EPs to
>> be out of scope for this series.
> 
> 
> Agree, we should consider EP later. When work at EP mode, #clkreq default
> it is 0. RC should not turn L1SS if RC don't support. If RC side support,
> it should be fine by turing on EP's L1SS because hardware already support
> it.

I agree to drop it from dw_pcie_ep_init_registers, and queue it up for
6.19.

Don't get me wrong, but I just need clearly speak out the thought: I
think the idea behind is something like quirk that a variant controller
works on EP mode claiming L1ss available through *CAP* regs but actually
it doesn't. This is nothing related to RC side, even if it pulls down
CLKREQ# to reject negotiation for L1ss, it still looks wrong from lspci
view. So of course, we could leave it to the glue driver to explictly
eliminate L1SS capability later. If they want, just export
dw_pcie_hide_unsupported_l1ss() the call it.

> 
> Frank
> 
>>
>> That way, we could still queue this series up for 6.19.
>>
>> Thoughts from everyone?
>>
>>
>>
>> Kind regards,
>> Niklas
> 




More information about the Linux-rockchip mailing list