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
