public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Mario Limonciello <mario.limonciello@outlook.com>,
	Andreas Noever <andreas.noever@gmail.com>,
	Michael Jamet <michael.jamet@intel.com>,
	Yehezkel Bernat <YehezkelShB@gmail.com>,
	linux-usb <linux-usb@vger.kernel.org>
Subject: Re: Disabling intel-wmi-thunderbolt on devices without Thunderbolt / detecting if a device has Thunderbolt
Date: Tue, 26 Oct 2021 11:53:46 +0300	[thread overview]
Message-ID: <YXfCGtrtUiej2EZT@lahna> (raw)
In-Reply-To: <ba1fdd81-0580-1d1f-9e09-d78642b13d95@redhat.com>

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.

  reply	other threads:[~2021-10-26  8:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-25 13:48 Disabling intel-wmi-thunderbolt on devices without Thunderbolt / detecting if a device has Thunderbolt Hans de Goede
2021-10-25 14:46 ` Oliver Neukum
     [not found] ` <PH0PR15MB4992B80415BE9BD4836CF336E1839@PH0PR15MB4992.namprd15.prod.outlook.com>
2021-10-25 14:54   ` Hans de Goede
2021-10-25 15:12     ` Mika Westerberg
2021-10-26  8:17       ` Hans de Goede
2021-10-26  8:53         ` Mika Westerberg [this message]
2021-10-26 10:34           ` Hans de Goede
2021-10-26 12:22             ` Mika Westerberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YXfCGtrtUiej2EZT@lahna \
    --to=mika.westerberg@linux.intel.com \
    --cc=YehezkelShB@gmail.com \
    --cc=andreas.noever@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=mario.limonciello@outlook.com \
    --cc=michael.jamet@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox