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.
