From: <Mario.Limonciello@dell.com> To: <yehezkel.bernat@intel.com>, <dvhart@infradead.org> Cc: <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 Date: Thu, 7 Sep 2017 01:38:37 +0000 [thread overview] Message-ID: <b347d99ca7c9439186d0c9db82210132@ausx13mpc120.AMER.DELL.COM> (raw) In-Reply-To: <1504737247.2677.170.camel@intel.com> > -----Original Message----- > From: Bernat, Yehezkel [mailto:yehezkel.bernat@intel.com] > Sent: Wednesday, September 6, 2017 5:34 PM > To: dvhart@infradead.org; Limonciello, Mario <Mario_Limonciello@Dell.com> > Cc: 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, 2017-09-06 at 15:27 -0700, Darren Hart wrote: > > On Wed, Sep 06, 2017 at 09:40:02PM +0000, Mario.Limonciello@dell.com > > wrote: > > > > > > > > > > > -----Original Message----- > > > > From: Bernat, Yehezkel [mailto:yehezkel.bernat@intel.com] > > > > Sent: Wednesday, September 6, 2017 3:27 PM > > > > To: dvhart@infradead.org; Limonciello, Mario <Mario_Limonciello@D > > > > ell.com> > > > > Cc: 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, 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... > >
WARNING: multiple messages have this Message-ID (diff)
From: <Mario.Limonciello@dell.com> To: yehezkel.bernat@intel.com, dvhart@infradead.org Cc: 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 Date: Thu, 7 Sep 2017 01:38:37 +0000 [thread overview] Message-ID: <b347d99ca7c9439186d0c9db82210132@ausx13mpc120.AMER.DELL.COM> (raw) In-Reply-To: <1504737247.2677.170.camel@intel.com> > -----Original Message----- > From: Bernat, Yehezkel [mailto:yehezkel.bernat@intel.com] > Sent: Wednesday, September 6, 2017 5:34 PM > To: dvhart@infradead.org; Limonciello, Mario <Mario_Limonciello@Dell.com> > Cc: 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, 2017-09-06 at 15:27 -0700, Darren Hart wrote: > > On Wed, Sep 06, 2017 at 09:40:02PM +0000, Mario.Limonciello@dell.com > > wrote: > > > > > > > > > > > -----Original Message----- > > > > From: Bernat, Yehezkel [mailto:yehezkel.bernat@intel.com] > > > > Sent: Wednesday, September 6, 2017 3:27 PM > > > > To: dvhart@infradead.org; Limonciello, Mario <Mario_Limonciello@D > > > > ell.com> > > > > Cc: 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, 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... > >
next prev parent reply other threads:[~2017-09-07 1:39 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-09-06 17:54 [PATCH] Add driver to force WMI Thunderbolt controller power status Mario Limonciello [not found] ` <CA+CmpXt9EtzObijHT3gmm=xUwFDF3Ec=SFbNnPAk+oRdzAUADQ@mail.gmail.com> 2017-09-06 19:40 ` Fwd: " Bernat, Yehezkel 2017-09-06 19:46 ` Bernat, Yehezkel 2017-09-06 19:46 ` Bernat, Yehezkel 2017-09-06 19:49 ` Fwd: " Mario.Limonciello 2017-09-06 19:49 ` Mario.Limonciello 2017-09-06 20:09 ` Darren Hart 2017-09-06 20:26 ` Bernat, Yehezkel 2017-09-06 20:26 ` Bernat, Yehezkel 2017-09-06 21:40 ` Mario.Limonciello 2017-09-06 21:40 ` Mario.Limonciello 2017-09-06 22:27 ` Darren Hart 2017-09-06 22:34 ` Bernat, Yehezkel 2017-09-06 22:34 ` Bernat, Yehezkel 2017-09-07 1:38 ` Mario.Limonciello [this message] 2017-09-07 1:38 ` Mario.Limonciello 2017-09-06 21:43 ` Mario.Limonciello 2017-09-06 21:43 ` Mario.Limonciello 2017-09-07 6:36 ` Mika Westerberg 2017-09-07 6:50 ` Mika Westerberg 2017-09-07 18:47 ` Mario.Limonciello 2017-09-07 18:47 ` Mario.Limonciello
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=b347d99ca7c9439186d0c9db82210132@ausx13mpc120.AMER.DELL.COM \ --to=mario.limonciello@dell.com \ --cc=dvhart@infradead.org \ --cc=hughsient@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mika.westerberg@linux.intel.com \ --cc=platform-driver-x86@vger.kernel.org \ --cc=yehezkel.bernat@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.