From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753322AbdIFVpK (ORCPT ); Wed, 6 Sep 2017 17:45:10 -0400 Received: from esa3.dell-outbound.iphmx.com ([68.232.153.94]:32713 "EHLO esa3.dell-outbound.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752313AbdIFVpI (ORCPT ); Wed, 6 Sep 2017 17:45:08 -0400 From: X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="5.42,355,1500958800"; d="scan'208";a="546969332" X-DLP: DLP_GlobalPCIDSS To: CC: , , , , Subject: RE: Fwd: [PATCH] Add driver to force WMI Thunderbolt controller power status Thread-Topic: Fwd: [PATCH] Add driver to force WMI Thunderbolt controller power status Thread-Index: AQHTJ0YV8o1w6haZs0+qP3ceDgEFGaKoQZmAgAABehCAAFpmgP//xdbQ Date: Wed, 6 Sep 2017 21:43:36 +0000 Message-ID: <77ca02732f5c4ac1a16c82bf7c893a9b@ausx13mpc120.AMER.DELL.COM> References: <1504720440-24423-1-git-send-email-mario.limonciello@dell.com> <1504726863.2677.154.camel@intel.com> <20170906200953.GA8298@fury> In-Reply-To: <20170906200953.GA8298@fury> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.143.18.86] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v86LjF34031815 > -----Original Message----- > From: Darren Hart [mailto:dvhart@infradead.org] > Sent: Wednesday, September 6, 2017 3:10 PM > To: Limonciello, Mario > Cc: yehezkel.bernat@intel.com; mika.westerberg@linux.intel.com; linux- > kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org; > hughsient@gmail.com > Subject: Re: Fwd: [PATCH] Add driver to force WMI Thunderbolt controller power > status > > On Wed, Sep 06, 2017 at 07:49:32PM +0000, Mario.Limonciello@dell.com wrote: > > > -----Original Message----- > > > From: Bernat, Yehezkel [mailto:yehezkel.bernat@intel.com] > > > Sent: Wednesday, September 6, 2017 2:41 PM > > > To: Limonciello, Mario > > > Cc: mika.westerberg@linux.intel.com; linux-kernel@vger.kernel.org; platform- > > > driver-x86@vger.ke; dvhart@infradead.org; hughsient@gmail.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. > > > > 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). > > > > > > > > + > > > > +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. > > > Ahhhrg, that was something I meant to follow up on as I was discussing using the > macros with Mario previously, and I forgot. Sorry about that Mario. > I double checked and with the way it's done right now, permissions are: --w------- Looks like the macro DTRT without me needing to override. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Subject: RE: Fwd: [PATCH] Add driver to force WMI Thunderbolt controller power status Date: Wed, 6 Sep 2017 21:43:36 +0000 Message-ID: <77ca02732f5c4ac1a16c82bf7c893a9b@ausx13mpc120.AMER.DELL.COM> References: <1504720440-24423-1-git-send-email-mario.limonciello@dell.com> <1504726863.2677.154.camel@intel.com> <20170906200953.GA8298@fury> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from esa3.dell-outbound.iphmx.com ([68.232.153.94]:32713 "EHLO esa3.dell-outbound.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752313AbdIFVpI (ORCPT ); Wed, 6 Sep 2017 17:45:08 -0400 In-Reply-To: <20170906200953.GA8298@fury> Content-Language: en-US Sender: platform-driver-x86-owner@vger.kernel.org List-ID: To: dvhart@infradead.org Cc: yehezkel.bernat@intel.com, mika.westerberg@linux.intel.com, linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org, hughsient@gmail.com > -----Original Message----- > From: Darren Hart [mailto:dvhart@infradead.org] > Sent: Wednesday, September 6, 2017 3:10 PM > To: Limonciello, Mario > Cc: yehezkel.bernat@intel.com; mika.westerberg@linux.intel.com; linux- > kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org; > hughsient@gmail.com > Subject: Re: Fwd: [PATCH] Add driver to force WMI Thunderbolt controller = power > status >=20 > On Wed, Sep 06, 2017 at 07:49:32PM +0000, Mario.Limonciello@dell.com wrot= e: > > > -----Original Message----- > > > From: Bernat, Yehezkel [mailto:yehezkel.bernat@intel.com] > > > Sent: Wednesday, September 6, 2017 2:41 PM > > > To: Limonciello, Mario > > > Cc: mika.westerberg@linux.intel.com; linux-kernel@vger.kernel.org; pl= atform- > > > driver-x86@vger.ke; dvhart@infradead.org; hughsient@gmail.com > > > Subject: Re: Fwd: [PATCH] Add driver to force WMI Thunderbolt control= ler > 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 u= p > > > > that can force the controller awake.=A0 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 persp= ective > > on if this should live in the TBT driver and the proper way to do it. > > >=20 > 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). >=20 > > > > > > > + > > > > +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. >=20 >=20 > Ahhhrg, that was something I meant to follow up on as I was discussing us= ing the > macros with Mario previously, and I forgot. Sorry about that Mario. >=20 I double checked and with the way it's done right now, permissions are: --w------- Looks like the macro DTRT without me needing to override.