Queued, thanks Arnd.
Yes, please keep the error messages. Costs us nothing and can be useful to have.
I corrected the prefix as noted, and added the details of the gcc and reverted
patch for reproducer context.
--
Darren Hart
VMware Open Source Technology Center
led in by the
> > retailler
> > since I only have the ODM base board information to identify a model.
>
> I see. I would like to have a consensus on this one with Darren, the
> rest (after addressing comments) looks good to me.
If you can definitively say that all models of brand X and this HID have this
quirk, that is considerably better than a lot of quirks we deal with today. I
suggest doing that and holding off on the option. If it gets to the point where
a number otherwise unidentifiable systems have this problem, we can add the
option then.
--
Darren Hart
VMware Open Source Technology Center
e ODM base board information to identify a model.
>
> I see. I would like to have a consensus on this one with Darren, the
> rest (after addressing comments) looks good to me.
If you can definitively say that all models of brand X and this HID have this
quirk, that is considerably better than a lot of quirks we deal with today. I
suggest doing that and holding off on the option. If it gets to the point where
a number otherwise unidentifiable systems have this problem, we can add the
option then.
--
Darren Hart
VMware Open Source Technology Center
esn't. Huh. For everything but
"net", comment blocks should start with /* and not following text.
/*
* First line.
* Second line.
*/
A nit, and I can clean up if no changes are deemed necessary here.
> + * -EPROBE_DEFER: probing for dell-wmi-descriptor not yet run
> + * 0:
esn't. Huh. For everything but
"net", comment blocks should start with /* and not following text.
/*
* First line.
* Second line.
*/
A nit, and I can clean up if no changes are deemed necessary here.
> + * -EPROBE_DEFER: probing for dell-wmi-descriptor not yet run
> + * 0:
On Fri, Nov 03, 2017 at 04:30:13PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Thursday, November 2, 2017 7:50 PM
> > To: Limonciello, Mario <mario_limoncie...@dell.com>
> &g
On Fri, Nov 03, 2017 at 04:30:13PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Thursday, November 2, 2017 7:50 PM
> > To: Limonciello, Mario
> > Cc: Andy Shevchenko ;
t; --- a/drivers/platform/x86/dell-laptop.c
> +++ b/drivers/platform/x86/dell-laptop.c
> @@ -49,6 +49,7 @@
>
> struct quirk_entry {
> u8 touchpad_led;
> + u8 kbd_led_levels_off_1;
I believe you and Andy agreed to use a boolean type here?
--
Darren Hart
VMware Open Source Technology Center
> +++ b/drivers/platform/x86/dell-laptop.c
> @@ -49,6 +49,7 @@
>
> struct quirk_entry {
> u8 touchpad_led;
> + u8 kbd_led_levels_off_1;
I believe you and Andy agreed to use a boolean type here?
--
Darren Hart
VMware Open Source Technology Center
Andy already caught this and has it queued.
--
Darren Hart
VMware Open Source Technology Center
Andy already caught this and has it queued.
--
Darren Hart
VMware Open Source Technology Center
alls
dell_wmi_get_descriptor_valid(). Seems like initializing to -EPROBE_DEFER here
in the declaration would be a better right approach.
--
Darren Hart
VMware Open Source Technology Center
d(). Seems like initializing to -EPROBE_DEFER here
in the declaration would be a better right approach.
--
Darren Hart
VMware Open Source Technology Center
e a proper interpreter
> of MOF in the kernel and controls for what drivers will be able to
> do with that MOF.
>
> NOTE: This patch series is intended to go on top of platform-drivers-x86
> linux-next.
>
> For convenience the entire series including those is also available
e a proper interpreter
> of MOF in the kernel and controls for what drivers will be able to
> do with that MOF.
>
> NOTE: This patch series is intended to go on top of platform-drivers-x86
> linux-next.
>
> For convenience the entire series including those is also available
an error and we can exit. If it fails, the
interface_version will return false, and it is also an error.
This can be easily added as a single patch on top of this series:
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index dcfa5de..964ca54 100644
--- a/drivers/pla
is series:
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index dcfa5de..964ca54 100644
--- a/drivers/platform/x86/dell-wmi.c
+++ b/drivers/platform/x86/dell-wmi.c
@@ -665,8 +665,9 @@ static int dell_wmi_probe(struct wmi_device *wdev)
return -ENOMEM;
dev_set_drvdata(>dev, priv);
+ request_module("dell-wmi-descriptor");
if (!dell_wmi_get_interface_version(>interface_version))
- return -EPROBE_DEFER;
+ return -ENODEV;
return dell_wmi_input_setup(wdev);
}
Pali, I believe this addresses your concern?
--
Darren Hart
VMware Open Source Technology Center
tion too slow?
> >
>
> ~< 250 on most machines is what I've seen. To me that that's a small
> enough number that this is quick. It only happens at initialization.
Agreed, not a hot path. Prefer simplicity to performance here.
--
Darren Hart
VMware Open Source Technology Center
tion too slow?
> >
>
> ~< 250 on most machines is what I've seen. To me that that's a small
> enough number that this is quick. It only happens at initialization.
Agreed, not a hot path. Prefer simplicity to performance here.
--
Darren Hart
VMware Open Source Technology Center
> + struct calling_interface_buffer std;
> + struct dell_wmi_extensions ext;
> +} __packed;
> +
> +/* Whitelisted smbios class/select commands */
> +#define CLASS_TOKEN_READ 0
> +#define CLASS_TOKEN_WRITE1
> +#define SELECT_TOKEN_STD 0
> +#define SELECT_TOKEN_BAT 1
> +#define SELECT_TOKEN_AC 2
> +#define CLASS_FLASH_INTERFACE7
> +#define SELECT_FLASH_INTERFACE 3
> +#define CLASS_ADMIN_PROP 10
> +#define SELECT_ADMIN_PROP3
> +#define CLASS_INFO 17
> +#define SELECT_RFKILL11
> +#define SELECT_APP_REGISTRATION 3
> +#define SELECT_DOCK 22
> +
> +/* whitelisted tokens */
> +#define CAPSULE_EN_TOKEN 0x0461
> +#define CAPSULE_DIS_TOKEN0x0462
> +#define WSMT_EN_TOKEN0x04EC
> +#define WSMT_DIS_TOKEN 0x04ED
> +
> +/* Dell SMBIOS calling IOCTL command used by dell-smbios-wmi */
> +#define DELL_WMI_SMBIOS_CMD _IOWR(WMI_IOC, 0, struct dell_wmi_smbios_buffer)
> +
> #endif
> --
> 2.14.1
>
>
--
Darren Hart
VMware Open Source Technology Center
} __packed;
> +
> +/* Whitelisted smbios class/select commands */
> +#define CLASS_TOKEN_READ 0
> +#define CLASS_TOKEN_WRITE1
> +#define SELECT_TOKEN_STD 0
> +#define SELECT_TOKEN_BAT 1
> +#define SELECT_TOKEN_AC 2
> +#define CLASS_FLASH_INTERFACE7
> +#define SELECT_FLASH_INTERFACE 3
> +#define CLASS_ADMIN_PROP 10
> +#define SELECT_ADMIN_PROP3
> +#define CLASS_INFO 17
> +#define SELECT_RFKILL11
> +#define SELECT_APP_REGISTRATION 3
> +#define SELECT_DOCK 22
> +
> +/* whitelisted tokens */
> +#define CAPSULE_EN_TOKEN 0x0461
> +#define CAPSULE_DIS_TOKEN0x0462
> +#define WSMT_EN_TOKEN0x04EC
> +#define WSMT_DIS_TOKEN 0x04ED
> +
> +/* Dell SMBIOS calling IOCTL command used by dell-smbios-wmi */
> +#define DELL_WMI_SMBIOS_CMD _IOWR(WMI_IOC, 0, struct dell_wmi_smbios_buffer)
> +
> #endif
> --
> 2.14.1
>
>
--
Darren Hart
VMware Open Source Technology Center
Yoga 920-13IKB to the no_hw_rfkill dmi list,
> fixing the WiFI breakage.
>
> Signed-off-by: Philipp Hug <phil...@hug.cx>
Thanks Phillip, queued for review and testing.
--
Darren Hart
VMware Open Source Technology Center
Yoga 920-13IKB to the no_hw_rfkill dmi list,
> fixing the WiFI breakage.
>
> Signed-off-by: Philipp Hug
Thanks Phillip, queued for review and testing.
--
Darren Hart
VMware Open Source Technology Center
expressed
preferences and is compatible with our tooling and checks.
Thanks,
Darren Hart
VMware Open Source Technology Center
The following changes since commit ce7c47d60bda6c7f09ccf16e978d971c8fa16ff0:
platform/x86: fujitsu-laptop: Don't oops when FUJ02E3 is not presnt
(2017-09-27 00:04:43
expressed
preferences and is compatible with our tooling and checks.
Thanks,
Darren Hart
VMware Open Source Technology Center
The following changes since commit ce7c47d60bda6c7f09ccf16e978d971c8fa16ff0:
platform/x86: fujitsu-laptop: Don't oops when FUJ02E3 is not presnt
(2017-09-27 00:04:43
t; > > @@ -115,6 +140,13 @@ static int __init dell_smbios_smm_init(void)
> > >
> > > dmi_walk(find_cmd_address, NULL);
> > >
> > > + ret = test_wsmt_enabled();
> >
> > ret is int, but test_wsmt_enabled() returns bool.
>
> Yes, ret is re-used within this method.
> 0, 1 enum is a subset of int, so this seemed like a logical thing to me to do.
Agreed, the conversion is automatic and he tests for it and returns an
appropriate error code. I don't see a real problem with this.
--
Darren Hart
VMware Open Source Technology Center
> > +
> > > static int __init dell_smbios_smm_init(void)
> > > {
> > > int ret;
> > > @@ -115,6 +140,13 @@ static int __init dell_smbios_smm_init(void)
> > >
> > > dmi_walk(find_cmd_address, NULL);
> > >
> > > + ret = test_wsmt_enabled();
> >
> > ret is int, but test_wsmt_enabled() returns bool.
>
> Yes, ret is re-used within this method.
> 0, 1 enum is a subset of int, so this seemed like a logical thing to me to do.
Agreed, the conversion is automatic and he tests for it and returns an
appropriate error code. I don't see a real problem with this.
--
Darren Hart
VMware Open Source Technology Center
ruct kbd_info *info)
> units = (buffer->output[2] >> 8) & 0xFF;
> info->levels = (buffer->output[2] >> 16) & 0xFF;
>
> + if (quirks && quirks->kbd_led_num_of_levels_instead_of_last_index &&
> info->levels)
> + info->levels--;
> +
> if (units & BIT(0))
> info->seconds = (buffer->output[3] >> 0) & 0xFF;
> if (units & BIT(1))
> --
> 1.7.9.5
>
>
--
Darren Hart
VMware Open Source Technology Center
uffer->output[2] >> 8) & 0xFF;
> info->levels = (buffer->output[2] >> 16) & 0xFF;
>
> + if (quirks && quirks->kbd_led_num_of_levels_instead_of_last_index &&
> info->levels)
> + info->levels--;
> +
> if (units & BIT(0))
> info->seconds = (buffer->output[3] >> 0) & 0xFF;
> if (units & BIT(1))
> --
> 1.7.9.5
>
>
--
Darren Hart
VMware Open Source Technology Center
know WSMT was enabled */
> > + if (buffer->output[0] != 0)
> > + return 1;
> > +
> > + /* query token status if it didn't fail */
> > + return (buffer->output[1] == token->value);
> > +}
>
> Maybe small suggestion... function returns only zero or one -- what is a
> good candidate to have return value boolean and not basic int.
Yes please.
--
Darren Hart
VMware Open Source Technology Center
know WSMT was enabled */
> > + if (buffer->output[0] != 0)
> > + return 1;
> > +
> > + /* query token status if it didn't fail */
> > + return (buffer->output[1] == token->value);
> > +}
>
> Maybe small suggestion... function returns only zero or one -- what is a
> good candidate to have return value boolean and not basic int.
Yes please.
--
Darren Hart
VMware Open Source Technology Center
no other
> feedback requiring changes to this series as is.
>
> One possible issue is that it currently uses glib. Is that OK?
In my opinion, what is important is that there is an open-source
userspace consumer of the interface. I don't think it needs to be in the
kernel. If this was a more generic interface which could be tested on
any hardware, then I think a selftests target would be sensible. As it
is, this is a very specific use case, and a simple reference to the
smbios-wmi-poc project URL in documentation someplace (or even in the
dell-smbios driver comments) seems more than adequate to me.
--
Darren Hart
VMware Open Source Technology Center
for wider distribution
> to the kernel so I would prefer to send it in a follow up patch if no other
> feedback requiring changes to this series as is.
>
> One possible issue is that it currently uses glib. Is that OK?
In my opinion, what is important is that there is an open-source
userspace consumer of the interface. I don't think it needs to be in the
kernel. If this was a more generic interface which could be tested on
any hardware, then I think a selftests target would be sensible. As it
is, this is a very specific use case, and a simple reference to the
smbios-wmi-poc project URL in documentation someplace (or even in the
dell-smbios driver comments) seems more than adequate to me.
--
Darren Hart
VMware Open Source Technology Center
dea being to translate what the platform firmware reports into what
the driver already understands, instead of giving the levels fields of
the structure multiple meanings.
--
Darren Hart
VMware Open Source Technology Center
dea being to translate what the platform firmware reports into what
the driver already understands, instead of giving the levels fields of
the structure multiple meanings.
--
Darren Hart
VMware Open Source Technology Center
patch.
> Since Vadim did some rather big driver changes I would like to hear
> from him how to proceed with this one: either I apply it now, or after
> we get Vadim's series in.
>
I've asked Vadim to rework some of the mlx platform and hotplug patches, so I'll
be taking this now as it i
like to hear
> from him how to proceed with this one: either I apply it now, or after
> we get Vadim's series in.
>
I've asked Vadim to rework some of the mlx platform and hotplug patches, so I'll
be taking this now as it is a minimal patch - this way it doesn't get lost.
Thanks Colin.
--
Darren Hart
VMware Open Source Technology Center
e
responsible for reviewing the patches and submitting the pull requests
to Linus.
Thanks,
--
Darren Hart
VMware Open Source Technology Center
e
responsible for reviewing the patches and submitting the pull requests
to Linus.
Thanks,
--
Darren Hart
VMware Open Source Technology Center
han the kernel?)
Even if updating the kernel was just as easy as updating a management
application they control, that's still twice the work.
> I know hardware companies want to stop writing software for their new
> hardware designs. I too want a pony :)
>
> Sorry, this argument isn't going to fly.
Well... I don't think reducing the amount of software required to
support a new platform is a bad thing.
I'm curious for your take on Alan's CAPs recommendation.
--
Darren Hart
VMware Open Source Technology Center
han the kernel?)
Even if updating the kernel was just as easy as updating a management
application they control, that's still twice the work.
> I know hardware companies want to stop writing software for their new
> hardware designs. I too want a pony :)
>
> Sorry, this argument isn't going to fly.
Well... I don't think reducing the amount of software required to
support a new platform is a bad thing.
I'm curious for your take on Alan's CAPs recommendation.
--
Darren Hart
VMware Open Source Technology Center
it the buffer in the general
case. Dell uses a sensible buffer format with 'command' and 'class' fields, but
the WMI spec explicitly makes no requirement on the format of the buffer. This
may prove much harder to implement for other vendors depending on their format -
but perhaps we accept that and deal with that as it comes up.
--
Darren Hart
VMware Open Source Technology Center
it the buffer in the general
case. Dell uses a sensible buffer format with 'command' and 'class' fields, but
the WMI spec explicitly makes no requirement on the format of the buffer. This
may prove much harder to implement for other vendors depending on their format -
but perhaps we accept that and deal with that as it comes up.
--
Darren Hart
VMware Open Source Technology Center
getting longer. Ah :-) So I'm sending
this now, and will continue with the rest of the thread. Yikes.
> On Thu, Oct 12, 2017 at 05:46:45PM -0700, Darren Hart wrote:
> > On Thu, Oct 12, 2017 at 11:09:03AM +0100, One Thousand Gnomes wrote:
> > > On Wed, 11 Oct 2017 11:27:36
getting longer. Ah :-) So I'm sending
this now, and will continue with the rest of the thread. Yikes.
> On Thu, Oct 12, 2017 at 05:46:45PM -0700, Darren Hart wrote:
> > On Thu, Oct 12, 2017 at 11:09:03AM +0100, One Thousand Gnomes wrote:
> > > On Wed, 11 Oct 2017 11:27:36
tures will not be
available on Linux for these platforms, or that vendors will develop a
single wmi mapping driver out of tree, likely without the noted
concessions.
1.
https://msdn.microsoft.com/en-us/library/windows/hardware/dn614028(v=vs.85).aspx
Specifically: "ACPI-to-WMI Mapper Goals for Windows Instrumentation"
--
Darren Hart
VMware Open Source Technology Center
nux for these platforms, or that vendors will develop a
single wmi mapping driver out of tree, likely without the noted
concessions.
1.
https://msdn.microsoft.com/en-us/library/windows/hardware/dn614028(v=vs.85).aspx
Specifically: "ACPI-to-WMI Mapper Goals for Windows Instrumentation"
--
Darren Hart
VMware Open Source Technology Center
llocating and populating the buffer with the
same values.
I see you've updated this in v7 with two calls. I'd call that a reasonable
compromise.
>
> It's very obvious if you look at the dell_send_request function what is
> happening.
There have been numerous analysis indicating that the more arguments a function
has, the more likely bugs are to be found in those functions. 6 is a lot.
--
Darren Hart
VMware Open Source Technology Center
k I suggested keeping the same
interface of dell_send_request(class, select) (with 2 arguments) rather than
replacing it with 3 or 4 lines of allocating and populating the buffer with the
same values.
I see you've updated this in v7 with two calls. I'd call that a reasonable
compromise.
>
>
ote this during
the merge window - whichever goes in second. Test merge will identify the merge
conflict, and we can include a note to Linus on the preference.
--
Darren Hart
VMware Open Source Technology Center
ote this during
the merge window - whichever goes in second. Test merge will identify the merge
conflict, and we can include a note to Linus on the preference.
--
Darren Hart
VMware Open Source Technology Center
patch.
> Since Vadim did some rather big driver changes I would like to hear
> from him how to proceed with this one: either I apply it now, or after
> we get Vadim's series in.
I'll be working with Vadim's series shortly and would like to take this
after that is settled.
--
Darren Hart
VMware Open Source Technology Center
like to hear
> from him how to proceed with this one: either I apply it now, or after
> we get Vadim's series in.
I'll be working with Vadim's series shortly and would like to take this
after that is settled.
--
Darren Hart
VMware Open Source Technology Center
On Fri, Oct 06, 2017 at 09:06:14PM +0200, Corentin Chary wrote:
> Yes, I'm just having trouble finding time to write it :)
> I'll try to make that happen next week.
OK, no problem. Marking the patch as "changes requested" and will keep an eye
out.
Thanks,
--
Darren Hart
VM
On Fri, Oct 06, 2017 at 09:06:14PM +0200, Corentin Chary wrote:
> Yes, I'm just having trouble finding time to write it :)
> I'll try to make that happen next week.
OK, no problem. Marking the patch as "changes requested" and will keep an eye
out.
Thanks,
--
Darren Hart
VM
_BUTTON_GUID))
> > return;
>
> I was thinking, after got kbuid bot complains on Kai's patch on
> sections mismatch, do we need these checks at all?
> How would be possible to get a module loaded in the first place if
> system is not in whitelist?
>
I was wondering this myself.
--
Darren Hart
VMware Open Source Technology Center
return;
>
> I was thinking, after got kbuid bot complains on Kai's patch on
> sections mismatch, do we need these checks at all?
> How would be possible to get a module loaded in the first place if
> system is not in whitelist?
>
I was wondering this myself.
--
Darren Hart
VMware Open Source Technology Center
On Thu, Oct 05, 2017 at 07:47:38PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Thursday, October 5, 2017 12:58 PM
> > To: Limonciello, Mario <mario_limoncie...@dell.com>
>
On Thu, Oct 05, 2017 at 07:47:38PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Thursday, October 5, 2017 12:58 PM
> > To: Limonciello, Mario
> > Cc: andy.shevche...@gmail.com
nt WMI GUIDs, we need to
review them.
This driver not having MOF data should be the exception. We'll have more
ability to inspect others. If drivers are submitted that don't look at
the MOF data even through it is present, we should reject them.
--
Darren Hart
VMware Open Source Technology Center
nt WMI GUIDs, we need to
review them.
This driver not having MOF data should be the exception. We'll have more
ability to inspect others. If drivers are submitted that don't look at
the MOF data even through it is present, we should reject them.
--
Darren Hart
VMware Open Source Technology Center
ovide for the MOF parsing within the kernel so Linux
will have more ability to audit messaging.
--
Darren Hart
VMware Open Source Technology Center
ovide for the MOF parsing within the kernel so Linux
will have more ability to audit messaging.
--
Darren Hart
VMware Open Source Technology Center
ure *flags =
> > > + container_of(dm, struct misc_bios_flags_structure, header);
> > > +
> > > + /* 4 bytes header, and one word of flags */
> >
> > Assuming specifically 8 bytes of flags, independent of arch?
>
> Well platform/drivers/*x86*...
I was thinking 32b vs 64b x86 which have a different definition of word size.
(and depending on context, even that changes)
So... "8 bytes" ? I presume this is a fixed length independent of word size?
--
Darren Hart
VMware Open Source Technology Center
ure *flags =
> > > + container_of(dm, struct misc_bios_flags_structure, header);
> > > +
> > > + /* 4 bytes header, and one word of flags */
> >
> > Assuming specifically 8 bytes of flags, independent of arch?
>
> Well platform/drivers/*x86*...
I was thinking 32b vs 64b x86 which have a different definition of word size.
(and depending on context, even that changes)
So... "8 bytes" ? I presume this is a fixed length independent of word size?
--
Darren Hart
VMware Open Source Technology Center
t by doing it in the
kernel, we can do at least some amount of message auditing within the
kernel in a generic way. So long as vendors continue using the same
GUIDs and provide proper MOF data, the kernel wouldn't need to be
changed. New GUIDs require new drivers, which must create the function
ops to get the char device created.
I thought this served as a pragmatic bridge between the two approaches.
This particular driver, doesn't have the benefit of the MOF data. It is
a halfway point intended to eliminate the SMI access to SMBIOS and
replace it with the WMI access, which uses an op region instead of
passing a physical memory pointer to SMM - but doesn't improve on the
message audit of the existing mechanism (but it shouldn't make it any
worse either).
--
Darren Hart
VMware Open Source Technology Center
t by doing it in the
kernel, we can do at least some amount of message auditing within the
kernel in a generic way. So long as vendors continue using the same
GUIDs and provide proper MOF data, the kernel wouldn't need to be
changed. New GUIDs require new drivers, which must create the function
ops to get the char device created.
I thought this served as a pragmatic bridge between the two approaches.
This particular driver, doesn't have the benefit of the MOF data. It is
a halfway point intended to eliminate the SMI access to SMBIOS and
replace it with the WMI access, which uses an op region instead of
passing a physical memory pointer to SMM - but doesn't improve on the
message audit of the existing mechanism (but it shouldn't make it any
worse either).
--
Darren Hart
VMware Open Source Technology Center
t; >
> > This was nagging me all night, and I was thinking the last time I had to
> > use this it was indeed a runtime dependency. Sorry for the noise on
> > this.
> >
> > The kconfig needs to be setup such that dell-wmi-descriptor cannot be a
> > module if
t; >
> > This was nagging me all night, and I was thinking the last time I had to
> > use this it was indeed a runtime dependency. Sorry for the noise on
> > this.
> >
> > The kconfig needs to be setup such that dell-wmi-descriptor cannot be a
> > module if
On Thu, Oct 05, 2017 at 01:59:36PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
> > Sent: Thursday, October 5, 2017 3:48 AM
> > To: Darren Hart <dvh...@infradead.org>
> > Cc
On Thu, Oct 05, 2017 at 01:59:36PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
> > Sent: Thursday, October 5, 2017 3:48 AM
> > To: Darren Hart
> > Cc: Limonciello, Mario ;
On Thu, Oct 05, 2017 at 08:29:10AM +0300, Andy Shevchenko wrote:
> On Thu, Oct 5, 2017 at 4:09 AM, Darren Hart <dvh...@infradead.org> wrote:
> > On Wed, Oct 04, 2017 at 05:48:31PM -0500, Mario Limonciello wrote:
> >> All communication on individual GUIDs should o
On Thu, Oct 05, 2017 at 08:29:10AM +0300, Andy Shevchenko wrote:
> On Thu, Oct 5, 2017 at 4:09 AM, Darren Hart wrote:
> > On Wed, Oct 04, 2017 at 05:48:31PM -0500, Mario Limonciello wrote:
> >> All communication on individual GUIDs should occur in separate drivers.
>
ies).
Hi Corentin,
Just to make sure I haven't missed it - I believe we're waiting for a v2 of this
patch. Is that right?
--
Darren Hart
VMware Open Source Technology Center
make sure I haven't missed it - I believe we're waiting for a v2 of this
patch. Is that right?
--
Darren Hart
VMware Open Source Technology Center
On Sat, Sep 30, 2017 at 07:56:33PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Friday, September 29, 2017 9:17 PM
> > To: Limonciello, Mario <mario_limoncie...@dell.com>
> &g
On Sat, Sep 30, 2017 at 07:56:33PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Friday, September 29, 2017 9:17 PM
> > To: Limonciello, Mario
> > Cc: Andy Shevchenko ;
On Wed, Oct 04, 2017 at 03:30:12PM +0200, Hans de Goede wrote:
> Add touchscreen platform data for the Chuwi Hi8 Pro tablet.
>
> Signed-off-by: Hans de Goede <hdego...@redhat.com>
Queued for testing, thanks Hans.
--
Darren Hart
VMware Open Source Technology Center
On Wed, Oct 04, 2017 at 03:30:12PM +0200, Hans de Goede wrote:
> Add touchscreen platform data for the Chuwi Hi8 Pro tablet.
>
> Signed-off-by: Hans de Goede
Queued for testing, thanks Hans.
--
Darren Hart
VMware Open Source Technology Center
> + /* driver wants a character device made */
> + if (wdriver->file_operations) {
> + buf = kmalloc(strlen(wdriver->driver.name) + 4, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> + strcpy(buf, "wmi/");
> + strcpy(buf + 4, wdriver->driver.name);
sprintf(buf, "wmi/%s", wdriver->driver.name)
--
Darren Hart
VMware Open Source Technology Center
device made */
> + if (wdriver->file_operations) {
> + buf = kmalloc(strlen(wdriver->driver.name) + 4, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> + strcpy(buf, "wmi/");
> + strcpy(buf + 4, wdriver->driver.name);
sprintf(buf, "wmi/%s", wdriver->driver.name)
--
Darren Hart
VMware Open Source Technology Center
x86/dell-smbios-wmi.c
> b/drivers/platform/x86/dell-smbios-wmi.c
> +static void __init parse_b1_table(const struct dmi_header *dm)
> +{
> + struct misc_bios_flags_structure *flags =
> + container_of(dm, struct misc_bios_flags_structure, header);
> +
> + /* 4 bytes header, and one word of flags */
Assuming specifically 8 bytes of flags, independent of arch?
--
Darren Hart
VMware Open Source Technology Center
b/drivers/platform/x86/dell-smbios-wmi.c
> +static void __init parse_b1_table(const struct dmi_header *dm)
> +{
> + struct misc_bios_flags_structure *flags =
> + container_of(dm, struct misc_bios_flags_structure, header);
> +
> + /* 4 bytes header, and one word of flags */
Assuming specifically 8 bytes of flags, independent of arch?
--
Darren Hart
VMware Open Source Technology Center
access platform data in these
> instances is through the WMI SMBIOS calling interface.
Nit: This should probably come after 11/14 where the WMI SMBIOS calling
interface is introduced.
--
Darren Hart
VMware Open Source Technology Center
access platform data in these
> instances is through the WMI SMBIOS calling interface.
Nit: This should probably come after 11/14 where the WMI SMBIOS calling
interface is introduced.
--
Darren Hart
VMware Open Source Technology Center
> - buffer = dell_smbios_get_buffer();
> -
> - dell_smbios_send_request(17, 11);
> + memset(buffer, 0, sizeof(struct calling_interface_buffer));
> + buffer->class = 17;
> + buffer->select = 11;
Please move these three lines into a function, it's used far far too
often to be open coded. The dell_smbios_send_request is a reasonable
wrapper which you could just define here as well. This would minimize
the change to the driver.
--
Darren Hart
VMware Open Source Technology Center
_smbios_get_buffer();
> -
> - dell_smbios_send_request(17, 11);
> + memset(buffer, 0, sizeof(struct calling_interface_buffer));
> + buffer->class = 17;
> + buffer->select = 11;
Please move these three lines into a function, it's used far far too
often to be open coded. The dell_smbios_send_request is a reasonable
wrapper which you could just define here as well. This would minimize
the change to the driver.
--
Darren Hart
VMware Open Source Technology Center
buffer_entry < buffer_end)
> + if (!dell_wmi_get_interface_version(_version)) {
You've introduced a dependency on another module here and haven't
guaranteed that dell-wmi-descriptor will have been loaded prior to this
one.
You'll want to add something like:
#ifdef CONFIG_DELL_WMI_DESCRIPTOR_MODULE
if (request_module("dell_wmi_descriptor"))
/* FAIL */
#endif
During init.
--
Darren Hart
VMware Open Source Technology Center
module here and haven't
guaranteed that dell-wmi-descriptor will have been loaded prior to this
one.
You'll want to add something like:
#ifdef CONFIG_DELL_WMI_DESCRIPTOR_MODULE
if (request_module("dell_wmi_descriptor"))
/* FAIL */
#endif
During init.
--
Darren Hart
VMware Open Source Technology Center
On Wed, Oct 04, 2017 at 05:48:26PM -0500, Mario Limonciello wrote:
>
> NOTE: This patch is intended to go on top of the 6 patches already in
> Darren's review tree.
I pushed these to for-next today, they should be available in linux-next
shortly.
--
Darren Hart
VMware Open Source T
On Wed, Oct 04, 2017 at 05:48:26PM -0500, Mario Limonciello wrote:
>
> NOTE: This patch is intended to go on top of the 6 patches already in
> Darren's review tree.
I pushed these to for-next today, they should be available in linux-next
shortly.
--
Darren Hart
VMware Open Source T
On Tue, Oct 03, 2017 at 03:49:04PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Tuesday, October 3, 2017 10:20 AM
> > To: Greg KH <g...@kroah.com>
> > Cc: Limonciello, Mari
On Tue, Oct 03, 2017 at 03:49:04PM +, mario.limoncie...@dell.com wrote:
> > -Original Message-
> > From: Darren Hart [mailto:dvh...@infradead.org]
> > Sent: Tuesday, October 3, 2017 10:20 AM
> > To: Greg KH
> > Cc: Limonciello, Mario ; Andy Shevchenko
&g
to go to stable
> since it fixes a regression.
>
> Reviewed-by: Jonathan Woithe <jwoi...@just42.net>
Thanks for the due diligence here Jonathan, but for stable backport
announcements, you don't need to speak up unless you have an objection.
--
Darren Hart
VMware Open Source Technology Center
to go to stable
> since it fixes a regression.
>
> Reviewed-by: Jonathan Woithe
Thanks for the due diligence here Jonathan, but for stable backport
announcements, you don't need to speak up unless you have an objection.
--
Darren Hart
VMware Open Source Technology Center
ar driver is an intermediate step improving on the
mechanism used for existing devices (libsmbios -> dcdbas -> SMM) to use
the safer WMI entry point (using an op region instead of passing a
physical memory pointer to SMM).
But, that said... Mario, in lieu of the MOF description of the buffer,
we should be able to do some driver specific validation of this buffer
here.
--
Darren Hart
VMware Open Source Technology Center
ar driver is an intermediate step improving on the
mechanism used for existing devices (libsmbios -> dcdbas -> SMM) to use
the safer WMI entry point (using an op region instead of passing a
physical memory pointer to SMM).
But, that said... Mario, in lieu of the MOF description of the buffer,
we should be able to do some driver specific validation of this buffer
here.
--
Darren Hart
VMware Open Source Technology Center
reduce your code size a lot.
Thank you Greg, this simplifies things quite a bit.
Mario, the misc device interface will remove a lot of the boiler plate
setup and eliminate the need to allocate a new major number.
--
Darren Hart
VMware Open Source Technology Center
reduce your code size a lot.
Thank you Greg, this simplifies things quite a bit.
Mario, the misc device interface will remove a lot of the boiler plate
setup and eliminate the need to allocate a new major number.
--
Darren Hart
VMware Open Source Technology Center
On Mon, Oct 02, 2017 at 11:24:53AM +0200, Greg Kroah-Hartman wrote:
> On Sun, Oct 01, 2017 at 05:57:20PM -0700, Darren Hart wrote:
> > On Sat, Sep 30, 2017 at 10:12:05AM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Sep 29, 2017 at 06:52:28PM -0700, Darren Hart wrote:
> >
501 - 600 of 3303 matches
Mail list logo
