At some point, we'll want to subdrivers to get references to other
devices on the same WMI bus. This change is needed to avoid races.
This ends up simplifying the setup code and fixng some leaks, too.
Signed-off-by: Andy Lutomirski
---
drivers/platform/x86/wmi.c | 49 ++
Arguably wmi should attach to the PNP platform device, not the ACPI
device. As a platform driver, acpi_driver.notify won't be
available, so stop using it.
Signed-off-by: Andy Lutomirski
---
drivers/platform/x86/wmi.c | 29 ++---
1 file changed, 22 insertions(+), 7 deleti
wmi_query_block is unnecessarily indirect. Add a straightforward
method for wmi bus drivers to use to read block data.
Signed-off-by: Andy Lutomirski
---
drivers/platform/x86/wmi.c | 52 +-
include/linux/wmi.h| 4
2 files changed, 41 ins
This gives event drivers a very simple way to handle events. It
also seems closer to what the Windows docs suggest that Windows
does: it sounds like, in Windows, the mapper is responsible for
called _WED before dispatching to the subdriver.
Signed-off-by: Andy Lutomirski
---
drivers/platform/x8
Signed-off-by: Andy Lutomirski
---
drivers/platform/x86/dell-wmi.c | 132
1 file changed, 66 insertions(+), 66 deletions(-)
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
index 7c3ebda811ca..48423e53bf94 100644
--- a/driver
We already have the PNP glue to instantiate platform devices for the
ACPI devices that WMI drives. WMI should therefore attach to the
platform device, not the ACPI node.
Signed-off-by: Andy Lutomirski
---
drivers/platform/x86/wmi.c | 57 +++---
1 file cha
My laptop has one RW data object, one RO data object, and one
totally inaccessible data object. Check for the existence of the
accessor methods and report in sysfs.
The docs also permit WQxx getters for single-instance objects to
take no parameters. Probe for that as well to avoid ACPICA warning
Currently we free all devices when we detach from any ACPI node.
Instead, keep track of which node WMI devices are attached to and
free them only as needed. While we're at it, match up notifications
with the device they came from correctly.
This will make our behavior more straightforward on syst
Signed-off-by: Andy Lutomirski
---
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 a17c3d5effe4..383efb8260c7 100644
--- a/drivers/platform/x86/wmi.c
+++ b/drivers/platform/x
This devices the "data", "method" and "event" types. All devices
get "instance_count" and "expensive" attributes, data and method
devices get "object_id" attributes, and event devices get
"notify_id" attributes.
Signed-off-by: Andy Lutomirski
---
drivers/platform/x86/wmi.c | 78
Rearrange acpi_wmi_add to use Linux's error handling conventions.
Signed-off-by: Andy Lutomirski
---
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 383efb8260c7..fc1f339b7
We had two memory leaks. If guid_already_parsed returned true, we'd
leak the wmi_block. If wmi_create_device failed, we'd leak the
device.
Simplify the logic and fix both of them.
Signed-off-by: Andy Lutomirski
---
drivers/platform/x86/wmi.c | 28 +++-
1 file changed,
WMI is just a driver. There's no need to announce when it's loaded.
Signed-off-by: Andy Lutomirski
---
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 eb391a281833..a17c3d5effe4 100644
--- a/drivers/p
WMI is logically a bus: the WMI driver binds to an ACPI node (or
more than one), and each instance of the WMI driver enumerates its
children and hopes that drivers will attach to the children that are
useful.
This patch gives WMI a driver model bus type and the ability to
match to drivers. The bu
Here's v1. I'm sure it still needs work. Thoughts?
Andy Lutomirski (14):
wmi: Drop "Mapper (un)loaded" messages
wmi: Pass the acpi_device through to parse_wdg
wmi: Clean up acpi_wmi_add
wmi: Track wmi devices per ACPI device
wmi: Turn WMI into a bus driver
wmi: Fix error handling whe
The XPS 13 9350 sends WMI keypress events that aren't enumerated in
the DMI table. Add a table listing them. To avoid breaking things
that worked before, these un-enumerated hotkeys won't be used if the
DMI table maps them to something else.
FWIW, it appears that the DMI table may be a legacy th
If DMI lists a hotkey that we don't recognize, log and ignore it
instead of trying to map it to keycode 0. I haven't seen this happen,
but it will help maintain the key map in the future and it will help
avoid sending bogus events.
This also improves the message that we log when we get an unknown
Here's v2.
I'm still hoping to hear more details about the rfkill button.
Meanwhile, let's at least wire up the WMI decoding stuff and
get the rest in.
Changes from v1:
- The new hotkey code matches reality better.
- Don't send key events for the new hotkeys (yet?)
- Improve warning formatting
It's currently hard to follow what maps to what, and it's hard to edit
the array. Redo it as a C99-style array.
I generated this using emacs regexes and a python one-liner.
objdump says this didn't change the table.
Acked-by: Pali Rohár
Signed-off-by: Andy Lutomirski
---
drivers/platform/x86/
On Thu, Nov 26, 2015 at 03:18:32PM +0100, Michał Kępień wrote:
> On some laptop models (e.g. Dell Vostro V131), pressing the Dell Instant
> Launch hotkey does not raise an i8042 interrupt - only WMI event 0xe025
> is generated. As there is no flawless way to determine whether a given
> machine is
On Mon, Nov 30, 2015 at 03:54:58PM +0100, Michał Kępień wrote:
> > The best would be if embedded controller could be configured to send
> > events via i8042 bus...
>
> Yes, but if I correctly understand Mario's message back from July [1],
> V131's EC simply does not support generating scancodes at
On Wed, Nov 25, 2015 at 05:28:54PM -0800, Andy Lutomirski wrote:
> On Mon, Nov 23, 2015 at 11:37 AM, Darren Hart wrote:
> > On Mon, Nov 23, 2015 at 11:25:30AM -0800, Andy Lutomirski wrote:
> >> Without this patch, wmi devices are in /sys/virtual/wmi. They're
> >> logically children of the ACPI WM
On Mon, Nov 30, 2015 at 10:51 AM, Darren Hart wrote:
> On Thu, Nov 26, 2015 at 03:09:29PM +0100, Rafael Wysocki wrote:
>> On Wednesday, November 25, 2015 05:28:54 PM Andy Lutomirski wrote:
>> > On Mon, Nov 23, 2015 at 11:37 AM, Darren Hart wrote:
>> > > On Mon, Nov 23, 2015 at 11:25:30AM -0800, A
On Thu, Nov 26, 2015 at 03:09:29PM +0100, Rafael Wysocki wrote:
> On Wednesday, November 25, 2015 05:28:54 PM Andy Lutomirski wrote:
> > On Mon, Nov 23, 2015 at 11:37 AM, Darren Hart wrote:
> > > On Mon, Nov 23, 2015 at 11:25:30AM -0800, Andy Lutomirski wrote:
> > >> Without this patch, wmi device
On Mon, Nov 30, 2015 at 10:27 AM, Darren Hart wrote:
> On Mon, Nov 23, 2015 at 08:47:10PM +0100, Pali Rohár wrote:
>> On Friday 20 November 2015 17:27:00 Andy Lutomirski wrote:
>> > + if (keycode == KEY_RESERVED) {
>> > + pr_info("firmware scancode %d maps to unrecogniz
On Mon, Nov 23, 2015 at 08:47:10PM +0100, Pali Rohár wrote:
> On Friday 20 November 2015 17:27:00 Andy Lutomirski wrote:
> > + if (keycode == KEY_RESERVED) {
> > + pr_info("firmware scancode %d maps to unrecognized
> > keycode %d\n",
> > + bios
> The best would be if embedded controller could be configured to send
> events via i8042 bus...
Yes, but if I correctly understand Mario's message back from July [1],
V131's EC simply does not support generating scancodes at all.
> I'm starting to thing that blacklist or whitelist of machines is
On Monday 30 November 2015 15:14:00 Michał Kępień wrote:
> Hi Pali,
>
> Thanks again for your efforts.
>
> > $ sudo /usr/bin/input-events 4
> > /dev/input/event4
> > bustype : BUS_I8042
> > vendor : 0x1
> > product : 0x1
> > version : 43841
> > name: "AT Translated Set 2
Hi Pali,
Thanks again for your efforts.
> $ sudo /usr/bin/input-events 4
> /dev/input/event4
> bustype : BUS_I8042
> vendor : 0x1
> product : 0x1
> version : 43841
> name: "AT Translated Set 2 keyboard"
> phys: "isa0060/serio0/input0"
> bits ev : EV_SYN EV_KEY
29 matches
Mail list logo
