summaryrefslogtreecommitdiff
path: root/drivers/platform
AgeCommit message (Collapse)AuthorFilesLines
2023-11-28platform/x86: thinkpad_acpi: Add battery quirk for Thinkpad X120eOlli Asikainen1-0/+1
[ Upstream commit 916646758aea81a143ce89103910f715ed923346 ] Thinkpad X120e also needs this battery quirk. Signed-off-by: Olli Asikainen <olli.asikainen@gmail.com> Link: https://lore.kernel.org/r/20231024190922.2742-1-olli.asikainen@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-28platform/chrome: kunit: initialize lock for fake ec_devTzung-Bi Shih1-0/+1
[ Upstream commit e410b4ade83d06a046f6e32b5085997502ba0559 ] cros_ec_cmd_xfer() uses ec_dev->lock. Initialize it. Otherwise, dmesg shows the following: > DEBUG_LOCKS_WARN_ON(lock->magic != lock) > ... > Call Trace: > ? __mutex_lock > ? __warn > ? __mutex_lock > ... > ? cros_ec_cmd_xfer Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20231003080504.4011337-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20platform/x86: wmi: Fix opening of char deviceArmin Wolf1-14/+6
[ Upstream commit eba9ac7abab91c8f6d351460239108bef5e7a0b6 ] Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via file private data"), the miscdevice stores a pointer to itself inside filp->private_data, which means that private_data will not be NULL when wmi_char_open() is called. This might cause memory corruption should wmi_char_open() be unable to find its driver, something which can happen when the associated WMI device is deleted in wmi_free_devices(). Fix the problem by using the miscdevice pointer to retrieve the WMI device data associated with a char device using container_of(). This also avoids wmi_char_open() picking a wrong WMI device bound to a driver with the same name as the original driver. Fixes: 44b6b7661132 ("platform/x86: wmi: create userspace interface for drivers") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231020211005.38216-5-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20platform/x86: wmi: Fix probe failure when failing to register WMI devicesArmin Wolf1-8/+8
[ Upstream commit ed85891a276edaf7a867de0e9acd0837bc3008f2 ] When a WMI device besides the first one somehow fails to register, retval is returned while still containing a negative error code. This causes the ACPI device fail to probe, leaving behind zombie WMI devices leading to various errors later. Handle the single error path separately and return 0 unconditionally after trying to register all WMI devices to solve the issue. Also continue to register WMI devices even if some fail to allocate memory. Fixes: 6ee50aaa9a20 ("platform/x86: wmi: Instantiate all devices before adding them") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231020211005.38216-4-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-08platform/mellanox: mlxbf-tmfifo: Fix a warning messageLiming Sun1-10/+11
[ Upstream commit 99c09c985e5973c8f0ad976ebae069548dd86f12 ] This commit fixes the smatch static checker warning in function mlxbf_tmfifo_rxtx_word() which complains data not initialized at line 634 when IS_VRING_DROP() is TRUE. Signed-off-by: Liming Sun <limings@nvidia.com> Link: https://lore.kernel.org/r/20231012230235.219861-1-limings@nvidia.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-02platform/x86: Add s2idle quirk for more Lenovo laptopsDavid Lazar1-0/+73
commit 3bde7ec13c971445faade32172cb0b4370b841d9 upstream. When suspending to idle and resuming on some Lenovo laptops using the Mendocino APU, multiple NVME IOMMU page faults occur, showing up in dmesg as repeated errors: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000b address=0xb6674000 flags=0x0000] The system is unstable afterwards. Applying the s2idle quirk introduced by commit 455cd867b85b ("platform/x86: thinkpad_acpi: Add a s2idle resume quirk for a number of laptops") allows these systems to work with the IOMMU enabled and s2idle resume to work. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218024 Suggested-by: Mario Limonciello <mario.limonciello@amd.com> Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: David Lazar <dlazar@gmail.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://lore.kernel.org/r/ZTlsyOaFucF2pWrL@localhost Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-25platform/x86: asus-wmi: Map 0x2a code, Ignore 0x2b and 0x2c eventsHans de Goede1-0/+3
commit 235985d1763f7aba92c1c64e5f5aaec26c2c9b18 upstream. Newer Asus laptops send the following new WMI event codes when some of the F1 - F12 "media" hotkeys are pressed: 0x2a Screen Capture 0x2b PrintScreen 0x2c CapsLock Map 0x2a to KEY_SELECTIVE_SCREENSHOT mirroring how similar hotkeys are mapped on other laptops. PrintScreem and CapsLock are also reported as normal PS/2 keyboard events, map these event codes to KE_IGNORE to avoid "Unknown key code 0x%x\n" log messages. Reported-by: James John <me@donjajo.com> Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/ Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231017090725.38163-4-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-25platform/x86: asus-wmi: Only map brightness codes when using asus-wmi ↵Hans de Goede1-11/+4
backlight control commit a5b92be2482e5f9ef30be4e4cda12ed484381493 upstream. Older Asus laptops change the backlight level themselves and then send WMI events with different codes for different backlight levels. The asus-wmi.c code maps the entire range of codes reported on brightness down keypresses to an internal ASUS_WMI_BRN_DOWN code: define NOTIFY_BRNUP_MIN 0x11 define NOTIFY_BRNUP_MAX 0x1f define NOTIFY_BRNDOWN_MIN 0x20 define NOTIFY_BRNDOWN_MAX 0x2e if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX) code = ASUS_WMI_BRN_UP; else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX) code = ASUS_WMI_BRN_DOWN; This mapping is causing issues on new laptop models which actually send 0x2b events for printscreen presses and 0x2c events for capslock presses, which get translated into spurious brightness-down presses. This mapping is really only necessary when asus-wmi has registered a backlight-device for backlight control. In this case the mapping was used to decide to filter out the keypresss since in this case the firmware has already modified the brightness itself and instead of reporting a keypress asus-wmi will just report the new brightness value to userspace. OTOH when the firmware does not adjust the brightness itself then it seems to always report 0x2e for brightness-down presses and 0x2f for brightness up presses independent of the actual brightness level. So in this case the mapping of the code is not necessary and this translation actually leads to spurious brightness-down presses being send to userspace when pressing printscreen or capslock. Modify asus_wmi_handle_event_code() to only do the mapping when using asus-wmi backlight control to fix the spurious brightness-down presses. Reported-by: James John <me@donjajo.com> Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/ Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231017090725.38163-3-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-25platform/x86: asus-wmi: Change ASUS_WMI_BRN_DOWN code from 0x20 to 0x2eHans de Goede1-1/+1
commit f37cc2fc277b371fc491890afb7d8a26e36bb3a1 upstream. Older Asus laptops change the backlight level themselves and then send WMI events with different codes for different backlight levels. The asus-wmi.c code maps the entire range of codes reported on brightness down keypresses to an internal ASUS_WMI_BRN_DOWN code: define NOTIFY_BRNUP_MIN 0x11 define NOTIFY_BRNUP_MAX 0x1f define NOTIFY_BRNDOWN_MIN 0x20 define NOTIFY_BRNDOWN_MAX 0x2e if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX) code = ASUS_WMI_BRN_UP; else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX) code = ASUS_WMI_BRN_DOWN; Before this commit all the NOTIFY_BRNDOWN_MIN - NOTIFY_BRNDOWN_MAX aka 0x20 - 0x2e events were mapped to 0x20. This mapping is causing issues on new laptop models which actually send 0x2b events for printscreen presses and 0x2c events for capslock presses, which get translated into spurious brightness-down presses. The plan is disable the 0x11-0x2e special mapping on laptops where asus-wmi does not register a backlight-device to avoid the spurious brightness-down keypresses. New laptops always send 0x2e for brightness-down presses, change the special internal ASUS_WMI_BRN_DOWN value from 0x20 to 0x2e to match this in preparation for fixing the spurious brightness-down presses. This change does not have any functional impact since all of 0x20 - 0x2e is mapped to ASUS_WMI_BRN_DOWN first and only then checked against the keymap code and the new 0x2e value is still in the 0x20 - 0x2e range. Reported-by: James John <me@donjajo.com> Closes: https://lore.kernel.org/platform-driver-x86/a2c441fe-457e-44cf-a146-0ecd86b037cf@donjajo.com/ Closes: https://bbs.archlinux.org/viewtopic.php?pid=2123716 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231017090725.38163-2-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-25platform/x86: intel-uncore-freq: Conditionally create attribute for read ↵Srinivas Pandruvada1-2/+6
frequency commit 4d73c6772ab771cbbe7e46a73e7c78ba490350fa upstream. When the current uncore frequency can't be read, don't create attribute "current_freq_khz" as any read will fail later. Some user space applications like turbostat fail to continue with the failure. So, check error during attribute creation. Fixes: 414eef27283a ("platform/x86/intel/uncore-freq: Display uncore current frequency") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20231004181915.1887913-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-25platform/surface: platform_profile: Propagate error if profile registration ↵Armin Wolf1-2/+1
fails commit fe0e04cf66a12ffe6d1b43725ddaabd5599d024f upstream. If platform_profile_register() fails, the driver does not propagate the error, but instead probes successfully. This means when the driver unbinds, the a warning might be issued by platform_profile_remove(). Fix this by propagating the error back to the caller of surface_platform_profile_probe(). Compile-tested only. Fixes: b78b4982d763 ("platform/surface: Add platform profile driver") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> Tested-by: Maximilian Luz <luzmaximilian@gmail.com> Link: https://lore.kernel.org/r/20231014235449.288702-1-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-25platform/x86: touchscreen_dmi: Add info for the Positivo C4128BRenan Guilherme Lebre Ramos1-0/+23
[ Upstream commit aa7dcba3bae6869122828b144a3cfd231718089d ] Add information for the Positivo C4128B, a notebook/tablet convertible. Link: https://github.com/onitake/gsl-firmware/pull/217 Signed-off-by: Renan Guilherme Lebre Ramos <japareaggae@gmail.com> Link: https://lore.kernel.org/r/20231004235900.426240-1-japareaggae@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-20platform/x86: hp-wmi:: Mark driver struct with __refdata to prevent section ↵Uwe Kleine-König1-1/+7
mismatch warning [ Upstream commit 5b44abbc39ca15df80d0da4756078c98c831090f ] As described in the added code comment, a reference to .exit.text is ok for drivers registered via module_platform_driver_probe(). Make this explicit to prevent a section mismatch warning: WARNING: modpost: drivers/platform/x86/hp/hp-wmi: section mismatch in reference: hp_wmi_driver+0x8 (section: .data) -> hp_wmi_bios_remove (section: .exit.text) Fixes: c165b80cfecc ("hp-wmi: fix handling of platform device") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231004111624.2667753-1-u.kleine-koenig@pengutronix.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-20platform/x86: think-lmi: Fix reference leakArmin Wolf1-4/+20
[ Upstream commit 528ab3e605cabf2f9c9bd5944d3bfe15f6e94f81 ] If a duplicate attribute is found using kset_find_obj(), a reference to that attribute is returned which needs to be disposed accordingly using kobject_put(). Move the setting name validation into a separate function to allow for this change without having to duplicate the cleanup code for this setting. As a side note, a very similar bug was fixed in commit 7295a996fdab ("platform/x86: dell-sysman: Fix reference leak"), so it seems that the bug was copied from that driver. Compile-tested only. Fixes: 1bcad8e510b2 ("platform/x86: think-lmi: Fix issues with duplicate attributes") Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20230925142819.74525-2-W_Armin@gmx.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06platform/x86: asus-wmi: Support 2023 ROG X16 tablet modeLuke D. Jones1-0/+9
[ Upstream commit 4106a70ddad57ee6d8f98b81d6f036740c72762b ] Add quirk for ASUS ROG X16 (GV601V, 2023 versions) Flow 2-in-1 to enable tablet mode with lid flip (all screen rotations). Signed-off-by: Luke D. Jones <luke@ljones.dev> Link: https://lore.kernel.org/r/20230905082813.13470-1-luke@ljones.dev Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06platform/mellanox: mlxbf-bootctl: add NET dependency into KconfigDavid Thompson1-0/+1
[ Upstream commit c2dffda1d8f7511505bbbf16ba282f2079b30089 ] The latest version of the mlxbf_bootctl driver utilizes "sysfs_format_mac", and this API is only available if NET is defined in the kernel configuration. This patch changes the mlxbf_bootctl Kconfig to depend on NET. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202309031058.JvwNDBKt-lkp@intel.com/ Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: David Thompson <davthompson@nvidia.com> Link: https://lore.kernel.org/r/20230905133243.31550-1-davthompson@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06platform/x86: intel_scu_ipc: Fail IPC send if still busyStephen Boyd1-12/+28
[ Upstream commit 85e654c9f722853a595fa941dca60c157b707b86 ] It's possible for interrupts to get significantly delayed to the point that callers of intel_scu_ipc_dev_command() and friends can call the function once, hit a timeout, and call it again while the interrupt still hasn't been processed. This driver will get seriously confused if the interrupt is finally processed after the second IPC has been sent with ipc_command(). It won't know which IPC has been completed. This could be quite disastrous if calling code assumes something has happened upon return from intel_scu_ipc_dev_simple_command() when it actually hasn't. Let's avoid this scenario by simply returning -EBUSY in this case. Hopefully higher layers will know to back off or fail gracefully when this happens. It's all highly unlikely anyway, but it's better to be correct here as we have no way to know which IPC the status register is telling us about if we send a second IPC while the previous IPC is still processing. Cc: Prashant Malani <pmalani@chromium.org> Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Fixes: ed12f295bfd5 ("ipc: Added support for IPC interrupt mode") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20230913212723.3055315-5-swboyd@chromium.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06platform/x86: intel_scu_ipc: Don't override scu in ↵Stephen Boyd1-1/+0
intel_scu_ipc_dev_simple_command() [ Upstream commit efce78584e583226e9a1f6cb2fb555d6ff47c3e7 ] Andy discovered this bug during patch review. The 'scu' argument to this function shouldn't be overridden by the function itself. It doesn't make any sense. Looking at the commit history, we see that commit f57fa18583f5 ("platform/x86: intel_scu_ipc: Introduce new SCU IPC API") removed the setting of the scu to ipcdev in other functions, but not this one. That was an oversight. Remove this line so that we stop overriding the scu instance that is used by this function. Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Closes: https://lore.kernel.org/r/ZPjdZ3xNmBEBvNiS@smile.fi.intel.com Cc: Prashant Malani <pmalani@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Fixes: f57fa18583f5 ("platform/x86: intel_scu_ipc: Introduce new SCU IPC API") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20230913212723.3055315-4-swboyd@chromium.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06platform/x86: intel_scu_ipc: Check status upon timeout in ↵Stephen Boyd1-2/+4
ipc_wait_for_interrupt() [ Upstream commit 427fada620733e6474d783ae6037a66eae42bf8c ] It's possible for the completion in ipc_wait_for_interrupt() to timeout, simply because the interrupt was delayed in being processed. A timeout in itself is not an error. This driver should check the status register upon a timeout to ensure that scheduling or interrupt processing delays don't affect the outcome of the IPC return value. CPU0 SCU ---- --- ipc_wait_for_interrupt() wait_for_completion_timeout(&scu->cmd_complete) [TIMEOUT] status[IPC_STATUS_BUSY]=0 Fix this problem by reading the status bit in all cases, regardless of the timeout. If the completion times out, we'll assume the problem was that the IPC_STATUS_BUSY bit was still set, but if the status bit is cleared in the meantime we know that we hit some scheduling delay and we should just check the error bit. Cc: Prashant Malani <pmalani@chromium.org> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Fixes: ed12f295bfd5 ("ipc: Added support for IPC interrupt mode") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20230913212723.3055315-3-swboyd@chromium.org Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06platform/x86: intel_scu_ipc: Check status after timeout in busy_loop()Stephen Boyd1-11/+8
[ Upstream commit e0b4ab3bb92bda8d12f55842614362989d5b2cb3 ] It's possible for the polling loop in busy_loop() to get scheduled away for a long time. status = ipc_read_status(scu); // status = IPC_STATUS_BUSY <long time scheduled away> if (!(status & IPC_STATUS_BUSY)) If this happens, then the status bit could change while the task is scheduled away and this function would never read the status again after timing out. Instead, the function will return -ETIMEDOUT when it's possible that scheduling didn't work out and the status bit was cleared. Bit polling code should always check the bit being polled one more time after the timeout in case this happens. Fix this by reading the status once more after the while loop breaks. The readl_poll_timeout() macro implements all of this, and it is shorter, so use that macro here to consolidate code and fix this. There were some concerns with using readl_poll_timeout() because it uses timekeeping, and timekeeping isn't running early on or during the late stages of system suspend or early stages of system resume, but an audit of the code concluded that this code isn't called during those times so it is safe to use the macro. Cc: Prashant Malani <pmalani@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Fixes: e7b7ab3847c9 ("platform/x86: intel_scu_ipc: Sleeping is fine when polling") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20230913212723.3055315-2-swboyd@chromium.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19platform/mellanox: NVSW_SN2201 should depend on ACPIGeert Uytterhoeven1-2/+2
[ Upstream commit 0a138f1670bd1af13ba6949c48ea86ddd4bf557e ] The only probing method supported by the Nvidia SN2201 platform driver is probing through an ACPI match table. Hence add a dependency on ACPI, to prevent asking the user about this driver when configuring a kernel without ACPI support. Fixes: 662f24826f95 ("platform/mellanox: Add support for new SN2201 system") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Vadim Pasternak <vadimp@nvidia.com> Acked-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/ec5a4071691ab08d58771b7732a9988e89779268.1693828363.git.geert+renesas@glider.be Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19platform/mellanox: mlxbf-pmc: Fix reading of unprogrammed eventsShravan Kumar Ramani1-20/+7
[ Upstream commit 0f5969452e162efc50bdc98968fb62b424a9874b ] This fix involves 2 changes: - All event regs have a reset value of 0, which is not a valid event_number as per the event_list for most blocks and hence seen as an error. Add a "disable" event with event_number 0 for all blocks. - The enable bit for each counter need not be checked before reading the event info, and hence removed. Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver") Signed-off-by: Shravan Kumar Ramani <shravankr@nvidia.com> Reviewed-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: David Thompson <davthompson@nvidia.com> Link: https://lore.kernel.org/r/04d0213932d32681de1c716b54320ed894e52425.1693917738.git.shravankr@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19platform/mellanox: mlxbf-pmc: Fix potential buffer overflowsShravan Kumar Ramani1-7/+7
[ Upstream commit 80ccd40568bcd3655b0fd0be1e9b3379fd6e1056 ] Replace sprintf with sysfs_emit where possible. Size check in mlxbf_pmc_event_list_show should account for "\0". Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver") Signed-off-by: Shravan Kumar Ramani <shravankr@nvidia.com> Reviewed-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: David Thompson <davthompson@nvidia.com> Link: https://lore.kernel.org/r/bef39ef32319a31b32f999065911f61b0d3b17c3.1693917738.git.shravankr@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19platform/mellanox: mlxbf-tmfifo: Drop jumbo framesLiming Sun1-7/+17
[ Upstream commit fc4c655821546239abb3cf4274d66b9747aa87dd ] This commit drops over-sized network packets to avoid tmfifo queue stuck. Fixes: 1357dfd7261f ("platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc") Signed-off-by: Liming Sun <limings@nvidia.com> Reviewed-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: David Thompson <davthompson@nvidia.com> Link: https://lore.kernel.org/r/9318936c2447f76db475c985ca6d91f057efcd41.1693322547.git.limings@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19platform/mellanox: mlxbf-tmfifo: Drop the Rx packet if no more descriptorsLiming Sun1-17/+49
[ Upstream commit 78034cbece79c2d730ad0770b3b7f23eedbbecf5 ] This commit fixes tmfifo console stuck issue when the virtual networking interface is in down state. In such case, the network Rx descriptors runs out and causes the Rx network packet staying in the head of the tmfifo thus blocking the console packets. The fix is to drop the Rx network packet when no more Rx descriptors. Function name mlxbf_tmfifo_release_pending_pkt() is also renamed to mlxbf_tmfifo_release_pkt() to be more approperiate. Fixes: 1357dfd7261f ("platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc") Signed-off-by: Liming Sun <limings@nvidia.com> Reviewed-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: David Thompson <davthompson@nvidia.com> Link: https://lore.kernel.org/r/8c0177dc938ae03f52ff7e0b62dbeee74b7bec09.1693322547.git.limings@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13platform/chrome: chromeos_acpi: print hex string for ACPI_TYPE_BUFFERTzung-Bi Shih1-1/+30
commit 0820debb7d489e9eb1f68b7bb69e6ae210699b3f upstream. `element->buffer.pointer` should be binary blob. `%s` doesn't work perfect for them. Print hex string for ACPI_TYPE_BUFFER. Also update the documentation to reflect this. Fixes: 0a4cad9c11ad ("platform/chrome: Add ChromeOS ACPI device driver") Cc: stable@vger.kernel.org Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20230803011245.3773756-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-13platform/x86/amd/pmf: Fix a missing cleanup pathMario Limonciello1-1/+2
[ Upstream commit 4dbd6e61adc7e52dd1c9165f0ccaa90806611e40 ] On systems that support slider notifications but don't otherwise support granular slider the SPS cleanup path doesn't run. This means that loading/unloading/loading leads to failures because the sysfs files don't get setup properly when reloaded. Add the missing cleanup path. Fixes: 33c9ab5b493a ("platform/x86/amd/pmf: Notify OS power slider update") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230823185421.23959-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13platform/x86: dell-sysman: Fix reference leakArmin Wolf1-3/+6
[ Upstream commit 7295a996fdab7bf83dc3d4078fa8b139b8e0a1bf ] If a duplicate attribute is found using kset_find_obj(), a reference to that attribute is returned. This means that we need to dispose it accordingly. Use kobject_put() to dispose the duplicate attribute in such a case. Compile-tested only. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20230805053610.7106-1-W_Armin@gmx.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13platform/mellanox: Fix mlxbf-tmfifo not handling all virtio CONSOLE ↵Shih-Yi Chen1-0/+1
notifications [ Upstream commit 0848cab765c634597636810bf76d0934003cce28 ] rshim console does not show all entries of dmesg. Fixed by setting MLXBF_TM_TX_LWM_IRQ for every CONSOLE notification. Signed-off-by: Shih-Yi Chen <shihyic@nvidia.com> Reviewed-by: Liming Sung <limings@nvidia.com> Reviewed-by: David Thompson <davthompson@nvidia.com> Link: https://lore.kernel.org/r/20230821150627.26075-1-shihyic@nvidia.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13platform/x86/amd/pmf: Fix unsigned comparison with less than zeroYang Li1-1/+2
[ Upstream commit 785c00993dc4c4bb2f7b0f3a3f29c03a6f7aab2e ] The return value from the call to amd_pmf_get_pprof_modes() is int. However, the return value is being assigned to an unsigned char variable 'mode', so making 'mode' an int. silence the warning: ./drivers/platform/x86/amd/pmf/sps.c:183:5-9: WARNING: Unsigned expression compared with zero: mode < 0 Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5995 Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/20230727014315.51375-1-yang.lee@linux.alibaba.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13platform/x86: huawei-wmi: Silence ambient light sensorKonstantin Shelekhin1-0/+2
[ Upstream commit c21733754cd6ecbca346f2adf9b17d4cfa50504f ] Currently huawei-wmi causes a lot of spam in dmesg on my Huawei MateBook X Pro 2022: ... [36409.328463] input input9: Unknown key pressed, code: 0x02c1 [36411.335104] input input9: Unknown key pressed, code: 0x02c1 [36412.338674] input input9: Unknown key pressed, code: 0x02c1 [36414.848564] input input9: Unknown key pressed, code: 0x02c1 [36416.858706] input input9: Unknown key pressed, code: 0x02c1 ... Fix that by ignoring events generated by ambient light sensor. This issue was reported on GitHub and resolved with the following merge request: https://github.com/aymanbagabas/Huawei-WMI/pull/70 I've contacted the mainter of this repo and he gave me the "go ahead" to send this patch to the maling list. Signed-off-by: Konstantin Shelekhin <k.shelekhin@ftml.net> Link: https://lore.kernel.org/r/20230722155922.173856-1-k.shelekhin@ftml.net Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13platform/x86: asus-wmi: Fix setting RGB mode on some TUF laptopsKristian Angelov1-2/+12
[ Upstream commit 6a758a3e831ce1a84c9c209ac6dc755f4c8ce77a ] This patch fixes setting the cmd values to 0xb3 and 0xb4. This is necessary on some TUF laptops in order to set the RGB mode. Closes: https://lore.kernel.org/platform-driver-x86/443078148.491022.1677576298133@nm83.abv.bg Signed-off-by: Kristian Angelov <kristiana2000@abv.bg> Reviewed-by: Luke D. Jones <luke@ljones.dev> Link: https://lore.kernel.org/r/ZLlS7o6UdTUBkyqa@wyvern.localdomain Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13platform/x86: think-lmi: Use kfree_sensitive instead of kfreeWang Ming1-2/+2
[ Upstream commit 1da0893aed2e48e2bdf37c29b029f2e060d25927 ] key might contain private part of the key, so better use kfree_sensitive to free it. Signed-off-by: Wang Ming <machel@vivo.com> Link: https://lore.kernel.org/r/20230717101114.18966-1-machel@vivo.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13platform/x86/intel/hid: Add HP Dragonfly G2 to VGBS DMI quirksMaxim Mikityanskiy1-0/+6
[ Upstream commit 7783e97f8558ad7a4d1748922461bc88483fbcdf ] HP Elite Dragonfly G2 (a convertible laptop/tablet) has a reliable VGBS method. If VGBS is not called on boot, the firmware sends an initial 0xcd event shortly after calling the BTNL method, but only if the device is booted in the laptop mode. However, if the device is booted in the tablet mode and VGBS is not called, there is no initial 0xcc event, and the input device for SW_TABLET_MODE is not registered up until the user turns the device into the laptop mode. Call VGBS on boot on this device to get the initial state of SW_TABLET_MODE in a reliable way. Tested with BIOS 1.13.1. Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com> Link: https://lore.kernel.org/r/20230716183213.64173-1-maxtram95@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13platform/x86: intel: hid: Always call BTNL ACPI methodHans de Goede1-12/+9
[ Upstream commit e3ab18de2b09361d6f0e4aafb9cfd6d002ce43a1 ] On a HP Elite Dragonfly G2 the 0xcc and 0xcd events for SW_TABLET_MODE are only send after the BTNL ACPI method has been called. Likely more devices need this, so make the BTNL ACPI method unconditional instead of only doing it on devices with a 5 button array. Note this also makes the intel_button_array_enable() call in probe() unconditional, that function does its own priv->array check. This makes the intel_button_array_enable() call in probe() consistent with the calls done on suspend/resume which also rely on the priv->array check inside the function. Reported-by: Maxim Mikityanskiy <maxtram95@gmail.com> Closes: https://lore.kernel.org/platform-driver-x86/20230712175023.31651-1-maxtram95@gmail.com/ Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230715181516.5173-1-hdegoede@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-08-30platform/x86: ideapad-laptop: Add support for new hotkeys found on ThinkBook ↵André Apitzsch1-0/+5
14s Yoga ITL commit a260f7d726fde52c0278bd3fa085a758639bcee2 upstream. The Lenovo Thinkbook 14s Yoga ITL has 4 new symbols/shortcuts on their F9-F11 and PrtSc keys: F9: Has a symbol of a head with a headset, the manual says "Service key" F10: Has a symbol of a telephone horn which has been picked up from the receiver, the manual says: "Answer incoming calls" F11: Has a symbol of a telephone horn which is resting on the receiver, the manual says: "Reject incoming calls" PrtSc: Has a symbol of a siccor and a dashed ellipse, the manual says: "Open the Windows 'Snipping' Tool app" This commit adds support for these 4 new hkey events. Signed-off-by: André Apitzsch <git@apitzsch.eu> Link: https://lore.kernel.org/r/20230819-lenovo_keys-v1-1-9d34eac88e0a@apitzsch.eu Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-16ACPI: scan: Create platform device for CS35L56Simon Trimmer1-0/+14
commit 1cd0302be5645420f73090aee26fa787287e1096 upstream. The ACPI device CSC3556 is a Cirrus Logic CS35L56 mono amplifier which is used in multiples, and can be connected either to I2C or SPI. There will be multiple instances under the same Device() node. Add it to ignore_serial_bus_ids and handle it in the serial-multi-instantiate driver. There can be a 5th I2cSerialBusV2, but this is an alias address and doesn't represent a real device. Ignore this by having a dummy 5th entry in the serial-multi-instantiate instance list with the name of a non-existent driver, on the same pattern as done for bsg2150. Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20230728111345.7224-1-rf@opensource.cirrus.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-16platform/x86: serial-multi-instantiate: Auto detect IRQ resource for CSC3551David Xu1-4/+17
commit 676b7c5ecab36274442887ceadd6dee8248a244f upstream. The current code assumes that the CSC3551(multiple cs35l41) always have its interrupt pin connected to GPIO thus the IRQ can be acquired with acpi_dev_gpio_irq_get. However on some newer laptop models this is no longer the case as they have the CSC3551's interrupt pin connected to APIC. This causes smi_i2c_probe to fail on these machines. To support these machines, a new macro IRQ_RESOURCE_AUTO was introduced for cs35l41 smi_node, and smi_get_irq function was modified so it tries to get GPIO irq resource first and if failed, tries to get APIC irq resource for cs35l41. This patch affects only the cs35l41's probing and brings no negative influence on machines that indeed have the cs35l41's interrupt pin connected to GPIO. Signed-off-by: David Xu <xuwd1@hotmail.com> Link: https://lore.kernel.org/r/SY4P282MB18350CD8288687B87FFD2243E037A@SY4P282MB1835.AUSP282.PROD.OUTLOOK.COM Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-03platform/x86: msi-laptop: Fix rfkill out-of-sync on MSI Wind U100Maxim Mikityanskiy1-4/+4
[ Upstream commit ad084a6d99bc182bf109c190c808e2ea073ec57b ] Only the HW rfkill state is toggled on laptops with quirks->ec_read_only (so far only MSI Wind U90/U100). There are, however, a few issues with the implementation: 1. The initial HW state is always unblocked, regardless of the actual state on boot, because msi_init_rfkill only sets the SW state, regardless of ec_read_only. 2. The initial SW state corresponds to the actual state on boot, but it can't be changed afterwards, because set_device_state returns -EOPNOTSUPP. It confuses the userspace, making Wi-Fi and/or Bluetooth unusable if it was blocked on boot, and breaking the airplane mode if the rfkill was unblocked on boot. Address the above issues by properly initializing the HW state on ec_read_only laptops and by allowing the userspace to toggle the SW state. Don't set the SW state ourselves and let the userspace fully control it. Toggling the SW state is a no-op, however, it allows the userspace to properly toggle the airplane mode. The actual SW radio disablement is handled by the corresponding rtl818x_pci and btusb drivers that have their own rfkills. Tested on MSI Wind U100 Plus, BIOS ver 1.0G, EC ver 130. Fixes: 0816392b97d4 ("msi-laptop: merge quirk tables to one") Fixes: 0de6575ad0a8 ("msi-laptop: Add MSI Wind U90/U100 support") Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com> Link: https://lore.kernel.org/r/20230721145423.161057-1-maxtram95@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-08-03platform/x86/amd/pmf: reduce verbosity of apmf_get_system_paramsShyam Sundar S K1-1/+1
commit 839e90e75e695b3d9ee17f5a2811e7ee5aea8d4a upstream. apmf_get_system_params() failure is not a critical event, reduce its verbosity from dev_err to dev_dbg. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20230714144435.1239776-1-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-03platform/x86/amd/pmf: Notify OS power slider updateShyam Sundar S K4-6/+114
commit 33c9ab5b493a0e922b06c12fed4fdcb862212cda upstream. APMF fn8 can notify EC about the OS slider position change. Add this capability to the PMF driver so that it can call the APMF fn8 based on the changes in the Platform profile events. Co-developed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://lore.kernel.org/r/20230714144435.1239776-2-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-23platform/x86: wmi: Break possible infinite loop when parsing GUIDAndy Shevchenko1-10/+12
[ Upstream commit 028e6e204ace1f080cfeacd72c50397eb8ae8883 ] The while-loop may break on one of the two conditions, either ID string is empty or GUID matches. The second one, may never be reached if the parsed string is not correct GUID. In such a case the loop will never advance to check the next ID. Break possible infinite loop by factoring out guid_parse_and_compare() helper which may be moved to the generic header for everyone later on and preventing from similar mistake in the future. Interestingly that firstly it appeared when WMI was turned into a bus driver, but later when duplicated GUIDs were checked, the while-loop has been replaced by for-loop and hence no mistake made again. Fixes: a48e23385fcf ("platform/x86: wmi: add context pointer field to struct wmi_device_id") Fixes: 844af950da94 ("platform/x86: wmi: Turn WMI into a bus driver") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230621151155.78279-1-andriy.shevchenko@linux.intel.com Tested-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19platform/x86/dell/dell-rbtn: Fix resources leaking on error pathMichal Wilczynski1-6/+7
[ Upstream commit 966cca72ab20289083521a385fa56035d85a222d ] Currently rbtn_add() in case of failure is leaking resources. Fix this by adding a proper rollback. Move devm_kzalloc() before rbtn_acquire(), so it doesn't require rollback in case of failure. While at it, remove unnecessary assignment of NULL to device->driver_data and unnecessary whitespace, plus add a break for the default case in a switch. Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Suggested-by: Pali Rohár <pali@kernel.org> Fixes: 817a5cdb40c8 ("dell-rbtn: Dell Airplane Mode Switch driver") Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Reviewed-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20230613084310.2775896-1-michal.wilczynski@intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19platform/x86: thinkpad_acpi: Fix lkp-tests warnings for platform profilesMark Pearson1-2/+4
[ Upstream commit f999e23ce66c1555d7b653fba171a88ecee53704 ] Fix issues identified in dytc_profile_refresh identified by lkp-tests. drivers/platform/x86/thinkpad_acpi.c:10538 dytc_profile_refresh() error: uninitialized symbol 'funcmode'. drivers/platform/x86/thinkpad_acpi.c:10531 dytc_profile_refresh() error: uninitialized symbol 'output'. drivers/platform/x86/thinkpad_acpi.c:10537 dytc_profile_refresh() error: uninitialized symbol 'output'. These issues should not lead to real problems in the field as the refresh function should only be called if MMC or PSC mode enabled. But good to fix. Thanks to Dan Carpenter and the lkp-tests project for flagging these. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/r/202306011202.1hbgLRD4-lkp@intel.com/ Fixes: 1bc5d819f0b9 ("platform/x86: thinkpad_acpi: Fix profile modes on Intel platforms") Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://lore.kernel.org/r/20230606151804.8819-1-mpearson-lenovo@squebb.ca Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19platform/x86: think-lmi: Correct NVME password handlingMark Pearson1-2/+2
[ Upstream commit 4cebb42412248d28df6de01420cfac5654428d41 ] NVME passwords identifier have been standardised across the Lenovo systems and now use udrp and adrp (user and admin level) instead of unvp and mnvp. This should apparently be backwards compatible. Fixes: 640a5fa50a42 ("platform/x86: think-lmi: Opcode support") Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230601200552.4396-6-mpearson-lenovo@squebb.ca Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19platform/x86: think-lmi: Correct System password interfaceMark Pearson1-3/+3
[ Upstream commit 97eef5983372d7aee6549d644d788fd0c10d2b6e ] The system password identification was incorrect. This means that if the password was enabled it wouldn't be detected correctly; and setting it would not work. Also updated code to use TLMI_SMP_PWD instead of TLMI_SYS_PWD to be in sync with Lenovo documentation. Fixes: 640a5fa50a42 ("platform/x86: think-lmi: Opcode support") Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230601200552.4396-3-mpearson-lenovo@squebb.ca Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19platform/x86: think-lmi: mutex protection around multiple WMI callsMark Pearson1-0/+10
[ Upstream commit c41e0121a1221894a1a9c4666156db9e1def4d6c ] When an attribute is being changed if the Admin account is enabled, or if a password is being updated then multiple WMI calls are needed. Add mutex protection to ensure no race conditions are introduced. Fixes: b49f72e7f96d ("platform/x86: think-lmi: Certificate authentication support") Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230601200552.4396-1-mpearson-lenovo@squebb.ca Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19platform/x86: lenovo-yogabook: Set default keyboard backligh brightness on ↵Hans de Goede1-0/+3
probe() [ Upstream commit 9e6380d6573181c555ca1b5019b08d19a9ee581c ] Set default keyboard backlight brightness on probe(), this fixes the backlight being off after a rmmod + modprobe. Fixes: c0549b72d99d ("platform/x86: lenovo-yogabook-wmi: Add driver for Lenovo Yoga Book") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230430165807.472798-5-hdegoede@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19platform/x86: lenovo-yogabook: Reprobe devices on remove()Hans de Goede1-0/+11
[ Upstream commit 711bcc0cb34e96a60e88d7b0260862781de3e530 ] Ensure that both the keyboard touchscreen and the digitizer have their driver bound after remove(). Without this modprobing lenovo-yogabook-wmi after a rmmod fails because lenovo-yogabook-wmi defers probing until both devices have their driver bound. Fixes: c0549b72d99d ("platform/x86: lenovo-yogabook-wmi: Add driver for Lenovo Yoga Book") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230430165807.472798-4-hdegoede@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19platform/x86: lenovo-yogabook: Fix work race on remove()Hans de Goede1-10/+10
[ Upstream commit 9148cd2eb4450a8e9c49c8a14201fb82f651128f ] When yogabook_wmi_remove() runs yogabook_wmi_work might still be running and using the devices which yogabook_wmi_remove() puts. To avoid this move to explicitly cancelling the work rather then using devm_work_autocancel(). This requires also making the yogabook_backside_hall_irq handler non devm managed, so that it cannot re-queue the work while yogabook_wmi_remove() runs. Fixes: c0549b72d99d ("platform/x86: lenovo-yogabook-wmi: Add driver for Lenovo Yoga Book") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230430165807.472798-3-hdegoede@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-01-10 08:05:45 +0300