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

[Mika Westerberg <mika.westerberg@linux.intel.com>]

On Tue, Oct 26, 2021 at 12:34:33PM +0200, Hans de Goede wrote:
> 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...

The whole PCI bus does not need to be enumerated - just the host bridge
which is typically pretty early.

> 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.

I agree. We can look for the other option later if more devices with
this issue are found.