> -----Original Message----- > From: Bernat, Yehezkel [mailto:yehezkel.bernat@xxxxxxxxx] > Sent: Wednesday, September 6, 2017 5:34 PM > To: dvhart@xxxxxxxxxxxxx; Limonciello, Mario <Mario_Limonciello@xxxxxxxx> > Cc: mika.westerberg@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; platform- > driver-x86@xxxxxxxxxxxxxxx; hughsient@xxxxxxxxx > Subject: Re: Fwd: [PATCH] Add driver to force WMI Thunderbolt controller power > status > > On Wed, 2017-09-06 at 15:27 -0700, Darren Hart wrote: > > On Wed, Sep 06, 2017 at 09:40:02PM +0000, Mario.Limonciello@xxxxxxxx > > wrote: > > > > > > > > > > > -----Original Message----- > > > > From: Bernat, Yehezkel [mailto:yehezkel.bernat@xxxxxxxxx] > > > > Sent: Wednesday, September 6, 2017 3:27 PM > > > > To: dvhart@xxxxxxxxxxxxx; Limonciello, Mario <Mario_Limonciello@D > > > > ell.com> > > > > Cc: mika.westerberg@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx > > > > ; platform- > > > > driver-x86@xxxxxxxxxxxxxxx; hughsient@xxxxxxxxx > > > > Subject: Re: Fwd: [PATCH] Add driver to force WMI Thunderbolt > > > > controller power > > > > status > > > > > > > > On Wed, 2017-09-06 at 13:09 -0700, Darren Hart wrote: > > > > > > > > > > The other question I had about this was if the typical use case > > > > > involves the OS, > > > > > or if the firmware update (for example) would be performed as > > > > > part of > > > > > the > > > > > general platform firmware update (from the UEFI update > > > > > utility). > > > > First, there is the use-case of add-in card, where it's > > > > impossible to > > > > use UEFI-based update, as much as I understand, as the BIOS isn't > > > > expected to expose an ESRT entry for it. > > > > > > > > Even for built-in controller, my impression is that most OEMs use > > > > a FW > > > > update application (running on Windows) and are not publishing a > > > > UEFI- > > > > based solution. > > > Yeah I'd agree with that impression. > > > > > > Even if an OEM does choose to publish a UEFI based solution, it's > > > still > > > useful to present FW information for the TBT controller in fwupd > > > however too. > > > > > > Similar to how fwupd displays the information for the ME even > > > though > > > the ME is typically updated via UEFI. > > So this raises the question: can we come up with a mechanism as part > > of the tb > > driver that will work on both on-board controllers and add on cards? > > In it's > > current form, this driver will only address on-board controllers. > > Both this wmi driver and Thunderbolt driver are relevant for both on- > board controllers and add-in cards. > Maybe I'm missing something. Would you mind to elaborate? > What this WMI driver I submitted does is modifies a "platform" feature (a GPIO) that turns on the on-board controller to a forced power on state. It typically shouldn't remain in this state if not in use as that will waste power. If a separate TBT device is plugged in that would cause the TBT controller to also wake up. In that case you wouldn't need to use this WMI driver. That’s why I say this should really be a platform feature that makes the thunderbolt host controller behave as expected whether something is plugged in or not when queried from fwupd. >From the userspace fwupd perspective the (unwritten patch) behavior would be: 1) fwupd starts up and does coldplug routine 2a) If any TBT devices are plugged in, enumerate everything up the chain from udev, don't use force power 2b) If no TBT devices are plugged in but the force power sysfs file is available, try to write 1 to force power the device 3) wait a few seconds. 4) If new devices show up after the waiting, enumerate. 5) Write 0 to the force power to turn off the TBT host device if nothing is plugged in > > > > The TB driver could use the WMI method if it exists, or some other > > method to > > power it up, but present the same sysfs interface to userspace... > >
