[PATCH] pci: quirks: Advertise D3cold capability for UPD720201

[PATCH] pci: quirks: Advertise D3cold capability for UPD720201

[Sushrut Shree Trivedi]

PCIe-to-USB bridge UPD720201 does not advertise D3cold
support until firmware is loaded post pci enumeration.
This results in upd blocking D3cold entry during system
suspend and causing overall failure to enter XO
shutdown.

Hence, add a quirk to advertise D3cold PME capability
since the HW actually supports and advertises it post
firmware loading.

Signed-off-by: Sushrut Shree Trivedi <sushrut.trivedi@oss.qualcomm.com>
---
 drivers/pci/quirks.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index caaed1a01dc0..c32617ed33aa 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -6381,3 +6381,13 @@ static void pci_mask_replay_timer_timeout(struct pci_dev *pdev)
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9750, pci_mask_replay_timer_timeout);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9755, pci_mask_replay_timer_timeout);
 #endif
+
+/*
+ * Renesas PCIe-to-USB bridge UPD720201 does not advertise D3cold
+ * capability by default until firmware is loaded post-enumeration.
+ */
+static void quirk_enable_d3cold(struct pci_dev *dev)
+{
+	dev->pme_support = dev->pme_support | (1 << PCI_D3cold);
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_RENESAS, 0x0014, quirk_enable_d3cold);

---
base-commit: 0787c45ea08a13b5482e701fabc741877cf681f6
change-id: 20260430-d3cold_support-36dcf6011571

Best regards,
-- 
Sushrut Shree Trivedi <sushrut.trivedi@oss.qualcomm.com>

Re: [PATCH] pci: quirks: Advertise D3cold capability for UPD720201

[Bjorn Helgaas]

On Thu, Apr 30, 2026 at 10:12:18AM +0530, Sushrut Shree Trivedi wrote:
> PCIe-to-USB bridge UPD720201 does not advertise D3cold
> support until firmware is loaded post pci enumeration.
> This results in upd blocking D3cold entry during system
> suspend and causing overall failure to enter XO
> shutdown.

I think you're saying that the PM Capability in config space changes
when the firmware is loaded.  That makes me worry about what *other*
config space changes might happen when the firmware is loaded.
There's all sorts of stuff we do during enumeration that depends on
what's in config space.

> Hence, add a quirk to advertise D3cold PME capability
> since the HW actually supports and advertises it post
> firmware loading.
> 
> Signed-off-by: Sushrut Shree Trivedi <sushrut.trivedi@oss.qualcomm.com>
> ---
>  drivers/pci/quirks.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index caaed1a01dc0..c32617ed33aa 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -6381,3 +6381,13 @@ static void pci_mask_replay_timer_timeout(struct pci_dev *pdev)
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9750, pci_mask_replay_timer_timeout);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9755, pci_mask_replay_timer_timeout);
>  #endif
> +
> +/*
> + * Renesas PCIe-to-USB bridge UPD720201 does not advertise D3cold
> + * capability by default until firmware is loaded post-enumeration.

There are several mentions of "Renesas UPD720201/UPD720202 USB 3.0
xHCI Host Controller" in the tree.  I assume this is the same device?
If so, I think it'd be worth using similar terminology, i.e., "USB
xHCI host controller" instead of "PCIe-to-USB bridge"

> +static void quirk_enable_d3cold(struct pci_dev *dev)
> +{
> +	dev->pme_support = dev->pme_support | (1 << PCI_D3cold);
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_RENESAS, 0x0014, quirk_enable_d3cold);

How do we know that FINAL fixups happen after firmware loading?

Re: [PATCH] pci: quirks: Advertise D3cold capability for UPD720201

[Sushrut Shree Trivedi]

On 5/1/2026 2:44 AM, Bjorn Helgaas wrote:
> On Thu, Apr 30, 2026 at 10:12:18AM +0530, Sushrut Shree Trivedi wrote:
>> PCIe-to-USB bridge UPD720201 does not advertise D3cold
>> support until firmware is loaded post pci enumeration.
>> This results in upd blocking D3cold entry during system
>> suspend and causing overall failure to enter XO
>> shutdown.
> I think you're saying that the PM Capability in config space changes
> when the firmware is loaded.  That makes me worry about what *other*
> config space changes might happen when the firmware is loaded.
> There's all sorts of stuff we do during enumeration that depends on
> what's in config space.

Yeah, that's a valid concern here but we checked with renesas also and
they have confirmed this is the only delta in PCI config space before/after
firmware loading.

>
>> Hence, add a quirk to advertise D3cold PME capability
>> since the HW actually supports and advertises it post
>> firmware loading.
>>
>> Signed-off-by: Sushrut Shree Trivedi <sushrut.trivedi@oss.qualcomm.com>
>> ---
>>   drivers/pci/quirks.c | 10 ++++++++++
>>   1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index caaed1a01dc0..c32617ed33aa 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -6381,3 +6381,13 @@ static void pci_mask_replay_timer_timeout(struct pci_dev *pdev)
>>   DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9750, pci_mask_replay_timer_timeout);
>>   DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9755, pci_mask_replay_timer_timeout);
>>   #endif
>> +
>> +/*
>> + * Renesas PCIe-to-USB bridge UPD720201 does not advertise D3cold
>> + * capability by default until firmware is loaded post-enumeration.
> There are several mentions of "Renesas UPD720201/UPD720202 USB 3.0
> xHCI Host Controller" in the tree.  I assume this is the same device?
> If so, I think it'd be worth using similar terminology, i.e., "USB
> xHCI host controller" instead of "PCIe-to-USB bridge"
ACK'd.
>
>> +static void quirk_enable_d3cold(struct pci_dev *dev)
>> +{
>> +	dev->pme_support = dev->pme_support | (1 << PCI_D3cold);
>> +}
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_RENESAS, 0x0014, quirk_enable_d3cold);
> How do we know that FINAL fixups happen after firmware loading?
FINAL fixups would actually happen before firmware-loading because firmware
is loaded as part of xhci host controller driver probe. That shouldn't 
be an issue
because we know post successful firmware loading, D3cold is supported by
the xHCI controller. In the odd scenario that FW loading fails, xHCI 
controller
functionality will be completely broken and it makes sense to put it in 
D3cold.

Re: [PATCH] pci: quirks: Advertise D3cold capability for UPD720201

[Manivannan Sadhasivam]

On Tue, May 12, 2026 at 11:09:22AM +0530, Sushrut Shree Trivedi wrote:
> 
> On 5/1/2026 2:44 AM, Bjorn Helgaas wrote:
> > On Thu, Apr 30, 2026 at 10:12:18AM +0530, Sushrut Shree Trivedi wrote:
> > > PCIe-to-USB bridge UPD720201 does not advertise D3cold
> > > support until firmware is loaded post pci enumeration.
> > > This results in upd blocking D3cold entry during system
> > > suspend and causing overall failure to enter XO
> > > shutdown.
> > I think you're saying that the PM Capability in config space changes
> > when the firmware is loaded.  That makes me worry about what *other*
> > config space changes might happen when the firmware is loaded.
> > There's all sorts of stuff we do during enumeration that depends on
> > what's in config space.
> 
> Yeah, that's a valid concern here but we checked with renesas also and
> they have confirmed this is the only delta in PCI config space before/after
> firmware loading.
> 
> > 
> > > Hence, add a quirk to advertise D3cold PME capability
> > > since the HW actually supports and advertises it post
> > > firmware loading.
> > > 
> > > Signed-off-by: Sushrut Shree Trivedi <sushrut.trivedi@oss.qualcomm.com>
> > > ---
> > >   drivers/pci/quirks.c | 10 ++++++++++
> > >   1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > > index caaed1a01dc0..c32617ed33aa 100644
> > > --- a/drivers/pci/quirks.c
> > > +++ b/drivers/pci/quirks.c
> > > @@ -6381,3 +6381,13 @@ static void pci_mask_replay_timer_timeout(struct pci_dev *pdev)
> > >   DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9750, pci_mask_replay_timer_timeout);
> > >   DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9755, pci_mask_replay_timer_timeout);
> > >   #endif
> > > +
> > > +/*
> > > + * Renesas PCIe-to-USB bridge UPD720201 does not advertise D3cold
> > > + * capability by default until firmware is loaded post-enumeration.
> > There are several mentions of "Renesas UPD720201/UPD720202 USB 3.0
> > xHCI Host Controller" in the tree.  I assume this is the same device?
> > If so, I think it'd be worth using similar terminology, i.e., "USB
> > xHCI host controller" instead of "PCIe-to-USB bridge"
> ACK'd.
> > 
> > > +static void quirk_enable_d3cold(struct pci_dev *dev)
> > > +{
> > > +	dev->pme_support = dev->pme_support | (1 << PCI_D3cold);
> > > +}
> > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_RENESAS, 0x0014, quirk_enable_d3cold);
> > How do we know that FINAL fixups happen after firmware loading?
> FINAL fixups would actually happen before firmware-loading because firmware
> is loaded as part of xhci host controller driver probe. That shouldn't be an
> issue
> because we know post successful firmware loading, D3cold is supported by
> the xHCI controller. In the odd scenario that FW loading fails, xHCI
> controller
> functionality will be completely broken and it makes sense to put it in
> D3cold.
> 

This patch has nothing to do with firmware loading. The issue is, these Renesas
devices only expose the proper PME capability (PME from D3Cold) after loading
the firmware and their Reset value of the PME capability is wrong.

So when the PCI core reads the PME capability in pci_pm_init() (which happens
way before driver loading), it caches the wrong value and it stays like that
even after the device updates the capability with firmware loading.

And this quirk directly updates the cached value with device's actual
capability.

- Mani

-- 
மணிவண்ணன் சதாசிவம்