Re: Disabling intel-wmi-thunderbolt on devices without Thunderbolt / detecting if a device has Thunderbolt

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 10/26/21 10:53, Mika Westerberg wrote:
> Hi,
> 
> On Tue, Oct 26, 2021 at 10:17:53AM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 10/25/21 17:12, Mika Westerberg wrote:
>>> On Mon, Oct 25, 2021 at 04:54:41PM +0200, Hans de Goede wrote:
>>>>> Yes that's exactly what is supposed to happen that this attribute is made.
>>>>> What exactly happens when you write into it?
>>>>
>>>> The _SB.CGWR ACPI method gets called, with arguments coming from ACPI
>>>> settings stored in memory. Depending on those settings this function
>>>> either directly pokes some MMIO or tries to talk to an I2C GPIO
>>>> expander which is not present on the Surface Go, causing it to
>>>> MMIO poke an I2C controller which it should not touch.
>>>>
>>>> In either case the AML code ends up poking stuff it should not touch
>>>> and the entire force_power sysfs attribute should simply not be
>>>> there on devices without thunderbolt.
>>>
>>> That's right - it should not be there in the first place if there is no
>>> Thunderbolt controller on that thing.
>>>
>>> I guess most of the systems that have this actually do support
>>> Thunderbolt so maybe we can work this around by quirking all the Surface
>>> models in that driver?
>>
>> I was hoping that we could avoid this, but yes if there is no easy /
>> clean way to detect if there are any Thunderbolt controllers on the
>> system then a DMI table is necessary.
> 
> Well, the force power thing is there just for this reason. It should
> only be present on systems using ACPI assisted PCIe hotplug for
> Thunderbolt devices. Apparantly some BIOS engineer forgot to remove it
> on Surface :( I need to check if it is present on recent reference
> BIOSes too. If it is then I'll report an internal sighting about this to
> get it removed.
> 
> In theory we could also use a heuristic that if there is a TBT
> controller present when the driver probes it should fail the probe or
> so. Or even look for the PCI host bridge and if it got the PCIe hotplug
> capability from the BIOS (through _OSC negotiation) we can assume this
> system does not need the force power.

I think adding such heuristics might be a good thing to do, because
I suspect that this problem is much wider then just a couple of
surface devices.

One worry I have about this is probe ordering. We cannot assume the
entire PCI bus has been enumerated when the intel-wmi-thunderbolt's
probe() method runs. So that would mean doing something like
returning -EPROBE_DEFER if no thunderbolt controller is found and
then say 1 minute after boot return -ENODEV to get us of the
probe_deferal devices list...

IOW this is going to be ugly so for now I think a DMI list for the
devices where I want to make sure force_power does not poke the
GEXP device is best.

Regards,

Hans