| Age | Commit message (Collapse) | Author |
|---|
|
Move Intel vButton driver to intel sub-directory to improve readability.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20210820110458.73018-19-andriy.shevchenko@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Various 360 degree hinges (yoga) style 2-in-1 devices use 2 accelerometers
to allow the OS to determine the angle between the display and the base of
the device.
On Windows these are read by a special HingeAngleService process which
calls undocumented ACPI methods, to let the firmware know if the 2-in-1 is
in tablet- or laptop-mode. The firmware may use this to disable the kbd and
touchpad to avoid spurious input in tablet-mode as well as to report
SW_TABLET_MODE info to the OS.
Since Linux does not call these undocumented methods, the SW_TABLET_MODE
info reported by various pdx86 drivers is incorrect on these devices.
Before this commit the intel-hid and thinkpad_acpi code already had 2
hardcoded checks for ACPI hardware-ids of dual-accel sensors to avoid
reporting broken info.
And now we also have a bug-report about the same problem in the intel-vbtn
code. Since there are at least 3 different ACPI hardware-ids in play, add
a new dual_accel_detect() helper which checks for all 3, rather then
adding different hardware-ids to the drivers as bug-reports trickle in.
Having shared code which checks all known hardware-ids is esp. important
for the intel-hid and intel-vbtn drivers as these are generic drivers
which are used on a lot of devices.
The BOSC0200 hardware-id requires special handling, because often it is
used for a single-accelerometer setup. Only in a few cases it refers to
a dual-accel setup, in which case there will be 2 I2cSerialBus resources
in the device's resource-list, so the helper checks for this.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209011
Reported-and-tested-by: Julius Lehmann <julius@devpi.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210729082134.6683-1-hdegoede@redhat.com
|
|
Now that we have 2 separate input_dev-s for the buttons and the switches,
this is no longer used, remove it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20210325123255.73103-1-hdegoede@redhat.com
|
|
Stop reporting SW_DOCK events because this breaks suspend-on-lid-close.
SW_DOCK should only be reported for docking stations, but all the DSDTs in
my DSDT collection which use the intel-vbtn code, always seem to use this
for 2-in-1s / convertibles and set SW_DOCK=1 when in laptop-mode (in tandem
with setting SW_TABLET_MODE=0).
This causes userspace to think the laptop is docked to a port-replicator
and to disable suspend-on-lid-close, which is undesirable.
Map the dock events to KEY_IGNORE to avoid this broken SW_DOCK reporting.
Note this may theoretically cause us to stop reporting SW_DOCK on some
device where the 0xCA and 0xCB intel-vbtn events are actually used for
reporting docking to a classic docking-station / port-replicator but
I'm not aware of any such devices.
Also the most important thing is that we only report SW_DOCK when it
reliably reports being docked to a classic docking-station without any
false positives, which clearly is not the case here. If there is a
chance of reporting false positives then it is better to not report
SW_DOCK at all.
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210321163513.72328-1-hdegoede@redhat.com
|
|
The VBDL ACPI method enables button/switch reporting through the
intel-vbtn device. In some cases the embedded-controller (EC) might
call Notify() on the intel-vbtn device immediately after the
the VBDL call to make sure that the OS is synced with the EC's
button and switch state.
If we register our notify_handler after evaluating VBDL this means
that we might miss the Notify() calls made by the EC to sync the
state.
E.g. the HP Stream x360 Convertible PC 11 has a VGBS method which
always returns 0, independent of the actual SW_TABLET_MODE state
of the device; and immediately after the VBDL call it calls
Notify(0xCD) or Notify(0xCC) to report the actual state.
Move the evaluation of VBDL to after registering our notify_handler
so that we don't miss any events.
Cc: Elia Devito <eliadevito@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210115161850.117614-4-hdegoede@redhat.com
|
|
Some 2-in-1s have a broken VGBS method, so we cannot get an initial
state for the switches from them. Reporting the wrong initial state for
SW_TABLET_MODE causes serious problems (touchpad and/or keyboard events
being ignored by userspace when reporting SW_TABLET_MODE=1), so on these
devices we cannot register an input-dev for the switches at probe time.
We can however register an input-dev for the switches as soon as we
receive the first switches event, because then we will know the state.
Note this mirrors the behavior of recent changs to the intel-hid driver
which also registers a separate switches input-dev on receiving the
first event on machines with a broken VGBS method.
Cc: Elia Devito <eliadevito@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210115161850.117614-3-hdegoede@redhat.com
|
|
Create 2 separate input-devs for buttons and switches, this is a
preparation for dynamically registering the switches-input device
for devices which are not on the switches allow-list, but do make
Notify() calls with an event value from the switches sparse-keymap.
This also brings the intel-vbtn driver inline with the intel-hid
driver which is doing the same thing.
Cc: Elia Devito <eliadevito@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210115161850.117614-2-hdegoede@redhat.com
|
|
Rework the wakeup path inside notify_handler() to special case the
buttons (KE_KEY) case instead of the switches case.
In case of a button wake event we want to skip reporting this,
mirroring how the drivers/acpi/button.c code skips the reporting
in the wakeup case (suspended flag set) too.
The reason to skip reporting in this case is that some Linux
desktop-environments will immediately resuspend if we report an
evdev event for the power-button press on wakeup.
Before this commit the skipping of the button-press was done
in a round-about way: In case of a wakeup the regular
sparse_keymap_report_event() would always be skipped by
an early return, and then to avoid not reporting switch changes
on wakeup there was a special KE_SW path with a duplicate
sparse_keymap_report_event() call.
This commit refactors the wakeup handling to explicitly skip the
reporting for button wake events, while using the regular
reporting path for non button (switches) wakeup events.
No intentional functional impact.
Cc: Elia Devito <eliadevito@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210115161850.117614-1-hdegoede@redhat.com
|
|
THe HP Stream x360 Convertible PC 11 DSDT has the following VGBS function:
Method (VGBS, 0, Serialized)
{
If ((^^PCI0.LPCB.EC0.ROLS == Zero))
{
VBDS = Zero
}
Else
{
VBDS = Zero
}
Return (VBDS) /* \_SB_.VGBI.VBDS */
}
Which is obviously wrong, because it always returns 0 independent of the
2-in-1 being in laptop or tablet mode. This causes the intel-vbtn driver
to initially report SW_TABLET_MODE = 1 to userspace, which is known to
cause problems when the 2-in-1 is actually in laptop mode.
During earlier testing this turned out to not be a problem because the
2-in-1 would do a Notify(..., 0xCC) or Notify(..., 0xCD) soon after
the intel-vbtn driver loaded, correcting the SW_TABLET_MODE state.
Further testing however has shown that this Notify() soon after the
intel-vbtn driver loads, does not always happen. When the Notify
does not happen, then intel-vbtn reports SW_TABLET_MODE = 1 resulting in
a non-working touchpad.
IOW the tablet-mode reporting is not reliable on this device, so it
should be dropped from the allow-list, fixing the touchpad sometimes
not working.
Fixes: 8169bd3e6e19 ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting")
Link: https://lore.kernel.org/r/20210114143432.31750-1-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
The Dell Inspiron 7352 is a 2-in-1 model that has chassis-type "Notebook".
Add this model to the dmi_switches_allow_list.
Signed-off-by: Arnold Gozum <arngozum@gmail.com>
Link: https://lore.kernel.org/r/20201226205307.249659-1-arngozum@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
x360 models
Some HP x360 models have an ACPI VGBS method which sets bit 4 instead of
bit 6 when NOT in tablet mode at boot. Inspecting all the DSDTs in my DSDT
collection shows only one other model, the Medion E1239T ever setting bit 4
and it always sets this together with bit 6.
So lets treat bit 4 as a second bit which when set indicates the device not
being in tablet-mode, as we already do for bit 6.
While at it also prefix all VGBS constant defines with "VGBS_".
Note this wrokaround was first added to the kernel as
commit d823346876a9 ("platform/x86: intel-vbtn: Fix SW_TABLET_MODE always
reporting 1 on the HP Pavilion 11 x360").
After commit 8169bd3e6e19 ("platform/x86: intel-vbtn: Switch to an
allow-list for SW_TABLET_MODE reporting") got added to the kernel this
was reverted, because with the new allow-list approach the workaround
was no longer necessary for the model on which the issue was first
reported.
But it turns out that the workaround is still necessary because some
affected models report a chassis-type of 31 which is on the allow-list.
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894017
Fixes: 21d64817c724 ("platform/x86: intel-vbtn: Revert "Fix SW_TABLET_MODE always reporting 1 on the HP Pavilion 11 x360"")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
This 2-in-1 model (Product name: Switch SA5-271) features a SW_TABLET_MODE
that works as it would be expected, both when detaching the keyboard and
when folding it behind the tablet body.
It used to work until the introduction of the allow list at
commit 8169bd3e6e193 ("platform/x86: intel-vbtn: Switch to an allow-list
for SW_TABLET_MODE reporting"). Add this model to it, so that the Virtual
Buttons device announces the EV_SW features again.
Fixes: 8169bd3e6e193 ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting")
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Link: https://lore.kernel.org/r/20201201135727.212917-1-carlosg@gnome.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
The Pavilion 13 x360 PC has a chassis-type which does not indicate it is
a convertible, while it is actually a convertible. Add it to the
dmi_switches_allow_list.
Signed-off-by: Max Verevkin <me@maxverevkin.tk>
Link: https://lore.kernel.org/r/20201124131652.11165-1-me@maxverevkin.tk
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
2 recent commits:
cfae58ed681c ("platform/x86: intel-vbtn: Only blacklist SW_TABLET_MODE
on the 9 / "Laptop" chasis-type")
1fac39fd0316 ("platform/x86: intel-vbtn: Also handle tablet-mode switch on
"Detachable" and "Portable" chassis-types")
Enabled reporting of SW_TABLET_MODE on more devices since the vbtn ACPI
interface is used by the firmware on some of those devices to report this.
Testing has shown that unconditionally enabling SW_TABLET_MODE reporting
on all devices with a chassis type of 8 ("Portable") or 10 ("Notebook")
which support the VGBS method is a very bad idea.
Many of these devices are normal laptops (non 2-in-1) models with a VGBS
which always returns 0, which we translate to SW_TABLET_MODE=1. This in
turn causes userspace (libinput) to suppress events from the builtin
keyboard and touchpad, making the laptop essentially unusable.
Since the problem of wrongly reporting SW_TABLET_MODE=1 in combination
with libinput, leads to a non-usable system. Where as OTOH many people will
not even notice when SW_TABLET_MODE is not being reported, this commit
changes intel_vbtn_has_switches() to use a DMI based allow-list.
The new DMI based allow-list matches on the 31 ("Convertible") and
32 ("Detachable") chassis-types, as these clearly are 2-in-1s and
so far if they support the intel-vbtn ACPI interface they all have
properly working SW_TABLET_MODE reporting.
Besides these 2 generic matches, it also contains model specific matches
for 2-in-1 models which use a different chassis-type and which are known
to have properly working SW_TABLET_MODE reporting.
This has been tested on the following 2-in-1 devices:
Dell Venue 11 Pro 7130 vPro
HP Pavilion X2 10-p002nd
HP Stream x360 Convertible PC 11
Medion E1239T
Fixes: cfae58ed681c ("platform/x86: intel-vbtn: Only blacklist SW_TABLET_MODE on the 9 / "Laptop" chasis-type")
BugLink: https://forum.manjaro.org/t/keyboard-and-touchpad-only-work-on-kernel-5-6/22668
BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1175599
Cc: Barnabás Pőcze <pobrn@protonmail.com>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
the HP Pavilion 11 x360"
After discussion, see the Link tag, it appears that this is not good enough.
So, revert it now and apply a better fix.
This reverts commit d823346876a970522ff9e4d2b323c9b734dcc4de.
Link: https://lore.kernel.org/platform-driver-x86/s5hft71klxl.wl-tiwai@suse.de/
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
Pavilion 11 x360
Commit cfae58ed681c ("platform/x86: intel-vbtn: Only blacklist
SW_TABLET_MODE on the 9 / "Laptop" chasis-type") restored SW_TABLET_MODE
reporting on the HP stream x360 11 series on which it was previously broken
by commit de9647efeaa9 ("platform/x86: intel-vbtn: Only activate tablet
mode switch on 2-in-1's").
It turns out that enabling SW_TABLET_MODE reporting on devices with a
chassis-type of 10 ("Notebook") causes SW_TABLET_MODE to always report 1
at boot on the HP Pavilion 11 x360, which causes libinput to disable the
kbd and touchpad.
The HP Pavilion 11 x360's ACPI VGBS method sets bit 4 instead of bit 6 when
NOT in tablet mode at boot. Inspecting all the DSDTs in my DSDT collection
shows only one other model, the Medion E1239T ever setting bit 4 and it
always sets this together with bit 6.
So lets treat bit 4 as a second bit which when set indicates the device not
being in tablet-mode, as we already do for bit 6.
While at it also prefix all VGBS constant defines with "VGBS_".
Fixes: cfae58ed681c ("platform/x86: intel-vbtn: Only blacklist SW_TABLET_MODE on the 9 / "Laptop" chasis-type")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Mark Gross <mgross@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
In the function check_acpi_dev(), if it fails to create
platform device, the return value is ERR_PTR() or NULL.
Thus it must use IS_ERR_OR_NULL() to check return value.
Fixes: 332e081225fc ("intel-vbtn: new driver for Intel Virtual Button")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Lu Wei <luwei32@huawei.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
chasis-type
The HP Stream x360 11-p000nd no longer report SW_TABLET_MODE state / events
with recent kernels. This model reports a chassis-type of 10 / "Notebook"
which is not on the recently introduced chassis-type whitelist
Commit de9647efeaa9 ("platform/x86: intel-vbtn: Only activate tablet mode
switch on 2-in-1's") added a chassis-type whitelist and only listed 31 /
"Convertible" as being capable of generating valid SW_TABLET_MOD events.
Commit 1fac39fd0316 ("platform/x86: intel-vbtn: Also handle tablet-mode
switch on "Detachable" and "Portable" chassis-types") extended the
whitelist with chassis-types 8 / "Portable" and 32 / "Detachable".
And now we need to exten the whitelist again with 10 / "Notebook"...
The issue original fixed by the whitelist is really a ACPI DSDT bug on
the Dell XPS 9360 where it has a VGBS which reports it is in tablet mode
even though it is not a 2-in-1 at all, but a regular laptop.
So since this is a workaround for a DSDT issue on that specific model,
instead of extending the whitelist over and over again, lets switch to
a blacklist and only blacklist the chassis-type of the model for which
the chassis-type check was added.
Note this also fixes the current version of the code no longer checking
if dmi_get_system_info(DMI_CHASSIS_TYPE) returns NULL.
Fixes: 1fac39fd0316 ("platform/x86: intel-vbtn: Also handle tablet-mode switch on "Detachable" and "Portable" chassis-types")
Cc: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mario Limonciello <Mario.limonciello@dell.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
input-device
Setting the initial state of input-device switches must be done before
registering the input-device.
Otherwise the initial state will get send out as an event as soon
as input_sync() gets called.
E.g. when undocking a tablet using intel-vbtn to report SW_TABLET_MODE
and SW_DOCK before this commit we would get (evemu-record output):
E: 0.000001 0005 0005 0001 # EV_SW / SW_DOCK 1
E: 0.000001 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms
E: 0.000109 0005 0005 0000 # EV_SW / SW_DOCK 0
E: 0.000109 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms
E: 0.000133 0005 0001 0001 # EV_SW / SW_TABLET_MODE 1
E: 0.000133 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms
The first SW_DOCK=1 report is spurious, setting the initial switch
state before registering the input-device fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
This is a preparation patch for calling detect_tablet_mode() from
intel_vbtn_input_setup() without needing a forward declaration.
Note this commit makes no functional changes, the moved block of code
is completely unchanged.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
On some devices the INT33D6 vbtn device is only used to report
tablet-mode / docked status (switches) and there are no vbtn managed
buttons.
On these devices there is no VBDL object.
Move the VBDL check to a intel_vbtn_has_buttons() helper and only exit
from intel_vbtn_probe() with -ENODEV when there are both no buttons and
no switches. Also only report the buttons being present to userspace if
the has_buttons check has succeeded.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
"Portable" chassis-types
Commit de9647efeaa9 ("platform/x86: intel-vbtn: Only activate tablet mode
switch on 2-in-1's") added a DMI chassis-type check to avoid accidentally
reporting SW_TABLET_MODE = 1 to userspace on laptops.
Some devices with a detachable keyboard and using the intel-vbnt (INT33D6)
interface to report if they are in tablet mode (keyboard detached) or not,
report 32 / "Detachable" as chassis-type, e.g. the HP Pavilion X2 series.
Other devices with a detachable keyboard and using the intel-vbnt (INT33D6)
interface to report SW_TABLET_MODE, report 8 / "Portable" as chassis-type.
The Dell Venue 11 Pro 7130 is an example of this.
Extend the DMI chassis-type check to also accept Portables and Detachables
so that the intel-vbtn driver will report SW_TABLET_MODE on these devices.
Note the chassis-type check was originally added to avoid a false-positive
tablet-mode report on the Dell XPS 9360 laptop. To the best of my knowledge
that laptop is using a chassis-type of 9 / "Laptop", so after this commit
we still ignore the tablet-switch for that chassis-type.
Fixes: de9647efeaa9 ("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mario Limonciello <Mario.limonciello@dell.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
not there
Commit de9647efeaa9 ("platform/x86: intel-vbtn: Only activate tablet mode
switch on 2-in-1's") added a DMI chassis-type check to avoid accidentally
reporting SW_TABLET_MODE = 1 to userspace on laptops (specifically on the
Dell XPS 9360), to avoid e.g. userspace ignoring touchpad events because
userspace thought the device was in tablet-mode.
But if we are not getting the initial status of the switch because the
device does not have a tablet mode, then we really should not advertise
the presence of a tablet-mode switch to userspace at all, as userspace may
use the mere presence of this switch for certain heuristics.
Fixes: de9647efeaa9 ("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
Split the sparse keymap into 2 separate keymaps, a buttons and a switches
keymap and combine the 2 to a single map again in intel_vbtn_input_setup().
This is a preparation patch for not telling userspace that we have switches
when we do not have them (and for doing the same for the buttons).
Fixes: de9647efeaa9 ("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
Use acpi_evaluate_integer() instead of open-coding it.
This is a preparation patch for adding a intel_vbtn_has_switches()
helper function.
Fixes: de9647efeaa9 ("platform/x86: intel-vbtn: Only activate tablet mode switch on 2-in-1's")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
Move MODULE_DEVICE_TABLE() closer to the table for better maintenance.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
Commit 10a08fd65ec1 ("ACPI: PM: Set up EC GPE for system wakeup from
drivers that need it") assumed that the EC GPE would only need to be
set up for system wakeup if either the intel-hid or the intel-vbtn
driver was in use, but that turns out to be incorrect. In particular,
on ASUS Zenbook UX430UNR/i7-8550U, if the EC GPE is not enabled while
suspended, the system cannot be woken up by opening the lid or
pressing a key, and that machine doesn't use any of the drivers
mentioned above.
For this reason, always set up the EC GPE for system wakeup from
suspend-to-idle by setting and clearing its wake mask in the ACPI
suspend-to-idle callbacks.
Fixes: 10a08fd65ec1 ("ACPI: PM: Set up EC GPE for system wakeup from drivers that need it")
Reported-by: Kristian Klausen <kristian@klausen.dk>
Tested-by: Kristian Klausen <kristian@klausen.dk>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Both intel-hid and intel-vbtn set a wakeup_mode flag causing them
to behave in a special way during system suspend and while suspended
in their "prepare" PM callbacks and clear it in their "resume" PM
callbacks. That may cause the wakeup_mode flag to remain set after
a system suspend failure (if some other driver's "suspend" callback
returns an error before the "suspend" callback of either intel-hid
or intel-vbtn is invoked).
After commit 10a08fd65ec1 ("ACPI: PM: Set up EC GPE for system wakeup
from drivers that need it") that also affects the "wakeup mask" bit
of the EC GPE, which may not be cleared after a failing system
suspend.
Fix this issue by adding "complete" PM callbacks to intel-hid and
intel-vbtn to clear the wakeup_mode flag and the "wakeup mask" bit
of the EC GPE if they have not been cleared earlier.
Fixes: 10a08fd65ec1 ("ACPI: PM: Set up EC GPE for system wakeup from drivers that need it")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
The EC GPE needs to be set up for system wakeup only if there is a
driver depending on it, either intel-hid or intel-vbtn, bound to a
button device that is expected to wake up the system from sleep (such
as the power button on some Dell systems, like the XPS13 9360). It
doesn't need to be set up for waking up the system from sleep in any
other cases and whether or not it is expected to wake up the system
from sleep doesn't depend on whether or not the LPS0 device is
present in the ACPI namespace.
For this reason, rearrange the ACPI suspend-to-idle code to make the
drivers depending on the EC GPE wakeup take care of setting it up and
decouple that from the LPS0 device handling.
While at it, make intel-hid and intel-vbtn prepare for system wakeup
only if they are allowed to wake up the system from sleep by user
space (via sysfs).
[Note that acpi_ec_mark_gpe_for_wake() and acpi_ec_set_gpe_wake_mask()
are there to prevent the EC GPE from being disabled by the
acpi_enable_all_wakeup_gpes() call in acpi_s2idle_prepare(), so on
systems with either intel-hid or intel-vbtn this change doesn't
affect any interactions with the hardware or platform firmware.]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
|
|
When a switch event, such as tablet mode/laptop mode or docked/undocked,
wakes a device make sure that the value of the swich is reported.
Without when a device is put in tablet mode from laptop mode when it is
suspended or vice versa the device will wake up but mode will be
incorrect.
Tested by suspending a device in laptop mode and putting it in tablet
mode, the device resumes and is in tablet mode. When suspending the
device in tablet mode and putting it in laptop mode the device resumes
and is in laptop mode.
Signed-off-by: Mathew King <mathewk@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Reviewed-by: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
The Dell laptop I have has an ACPI that sends 0xCB and 0xCC on entering
tablet mode. On exiting tablet mode it sends 0xCA and 0xCD. Based on:
http://www.traby.de/medion/DSDT/dsdt.dsl
https://gist.github.com/jprvita/5737de3cbb670e80973b7d4e51c38ab6
https://osdn.net/projects/android-x86/scm/git/kernel/commits/
7cbe5a330687b851f32dd9f1048a6ce182d0ff44
It appears that 0xCA and 0xCB are about dock mode, which for my
convertible laptop seems questionably tied to whether I've put
the laptop in tablet or laptop mode. I previously proposed no-oping
0xCA and 0xCB but this revised change attempts to add support for
detecting dock mode--this detection will essentially be broken for
my laptop (the main workaround would be for 0xCA and 0xCB to be used
to provoke a query of the VGBS method that reports the current dock &
tablet mode [which is accurately reported on my laptop but based on
the prior workarounds in the driver it apparently can't be trusted
for all systems]).
Signed-off-by: Matt Delco <delco@chromium.org>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
The intel-vbtn device will not be able to wake up the system any more
after removing the notify handler provided by its driver, so make
its sysfs attributes reflect that.
Fixes: 91f9e850d465 (platform: x86: intel-vbtn: Wake up the system from suspend-to-idle)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
Some laptops such as the XPS 9360 support the intel-vbtn INT33D6
interface but don't initialize the bit that intel-vbtn uses to
represent switching tablet mode.
By running this only on real 2-in-1's it shouldn't cause false
positives.
Fixes: 30323fb6d5 ("Support tablet mode switch")
Reported-by: Jeremy Cline <jeremy@jcline.org>
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Tested-by: Jeremy Cline <jeremy@jcline.org>
Tested-by: Darren Hart (VMware) <dvhart@infradead.org>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
|
|
Replace License short header by SPDX identifier.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Darren Hart (VMware) <dvhart@infradead.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
Some headers are not needed since the driver can be built as module.
Remove them.
While here, sort headers alphabetically.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Darren Hart (VMware) <dvhart@infradead.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
On some laptop like the Dell Inspiron 7000 series tablet mode switch
implemented in Intel ACPI, the events to enter and exit the tablet mode
are 0xCC and 0xCD
This initializes the tablet/laptop mode at the correct value
if the system booted in tablet mode (or the intel-vbtn module
loaded with the device in tablet mode)
Cc: platform-driver-x86@vger.kernel.org
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: "Pali Rohár" <pali.rohar@gmail.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Mario Limonciello <mario_limonciello@dell.com>
Cc: Andy Shevchenko <andy@infradead.org>
Cc: Stefan Brüns<stefan.bruens@rwth-aachen.de>
Signed-off-by: Marco Martin <notmart@gmail.com>
Reviewed-by: Mario Limonciello <mario.limonciello@dell.com>
Acked-by: Pali Rohár <pali.rohar@gmail.com>
[andy: fixed style of comments, indentation, and massaged commit message]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
The new notify_handler logic determining if autorelease should be used or
not is a bit awkward, and can result in more than one call to
sparse_keymap_report_event for the same event (scancode). The nesting
and long lines also made it difficult to read.
Simplify the logic by eliminating a level of nesting with a goto and
always calculate autorelease and val so we can make a single call to
sparse_keymap_report_event.
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Reviewed-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Tested-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Cc: AceLan Kao <acelan.kao@canonical.com>
|
|
The Lenovo Helix 2 and Dell XPS 12 (9Q33) have an extra button on the
front showing a 'Windows' logo, both reporting event codes 0xC2/0xC3
on press/release. On the Dell, both press/release are distinct events
while on the Helix 2 both events are generated on release.
Tested on XPS 12, for info on the Helix 2 see:
https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
|
|
The Rotate Lock button event is emitted on the XPS 12 (BIOS A8, but not
on BIOS A2).
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
|
|
Currently all key events use autorelease, but this forbids use as a
modifier key.
As all event codes come in even/odd pairs, we can lookup the key type
(KE_KEY/KE_IGNORE) for the key up event corresponding to the currently
handled key down event. If the key up is ignored, we keep setting the
autorelease flag for the key down.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
|
|
Event code 0xcc is emitted by several convertibles (Dell XPS 12 9Q33 BIOS
A8, Dell XPS 13 2in1 9365, HP Spectre x360, Lenovo Thinkpad Helix) when
entering tablet mode, and 0xcd on return to laptop mode.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
|
|
Unsupported events is only useful for developers and does not meaningful
for users. Using dev_dbg makes more sense and reduces noise in kernel
messages.
Signed-off-by: Alex Hung <alex.hung@canonical.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
|
|
This fixes a problem where the system gets stuck in a loop
unable to wakeup via power button in s2idle.
The problem happens because:
- press power button:
- system emits 0xc0 (power press), event ignored
- system emits 0xc1 (power release), event processed,
emited as KEY_POWER
- set wakeup_mode to true
- system goes to s2idle
- press power button
- system emits 0xc0 (power press), wakeup_mode is true,
system wakes
- system emits 0xc1 (power release), event processed,
emited as KEY_POWER
- system goes to s2idle again
To avoid this situation, process the presses (which matches what
intel-hid does too).
Verified on an Dell XPS 9365
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
|
|
Allow the intel-vbtn driver to wake up the system from suspend-to-idle
by configuring its platform device as a wakeup one by default and
switching it over to a system wakeup events triggering mode during
system suspend transitions.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
Tested on HP Elite X2 1012 G1.
Matches event report of Lenovo Helix 2
(https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
Signed-off-by: Maarten Maathuis <madman2003@shikahr.net>
[andy: fixed indentation of comments and massaged title of the change]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
git://git.infradead.org/users/dvhart/linux-platform-drivers-x86
Pull x86 platform driver updates from Darrent Hart:
"Introduce one new driver for Mellanox platforms. Add support for
various new models to existing drivers via quirks, hotkeys, etc.
Significant updates to intel_pmc_core in support of Kabylake and
Sunrise Point PCH power management debug. Some cleanup and refactoring
across various drivers.
Detailed summary:
dell-laptop:
- Use brightness_set_blocking for kbd_led_level_set
thinkpad_acpi:
- Initialize local in_tablet_mode and type
- Fix old style declaration GCC warning
- Adding new hotkey ID for Lenovo thinkpad
- Add support for X1 Yoga (2016) Tablet Mode
- Move tablet detection into separate function
asus-nb-wmi:
- Add X45U quirk
- Make use of dmi->ident
asus-wmi:
- Set specified XUSB2PR value for X550LB
intel_mid_thermal:
- Fix suspend handlers unused warning
intel-vbtn:
- Switch to use devm_input_allocate_device
dell-wmi:
- Add events created by Dell Rugged 2-in-1s
- Adjust wifi catcher to emit KEY_WLAN
intel_pmc_core:
- Add KBL CPUID support
- Add LTR IGNORE debug feature
- Add MPHY PLL clock gating status
- ModPhy core lanes pg status
- Add PCH IP Power Gating Status
- Fix PWRMBASE mask and mmio reg len
acer-wmi:
- Only supports AMW0_GUID1 on acer family
mlx-platform:
- Introduce support for Mellanox hotplug driver
platform/x86:
- Use ACPI_FAILURE at appropriate places"
* tag 'platform-drivers-x86-v4.10-1' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86: (22 commits)
platform/x86: thinkpad_acpi: Initialize local in_tablet_mode and type
platform/x86: dell-laptop: Use brightness_set_blocking for kbd_led_level_set
platform/x86: thinkpad_acpi: Fix old style declaration GCC warning
platform/x86: thinkpad_acpi: Adding new hotkey ID for Lenovo thinkpad
platform/x86: thinkpad_acpi: Add support for X1 Yoga (2016) Tablet Mode
platform/x86: thinkpad_acpi: Move tablet detection into separate function
platform/x86: asus-nb-wmi.c: Add X45U quirk
platform/x86: asus-nb-wmi: Make use of dmi->ident
platform/x86: asus-wmi: Set specified XUSB2PR value for X550LB
platform/x86: intel_mid_thermal: Fix suspend handlers unused warning
platform/x86: intel-vbtn: Switch to use devm_input_allocate_device
platform/x86: Use ACPI_FAILURE at appropriate places
platform/x86: dell-wmi: Add events created by Dell Rugged 2-in-1s
platform/x86: dell-wmi: Adjust wifi catcher to emit KEY_WLAN
platform/x86: intel_pmc_core: Add KBL CPUID support
platform/x86: intel_pmc_core: Add LTR IGNORE debug feature
platform/x86: intel_pmc_core: Add MPHY PLL clock gating status
platform/x86: intel_pmc_core: ModPhy core lanes pg status
platform/x86: intel_pmc_core: Add PCH IP Power Gating Status
platform/x86: intel_pmc_core: Fix PWRMBASE mask and mmio reg len
...
|
|
Use devm_input_allocate_device to simplify the error handling code.
This conversion also makes input_register_device() to be called after
acpi_remove_notify_handler. This avoid a small window that it's possible
to call notify_handler after unregister input device.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
Use ACPI_FAILURE() to replace !ACPI_SUCCESS(), this avoid !! operations.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
|
We have a couple of drivers, acpi_apd.c and acpi_lpss.c,
that need to pass extra build-in properties to the devices
they create. Previously the drivers added those properties
to the struct device which is member of the struct
acpi_device, but that does not work. Those properties need
to be assigned to the struct device of the platform device
instead in order for them to become available to the
drivers.
To fix this, this patch changes acpi_create_platform_device
function to take struct property_entry pointer as parameter.
Fixes: 20a875e2e86e (serial: 8250_dw: Add quirk for APM X-Gene SoC)
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Tested-by: Yazen Ghannam <yazen.ghannam@amd.com>
Tested-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This driver supports power button event in Intel Virtual Button currently.
New Dell XPS 13 requires this driver for the power button.
This driver is copied/modified from intel-hid.c
Most credit goes to the author of intel-hid.c,
Alex Hung <alex.hung@canonical.com>
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
