Coccinelle noticed:
drivers/platform/x86/intel_chtdc_ti_pwrbtn.c:59:7-32: ERROR: Threaded IRQ
with no primary handler requested without IRQF_ONESHOT
Signed-off-by: Guangqing Zhu <zhuguangqing83@gmail.com>
Link: https://lore.kernel.org/r/20210415091435.10486-1-zhuguangqing83@gmail.com
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add the X570 AORUS ELITE to gigabyte_wmi_known_working_platforms
Signed-off-by: Julian Labus <julian@labus-online.de>
Acked-By: Thomas Weißschuh <thomas@weissschuh.net>
Link: https://lore.kernel.org/r/20210415074526.1782-1-julian@labus-online.de
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
On EC version 3, the first 2 temperature sensors are always CPU and GPU
add labels for these.
This changes e.g. the "sensors" command output on a X1C8 from:
thinkpad-isa-0000
Adapter: ISA adapter
fan1: 2694 RPM
temp1: +42.0°C
temp2: N/A
temp3: +33.0°C
temp4: +0.0°C
temp5: +35.0°C
temp6: +42.0°C
temp7: +42.0°C
temp8: N/A
into:
thinkpad-isa-0000
Adapter: ISA adapter
fan1: 2694 RPM
CPU: +42.0°C
GPU: N/A
temp3: +33.0°C
temp4: +0.0°C
temp5: +35.0°C
temp6: +42.0°C
temp7: +42.0°C
temp8: N/A
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210413072112.183550-1-hdegoede@redhat.com
pmc_plt_clk* clocks are used for ethernet controllers, so need to stay
turned on. This adds the affected board family to critclk_systems DMI
table, so the clocks are marked as CLK_CRITICAL and not turned off.
This replaces the previously listed boards with a match for the whole
device family CBxx63. CBxx63 matches only baytrail devices.
There are new affected boards that would otherwise need to be listed.
There are unaffected boards in the family, but having the clocks
turned on is not an issue.
Fixes: 648e921888 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Steffen Dirkwinkel <s.dirkwinkel@beckhoff.com>
Link: https://lore.kernel.org/r/20210412133006.397679-1-linux-kernel-dev@beckhoff.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested with
* X570 I Aorus Pro Wifi (rev 1.0)
* B550M DS3H
* B550 Gaming X V2 (rev.1.x)
* Z390 I AORUS PRO WIFI (rev. 1.0)
Those mainboards contain an ITE chips for management and
monitoring.
They could also be handled by drivers/hwmon/i87.c.
But the SuperIO range used by i87 is already claimed and used by the
firmware.
The following warning is printed at boot:
kernel: ACPI Warning: SystemIO range 0x0000000000000A45-0x0000000000000A46 conflicts with OpRegion 0x0000000000000A45-0x0000000000000A46 (\GSA1.SIO1) (20200528/utaddress-204)
kernel: ACPI: This conflict may cause random problems and system instability
kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
This driver implements such an ACPI driver.
Unfortunately not all sensor registers are handled by the firmware and even
less are exposed via WMI.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20210412123513.628901-1-linux@weissschuh.net
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
During PCH (platform/board) manufacturing process a global platform
reset has to be induced in order for the configuration changes take
the effect upon following platform reset. This is an internal platform
state and is not intended to be used in the regular platform resets.
The setting is exposed via ETR3 (Extended Test Mode Register 3).
After the manufacturing process is completed the register cannot be
written anymore and is hardware locked.
This setting was commonly done by accessing PMC registers via /dev/mem
but due to security concerns /dev/mem access is much more restricted,
hence the reason for exposing this setting via the dedicated sysfs
interface.
To prevent post manufacturing abuse the register is protected
by hardware locking and the file is set to read-only mode via is_visible
handler.
The register in MMIO space is defined for Cannon Lake and newer PCHs.
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: David E Box <david.e.box@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Tamar Mashiah <tamar.mashiah@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Link: https://lore.kernel.org/r/20210411141532.3004893-1-tomas.winkler@intel.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
On recent Thinkpad platforms it was reported that temp sensor 11 was
always incorrectly displaying 66C. It turns out the reason for this is
that this location in EC RAM is not a temperature sensor but is the
power supply ID (offset 0xC2).
Based on feedback from the Lenovo firmware team the EC RAM version can
be determined and for the current version (3) only the 0x78 to 0x7F
range is used for temp sensors. I don't have any details for earlier
versions so I have left the implementation unaltered there.
Note - in this block only 0x78 and 0x79 are officially designated (CPU &
GPU sensors). The use of the other locations in the block will vary from
platform to platform; but the existing logic to detect a sensor presence
holds.
Signed-off-by: Mark Pearson <markpearson@lenovo.com>
Link: https://lore.kernel.org/r/20210407212015.298222-1-markpearson@lenovo.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
disable_irq() after request_irq() still has a time gap in which
interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
disable IRQ auto-enable because of requesting.
this patch is made base on "add IRQF_NO_AUTOEN for request_irq" which
is being merged: https://lore.kernel.org/patchwork/patch/1388765/
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/1617778852-26492-1-git-send-email-tiantao6@hisilicon.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
disable_irq() after request_irq() still has a time gap in which
interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
disable IRQ auto-enable because of requesting.
this patch is made base on "add IRQF_NO_AUTOEN for request_irq" which
is being merged: https://lore.kernel.org/patchwork/patch/1388765/
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Acked-by: Vadim Pasternak <vadimp@nvidia.com>
Link: https://lore.kernel.org/r/1617785983-28878-1-git-send-email-tiantao6@hisilicon.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmBcNE4THHRnbHhAbGlu
dXRyb25peC5kZQAKCRCmGPVMDXSYoYSnD/0Sag2x37ksPdWlSJ8/j9r79+0u/r8W
QRN7ln6DP/RwGHuFMYNhjczagfyHcjH+1fSFfIhnic0ZlodiJqzGpsHl153bgvci
hi+Qe1ad+a1FlQSAd5A00lDfApc1q24RKq+Qyx7O/cnh2A6jb46a5pFRrKxuY0ys
H7WprWVSkkO7TEzECbkiqDJfz2gAhn2n05iHndbgzuYEYyHepahV5vPfz9xBjNvN
pvVUU0F/1GDDgpJcLWBCZkMx21O/J1lXl6cZx/l5awM5XhEOInnrjEMz0r6do/QE
pQQTxdUZHaQAC+6mQg0yNPavWR4Y/RlNcD00Mg/LRkkxZiD4wjygk3taUZcgg50R
ScqXaDAyIBSbSF/VyDAf+k1PAdw+tFKWUIS0C0KiMla7c6S9OfUXOLBoCF17P+3P
l5GQWWLhAERklRm8tyIfwD3VarlQGzVYsonlauttaIaR5wd49kswr7kVUztQSUTu
ncC/k2sz1bYQ6iltNcXq7Fsp8oMham4QH1TwHv5+HZeNV8zNJXtkqfdSxacY7qvn
xq3wahM6TiWsh0u8tlFA567uwv9sKRwEYHhwh2SoRR7vxYeQhoggvsapjXbOEGx0
9kDPMbbSofrQoAjdPP610sHNuiDAjxGMV3AM+ybkLRwLX1mH/wucS6w+KC+5+Umh
5jWxpa5D6znQKw==
=A79t
-----END PGP SIGNATURE-----
Merge tag 'irq-no-autoen-2021-03-25' into review-hans
Tag for the input subsystem to pick up
The BIOS team have added a new API that allows us to retrieve the
current performance profile without having to disable/enable CQL
mode. Adding the changes to use this API.
Tested on P15 and X1C8
Signed-off-by: Mark Pearson <markpearson@lenovo.com>
Link: https://lore.kernel.org/r/20210406233203.232860-1-markpearson@lenovo.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Sometimes, the "base connected" event that we rely on to (re-)attach the
device connected to the base is sent a bit too early. When this happens,
some devices may not be completely ready yet.
Specifically, the battery has been observed to report zero-values for
things like full charge capacity, which, however, is only loaded once
when the driver for that device probes. This can thus result in battery
readings being unavailable.
As we cannot easily and reliably discern between devices that are not
ready yet and devices that are not connected (i.e. will never be ready),
delay adding these devices. This should give them enough time to set up.
The delay is set to 2.5 seconds, which should give us a good safety
margin based on testing and still be fairly responsive for users.
To achieve that delay switch to updating via a delayed work struct,
which means that we can also get rid of some locking.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20210405231222.358113-1-luzmaximilian@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
In some cases when firmware is busy or updating, some mailbox commands
still timeout on some newer CPUs. To fix this issue, change how we
process timeout.
With this change, replaced timeout from using simple count with real
timeout in micro-seconds using ktime. When the command response takes
more than average processing time, yield to other tasks. The worst case
timeout is extended upto 1 milli-second.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://lore.kernel.org/r/20210330220840.3113959-1-srinivas.pandruvada@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This release adds following changes:
- Support increased number of CPUs
- Return error when mailbox commmand fails to enable core-power
- Option to online all CPUs
- Removes build date and time print
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
These macros introduce nondeterminism in builds, and break reproducible
builds.
Signed-off-by: Antonio Terceiro <antonio.terceiro@linaro.org>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
It is possible that users manually offlined CPUs via sysfs interface
and then started this utility. In this case we will not be able to get
package and die id of the those CPUs. So add an option to force online
if required for some commands.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Some older kernels don't support reading core-power status. In that case
mailbox command fails. So, display core-power status as "unknown" instead
of supported.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The current string size to print cpulist can accommodate upto 80
logical CPUs per package. But this limit is not enough. So increase
the string size. Also prevent buffer overflow, if the string size
reaches limit.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Make init_bios_attributes() ACPI object parsing more robust:
1. Always check that the type of the return ACPI object is package, rather
then only checking this for instance_id == 0
2. Check that the package has the minimum amount of elements which will
be consumed by the populate_foo_data() for the attr_type
Note/TODO: The populate_foo_data() functions should also be made more
robust. The should check the type of each of the elements matches the
type which they expect and in case of populate_enum_data()
obj->package.count should be passed to it as an argument and it should
re-check this itself since it consume a variable number of elements.
Fixes: e8a60aa740 ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
Cc: Divya Bharathi <Divya_Bharathi@dell.com>
Cc: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210321121607.35717-1-hdegoede@redhat.com
The variable result is being assigned a value that is never
read and it is being updated later with a new value. The
assignment is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20210326192022.623001-1-colin.king@canonical.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The "&client->ddev->lock" and "&ddev->lock" are the same thing. Let's
use "&ddev->lock" consistently.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/YF3TgCcpcCYl3a//@mwanda
Signed-off-by: Hans de Goede <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
* On recent ZenBooks the fn-lock is disabled
by default on boot while running Windows.
* Add a module param ( fnlock_default ) that allows
changing the default at probe time
Signed-off-by: Luca Stefani <luca.stefani.ge1@gmail.com>
Link: https://lore.kernel.org/r/20210323210126.145286-1-luca.stefani.ge1@gmail.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Advantech sw_button is a ACPI event trigger button.
With this driver, we can report KEY_PROG1 on the
Advantech Tabletop Network Appliances products and it has been
tested in FWA1112VC.
Add the software define button support to report EV_REP key_event
(KEY_PROG1) by pressing button that could be get on user
interface and trigger the customized actions.
Signed-off-by: Andrea.Ho <Andrea.Ho@advantech.com.tw>
Link: https://lore.kernel.org/r/20210319034427.23222-1-andrea.cs97g@nctu.edu.tw
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Some devices send (duplicate) tablet-mode events when moved around even
though the mode has not changed; and they do this even when suspended.
Change the tablet-mode event handling when priv->wakeup_mode is set to
update the switch state in case it changed and then return immediately
(without calling pm_wakeup_hard_event()) to avoid spurious wakeups.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212537
Fixes: 537b0dd472 ("platform/x86: intel-hid: Add support for SW_TABLET_MODE")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Elia Devito <eliadevito@gmail.com>
Link: https://lore.kernel.org/r/20210404143831.25173-1-hdegoede@redhat.com
Due to a HW limitation, the Latency Tolerance Reporting (LTR) value
programmed in the Tiger Lake GBE controller is not large enough to allow
the platform to enter Package C10, which in turn prevents the platform from
achieving its low power target during suspend-to-idle. Ignore the GBE LTR
value on Tiger Lake. LTR ignore functionality is currently performed solely
by a debugfs write call. Split out the LTR code into its own function that
can be called by both the debugfs writer and by this work around.
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Reviewed-by: Sasha Neftin <sasha.neftin@intel.com>
Cc: intel-wired-lan@lists.osuosl.org
Reviewed-by: Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>
Link: https://lore.kernel.org/r/20210319201844.3305399-2-david.e.box@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The intel_pmc_core driver is mostly used as a debugging driver for Intel
platforms that support SLPS0 (S0ix). But the driver may also be used to
communicate actions to the PMC in order to ensure transition to SLPS0 on
some systems and architectures. As such the driver should be built on all
platforms it supports. Indicate this in the Kconfig. Also update the list
of supported features.
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Suggested-by: Mario Limonciello <mario.limonciello@dell.com>
Link: https://lore.kernel.org/r/20210319201844.3305399-1-david.e.box@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Use kobj_to_dev() instead of container_of()
Generated by: scripts/coccinelle/api/kobj_to_dev.cocci
CC: Denis Efremov <efremov@linux.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: kernel test robot <lkp@intel.com>
Signed-off-by: Julia Lawall <julia.lawall@inria.fr>
Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2103171258010.2981@hadrien
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
s/derefence/dereference/
Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@cascardo.eti.br>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20210317084343.3788084-1-unixbhaskar@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Fixes off-by-one bugs in the macro assignments for the crashlog control
bits. Was initially tested on emulation but bug revealed after testing on
silicon.
Fixes: 5ef9998c96 ("platform/x86: Intel PMT Crashlog capability driver")
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Link: https://lore.kernel.org/r/20210317024455.3071477-2-david.e.box@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Initialize the struct resource in intel_pmt_dev_register to zero to avoid a
fault should the char *name field be non-zero.
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Link: https://lore.kernel.org/r/20210317024455.3071477-1-david.e.box@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
On some newer Thinkpads we need to set SAR value based on antenna type.
This patch provides a sysfs interface that userspace can use to get
antenna type and set corresponding SAR value, as is required for FCC
certification.
Reviewed-by: Mark Pearson <markpearson@lenovo.com>
Signed-off-by: Nitin Joshi <njoshi1@lenovo.com>
Link: https://lore.kernel.org/r/20210317024636.356175-1-njoshi1@lenovo.com
Signed-off-by: Hans de Goede <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
Cleanup create_attributes_level_sysfs_files():
1. There is no need to call sysfs_remove_file() on error, sysman_init()
will already call release_attributes_data() on failure which already does
this.
2. There is no need for the pr_debug() calls sysfs_create_file() should
never fail and if it does it will already complain about the problem
itself.
Fixes: e8a60aa740 ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
Cc: Divya Bharathi <Divya_Bharathi@dell.com>
Cc: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210321115901.35072-8-hdegoede@redhat.com
When either the attributes or the password interface is not found, then
unregister the 2 wmi drivers again and return -ENODEV from sysman_init().
Fixes: e8a60aa740 ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
Cc: Divya Bharathi <Divya_Bharathi@dell.com>
Cc: Mario Limonciello <mario.limonciello@dell.com>
Reported-by: Alexander Naumann <alexandernaumann@gmx.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210321115901.35072-7-hdegoede@redhat.com
Cleanup sysman_init() error-exit handling:
1. There is no need for the fail_reset_bios and fail_authentication_kset
eror-exit cases, these can be handled by release_attributes_data()
2. Rename all the labels from fail_what_failed, to err_what_to_cleanup
this is the usual way to name these and avoids the need to rename
them when extra steps are added.
Fixes: e8a60aa740 ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
Cc: Divya Bharathi <Divya_Bharathi@dell.com>
Cc: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210321115901.35072-6-hdegoede@redhat.com
All calls of init_bios_attributes() will result in a
goto fail_create_group if they fail, which calls
release_attributes_data().
So there is no need to call release_attributes_data() from
init_bios_attributes() on failure itself.
Fixes: e8a60aa740 ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
Cc: Divya Bharathi <Divya_Bharathi@dell.com>
Cc: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210321115901.35072-5-hdegoede@redhat.com
During some of the error-exit paths it is possible that
release_attributes_data() will get called multiple times,
which results in exit_foo_attributes() getting called multiple
times.
Make it safe to call exit_foo_attributes() multiple times,
avoiding double-free()s in this case.
Note that release_attributes_data() really should only be called
once during error-exit paths. This will be fixed in a separate patch
and it is good to have the exit_foo_attributes() functions modified
this way regardless.
Fixes: e8a60aa740 ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
Cc: Divya Bharathi <Divya_Bharathi@dell.com>
Cc: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210321115901.35072-4-hdegoede@redhat.com
It is possible for release_attributes_data() to get called when the
main_dir_kset has not been created yet, move the removal of the bios-reset
sysfs attr to under a if (main_dir_kset) check to avoid a NULL pointer
deref.
Fixes: e8a60aa740 ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
Cc: Divya Bharathi <Divya_Bharathi@dell.com>
Cc: Mario Limonciello <mario.limonciello@dell.com>
Reported-by: Alexander Naumann <alexandernaumann@gmx.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210321115901.35072-3-hdegoede@redhat.com
On some system the WMI GUIDs used by dell-wmi-sysman are present but there
are no enum type attributes, this causes init_bios_attributes() to return
-ENODEV, after which sysman_init() does a "goto fail_create_group" and then
calls release_attributes_data().
release_attributes_data() calls kset_unregister(wmi_priv.main_dir_kset);
but before this commit it was missing a "wmi_priv.main_dir_kset = NULL;"
statement; and after calling release_attributes_data() the sysman_init()
error handling does this:
if (wmi_priv.main_dir_kset) {
kset_unregister(wmi_priv.main_dir_kset);
wmi_priv.main_dir_kset = NULL;
}
Which causes a second kset_unregister(wmi_priv.main_dir_kset), leading to
a double-free, which causes a crash.
Add the missing "wmi_priv.main_dir_kset = NULL;" statement to
release_attributes_data() to fix this double-free crash.
Fixes: e8a60aa740 ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
Cc: Divya Bharathi <Divya_Bharathi@dell.com>
Cc: Mario Limonciello <mario.limonciello@dell.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210321115901.35072-2-hdegoede@redhat.com
Testing has shown that setting /sys/firmware/acpi/platform_profile to
"balanced" when /sys/bus/platform/devices/thinkpad_acpi/dytc_lapmode
reports 1, causes dytc_lapmode to get reset to 0 and then it becomes
stuck at 0 for aprox. 30 minutes even if the laptop is used on a lap.
Disabling CQL (when enabled) before issuing the DYTC_CMD_RESET to get
back to balanced mode and re-enabling it afterwards again, like the
code already does when switching to low-power / performance mode fixes
this.
Fixes: c3bfcd4c67 ("platform/x86: thinkpad_acpi: Add platform profile support")
Tested-by: Mark Pearson <markpearson@lenovo.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210321113108.7069-1-hdegoede@redhat.com
On many recent ThinkPad laptops, there's a new LED next to the ESC key,
that indicates the FnLock status.
When the Fn+ESC combo is pressed, FnLock is toggled, which causes the
Media Key functionality to change, making it so that the media keys
either perform their media key function, or function as an F-key by
default. The Fn key can be used the access the alternate function at any
time.
With the current linux kernel, the LED doens't change state if you press
the Fn+ESC key combo. However, the media key functionality *does*
change. This is annoying, since the LED will stay on if it was on during
bootup, and it makes it hard to keep track what the current state of the
FnLock is.
This patch calls an ACPI function, that gets the current media key
state, when the Fn+ESC key combo is pressed. Through testing it was
discovered that this function causes the LED to update correctly to
reflect the current state when this function is called.
The relevant ACPI calls are the following:
\_SB_.PCI0.LPC0.EC0_.HKEY.GMKS: Get media key state, returns 0x603 if the FnLock mode is enabled, and 0x602 if it's disabled.
\_SB_.PCI0.LPC0.EC0_.HKEY.SMKS: Set media key state, sending a 1 will enable FnLock mode, and a 0 will disable it.
Relevant discussion:
https://bugzilla.kernel.org/show_bug.cgi?id=207841https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1881015
Signed-off-by: Esteve Varela Colominas <esteve.varela@gmail.com>
Link: https://lore.kernel.org/r/20210315195823.23212-1-esteve.varela@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Lenovo platforms with DYTC versions earlier than version 5 don't set
the lapmode interface correctly, causing issues with thermald on
older platforms.
Add checking to only create the dytc_lapmode interface for version
5 and later.
Fixes: 1ac09656bd ("platform/x86: thinkpad_acpi: Add palm sensor support")
Signed-off-by: Mark Pearson <markpearson@lenovo.com>
Link: https://lore.kernel.org/r/20210311174843.3161-1-markpearson@lenovo.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
