On Wed, Sep 06, 2017 at 09:40:02PM +0000, [email protected] wrote: > > -----Original Message----- > > From: Bernat, Yehezkel [mailto:[email protected]] > > Sent: Wednesday, September 6, 2017 3:27 PM > > To: [email protected]; Limonciello, Mario <[email protected]> > > Cc: [email protected]; [email protected]; platform- > > [email protected]; [email protected] > > 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. 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... -- Darren Hart VMware Open Source Technology Center
