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]
Message-ID: <b74a2237da254faea0377fdcb93aa3e0@ausx13mpc120.AMER.DELL.COM>
Date:   Wed, 6 Sep 2017 19:49:32 +0000
From:   <Mario.Limonciello@...l.com>
To:     <yehezkel.bernat@...el.com>
CC:     <mika.westerberg@...ux.intel.com>, <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>, <dvhart@...radead.org>,
        <hughsient@...il.com>
Subject: RE: Fwd: [PATCH] Add driver to force WMI Thunderbolt controller power
 status

> -----Original Message-----
> From: Bernat, Yehezkel [mailto:yehezkel.bernat@...el.com]
> Sent: Wednesday, September 6, 2017 2:41 PM
> To: Limonciello, Mario <Mario_Limonciello@...l.com>
> Cc: mika.westerberg@...ux.intel.com; linux-kernel@...r.kernel.org; platform-
> driver-x86@...r.ke; dvhart@...radead.org; hughsient@...il.com
> Subject: Re: Fwd: [PATCH] Add driver to force WMI Thunderbolt controller power
> status
> 
> 
> > Current implementations of Intel Thunderbolt controllers will go
> > into a low power mode when not in use.
> >
> > Many machines containing these controllers also have a GPIO wired up
> > that can force the controller awake.  This is offered via a ACPI-WMI
> > interface intended to be manipulated by a userspace utility.
> 
> 
> > This mechanism is provided by Intel to OEMs to include in BIOS.
> > It uses an industry wide GUID that is populated in a separate _WDG
> > entry with no binary MOF.
> >
> > This interface allow software such as fwupd to wake up thunderbolt
> > controllers to query the firmware version or flash new firmware.
> 
> As this is a Thunderbolt specific function, maybe it's better to be
> exposed from the Thunderbolt driver?
> 

I thought about this too, but the thunderbolt driver won't load if the
controller doesn't exist in the first place, whereas this is a platform
BIOS feature.  I'll be interested to hear if Mika has a different perspective
on if this should live in the TBT driver and the proper way to do it.

> 
> > +
> > +static DEVICE_ATTR_WO(force_power);
> > +
> 
> I'm not sure what is the convention for permissions for this type of
> attributes but I feel like this worth being root-only writable, as it
> can be used to power-off the controller in the middle of a FW update,
> for example.

Yeah I think you're right.  I'll adjust it in a follow up patch if this is the
correct way to go afterall.

Thanks,

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ