On Fri, Jun 23, 2017 at 09:44:58AM +0930, Jonathan Woithe wrote:
> On Thu, Jun 22, 2017 at 04:58:09PM -0700, Darren Hart wrote:
> > On Thu, Jun 22, 2017 at 10:46:19PM +0200, Micha?? K??pie?? wrote:
> > > > The events seen by userspace with the original code would be "
On Fri, Jun 23, 2017 at 09:46:59AM +0930, Jonathan Woithe wrote:
> Thanks. In case it was missed, I supplied my reviewed-by message and
> sign-off in an earlier post.
Yup, got it - thanks!
--
Darren Hart
VMware Open Source Technology Center
d for
> them. I do not think we have a way of ensuring that the above holds
> true for every other model out there, but I will point out that
> fujitsu-laptop is the only user of acpi_bus_update_power() outside of
> drivers/acpi.
OK, thanks. Queueing to testing.
--
Darren Hart
VMware Open Source Technology Center
will be happy to
> revert to FIFO in v2.
This all looks reasonable to me, I don't see anything requiring a respin.
--
Darren Hart
VMware Open Source Technology Center
gt; some way, which is why I am CCing linux-acpi as per Rafael's previous
> advice.
>
> This patch series was based on platform-driver-x86/for-next and tested
> on a Lifebook S7020.
I'm satisfied with the responses to all questions on this series. Queued to
testing. Thanks Mic
simplicity (it gets
> optimized away anyway).
>
This required a minor manual merge for ARM on the tip of Linus' tree today. The
reduced duplication is a welcome improvement.
Reviewed-by: Darren Hart (VMware)
--
Darren Hart
VMware Open Source Technology Center
On Thu, Jun 22, 2017 at 09:20:21AM +0930, Jonathan Woithe wrote:
> On Wed, Jun 21, 2017 at 11:15:43AM -0700, Darren Hart wrote:
> > On Fri, Jun 16, 2017 at 06:40:52AM +0200, Micha?? K??pie?? wrote:
> > > -#define RINGBUFFERSIZE 40
> > >
> > > /* Debugging *
ling_device_ops structure
>
> drivers/platform/x86/acerhdf.c | 2 +-
> drivers/platform/x86/intel_menlow.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> --
> 2.7.4
>
>
--
Darren Hart
VMware Open Source Technology Center
or
> both FUJ02B1 and FUJ02E3 to always be ACPI_STATE_D0 ("on").
>
How confident are we that all implementations of these two ACPI devices lack
_PS0 and _PR0 ?
--
Darren Hart
VMware Open Source Technology Center
40];
Do we know why 40 was used here? A single use magic number is fine, but it would
be good to document why it is what it is if we know.
--
Darren Hart
VMware Open Source Technology Center
found that there have some wmi query/evaluation
> > >> code that they used 'one' as the first WMI instance number.
> > >> But the number is indexed from zero that it's must less than
> > >> the instance_count in _WDG.
> > >>
> > >
On Mon, Jun 19, 2017 at 03:10:09PM -0700, Andy Lutomirski wrote:
> On Tue, Jun 13, 2017 at 9:38 PM, Greg Kroah-Hartman
> wrote:
> > On Tue, Jun 13, 2017 at 10:07:19AM -0700, Darren Hart wrote:
> >> On Tue, Jun 13, 2017 at 06:52:47PM +0200, Greg Kroah-Hartman wrote:
> >
I suggest merging it to a local branch for safe keeping and if we see
conflicts in subsequent patches, we can apply it. I doubt it will be a problem.
--
Darren Hart
VMware Open Source Technology Center
On Fri, Jun 16, 2017 at 03:22:45PM +0200, Hans de Goede wrote:
> Hi,
>
> On 16-06-17 14:44, Andy Shevchenko wrote:
> > On Thu, Jun 15, 2017 at 7:53 PM, Darren Hart wrote:
> > > On Thu, Jun 15, 2017 at 08:48:31AM +0200, Hans de Goede wrote:
> >
> > > > +
-platform-drivers-x86.git
tags/platform-drivers-x86-v4.12-2
for you to fetch changes up to bf5d008164dd84d671ca2dd569a1676051f9faff:
platform/x86: intel_telemetry_debugfs: fix oops when load/unload module
(2017-06-13 10:57:54 -0700)
Thanks,
Darren Hart
VMware Open Source Technology Center
On Thu, Jun 15, 2017 at 08:48:32AM +0200, Hans de Goede wrote:
> Add touchscreen info for Pipo W2S tablet.
>
> Signed-off-by: Hans de Goede
Queued to testing, thanks Hans!
--
Darren Hart
VMware Open Source Technology Center
ords like "Aptio CRB" it's clear the vendor isn't doing their job and just
using unmodified reference code. The problem with this of course is that the
vendor is not providing a way to identify this hardware.
Andy, I'd appreciate your thoughts on this... I'm leaning towar
On Wed, Jun 14, 2017 at 05:46:54PM +0200, Pali Rohár wrote:
> On Tuesday 13 June 2017 11:42:28 Darren Hart wrote:
> > On Tue, Jun 13, 2017 at 08:04:57PM +0200, Pali Rohár wrote:
> > > On Tuesday 13 June 2017 18:49:51 Darren Hart wrote:
> > > > I'd suggest
On Tue, Jun 13, 2017 at 08:04:57PM +0200, Pali Rohár wrote:
> On Tuesday 13 June 2017 18:49:51 Darren Hart wrote:
> > On Sat, Jun 10, 2017 at 09:15:57PM +0200, Pali Rohár wrote:
> > > On Saturday 27 May 2017 13:55:34 Pali Rohár wrote:
> > > > instance_count defin
reg's advice and get some
code out there for review. I don't think we're going to make more
progress in pre-code discussions.
Thanks for all the time and effort everyone has put into the discussion.
--
Darren Hart
VMware Open Source Technology Center
On Tue, Jun 13, 2017 at 07:16:11PM +0200, Pali Rohár wrote:
> On Tuesday 13 June 2017 17:38:57 Darren Hart wrote:
> > I'll mention this again I suspect in this thread, but rather than a
> > "WMI filter" we can implement a "WMI proxy". If a kernel driver
&g
example patch of something that was needed to get a Dell
> laptop working for a new device id that didn't work this way?
Per Mario's comment, it sounds like they are and it does work this way.
It takes 8 weeks, and they don't see a reason to go through this for WMI
GUIDs.
--
Darren Hart
VMware Open Source Technology Center
ch eliminates it.
> >
> > Signed-off-by: Pali Rohár
>
> Reviewed-by: Andy Shevchenko
Thanks Pali, nice fix. Queued to testing.
--
Darren Hart
VMware Open Source Technology Center
as the potential to break functional drivers, I
wouldn't want to merge it without some evidence that those drivers still work.
I'd suggest reaching out to the maintainers and contributors to the drivers you
mention to request some help in testing.
--
Darren Hart
VMware Open Source Technology Center
On Tue, Jun 13, 2017 at 08:56:42AM -0700, Andy Lutomirski wrote:
> On Tue, Jun 13, 2017 at 8:50 AM, Greg Kroah-Hartman
> wrote:
> > On Tue, Jun 13, 2017 at 08:38:57AM -0700, Darren Hart wrote:
> >> On Tue, Jun 13, 2017 at 12:05:35AM -0700, Christoph Hellwig wr
On Tue, Jun 13, 2017 at 06:05:47PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Jun 13, 2017 at 08:44:19AM -0700, Darren Hart wrote:
> > > In some cases filter function can be simple in some cases hard. I can
> > > image that usage of while listing, plus in some cases also fil
their BIOS. They would like
to see those GUIDs automatically exposed.
Mario, can you provide any specific information about what the pain
points were that led to this request?
--
Darren Hart
VMware Open Source Technology Center
ent about it's OK to change the
interface, so long as it doesn't break anything. If instead of DENYing a
method call, we allow a driver to PROXY a method call, we make the
change transparent to userspace, and still retain the ability for kernel
drivers to claim ownership of certain WMI method signatures, and ensure
consistent internal state.
When a WMI driver binds to a GUID, it can also register a
wmi_method_proxy for that GUID. When a method call is received, the
proxy is called with the method ID, input and output buffers. The proxy
can choose to handle the call itself and populate the output buffer, or
not, and let the WMI system execute it.
--
Darren Hart
VMware Open Source Technology Center
On Tue, Jun 13, 2017 at 02:07:41PM +0200, Pali Rohár wrote:
> On Tuesday 13 June 2017 00:05:35 Christoph Hellwig wrote:
> > On Mon, Jun 12, 2017 at 06:24:35PM -0700, Darren Hart wrote:
> > > This is a big topic for sure. Speed and scale of platform enabling is
> > > s
I presume you mean? I usually have tw set to 72...
apparently I dropped that setting at some point. Will correct.
>
> On Mon, Jun 12, 2017 at 06:24:35PM -0700, Darren Hart wrote:
> > This is a big topic for sure. Speed and scale of platform enabling is
> > something
> > I wo
On Tue, Jun 13, 2017 at 12:17:28AM +0200, Pali Rohár wrote:
> On Monday 12 June 2017 19:02:49 Darren Hart wrote:
> > On Sat, Jun 10, 2017 at 12:36:40PM +0200, Pali Rohár wrote:
> > > On Saturday 10 June 2017 02:46:41 Darren Hart wrote:
> > > > On Fri, Jun 09, 2017 a
On Sat, Jun 10, 2017 at 12:36:40PM +0200, Pali Rohár wrote:
> On Saturday 10 June 2017 02:46:41 Darren Hart wrote:
> > On Fri, Jun 09, 2017 at 08:41:51AM +0200, Greg Kroah-Hartman wrote:
> > > On Sat, Jun 03, 2017 at 12:50:58PM -0700, Darren Hart wrote:
> > > > On W
saying that in a 00/11 email, I
> forgot that for this series.
OK, no dependencies that I see, but it's a simple mechanical change. Happy for
it to go through Greg's tree.
Reviewed-by: Darren Hart (VMware)
--
Darren Hart
VMware Open Source Technology Center
On Fri, Jun 09, 2017 at 08:41:51AM +0200, Greg Kroah-Hartman wrote:
> On Sat, Jun 03, 2017 at 12:50:58PM -0700, Darren Hart wrote:
> > On Wed, May 10, 2017 at 07:13:41AM +0200, Greg Kroah-Hartman wrote:
> > > On Tue, May 09, 2017 at 04:16:39PM -0700, Darren Hart wrote:
>
: ES: CR0: 80050033
> > [ 97.652423] CR2: a006f010 CR3: 0001775ef000 CR4:
> > 003406f0
> > [ 97.660423] Call Trace:
> > [ 97.663166] ? 0xffffa0031000
> > [ 97.666885] register_pm_notifier+0x18/0x20
> > [ 97.671581] telemetry_debugfs_init+0x92/0x1000
>
> Pushed to testing, thanks!
>
> Darren, do we need this in v4.12-rcX?
If it causes an Oops, it makes sense for an rcX to me. We're currently at RC4,
so yes.
--
Darren Hart
VMware Open Source Technology Center
> > Both is OK for me. Do you want to send a new patch with %2pE?
>
> To me it looks slightly cleaner.
I don't want to let this one fall through the cracks. Pali, is a new one coming?
--
Darren Hart
VMware Open Source Technology Center
Add copyright statements for Andy Lutomirski and Darren Hart (VMware)
for their contributions to the WMI bus infrastructure and the creation
of the wmi-bmof driver.
Signed-off-by: Darren Hart (VMware)
Cc: Andy Lutomirski
---
drivers/platform/x86/wmi-bmof.c | 1 +
drivers/platform/x86/wmi.c
On Fri, May 26, 2017 at 10:31:14PM -0700, Darren Hart wrote:
> From: "Darren Hart (VMware)"
>
> This series is based on the original work of
> Andy Lutomirski [1]. I have made minor edits, and in
> one instance, squashed two patches in which the latter undid the
LIAS from module_wmi_driver()? IIRC it is
> working for i2c drivers.
I could see this being automated since we always use wmi:GUID, but it isn't
currently. Happy to consider it as a follow on.
Do you have a specific i2c example you think we should consider following?
--
Darren Hart
VMware Open Source Technology Center
_create_bin_file
So I suggest:
#include
#include
#include
#include
#include
#include
#include
#include
#include
Which removes:
#include
#include
#include
#include
#include
#include
And adds:
#include
#include
#include
--
Darren Hart
VMware Open Source Technology Center
i_bmof_probe(struct wmi_device *wdev)
> > +{
>
> > + int ret;
> > +
> > + struct bmof_priv *priv =
> > + devm_kzalloc(&wdev->dev, sizeof(struct bmof_priv),
> > GFP_KERNEL);
>
> I'm not a fan of memory allocation in definition block, so, I would rewrite
> this
>
> struct bmof_priv *priv;
> int ret;
>
> priv = devm_kzalloc(&wdev->dev, sizeof(struct bmof_priv), GFP_KERNEL);
>
Agreed, changed.
Thanks for the review Andy.
--
Darren Hart
VMware Open Source Technology Center
;>On Sat, May 27, 2017 at 3:50 AM, Pali Rohár
> > >>wrote:
> > >>> On Saturday 27 May 2017 07:31:30 Darren Hart wrote:
> > >>>> - dell_wmi_input_dev->name = "Dell WMI hotkeys";
> > >>>> - dell_wmi_input_dev->
b410 Mon Sep 17 00:00:00 2001
Message-Id:
<2512da1593574a66eb48d7105885e959b38db410.1496717988.git.dvh...@infradead.org>
From: "Darren Hart (VMware)"
Date: Mon, 5 Jun 2017 19:54:03 -0700
Subject: [PATCH] =?UTF-8?q?platform/x86:=20wmi:=20Apply=20fixes=20per=20Mi?=
=?UTF-8?q?cha=C5=82=2
On Tue, Jun 06, 2017 at 12:19:26AM +0200, Pali Rohár wrote:
> On Tuesday 06 June 2017 00:14:56 Darren Hart wrote:
> > On Sat, May 27, 2017 at 01:14:15PM +0200, Pali Rohár wrote:
> > > > metadata. I think that Samba has tools to interpret it, but there
> > > > is
ggestion)
Did some digging, and yeah, you're right.
I've replaced with MOF with Binary MOF or bmof throughout the patch. Will resend
in a v2. Thanks.
>
> On Saturday 27 May 2017 07:31:29 Darren Hart wrote:
> > From: Andy Lutomirski
> >
> > Quite a few laptops (
On Wed, May 10, 2017 at 07:13:41AM +0200, Greg Kroah-Hartman wrote:
> On Tue, May 09, 2017 at 04:16:39PM -0700, Darren Hart wrote:
> > Linus and Greg,
> >
> > We are in the process of redesigning the Windows Management Instrumentation
> > (WMI) [1] system in the k
On Sat, May 27, 2017 at 07:27:19PM +0300, Andy Shevchenko wrote:
> On Sat, May 27, 2017 at 8:16 AM, Darren Hart wrote:
> > From: Andy Lutomirski
> >
> > According to Mario at Dell, the DELLABC6 device should not be used on a
> > Linux system. It also conflicts with Int
On Sat, May 27, 2017 at 12:51:36PM +0200, Pali Rohár wrote:
> On Saturday 27 May 2017 07:15:28 Darren Hart wrote:
> > From: Andy Lutomirski
> >
> > The hotkey table is 0xb2, add a comment for clarity.
> >
> > Suggested-by: Darren Hart
> > Signed-off-by: A
-laptop module into two drivers.
> This is motivated by the current use of two ACPI devices by the single
> fujitsu-laptop module, which is inconsistent with the kernel's "one driver
> per module" approach.
>
> Reviewed-by: Jonathan Woithe
Apologies for the delay gents. Reviewed and pushed to testing.
--
Darren Hart
VMware Open Source Technology Center
On Thu, Jun 01, 2017 at 10:05:43AM +0200, Jean Delvare wrote:
> Hi Darren,
>
> On Fri, 26 May 2017 16:59:17 -0700, Darren Hart wrote:
> > From: Andy Lutomirski
> >
> > Currently they return -1 on error, which will confuse callers if
> > they try to interpret i
atch set versions are bisectable.
>
> The problem was when I first created this patch set, typec wcove driver was
> not merged upstream.
> After creating the initial set, I was just improving the patch set and
> forgot to re-check for
> child devices that depend of PMIC MFD driver. Thats why we came across this
> compilation issue.
>
> In future, I will try to avoid these kind of issues. I think adding
> "allyesconfig" and "allmodconfig"
> compilation tests to my patch submit criteria should prevent these kind of
> issues.
We do this as well as 32 and 64b for the platform driver tree, I have found it
to be a reasonable sanity test.
--
Darren Hart
VMware Open Source Technology Center
gt;
> > > Not "a few", but "lots of" :-)
>
> Aren't they are synonyms ("quite a few" vs "lots of")?
The difference is subtle enough that people we can probably get several
different answers, but generally yes. I'm happy to update it in any case.
--
Darren Hart
VMware Open Source Technology Center
M_SLEEP */
>
> return err;
> }
> @@ -1022,6 +1029,9 @@ static void __exit telemetry_debugfs_exit(void)
> {
> debugfs_remove_recursive(debugfs_conf->telemetry_dbg_dir);
> debugfs_conf->telemetry_dbg_dir = NULL;
> +#ifdef CONFIG_PM_SLEEP
> + unregister_pm_notifier(&pm_notifier);
> +#endif /* CONFIG_PM_SLEEP */
> }
>
> late_initcall(telemetry_debugfs_init);
> --
> 2.10.0
>
>
--
Darren Hart
VMware Open Source Technology Center
Limonciello
Cc: Pali Rohár
Cc: Rafael Wysocki
Cc: linux-kernel@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Signed-off-by: Darren Hart (VMware)
---
drivers/platform/x86/dell-wmi.c | 136 +---
1 file changed, 70 insertions
-off-by: Darren Hart (VMware)
---
drivers/platform/x86/Kconfig | 12
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/wmi-mof.c | 125 +
3 files changed, 138 insertions(+)
create mode 100644 drivers/platform/x86/wmi-mof.c
diff --git a
...@vger.kernel.org
Signed-off-by: Darren Hart (VMware)
---
drivers/platform/x86/wmi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index ceeb8c1..0043581 100644
--- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x86/wmi.c
@@ -836,7
Lutomirski
Cc: Mario Limonciello
Cc: Pali Rohár
Cc: Rafael Wysocki
Cc: linux-kernel@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Signed-off-by: Darren Hart (VMware)
---
drivers/platform/x86/wmi.c | 58 --
1
nux-kernel@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Signed-off-by: Darren Hart (VMware)
---
drivers/platform/x86/wmi.c | 197 +++--
include/linux/wmi.h| 47 +++
2 files changed, 201 insertions(+), 43
: Rafael Wysocki
Cc: linux-kernel@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Signed-off-by: Darren Hart (VMware)
---
drivers/platform/x86/wmi.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers
Limonciello
Cc: Pali Rohár
Cc: Rafael Wysocki
Cc: linux-kernel@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Signed-off-by: Darren Hart (VMware)
---
drivers/platform/x86/wmi.c | 49 +-
1 file changed, 31 insertions
-kernel@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Signed-off-by: Darren Hart (VMware)
---
drivers/platform/x86/wmi.c | 89 +-
include/linux/wmi.h| 1 +
2 files changed, 73 insertions(+), 17 deletions
From: "Darren Hart (VMware)"
This series is based on the original work of
Andy Lutomirski [1]. I have made minor edits, and in
one instance, squashed two patches in which the latter undid the former.
This series converts WMI [2] into a proper bus, adds some useful information via
: Darren Hart (VMware)
---
drivers/platform/x86/wmi.c | 101 +++--
include/linux/wmi.h| 6 +++
2 files changed, 103 insertions(+), 4 deletions(-)
diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index 33a3609..651693a 100644
--- a
: platform-driver-...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Signed-off-by: Darren Hart (VMware)
---
drivers/platform/x86/wmi.c | 54 --
include/linux/wmi.h| 4
2 files changed, 42 insertions(+), 16 deletions(-)
diff --git a/drivers
Wysocki
Cc: linux-kernel@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Signed-off-by: Darren Hart (VMware)
---
drivers/platform/x86/wmi.c | 57 +++---
1 file changed, 33 insertions(+), 24 deletions(-)
diff --git a
: linux-a...@vger.kernel.org
Signed-off-by: Darren Hart (VMware)
---
drivers/platform/x86/wmi.c | 17 +
include/linux/wmi.h| 4
2 files changed, 21 insertions(+)
diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index f1c9464..8dd9988 100644
--- a
From: "Darren Hart (VMware)"
The Microsoft WMI documentation requires all data blocks to implement
the Query Control Method (WQxx). If we encounter a data block not
implementing this control method, issue a warning, and ignore the data
block. Remove the "readable" attribut
nux-a...@vger.kernel.org
Signed-off-by: Darren Hart (VMware)
---
drivers/platform/x86/wmi.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index c6e11b5..ac60a51 100644
--- a/drivers/platform/x86/wmi.c
+++ b/dr
butes.
Signed-off-by: Andy Lutomirski
Cc: Andy Lutomirski
Cc: Mario Limonciello
Cc: Pali Rohár
Cc: Rafael Wysocki
Cc: linux-kernel@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Signed-off-by: Darren Hart (VMware)
---
drivers/platform/x86/wmi.c | 78 +++
-...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Signed-off-by: Darren Hart (VMware)
---
drivers/platform/x86/wmi.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
index 0043581..c6e11b5 100644
--- a/drivers/platform/x86
From: Andy Lutomirski
The hotkey table is 0xb2, add a comment for clarity.
Suggested-by: Darren Hart
Signed-off-by: Andy Lutomirski
Cc: Matthew Garrett
Cc: "Pali Rohár"
Cc: Andy Shevchenko
Signed-off-by: Darren Hart (VMware)
---
drivers/platform/x86/dell-wmi.c | 1 +
1 file
Lutomirski
[dvhart: New commit message and minor comment wording fixes]
Cc: Mario Limonciello
Cc: "Pali Rohár"
Signed-off-by: Darren Hart (VMware)
---
drivers/platform/x86/dell-rbtn.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/pl
From: Andy Lutomirski
This is based on Mario's explanation and observation of my laptop.
Suggested-by: "Pali Rohár"
Signed-off-by: Andy Lutomirski
Cc: Mario Limonciello
Cc: Matthew Garrett
Cc: Andy Shevchenko
Signed-off-by: Darren Hart (VMware)
---
drivers/platform/x86
From: Andy Lutomirski
Currently they return -1 on error, which will confuse callers if
they try to interpret it as a normal negative error code.
Signed-off-by: Andy Lutomirski
Cc: Jean Delvare
Signed-off-by: Darren Hart (VMware)
---
drivers/firmware/dmi_scan.c | 9 +
include/linux
, you warned me about this and I had forgotten before I included it in next.
Would you like to drop this change, or drop the touchpad_store function?
--
Darren Hart
VMware Open Source Technology Center
On Tue, May 16, 2017 at 03:24:18PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 16 May 2017 10:35:40 -0700
> Darren Hart escreveu:
>
> > On Tue, May 16, 2017 at 09:15:56AM -0300, Mauro Carvalho Chehab wrote:
> > > There are a few issues on some kernel-doc markups that wa
xpected unindent.
>
> Fix them.
>
> No functional changes.
>
> Acked-by: Darren Hart (VMware)
> Signed-off-by: Mauro Carvalho Chehab
> ---
What was the difference from v1? Quick scan didn't reveal anything obvious to
me... (context left intact in case you wan
lier that you were not really fond of the fext_*()
> helper functions. Would you like me to drop them and simply use
> call_fext_func() with five arguments everywhere? Or should I keep
> the helper functions in v2?
I was torn on this as well - I didn't think they added much value. Let's focus
on splitting the driver, and we can revisit this later for the -laptop driver if
there is interest.
--
Darren Hart
VMware Open Source Technology Center
automated publication reduces the barrier to access. The lack of this kind of
tooling, honestly, also discourages participation among some groups of
of capable contributors.
That said, I support the direction both Mauro and Peter have voiced to minimize
the impact to comment blocks. What does rest do with this formatting it doesn't
understand - does it fail gracefully? Falling back to or something
like that?
--
Darren Hart
VMware Open Source Technology Center
he ReST changes (with -) make the comment block any
less readable in the C files.
> It is an incentive not to use kerneldoc..
>
I like the kerneldoc if for no other reason that it helps keeps formatting
consistent. I would object if I started seeing XML or some other horrible
formatting style showing up in the code, but this honestly seems like a fairly
minimal imposition... but that's me.
--
Darren Hart
VMware Open Source Technology Center
On Fri, May 12, 2017 at 06:51:50PM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 12 May 2017 09:41:22 -0700
> Darren Hart escreveu:
>
> > On Fri, May 12, 2017 at 10:59:47AM -0300, Mauro Carvalho Chehab wrote:
> > > There are a few issues on some kernel-doc markups that wa
at so it seems appropriate here.
>
> Signed-off-by: Hans de Goede
> Reviewed-by: Andy Shevchenko
> Reviewed-by: Dmitry Torokhov
Queued to testing, thanks.
--
Darren Hart
VMware Open Source Technology Center
the lock;
> + * - <0 - error
> *
e.g.
* Return:
* * 0 - ready to wait
* * 1 - acquired the lock
* * <0 - error
I'm fine with either though, just curious if this would be an improvement, or if
we have an established policy (which I didn't find in the docs on docs...).
Acked-by: Darren Hart (VMware)
--
Darren Hart
VMware Open Source Technology Center
On Thu, May 11, 2017 at 04:37:30PM +0200, Rafael Wysocki wrote:
> On Thursday, May 11, 2017 03:52:11 PM Michał Kępień wrote:
> > > On Tuesday, May 09, 2017 09:47:34 AM Darren Hart wrote:
> > > > On Tue, May 09, 2017 at 11:35:24AM +0200, Michał Kępień wrote:
> > >
on this point. Why are events not interesting to user space?
I don't think it would be too problematic to create a chardev for an Event GUID,
give platform drivers first chance to handle an event, and pass it up to
userspace for exported GUIDs if the kernel doesn't consume the event.
-
That would be a good way to deal with regressions if we encounter them after
filtering a call. In general we would want to filter as few calls as possible,
and only if there is a detrimental effect for both userspace and the kernel
using the call. e.g. if the backlight call is stateless, then there is
On Wed, May 10, 2017 at 10:02:46PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Wednesday, May 10, 2017 1:12 AM
> > To: Greg Kroah-Hartman
> > Cc: Linus Torvalds ; Limonciello,
On Wed, May 10, 2017 at 07:13:41AM +0200, Greg Kroah-Hartman wrote:
> On Tue, May 09, 2017 at 04:16:39PM -0700, Darren Hart wrote:
> > Linus and Greg,
> >
> > We are in the process of redesigning the Windows Management Instrumentation
> > (WMI) [1] system in the k
ts own use? And that this
filtering may change as new features are added to the platform drivers?
1. https://msdn.microsoft.com/en-us/library/aa384642(v=vs.85).aspx
2. https://lwn.net/Articles/391230/
3. https://lists.gt.net/linux/kernel/2671309/?page=1;
--
Darren Hart
VMware Open Source Technology Center
On Tue, May 09, 2017 at 08:33:13PM +0200, Hans de Goede wrote:
> Hi,
>
> On 05/09/2017 06:00 PM, Darren Hart wrote:
> > On Tue, May 09, 2017 at 09:54:31AM +0200, Hans de Goede wrote:
> > > PEAQ is a new European OEM, I've bought one of their 2-in-1 x86
> > &
to improve readability
and maintainability of the driver code. So long as we can keep coupling to a
minimum, I still think this makes sense.
So - static global variable for a driver with exactly one device that needs
offer services to another driver... not really all that horrible.
You could accomplish this by making call_fext_func() not static and calling it
from fujitsu-backlight. Or, you could further restrict it by exporting a
fujitsu_backlight_power() function which wraps call_fext_func() providing a
specific interface for fujitsu-backlight. This makes the ownership very explicit
and ensures the usage doesn't grow without explicit changes to fujitsu-laptop.
That is probably the most practical solution IFF we still feel it is worth
splitting the driver into two separate modules. We need to develop a more robust
and objective decision making process on module granularity (when to split, when
to keep together). Will continue to give this more thought.
--
Darren Hart
VMware Open Source Technology Center
oll;
> + peaq_poll_dev->poll_interval = PEAQ_POLL_INTERVAL_MS;
> + peaq_poll_dev->poll_interval_max = PEAQ_POLL_MAX_MS;
> + peaq_poll_dev->input->name = "PEAQ WMI hotkeys";
> + peaq_poll_dev->input->phys = "wmi/input0";
> + peaq_poll_dev->input-
On Tue, May 09, 2017 at 08:42:21AM +0200, Hans de Goede wrote:
> On 08-05-17 23:04, Darren Hart wrote:
> > On Mon, May 08, 2017 at 09:56:31PM +0200, Hans de Goede wrote:
> > > + peaq_poll_dev->input->name = "PEAQ WMI hotkeys";
> >
> > Are there add
->name = "PEAQ WMI hotkeys";
Are there additional keys/buttons?
> + peaq_poll_dev->input->phys = "wmi/input0";
> + peaq_poll_dev->input->id.bustype = BUS_HOST;
> + input_set_capability(peaq_poll_dev->input, EV_KEY, KEY_SOUND);
> +
> + return input_register_polled_device(peaq_poll_dev);
> +}
> +
> +static void __exit peaq_wmi_exit(void)
> +{
> + if (!wmi_has_guid(PEAQ_DOLBY_BUTTON_GUID))
> + return;
> +
> + input_unregister_polled_device(peaq_poll_dev);
> +}
> +
> +module_init(peaq_wmi_init);
> +module_exit(peaq_wmi_exit);
> +
> +MODULE_DESCRIPTION("PEAQ 2-in-1 WMI hotkey driver");
> +MODULE_AUTHOR("Hans de Goede ");
> +MODULE_LICENSE("GPL");
> --
> 2.12.2
>
>
--
Darren Hart
VMware Open Source Technology Center
l both be part of products for
the near term?
I'm trying to understand if BMOF is a legacy thing now, or if it will continue
to be used in new designs.
--
Darren Hart
VMware Open Source Technology Center
n it is a shared function which either
one of them can own and serialize (or not if fw indeed handles that).
Either way, the owning driver should abstract away the private data and present
an interface the other can use with only the "public" information.
I suggest investigating the various mechanisms Andy pointed at and revisiting
this after that.
--
Darren Hart
VMware Open Source Technology Center
On Mon, May 08, 2017 at 03:36:31PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Monday, May 8, 2017 10:29 AM
> > To: Andy Lutomirski
> > Cc: Limonciello, Mario ; Pali Rohár
>
On Fri, May 05, 2017 at 06:25:08PM -0700, Andy Lutomirski wrote:
> On Fri, May 5, 2017 at 5:51 PM, wrote:
> >> -Original Message-
> >> From: Darren Hart [mailto:dvh...@infradead.org]
> >> Sent: Friday, May 5, 2017 6:45 PM
> >> To: Limonciello,
On Fri, May 05, 2017 at 09:55:46PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Thursday, April 20, 2017 3:45 PM
> > To: Pali Rohár
> > Cc: Limonciello, Mario ; r...@rjwysock
t of legacy baggage and is more and more
difficult to maintain. thinkpad_acpi is the prime example of this.
In an ideal world, Single Function drivers are preferred, but if we end up have
to perform unnatural acts to keep the drivers separated, the advantages can be
lost. So it all hinges on how much Driver Coupling would exist in the separate
driver approach.
We'll accept either with supporting evidence for why it's the better choice. My
preference, under ideal conditions, would be for separate drivers, separate
modules, one per device.
--
Darren Hart
VMware Open Source Technology Center
401 - 500 of 1656 matches
Mail list logo
