summaryrefslogtreecommitdiff
path: root/drivers/acpi
AgeCommit message (Collapse)AuthorFilesLines
2023-05-11ACPI: PM: Do not turn of unused power resources on the Toshiba Click MiniHans de Goede1-0/+19
[ Upstream commit 9b04d99788cf475cbd277f30ec66230ccb7e99f4 ] The CPR3 power resource on the Toshiba Click Mini toggles a GPIO which is called SISP (for SIS touchscreen power?) on/off. This CPR3 power resource is not listed in any _PR? lists, let alone in a _PR0 list for the SIS0817 touchscreen ACPI device which needs it. Before commit a1224f34d72a ("ACPI: PM: Check states of power resources during initialization") this was not an issue because since nothing referenced the CPR3 power resource its state was always ACPI_POWER_RESOURCE_STATE_UNKNOWN and power resources with this state get ignored by acpi_turn_off_unused_power_resources(). This clearly is a bug in the DSDT of this device. Add a DMI quirk to make acpi_turn_off_unused_power_resources() a no-op on this model to fix the touchscreen no longer working since kernel 5.16 . This quirk also causes 2 other power resources to not get turned off, but the _OFF method on these already was a no-op, so this makes no difference for the other 2 power resources. Fixes: a1224f34d72a ("ACPI: PM: Check states of power resources during initialization") Reported-by: Gé Koerkamp <ge.koerkamp@gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216946 Link: https://lore.kernel.org/regressions/32a14a8a-9795-4c8c-7e00-da9012f548f8@leemhuis.info/ Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11ACPI: bus: Ensure that notify handlers are not running after removalRafael J. Wysocki1-0/+1
[ Upstream commit faae443738c6f0dac9b0d3d11d108f6911a989a9 ] Currently, acpi_device_remove_notify_handler() may return while the notify handler being removed is still running which may allow the module holding that handler to be torn down prematurely. Address this issue by making acpi_device_remove_notify_handler() wait for the handling of all the ACPI events in progress to complete before returning. Fixes: 5894b0c46e49 ("ACPI / scan: Move bus operations and notification routines to bus.c") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11ACPI: VIOT: Initialize the correct IOMMU fwspecJean-Philippe Brucker1-2/+3
[ Upstream commit 47d26684185d09e083669bbbd0c465ab3493a51f ] When setting up DMA for a PCI device, we need to initialize its iommu_fwspec with all possible alias RIDs (such as PCI bridges). To do this we use pci_for_each_dma_alias() which calls viot_pci_dev_iommu_init(). This function incorrectly initializes the fwspec of the bridge instead of the device being configured. Fix it by passing the original device as context to pci_for_each_dma_alias(). Fixes: 3cf485540e7b ("ACPI: Add driver for the VIOT table") Link: https://lore.kernel.org/all/Y8qzOKm6kvhGWG1T@myrica Reported-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11ACPI: processor: Fix evaluating _PDC method when running as Xen dom0Roger Pau Monne1-0/+11
[ Upstream commit 073828e954459b883f23e53999d31e4c55ab9654 ] In ACPI systems, the OS can direct power management, as opposed to the firmware. This OS-directed Power Management is called OSPM. Part of telling the firmware that the OS going to direct power management is making ACPI "_PDC" (Processor Driver Capabilities) calls. These _PDC methods must be evaluated for every processor object. If these _PDC calls are not completed for every processor it can lead to inconsistency and later failures in things like the CPU frequency driver. In a Xen system, the dom0 kernel is responsible for system-wide power management. The dom0 kernel is in charge of OSPM. However, the number of CPUs available to dom0 can be different than the number of CPUs physically present on the system. This leads to a problem: the dom0 kernel needs to evaluate _PDC for all the processors, but it can't always see them. In dom0 kernels, ignore the existing ACPI method for determining if a processor is physically present because it might not be accurate. Instead, ask the hypervisor for this information. Fix this by introducing a custom function to use when running as Xen dom0 in order to check whether a processor object matches a CPU that's online. Such checking is done using the existing information fetched by the Xen pCPU subsystem, extending it to also store the ACPI ID. This ensures that _PDC method gets evaluated for all physically online CPUs, regardless of the number of CPUs made available to dom0. Fixes: 5d554a7bb064 ("ACPI: processor: add internal processor_physically_present()") Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11ACPI: video: Remove acpi_backlight=video quirk for Lenovo ThinkPad W530Hans de Goede1-14/+0
commit 3db66620ea90b0fd4134b31eabfec16d7b07d7e3 upstream. Remove the acpi_backlight=video quirk for Lenovo ThinkPad W530. This was intended to help users of the (unsupported) Nvidia binary driver, but this has been reported to cause backlight control issues for users who have the gfx configured in hybrid (dual-GPU) mode, so drop this. The Nvidia binary driver should call acpi_video_register_backlight() when necessary and this has been reported to Nvidia. Until this is fixed Nvidia binary driver users can work around this by passing "acpi_backlight=video" on the kernel commandline (with the latest 6.1.y or newer stable series, kernels < 6.1.y don't need this). Fixes: a5b2781dcab2 ("ACPI: video: Add acpi_backlight=video quirk for Lenovo ThinkPad W530") Reported-by: Русев Путин <rockeraliexpress@gmail.com> Link: https://lore.kernel.org/linux-acpi/CAK4BXn0ngZRmzx1bodAF8nmYj0PWdUXzPGHofRrsyZj8MBpcVA@mail.gmail.com/ Cc: 6.1+ <stable@vger.kernel.org> # 6.1+ Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-26Revert "ACPICA: Events: Support fixed PCIe wake event"Linus Torvalds3-29/+0
commit 8e41e0a575664d26bb87e012c39435c4c3914ed9 upstream. This reverts commit 5c62d5aab8752e5ee7bfbe75ed6060db1c787f98. This broke wake-on-lan for multiple people, and for much too long. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217069 Link: https://lore.kernel.org/all/754225a2-95a9-2c36-1886-7da1a78308c2@loongson.cn/ Link: https://github.com/acpica/acpica/pull/866 Cc: Rafael J. Wysocki <rafael@kernel.org> Cc: Jianmin Lv <lvjianmin@loongson.cn> Cc: Huacai Chen <chenhuacai@loongson.cn> Cc: Bob Moore <robert.moore@intel.com> Cc: stable@kernel.org # 6.2 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20ACPI: resource: Add Medion S17413 to IRQ override quirkAymeric Wibo1-0/+7
[ Upstream commit 2d0ab14634a26e54f8d6d231b47b7ef233e84599 ] Add DMI info of the Medion S17413 (board M1xA) to the IRQ override quirk table. This fixes the keyboard not working on these laptops. Link: https://bugzilla.kernel.org/show_bug.cgi?id=213031 Signed-off-by: Aymeric Wibo <obiwac@gmail.com> [ rjw: Fixed up white space ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-20ACPI: video: Add backlight=native DMI quirk for Acer Aspire 3830TGHans de Goede1-0/+8
[ Upstream commit 5e7a3bf65db57461d0f47955248fcadf37321a74 ] The Acer Aspire 3830TG predates Windows 8, so it defaults to using acpi_video# for backlight control, but this is non functional on this model. Add a DMI quirk to use the native backlight interface which does work properly. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-13ACPI: video: Add acpi_backlight=video quirk for Lenovo ThinkPad W530Hans de Goede1-0/+14
commit a5b2781dcab2c77979a4b8adda781d2543580901 upstream. The Lenovo ThinkPad W530 uses a nvidia k1000m GPU. When this gets used together with one of the older nvidia binary driver series (the latest series does not support it), then backlight control does not work. This is caused by commit 3dbc80a3e4c5 ("ACPI: video: Make backlight class device registration a separate step (v2)") combined with commit 5aa9d943e9b6 ("ACPI: video: Don't enable fallback path for creating ACPI backlight by default"). After these changes the acpi_video# backlight device is only registered when requested by a GPU driver calling acpi_video_register_backlight() which the nvidia binary driver does not do. I realize that using the nvidia binary driver is not a supported use-case and users can workaround this by adding acpi_backlight=video on the kernel commandline, but the ThinkPad W530 is a popular model under Linux users, so it seems worthwhile to add a quirk for this. I will also email Nvidia asking them to make the driver call acpi_video_register_backlight() when an internal LCD panel is detected. So maybe the next maintenance release of the drivers will fix this... Fixes: 5aa9d943e9b6 ("ACPI: video: Don't enable fallback path for creating ACPI backlight by default") Cc: All applicable <stable@vger.kernel.org> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-13ACPI: video: Add acpi_backlight=video quirk for Apple iMac14,1 and iMac14,2Hans de Goede1-0/+23
commit 2699107989431d6db44f8a9e809ea74c387336d1 upstream. On the Apple iMac14,1 and iMac14,2 all-in-ones (monitors with builtin "PC") the connection between the GPU and the panel is seen by the GPU driver as regular DP instead of eDP, causing the GPU driver to never call acpi_video_register_backlight(). (GPU drivers only call acpi_video_register_backlight() when an internal panel is detected, to avoid non working acpi_video# devices getting registered on desktops which unfortunately is a real issue.) Fix the missing acpi_video# backlight device on these all-in-ones by adding a acpi_backlight=video DMI quirk, so that video.ko will immediately register the backlight device instead of waiting for an acpi_video_register_backlight() call. Fixes: 5aa9d943e9b6 ("ACPI: video: Don't enable fallback path for creating ACPI backlight by default") Cc: All applicable <stable@vger.kernel.org> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-13ACPI: video: Make acpi_backlight=video work independent from GPU driverHans de Goede1-2/+13
commit e506731c8f35699d746c615164ed620cd53c00ca upstream. Commit 3dbc80a3e4c5 ("ACPI: video: Make backlight class device registration a separate step (v2)") combined with commit 5aa9d943e9b6 ("ACPI: video: Don't enable fallback path for creating ACPI backlight by default") Means that the video.ko code now fully depends on the GPU driver calling acpi_video_register_backlight() for the acpi_video# backlight class devices to get registered. This means that if the GPU driver does not do this, acpi_backlight=video on the cmdline, or DMI quirks for selecting acpi_video# will not work. This is a problem on for example Apple iMac14,1 all-in-ones where the monitor's LCD panel shows up as a regular DP connection instead of eDP so the GPU driver will not call acpi_video_register_backlight() [1]. Fix this by making video.ko directly register the acpi_video# devices when these have been explicitly requested either on the cmdline or through DMI quirks (rather then auto-detection being used). [1] GPU drivers only call acpi_video_register_backlight() when an internal panel is detected, to avoid non working acpi_video# devices getting registered on desktops which unfortunately is a real issue. Fixes: 5aa9d943e9b6 ("ACPI: video: Don't enable fallback path for creating ACPI backlight by default") Cc: All applicable <stable@vger.kernel.org> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-13ACPI: video: Add auto_detect arg to __acpi_video_get_backlight_type()Hans de Goede1-13/+8
commit 78dfc9d1d1abb9e400386fa9c5724a8f7d75e3b9 upstream. Allow callers of __acpi_video_get_backlight_type() to pass a pointer to a bool which will get set to false if the backlight-type comes from the cmdline or a DMI quirk and set to true if auto-detection was used. And make __acpi_video_get_backlight_type() non static so that it can be called directly outside of video_detect.c . While at it turn the acpi_video_get_backlight_type() and acpi_video_backlight_use_native() wrappers into static inline functions in include/acpi/video.h, so that we need to export one less symbol. Fixes: 5aa9d943e9b6 ("ACPI: video: Don't enable fallback path for creating ACPI backlight by default") Cc: All applicable <stable@vger.kernel.org> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-06ACPI: bus: Rework system-level device notification handlingRafael J. Wysocki1-46/+37
[ Upstream commit c56610a869bce03490faf4f157076370c71b8ae3 ] For ACPI drivers that provide a ->notify() callback and set ACPI_DRIVER_ALL_NOTIFY_EVENTS in their flags, that callback can be invoked while either the ->add() or the ->remove() callback is running without any synchronization at the bus type level which is counter to the common-sense expectation that notification handling should only be enabled when the driver is actually bound to the device. As a result, if the driver is not careful enough, it's ->notify() callback may crash when it is invoked too early or too late [1]. This issue has been amplified by commit d6fb6ee1820c ("ACPI: bus: Drop driver member of struct acpi_device") that made acpi_bus_notify() check for the presence of the driver and its ->notify() callback directly instead of using an extra driver pointer that was only set and cleared by the bus type code, but it was present before that commit although it was harder to reproduce then. It can be addressed by using the observation that acpi_device_install_notify_handler() can be modified to install the handler for all types of events when ACPI_DRIVER_ALL_NOTIFY_EVENTS is set in the driver flags, in which case acpi_bus_notify() will not need to invoke the driver's ->notify() callback any more and that callback will only be invoked after acpi_device_install_notify_handler() has run and before acpi_device_remove_notify_handler() runs, which implies the correct ordering with respect to the other ACPI driver callbacks. Modify the code accordingly and while at it, drop two redundant local variables from acpi_bus_notify() and turn its description comment into a proper kerneldoc one. Fixes: d6fb6ee1820c ("ACPI: bus: Drop driver member of struct acpi_device") Link: https://lore.kernel.org/linux-acpi/9f6cba7a8a57e5a687c934e8e406e28c.squirrel@mail.panix.com # [1] Reported-by: Pierre Asselin <pa@panix.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Pierre Asselin <pa@panix.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-06ACPI: x86: Add skip i2c clients quirk for Lenovo Yoga Book X90Hans de Goede1-0/+11
[ Upstream commit 1a1e7540cf501dd5c8b57a577a155cdd13c7e202 ] The Lenovo Yoga Book X90 is a x86 tablet which ships with Android x86 as factory OS. The Android x86 kernel fork ignores I2C devices described in the DSDT, except for the PMIC and Audio codecs. As usual the Lenovo Yoga Book X90's DSDT contains a bunch of extra I2C devices which are not actually there, causing various resource conflicts. Add an ACPI_QUIRK_SKIP_I2C_CLIENTS quirk for the Lenovo Yoga Book X90 to the acpi_quirk_skip_dmi_ids table to woraround this. The DSDT also contains broken ACPI GPIO event handlers, disable those too. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-06ACPI: x86: Add skip i2c clients quirk for Acer Iconia One 7 B1-750Hans de Goede1-0/+10
[ Upstream commit a5cb0695c5f0ac2ab0cedf2c1c0d75826cb73448 ] The Acer Iconia One 7 B1-750 is a x86 tablet which ships with Android x86 as factory OS. The Android x86 kernel fork ignores I2C devices described in the DSDT, except for the PMIC and Audio codecs. As usual the Acer Iconia One 7 B1-750's DSDT contains a bunch of extra I2C devices which are not actually there, causing various resource conflicts. Add an ACPI_QUIRK_SKIP_I2C_CLIENTS quirk for the Acer Iconia One 7 B1-750 to the acpi_quirk_skip_dmi_ids table to woraround this. The DSDT also contains broken ACPI GPIO event handlers, disable those too. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-06ACPI: x86: Introduce an acpi_quirk_skip_gpio_event_handlers() helperHans de Goede1-3/+21
[ Upstream commit 5adc409340b1fc82bc1175e602d14ac82ac685e3 ] x86 ACPI boards which ship with only Android as their factory image usually have pretty broken ACPI tables, relying on everything being hardcoded in the factory kernel image and often disabling parts of the ACPI enumeration kernel code to avoid the broken tables causing issues. Part of this broken ACPI code is that sometimes these boards have _AEI ACPI GPIO event handlers which are broken. So far this has been dealt with in the platform/x86/x86-android-tablets.c module, which contains various workarounds for these devices, by it calling acpi_gpiochip_free_interrupts() on gpiochip-s with troublesome handlers to disable the handlers. But in some cases this is too late, if the handlers are of the edge type then gpiolib-acpi.c's code will already have run them at boot. This can cause issues such as GPIOs ending up as owned by "ACPI:OpRegion", making them unavailable for drivers which actually need them. Boards with these broken ACPI tables are already listed in drivers/acpi/x86/utils.c for e.g. acpi_quirk_skip_i2c_client_enumeration(). Extend the quirks mechanism for a new acpi_quirk_skip_gpio_event_handlers() helper, this re-uses the DMI-ids rather then having to duplicate the same DMI table in gpiolib-acpi.c . Also add the new ACPI_QUIRK_SKIP_GPIO_EVENT_HANDLERS quirk to existing boards with troublesome ACPI gpio event handlers, so that the current acpi_gpiochip_free_interrupts() hack can be removed from x86-android-tablets.c . Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-06ACPI: video: Add backlight=native DMI quirk for Dell Vostro 15 3535Chia-Lin Kao (AceLan)1-0/+7
[ Upstream commit 89b0411481967a2e8c91190a211a359966cfcf4b ] Sometimes the system boots up with a acpi_video0 backlight interface which doesn't work. So add Dell Vostro 15 3535 into the video_detect_dmi_table to set it to native explicitly. Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30ACPI: x86: utils: Add Cezanne to the list for forcing StorageD3EnableMario Limonciello1-24/+13
[ Upstream commit e2a56364485e7789e7b8f342637c7f3a219f7ede ] commit 018d6711c26e4 ("ACPI: x86: Add a quirk for Dell Inspiron 14 2-in-1 for StorageD3Enable") introduced a quirk to allow a system with ambiguous use of _ADR 0 to force StorageD3Enable. It was reported that several more Dell systems suffered the same symptoms. As the list is continuing to grow but these are all Cezanne systems, instead add Cezanne to the CPU list to apply the StorageD3Enable property and remove the whole list. It was also reported that an HP system only has StorageD3Enable on the ACPI device for the first NVME disk, not the second. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217003 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216773 Reported-by: David Alvarez Lombardi <dqalombardi@proton.me> Reported-by: dbilios@stdio.gr Reported-and-tested-by: Elvis Angelaccio <elvis.angelaccio@kde.org> Tested-by: victor.bonnelle@proton.me Tested-by: hurricanepootis@protonmail.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30ACPI: x86: Drop quirk for HP ElitebookMario Limonciello1-24/+0
[ Upstream commit e32d546c483a2a0f607687f5b521c2a2f942ffbe ] There was a quirk in `acpi/x86/s2idle.c` for an HP Elitebook G9 platforms to force AMD GUID codepath instead of Microsoft codepath. This was due to a bug with WCN6855 WLAN firmware interaction with the system. This bug is fixed by WCN6855 firmware: WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23 Remove the quirk as it's no longer necessary with this firmware. Link: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=c7a57ef688f7d99d8338a5d8edddc8836ff0e6de Tested-by: Anson Tsao <anson.tsao@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-22ACPI: PPTT: Fix to avoid sleep in the atomic context when PPTT is absentSudeep Holla1-1/+4
commit 91d7b60a65d9f71230ea09b86d2058a884a3c2af upstream. Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage") enabled to map PPTT once on the first invocation of acpi_get_pptt() and never unmapped the same allowing it to be used at runtime with out the hassle of mapping and unmapping the table. This was needed to fetch LLC information from the PPTT in the cpuhotplug path which is executed in the atomic context as the acpi_get_table() might sleep waiting for a mutex. However it missed to handle the case when there is no PPTT on the system which results in acpi_get_pptt() being called from all the secondary CPUs attempting to fetch the LLC information in the atomic context without knowing the absence of PPTT resulting in the splat like below: | BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:164 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | no locks held by swapper/1/0. | irq event stamp: 0 | hardirqs last enabled at (0): 0x0 | hardirqs last disabled at (0): copy_process+0x61c/0x1b40 | softirqs last enabled at (0): copy_process+0x61c/0x1b40 | softirqs last disabled at (0): 0x0 | CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.3.0-rc1 #1 | Call trace: | dump_backtrace+0xac/0x138 | show_stack+0x30/0x48 | dump_stack_lvl+0x60/0xb0 | dump_stack+0x18/0x28 | __might_resched+0x160/0x270 | __might_sleep+0x58/0xb0 | down_timeout+0x34/0x98 | acpi_os_wait_semaphore+0x7c/0xc0 | acpi_ut_acquire_mutex+0x58/0x108 | acpi_get_table+0x40/0xe8 | acpi_get_pptt+0x48/0xa0 | acpi_get_cache_info+0x38/0x140 | init_cache_level+0xf4/0x118 | detect_cache_attributes+0x2e4/0x640 | update_siblings_masks+0x3c/0x330 | store_cpu_topology+0x88/0xf0 | secondary_start_kernel+0xd0/0x168 | __secondary_switched+0xb8/0xc0 Update acpi_get_pptt() to consider the fact that PPTT is once checked and is not available on the system and return NULL avoiding any attempts to fetch PPTT and thereby avoiding any possible sleep waiting for a mutex in the atomic context. Fixes: 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage") Reported-by: Aishwarya TCV <aishwarya.tcv@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Pierre Gondois <pierre.gondois@arm.com> Cc: 6.0+ <stable@vger.kernel.org> # 6.0+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-11PCI/ACPI: Account for _S0W of the target bridge in acpi_pci_bridge_d3()Rafael J. Wysocki1-0/+19
[ Upstream commit 8133844a8f2434be9576850c6978179d7cca5c81 ] It is questionable to allow a PCI bridge to go into D3 if it has _S0W returning D2 or a shallower power state, so modify acpi_pci_bridge_d3(() to always take the return value of _S0W for the target bridge into account. That is, make it return 'false' if _S0W returns D2 or a shallower power state for the target bridge regardless of its ancestor Root Port properties. Of course, this also causes 'false' to be returned if the Root Port itself is the target and its _S0W returns D2 or a shallower power state. However, still allow bridges without _S0W that are power-manageable via ACPI to enter D3 to retain the current code behavior in that case. This fixes problems where a hotplug notification is missed because a bridge is in D3. That means hot-added devices such as USB4 docks (and the devices they contain) and Thunderbolt 3 devices may not work. Link: https://lore.kernel.org/linux-pci/20221031223356.32570-1-mario.limonciello@amd.com/ Link: https://lore.kernel.org/r/12155458.O9o76ZdvQC@kreacher Reported-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10ACPI: video: Fix Lenovo Ideapad Z570 DMI matchHans de Goede1-1/+1
[ Upstream commit 2d11eae42d52a131f06061015e49dc0f085c5bfc ] Multiple Ideapad Z570 variants need acpi_backlight=native to force native use on these pre Windows 8 machines since acpi_video backlight control does not work here. The original DMI quirk matches on a product_name of "102434U" but other variants may have different product_name-s such as e.g. "1024D9U". Move to checking product_version instead as is more or less standard for Lenovo DMI quirks for similar reasons. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10ACPI: Don't build ACPICA with '-Os'Mark Rutland1-1/+1
[ Upstream commit 8f9e0a52810dd83406c768972d022c37e7a18f1f ] The ACPICA code has been built with '-Os' since the beginning of git history, though there's no explanatory comment as to why. This is unfortunate as GCC drops the alignment specificed by '-falign-functions=N' when '-Os' is used, as reported in GCC bug 88345: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345 This prevents CONFIG_FUNCTION_ALIGNMENT and CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B from having their expected effect on the ACPICA code. This is doubly unfortunate as in subsequent patches arm64 will depend upon CONFIG_FUNCTION_ALIGNMENT for its ftrace implementation. Drop the '-Os' flag when building the ACPICA code. With this removed, the code builds cleanly and works correctly in testing so far. I've tested this by selecting CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B=y, building and booting a kernel using ACPI, and looking for misaligned text symbols: * arm64: Before, v6.2-rc3: # uname -rm 6.2.0-rc3 aarch64 # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l 5009 Before, v6.2-rc3 + fixed __cold: # uname -rm 6.2.0-rc3-00001-g2a2bedf8bfa9 aarch64 # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l 919 After: # uname -rm 6.2.0-rc3-00002-g267bddc38572 aarch64 # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l 323 # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | grep acpi | wc -l 0 * x86_64: Before, v6.2-rc3: # uname -rm 6.2.0-rc3 x86_64 # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l 11537 Before, v6.2-rc3 + fixed __cold: # uname -rm 6.2.0-rc3-00001-g2a2bedf8bfa9 x86_64 # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l 2805 After: # uname -rm 6.2.0-rc3-00002-g267bddc38572 x86_64 # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l 1357 # grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | grep acpi | wc -l 0 With the patch applied, the remaining unaligned text labels are a combination of static call trampolines and labels in assembly, which can be dealt with in subsequent patches. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Florent Revest <revest@chromium.org> Cc: Len Brown <lenb@kernel.org> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Robert Moore <robert.moore@intel.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Will Deacon <will@kernel.org> Cc: linux-acpi@vger.kernel.org Link: https://lore.kernel.org/r/20230123134603.1064407-4-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10ACPI: resource: Do IRQ override on all TongFang GMxRGxxWerner Sembach1-4/+3
[ Upstream commit 17bb7046e7ce038a73ee97eaa804e0300c5199e2 ] Apply commit 7592b79ba4a9 ("ACPI: resource: do IRQ override on XMG Core 15") override for all vendors using this mainboard. Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Fixes: 9946e39fe8d0 ("ACPI: resource: skip IRQ override on AMD Zen platforms") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10ACPI: resource: Add IRQ overrides for MAINGEAR Vector Pro 2 modelsAdam Niederer1-0/+19
[ Upstream commit cb18703c179713056bd7e3bdfc2260ab4e8658f0 ] Fix a regression introduced by commit 9946e39fe8d0 ("ACPI: resource: skip IRQ override on AMD Zen platforms") on MAINGEAR Vector Pro 2 systems, which causes the built-in keyboard to not work. This restores the functionality by adding an IRQ override. No other IRQs were being overridden before, so this should be all that is needed for these systems. I have personally tested this on the 15" model (MG-VCP2-15A3070T), and I have confirmation that the issue is present on the 17" model (MG-VCP2-17A3070T). Fixes: 9946e39fe8d0 ("ACPI: resource: skip IRQ override on AMD Zen platforms") Signed-off-by: Adam Niederer <adam.niederer@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10ACPI: battery: Fix missing NUL-termination with large stringsArmin Wolf1-1/+1
[ Upstream commit f2ac14b5f197e4a2dec51e5ceaa56682ff1592bc ] When encountering a string bigger than the destination buffer (32 bytes), the string is not properly NUL-terminated, causing buffer overreads later. This for example happens on the Inspiron 3505, where the battery model name is larger than 32 bytes, which leads to sysfs showing the model name together with the serial number string (which is NUL-terminated and thus prevents worse). Fix this by using strscpy() which ensures that the result is always NUL-terminated. Fixes: 106449e870b3 ("ACPI: Battery: Allow extract string from integer") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10ACPICA: nsrepair: handle cases without a return value correctlyDaniil Tatianin1-5/+7
[ Upstream commit ca843a4c79486e99a19b859ef0b9887854afe146 ] Previously acpi_ns_simple_repair() would crash if expected_btypes contained any combination of ACPI_RTYPE_NONE with a different type, e.g | ACPI_RTYPE_INTEGER because of slightly incorrect logic in the !return_object branch, which wouldn't return AE_AML_NO_RETURN_VALUE for such cases. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Link: https://github.com/acpica/acpica/pull/811 Fixes: 61db45ca2163 ("ACPICA: Restore code that repairs NULL package elements in return values.") Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10ACPICA: Drop port I/O validation for some regionsMario Limonciello1-3/+4
[ Upstream commit e1d9148582ab2c3dada5c5cf8ca7531ca269fee5 ] Microsoft introduced support in Windows XP for blocking port I/O to various regions. For Windows compatibility ACPICA has adopted the same protections and will disallow writes to those (presumably) the same regions. On some systems the AML included with the firmware will issue 4 byte long writes to 0x80. These writes aren't making it over because of this blockage. The first 4 byte write attempt is rejected, and then subsequently 1 byte at a time each offset is tried. The first at 0x80 works, but then the next 3 bytes are rejected. This manifests in bizarre failures for devices that expected the AML to write all 4 bytes. Trying the same AML on Windows 10 or 11 doesn't hit this failure and all 4 bytes are written. Either some of these regions were wrong or some point after Windows XP some of these regions blocks have been lifted. In the last 15 years there doesn't seem to be any reports popping up of this error in the Windows event viewer anymore. There is no documentation at Microsoft's developer site indicating that Windows ACPI interpreter blocks these regions. Between the lack of documentation and the fact that the writes actually do work in Windows 10 and 11, it's quite likely Windows doesn't actually enforce this anymore. So to help the issue, only enforce Windows XP specific entries if the latest _OSI supported is Windows XP. Continue to enforce the ALWAYS_ILLEGAL entries. Link: https://github.com/acpica/acpica/pull/817 Fixes: 7f0719039085 ("ACPICA: New: I/O port protection") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-11Merge tag 'libnvdimm-fixes-6.2' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm Pull libnvdimm fixes from Dan Williams: "A fix for an issue that could causes users to inadvertantly reserve too much capacity when debugging the KMSAN and persistent memory namespace, a lockdep fix, and a kernel-doc build warning: - Resolve the conflict between KMSAN and NVDIMM with respect to reserving pmem namespace / volume capacity for larger sizeof(struct page) - Fix a lockdep warning in the the NFIT code - Fix a kernel-doc build warning" * tag 'libnvdimm-fixes-6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: nvdimm: Support sizeof(struct page) > MAX_STRUCT_PAGE_SIZE ACPI: NFIT: fix a potential deadlock during NFIT teardown dax: super.c: fix kernel-doc bad line warning
2023-01-29Merge tag 'x86_urgent_for_v6.2_rc6' of ↵Linus Torvalds1-1/+5
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: - Start checking for -mindirect-branch-cs-prefix clang support too now that LLVM 16 will support it - Fix a NULL ptr deref when suspending with Xen PV - Have a SEV-SNP guest check explicitly for features enabled by the hypervisor and fail gracefully if some are unsupported by the guest instead of failing in a non-obvious and hard-to-debug way - Fix a MSI descriptor leakage under Xen - Mark Xen's MSI domain as supporting MSI-X - Prevent legacy PIC interrupts from being resent in software by marking them level triggered, as they should be, which lead to a NULL ptr deref * tag 'x86_urgent_for_v6.2_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/build: Move '-mindirect-branch-cs-prefix' out of GCC-only block acpi: Fix suspend with Xen PV x86/sev: Add SEV-SNP guest feature negotiation support x86/pci/xen: Fixup fallout from the PCI/MSI overhaul x86/pci/xen: Set MSI_FLAG_PCI_MSIX support in Xen MSI domain x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL
2023-01-28Merge tag 'acpi-6.2-rc6' of ↵Linus Torvalds1-0/+25
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "Add ACPI backlight handling quirks for 3 machines (Hans de Goede)" * tag 'acpi-6.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: video: Add backlight=native DMI quirk for Asus U46E ACPI: video: Add backlight=native DMI quirk for HP EliteBook 8460p ACPI: video: Add backlight=native DMI quirk for HP Pavilion g6-1d80nr
2023-01-25ACPI: NFIT: fix a potential deadlock during NFIT teardownVishal Verma1-1/+1
Lockdep reports that acpi_nfit_shutdown() may deadlock against an opportune acpi_nfit_scrub(). acpi_nfit_scrub () is run from inside a 'work' and therefore has already acquired workqueue-internal locks. It also acquiires acpi_desc->init_mutex. acpi_nfit_shutdown() first acquires init_mutex, and was subsequently attempting to cancel any pending workqueue items. This reversed locking order causes a potential deadlock: ====================================================== WARNING: possible circular locking dependency detected 6.2.0-rc3 #116 Tainted: G O N ------------------------------------------------------ libndctl/1958 is trying to acquire lock: ffff888129b461c0 ((work_completion)(&(&acpi_desc->dwork)->work)){+.+.}-{0:0}, at: __flush_work+0x43/0x450 but task is already holding lock: ffff888129b460e8 (&acpi_desc->init_mutex){+.+.}-{3:3}, at: acpi_nfit_shutdown+0x87/0xd0 [nfit] which lock already depends on the new lock. ... Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&acpi_desc->init_mutex); lock((work_completion)(&(&acpi_desc->dwork)->work)); lock(&acpi_desc->init_mutex); lock((work_completion)(&(&acpi_desc->dwork)->work)); *** DEADLOCK *** Since the workqueue manipulation is protected by its own internal locking, the cancellation of pending work doesn't need to be done under acpi_desc->init_mutex. Move cancel_delayed_work_sync() outside the init_mutex to fix the deadlock. Any work that starts after acpi_nfit_shutdown() drops the lock will see ARS_CANCEL, and the cancel_delayed_work_sync() will safely flush it out. Reported-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> Link: https://lore.kernel.org/r/20230112-acpi_nfit_lockdep-v1-1-660be4dd10be@intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-01-24ACPI: video: Fix apple gmux detectionHans de Goede1-21/+3
Some apple laptop models have an ACPI device with a HID of APP000B and that device has an IO resource (so it does not describe the new unsupported MMIO based gmux type), but there actually is no gmux in the laptop at all. The gmux_probe() function of the actual apple-gmux driver has code to detect this, this code has been factored out into a new apple_gmux_detect() helper in apple-gmux.h. Use this new function to fix acpi_video_get_backlight_type() wrongly returning apple_gmux as type on the following laptops: MacBookPro5,4 https://pastebin.com/8Xjq7RhS MacBookPro8,1 https://linux-hardware.org/?probe=e513cfbadb&log=dmesg MacBookPro9,2 https://bugzilla.kernel.org/attachment.cgi?id=278961 MacBookPro10,2 https://lkml.org/lkml/2014/9/22/657 MacBookPro11,2 https://forums.fedora-fr.org/viewtopic.php?id=70142 MacBookPro11,4 https://raw.githubusercontent.com/im-0/investigate-card-reader-suspend-problem-on-mbp11.4/mast Fixes: 21245df307cb ("ACPI: video: Add Apple GMUX brightness control detection") Link: https://lore.kernel.org/platform-driver-x86/20230123113750.462144-1-hdegoede@redhat.com/ Reported-by: Emmanouil Kouroupakis <kartebi@gmail.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230124105754.62167-4-hdegoede@redhat.com
2023-01-23ACPI: video: Add backlight=native DMI quirk for Asus U46EHans de Goede1-0/+8
The Asus U46E backlight tables have a set of interesting problems: 1. Its ACPI tables do make _OSI ("Windows 2012") checks, so acpi_osi_is_win8() should return true. But the tables have 2 sets of _OSI calls, one from the usual global _INI method setting a global OSYS variable and a second set of _OSI calls from a MSOS method and the MSOS method is the only one calling _OSI ("Windows 2012"). The MSOS method only gets called in the following cases: 1. From some Asus specific WMI methods 2. From _DOD, which only runs after acpi_video_get_backlight_type() has already been called by the i915 driver 3. From other ACPI video bus methods which never run (see below) 4. From some EC query callbacks So when i915 calls acpi_video_get_backlight_type() MSOS has never run and acpi_osi_is_win8() returns false, so acpi_video_get_backlight_type() returns acpi_video as the desired backlight type, which causes the intel_backlight device to not register. 2. _DOD effectively does this: Return (Package (0x01) { 0x0400 }) causing acpi_video_device_in_dod() to return false, which causes the acpi_video backlight device to not register. Leaving the user with no backlight device at all. Note that before 6.1.y the i915 driver would register the intel_backlight device unconditionally and since that then was the only backlight device userspace would use that. Add a backlight=native DMI quirk for this special laptop to restore the old (and working) behavior of the intel_backlight device registering. Fixes: fb1836c91317 ("ACPI: video: Prefer native over vendor") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-01-23ACPI: video: Add backlight=native DMI quirk for HP EliteBook 8460pHans de Goede1-0/+8
The HP EliteBook 8460p predates Windows 8, so it defaults to using acpi_video# for backlight control. Starting with the 6.1.y kernels the native radeon_bl0 backlight is hidden in this case instead of relying on userspace preferring acpi_video# over native backlight devices. It turns out that for the acpi_video# interface to work on the HP EliteBook 8460p, the brightness needs to be set at least once through the native interface, which now no longer is done breaking backlight control. The native interface however always works without problems, so add a quirk to use native backlight on the EliteBook 8460p to fix this. Fixes: fb1836c91317 ("ACPI: video: Prefer native over vendor") Link: https://bugzilla.redhat.com/show_bug.cgi?id=2161428 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-01-23ACPI: video: Add backlight=native DMI quirk for HP Pavilion g6-1d80nrHans de Goede1-0/+9
The HP Pavilion g6-1d80nr predates Windows 8, so it defaults to using acpi_video# for backlight control, but this is non functional on this model. Add a DMI quirk to use the native backlight interface which does work properly. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-01-20Merge branches 'acpi-prm' and 'acpi-video'Rafael J. Wysocki2-0/+18
Merge an ACPI PRM (platform runtime) support fix and an ACPI backlight quirk for 6.2-rc5: - Check whether EFI runtime is available when registering the ACPI PRM address space handler and when running it (Ard Biesheuvel). - Add backlight=native DMI quirk for Acer Aspire 4810T to the ACPI video driver (Hans de Goede). * acpi-prm: ACPI: PRM: Check whether EFI runtime is available * acpi-video: ACPI: video: Add backlight=native DMI quirk for Acer Aspire 4810T
2023-01-20acpi: Fix suspend with Xen PVJuergen Gross1-1/+5
Commit f1e525009493 ("x86/boot: Skip realmode init code when running as Xen PV guest") missed one code path accessing real_mode_header, leading to dereferencing NULL when suspending the system under Xen: [ 348.284004] PM: suspend entry (deep) [ 348.289532] Filesystems sync: 0.005 seconds [ 348.291545] Freezing user space processes ... (elapsed 0.000 seconds) done. [ 348.292457] OOM killer disabled. [ 348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 seconds) done. [ 348.396612] printk: Suspending console(s) (use no_console_suspend to debug) [ 348.749228] PM: suspend devices took 0.352 seconds [ 348.769713] ACPI: EC: interrupt blocked [ 348.816077] BUG: kernel NULL pointer dereference, address: 000000000000001c [ 348.816080] #PF: supervisor read access in kernel mode [ 348.816081] #PF: error_code(0x0000) - not-present page [ 348.816083] PGD 0 P4D 0 [ 348.816086] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 6.1.3-1.fc32.qubes.x86_64 #1 [ 348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 07/03/2022 [ 348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20 Fix that by adding an optional acpi callback allowing to skip setting the wakeup address, as in the Xen PV case this will be handled by the hypervisor anyway. Fixes: f1e525009493 ("x86/boot: Skip realmode init code when running as Xen PV guest") Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/all/20230117155724.22940-1-jgross%40suse.com
2023-01-18ACPI: PRM: Check whether EFI runtime is availableArd Biesheuvel1-0/+10
The ACPI PRM address space handler calls efi_call_virt_pointer() to execute PRM firmware code, but doing so is only permitted when the EFI runtime environment is available. Otherwise, such calls are guaranteed to result in a crash, and must therefore be avoided. Given that the EFI runtime services may become unavailable after a crash occurring in the firmware, we need to check this each time the PRM address space handler is invoked. If the EFI runtime services were not available at registration time to being with, don't install the address space handler at all. Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-01-17ACPI: video: Add backlight=native DMI quirk for Acer Aspire 4810THans de Goede1-0/+8
The Acer Aspire 4810T predates Windows 8, so it defaults to using acpi_video# for backlight control, but this is non functional on this model. Add a DMI quirk to use the native backlight interface which does work properly. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-01-13Merge branches 'acpi-resource' and 'acpi-video'Rafael J. Wysocki2-0/+11
Merge an ACPI resource management quirk and an ACPI backlight driver fix for 6.2-rc4: - Skip ACPI IRQ override on Asus Expertbook B2402CBA (Tamim Khan). - Add missing support for manual selection of NVidia-WMI-EC or Apple GMUX backlight in the kernel command line to the ACPI backlight driver (Hans de Goede). * acpi-resource: ACPI: resource: Skip IRQ override on Asus Expertbook B2402CBA * acpi-video: ACPI: video: Allow selecting NVidia-WMI-EC or Apple GMUX backlight from the cmdline
2023-01-10ACPI: Fix selecting wrong ACPI fwnode for the iGPU on some Dell laptopsHans de Goede2-4/+17
The Dell Latitude E6430 both with and without the optional NVidia dGPU has a bug in its ACPI tables which is causing Linux to assign the wrong ACPI fwnode / companion to the pci_device for the i915 iGPU. Specifically under the PCI root bridge there are these 2 ACPI Device()s : Scope (_SB.PCI0) { Device (GFX0) { Name (_ADR, 0x00020000) // _ADR: Address } ... Device (VID) { Name (_ADR, 0x00020000) // _ADR: Address ... Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching { VDP8 = Arg0 VDP1 (One, VDP8) } Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices { ... } ... } } The non-functional GFX0 ACPI device is a problem, because this gets returned as ACPI companion-device by acpi_find_child_device() for the iGPU. This is a long standing problem and the i915 driver does use the ACPI companion for some things, but works fine without it. However since commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()") acpi_get_pci_dev() relies on the physical-node pointer in the acpi_device and that is set on the wrong acpi_device because of the wrong acpi_find_child_device() return. This breaks the ACPI video code, leading to non working backlight control in some cases. Add a type.backlight flag, mark ACPI video bus devices with this and make find_child_checks() return a higher score for children with this flag set, so that it picks the right companion-device. Fixes: 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()") Co-developed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: 6.1+ <stable@vger.kernel.org> # 6.1+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-01-10ACPI: video: Allow selecting NVidia-WMI-EC or Apple GMUX backlight from the ↵Hans de Goede1-0/+4
cmdline The patches adding NVidia-WMI-EC and Apple GMUX backlight detection support to acpi_video_get_backlight_type(), forgot to update acpi_video_parse_cmdline() to allow manually selecting these from the commandline. Add support for these to acpi_video_parse_cmdline(). Fixes: fe7aebb40d42 ("ACPI: video: Add Nvidia WMI EC brightness control detection (v3)") Fixes: 21245df307cb ("ACPI: video: Add Apple GMUX brightness control detection") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-01-10ACPI: resource: Skip IRQ override on Asus Expertbook B2402CBATamim Khan1-0/+7
Like the Asus Expertbook B2502CBA and various Asus Vivobook laptops, the Asus Expertbook B2402CBA has an ACPI DSDT table that describes IRQ 1 as ActiveLow while the kernel overrides it to Edge_High. This prevents the keyboard from working. To fix this issue, add this laptop to the skip_override_table so that the kernel does not override IRQ 1. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216864 Tested-by: zelenat <zelenat@gmail.com> Signed-off-by: Tamim Khan <tamim@fusetak.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-30Merge tag 'acpi-6.2-rc2' of ↵Linus Torvalds4-83/+76
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "These are new ACPI IRQ override quirks, low-power S0 idle (S0ix) support adjustments and ACPI backlight handling fixes, mostly for platforms using AMD chips. Specifics: - Add ACPI IRQ override quirks for Asus ExpertBook B2502, Lenovo 14ALC7, and XMG Core 15 (Hans de Goede, Adrian Freund, Erik Schumacher). - Adjust ACPI video detection fallback path to prevent non-operational ACPI backlight devices from being created on systems where the native driver does not detect a suitable panel (Mario Limonciello). - Fix Apple GMUX backlight detection (Hans de Goede). - Add a low-power S0 idle (S0ix) handling quirk for HP Elitebook 865 and stop using AMD-specific low-power S0 idle code path for systems with Rembrandt chips and newer (Mario Limonciello)" * tag 'acpi-6.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: x86: s2idle: Stop using AMD specific codepath for Rembrandt+ ACPI: x86: s2idle: Force AMD GUID/_REV 2 on HP Elitebook 865 ACPI: video: Fix Apple GMUX backlight detection ACPI: resource: Add Asus ExpertBook B2502 to Asus quirks ACPI: resource: do IRQ override on Lenovo 14ALC7 ACPI: resource: do IRQ override on XMG Core 15 ACPI: video: Don't enable fallback path for creating ACPI backlight by default drm/amd/display: Report to ACPI video if no panels were found ACPI: video: Allow GPU drivers to report no panels
2022-12-30Merge branches 'acpi-resource' and 'acpi-video'Rafael J. Wysocki3-9/+63
Merge ACPI resource handling quirks and ACPI backlight handling fixes for 6.2-rc2: - Add ACPI IRQ override quirks for Asus ExpertBook B2502, Lenovo 14ALC7, and XMG Core 15 (Hans de Goede, Adrian Freund, Erik Schumacher). - Adjust ACPI video detection fallback path to prevent non-operational ACPI backlight devices from being created on systems where the native driver does not detect a suitable panel (Mario Limonciello). - Fix Apple GMUX backlight detection (Hans de Goede). * acpi-resource: ACPI: resource: Add Asus ExpertBook B2502 to Asus quirks ACPI: resource: do IRQ override on Lenovo 14ALC7 ACPI: resource: do IRQ override on XMG Core 15 * acpi-video: ACPI: video: Fix Apple GMUX backlight detection ACPI: video: Don't enable fallback path for creating ACPI backlight by default drm/amd/display: Report to ACPI video if no panels were found ACPI: video: Allow GPU drivers to report no panels
2022-12-26treewide: Convert del_timer*() to timer_shutdown*()Steven Rostedt (Google)1-1/+1
Due to several bugs caused by timers being re-armed after they are shutdown and just before they are freed, a new state of timers was added called "shutdown". After a timer is set to this state, then it can no longer be re-armed. The following script was run to find all the trivial locations where del_timer() or del_timer_sync() is called in the same function that the object holding the timer is freed. It also ignores any locations where the timer->function is modified between the del_timer*() and the free(), as that is not considered a "trivial" case. This was created by using a coccinelle script and the following commands: $ cat timer.cocci @@ expression ptr, slab; identifier timer, rfield; @@ ( - del_timer(&ptr->timer); + timer_shutdown(&ptr->timer); | - del_timer_sync(&ptr->timer); + timer_shutdown_sync(&ptr->timer); ) ... when strict when != ptr->timer ( kfree_rcu(ptr, rfield); | kmem_cache_free(slab, ptr); | kfree(ptr); ) $ spatch timer.cocci . > /tmp/t.patch $ patch -p1 < /tmp/t.patch Link: https://lore.kernel.org/lkml/20221123201306.823305113@linutronix.de/ Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Acked-by: Pavel Machek <pavel@ucw.cz> [ LED ] Acked-by: Kalle Valo <kvalo@kernel.org> [ wireless ] Acked-by: Paolo Abeni <pabeni@redhat.com> [ networking ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-12-22ACPI: x86: s2idle: Stop using AMD specific codepath for Rembrandt+Mario Limonciello1-84/+3
After we introduced a module parameter and quirk infrastructure for picking the Microsoft GUID over the SOC vendor GUID we discovered that lots and lots of systems are getting this wrong. The table continues to grow, and is becoming unwieldy. We don't really have any benefit to forcing vendors to populate the AMD GUID. This is just extra work, and more and more vendors seem to mess it up. As the Microsoft GUID is used by Windows as well, it's very likely that it won't be messed up like this. So drop all the quirks forcing it and the Rembrandt behavior. This means that Cezanne or later effectively only run the Microsoft GUID codepath with the exception of HP Elitebook 8*5 G9. Fixes: fd894f05cf30 ("ACPI: x86: s2idle: If a new AMD _HID is missing assume Rembrandt") Cc: stable@vger.kernel.org # 6.1 Reported-by: Benjamin Cheng <ben@bcheng.me> Reported-by: bilkow@tutanota.com Reported-by: Paul <paul@zogpog.com> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2292 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216768 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Philipp Zabel <philipp.zabel@gmail.com> Tested-by: Philipp Zabel <philipp.zabel@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-22ACPI: x86: s2idle: Force AMD GUID/_REV 2 on HP Elitebook 865Mario Limonciello1-0/+20
HP Elitebook 865 supports both the AMD GUID w/ _REV 2 and Microsoft GUID with _REV 0. Both have very similar code but the AMD GUID has a special workaround that is specific to a problem with spurious wakeups on systems with Qualcomm WLAN. This is believed to be a bug in the Qualcomm WLAN F/W (it doesn't affect any other WLAN H/W). If this WLAN firmware is fixed this quirk can be dropped. Cc: stable@vger.kernel.org # 6.1 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-12-22ACPI: video: Fix Apple GMUX backlight detectionHans de Goede1-1/+22
The apple-gmux driver only binds to old GMUX devices which have an IORESOURCE_IO resource (using inb()/outb()) rather then memory-mapped IO (IORESOURCE_MEM). T2 MacBooks use the new style GMUX devices (with IORESOURCE_MEM access), so these are not supported by the apple-gmux driver. This is not a problem since they have working ACPI video backlight support. But the apple_gmux_present() helper only checks if an ACPI device with the "APP000B" HID is present, causing acpi_video_get_backlight_type() to return acpi_backlight_apple_gmux disabling the acpi_video backlight device. Add a new apple_gmux_backlight_present() helper which checks that the "APP000B" device actually is an old GMUX device with an IORESOURCE_IO resource. This fixes the acpi_video0 backlight no longer registering on T2 MacBooks. Note people are working to add support for the new style GMUX to Linux: https://github.com/kekrby/linux-t2/commits/wip/hybrid-graphics Once this lands this patch should be reverted so that acpi_video_get_backlight_type() also prefers the gmux on new style GMUX MacBooks, but for now this is necessary to avoid regressing backlight control on T2 Macs. Fixes: 21245df307cb ("ACPI: video: Add Apple GMUX brightness control detection") Reported-and-tested-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2024-09-27 14:18:28 +0300