Re: [PATCH v3 03/12] PCI: Move check for old Apple Thunderbolt controllers into a quirk

["Limonciello, Mario" <mario.limonciello@amd.com>]

On 2/11/2022 15:35, Bjorn Helgaas wrote:
> On Fri, Feb 11, 2022 at 01:32:41PM -0600, Mario Limonciello wrote:
>> `pci_bridge_d3_possible` currently checks explicitly for a Thunderbolt
>> controller to indicate that D3 is possible.  As this is used solely
>> for older Apple systems, move it into a quirk that enumerates across
>> all Intel TBT controllers.
>>
>> Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>> ---
>>   drivers/pci/pci.c    | 12 +++++-----
>>   drivers/pci/quirks.c | 53 ++++++++++++++++++++++++++++++++++++++++++++
>>   2 files changed, 60 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index 9ecce435fb3f..5002e214c9a6 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -1064,7 +1064,13 @@ static inline bool platform_pci_bridge_d3(struct pci_dev *dev)
>>   	if (pci_use_mid_pm())
>>   		return false;
>>   
>> -	return acpi_pci_bridge_d3(dev);
>> +	if (acpi_pci_bridge_d3(dev))
>> +		return true;
>> +
>> +	if (device_property_read_bool(&dev->dev, "HotPlugSupportInD3"))
>> +		return true;
> 
> Why do we need this?  acpi_pci_bridge_d3() already looks for
> "HotPlugSupportInD3".

The Apple machines don't have ACPI companion devices that specify this 
property.

I guess this probes a different question; can 
`device_property_read_bool` be used in `acpi_pci_bridge_d3` instead of:

	if (acpi_dev_get_property(adev, "HotPlugSupportInD3",
				   ACPI_TYPE_INTEGER, &obj) < 0)
		return false;

	return obj->integer.value == 1;

If so, then yeah this can probably be simplified.

> 
>> +	return false;
>>   }
>>   
>>   /**
>> @@ -2954,10 +2960,6 @@ bool pci_bridge_d3_possible(struct pci_dev *bridge)
>>   		if (pci_bridge_d3_force)
>>   			return true;
>>   
>> -		/* Even the oldest 2010 Thunderbolt controller supports D3. */
>> -		if (bridge->is_thunderbolt)
>> -			return true;
>> -
>>   		/* Platform might know better if the bridge supports D3 */
>>   		if (platform_pci_bridge_d3(bridge))
>>   			return true;
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index 6d3c88edde00..aaf098ca7d54 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -3756,6 +3756,59 @@ DECLARE_PCI_FIXUP_SUSPEND_LATE(PCI_VENDOR_ID_INTEL,
>>   			       quirk_apple_poweroff_thunderbolt);
>>   #endif
>>   
>> +/* Apple machines as old as 2010 can do D3 with Thunderbolt controllers, but don't specify
>> + * it in the ACPI tables
> 
> Wrap to fit in 80 columns like the rest of the file.  Also use the:
> 
>    /*
>     * comment ...
>     */
> 
> style if it's more than one line.
> 
> I don't think "as old as 2010" is helpful here -- I assume 2010 is
> there because there *were* no Thunderbolt controllers before 2010, but
> the code doesn't check any dates, so we basically assume all Apple
> machines of any age with the listed controllers can do this.

The old comment was saying that, which is where I got it from.  Yeah, 
I'll update it.

> 
>> + */
>> +static void quirk_apple_d3_thunderbolt(struct pci_dev *dev)
>> +{
>> +	struct property_entry properties[] = {
>> +		PROPERTY_ENTRY_BOOL("HotPlugSupportInD3"),
>> +		{},
>> +	};
>> +
>> +	if (!x86_apple_machine)
>> +		return;
> 
> The current code doesn't check x86_apple_machine, so this needs some
> justification.  How do I know this works the same as before?

Mika and Lucas were saying the only reason for this codepath was Apple 
machines in the first place, which is where this idea came from.

Something specifically relevant is that the Apple machines use a SW 
connection manager, whereas everyone else up until USB4 devices use a 
firmware based connection manager with varying behaviors on generation 
(ICM).

> 
>> +
>> +	if (device_create_managed_software_node(&dev->dev, properties, NULL))
>> +		pci_warn(dev, "could not add HotPlugSupportInD3 property");
>> +}
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_LIGHT_RIDGE,
>> +			quirk_apple_d3_thunderbolt);
> 
> The current code assumes *all* Thunderbolt controllers support D3, so
> it would assume a controller released next year would support D3, but
> this code would assume the opposite.  Are we supposed to add
> everything to this list, or do newer machines supply
> HotPlugSupportInD3, or ...?

This quirk is intended specifically for Apple, which has stopped making 
Intel machines with Intel TBT controllers.

So I don't believe the list should be growing any more, if anything it 
might need to shrink if I got too many models that weren't actually in 
Apple products.  Lucas probably needs to confirm that.

> 
> How did you derive this list?  (Question for the commit log and/or
> comments here.)

I went to pci_ids.h and got all the Thunderbolt controllers listed there.

> 
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_EAGLE_RIDGE,
>> +			quirk_apple_d3_thunderbolt);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_LIGHT_PEAK,
>> +			quirk_apple_d3_thunderbolt);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C,
>> +			quirk_apple_d3_thunderbolt);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_2C,
>> +			quirk_apple_d3_thunderbolt);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PORT_RIDGE,
>> +			quirk_apple_d3_thunderbolt);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_REDWOOD_RIDGE_2C_NHI,
>> +			quirk_apple_d3_thunderbolt);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_REDWOOD_RIDGE_2C_BRIDGE,
>> +			quirk_apple_d3_thunderbolt);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_REDWOOD_RIDGE_4C_NHI,
>> +			quirk_apple_d3_thunderbolt);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_REDWOOD_RIDGE_4C_BRIDGE,
>> +			quirk_apple_d3_thunderbolt);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_NHI,
>> +			quirk_apple_d3_thunderbolt);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_BRIDGE,
>> +			quirk_apple_d3_thunderbolt);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_NHI,
>> +			quirk_apple_d3_thunderbolt);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_BRIDGE,
>> +			quirk_apple_d3_thunderbolt);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_2C_NHI,
>> +			quirk_apple_d3_thunderbolt);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_2C_BRIDGE,
>> +			quirk_apple_d3_thunderbolt);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_4C_NHI,
>> +			quirk_apple_d3_thunderbolt);
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_4C_BRIDGE,
>> +			quirk_apple_d3_thunderbolt);
>> +
>>   /*
>>    * Following are device-specific reset methods which can be used to
>>    * reset a single function if other methods (e.g. FLR, PM D0->D3) are
>> -- 
>> 2.34.1
>>