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

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

Hi,

On 10/25/21 16:36, Mario Limonciello wrote:
> Surface Laptop go is this right?
> New Lightweight Surface Laptop Go – The Everyday, Everywhere Laptop – Microsoft Surface <https://www.microsoft.com/en-us/d/surface-laptop-go/94fc0bdgq7wv?activetab=pivot:techspecstab>
> IOW: "10th Gen Intel® Core™ i5 processor – 1035G1".
> 
> That should be Ice Lake according to ARK:
> Intel Core i51035G1 Processor 6M Cache up to 3.60 GHz Product Specifications <https://ark.intel.com/content/www/us/en/ark/products/196603/intel-core-i51035g1-processor-6m-cache-up-to-3-60-ghz.html>
> 
> ICL should have integrated TBT3.  The concept of the force power WMI attribute makes "most" sense when it comes to a GPIO getting toggled.

I'm not talking about the Surface Laptop Go, but about the "Surface Go"
which uses the classic Surface tablet with kickstand form-factor with
the following CPU: Intel(R) Pentium(R) CPU 4415Y

The model definitely does not have Thunderbolt.

>>This causes a /sys/bus/wmi/devices/.../force_power attribute to be created
> and echoing to that executes ACPI code which ends up poking at things it
> should not be poking at on the Surface Go.
> 
> 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.

Regards,

Hans



> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Hans de Goede <hdegoede@redhat.com>
> *Sent:* Monday, October 25, 2021 8:48
> *To:* Mika Westerberg <mika.westerberg@linux.intel.com>; Andreas Noever <andreas.noever@gmail.com>; Michael Jamet <michael.jamet@intel.com>; Yehezkel Bernat <YehezkelShB@gmail.com>; Mario Limonciello <mario.limonciello@outlook.com>
> *Cc:* linux-usb <linux-usb@vger.kernel.org>
> *Subject:* Disabling intel-wmi-thunderbolt on devices without Thunderbolt / detecting if a device has Thunderbolt
>  
> Hi All,
> 
> While digging through Microsoft Surface Go ACPI tables to fix an unrelated
> issue, I noticed that there is an intel-wmi-thunderbolt WMI device in the
> ACPI tables and the intel-wmi-thunderbolt driver happily binds to this.
> This is likely the result of copy paste programming of the ACPI tables.
> 
> This causes a /sys/bus/wmi/devices/.../force_power attribute to be created
> and echoing to that executes ACPI code which ends up poking at things it
> should not be poking at on the Surface Go.
> 
> The problem of having these "nonsense" WMI devices with the
> intel-wmi-thunderbolt GUID is likely more wide-spread and ideally the
> intel-wmi-thunderbolt would ignore these.
> 
> This makes me wonder if there is a way to see if there are any thunderbolt
> controllers on the system at all ? (with as goal to make intel-wmi-thunderbolt
> not bind if there are none)
> 
> Regards,
> 
> Hans
> 
>