lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 6 Sep 2017 15:27:30 -0700
From:   Darren Hart <dvhart@...radead.org>
To:     Mario.Limonciello@...l.com
Cc:     yehezkel.bernat@...el.com, mika.westerberg@...ux.intel.com,
        linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        hughsient@...il.com
Subject: Re: Fwd: [PATCH] Add driver to force WMI Thunderbolt controller
 power status

On Wed, Sep 06, 2017 at 09:40:02PM +0000, Mario.Limonciello@...l.com wrote:
> > -----Original Message-----
> > From: Bernat, Yehezkel [mailto:yehezkel.bernat@...el.com]
> > Sent: Wednesday, September 6, 2017 3:27 PM
> > To: dvhart@...radead.org; Limonciello, Mario <Mario_Limonciello@...l.com>
> > Cc: mika.westerberg@...ux.intel.com; linux-kernel@...r.kernel.org; platform-
> > driver-x86@...r.kernel.org; hughsient@...il.com
> > 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ