aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/acpi
AgeCommit message (Collapse)AuthorFilesLines
2021-02-04ACPI: power: Clean up printing messagesRafael J. Wysocki1-29/+15
Replace all of the ACPI_DEBUG_PRINT() instances in power.c with acpi_handle_debug() or pr_debug(), depending on the context, drop the _COMPONENT and ACPI_MODULE_NAME() definitions that are not used any more, and replace the direct invocations of printk() in there with acpi_handle_info() or pr_info(), depending on the context. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-02-04Merge branch 'acpi-scan' into acpi-messagesRafael J. Wysocki1-50/+49
2021-02-04ACPI: Add support for native USB4 control _OSCMika Westerberg1-0/+76
ACPI 6.4 introduced a new _OSC capability that is used negotiate native connection manager support. Connection manager is the entity that is responsible for tunneling over the USB4 fabric. If the platform rejects the native access then firmware based connection manager is used. The new _OSC also includes a set of bits that can be used to disable certain tunnel types such as PCIe for security reasons for instance. This implements the new USB4 _OSC so that we try to negotiate native USB4 support if the Thunderbolt/USB4 (CONFIG_USB4) driver is enabled. Drivers can determine what was negotiated by checking two new variables exposed in this patch. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-02-04ACPI: Execute platform _OSC also with query bit clearMario Limonciello1-12/+31
The platform _OSC can change the hardware state when query bit is not set. According to ACPI spec it is recommended that the OS runs _OSC with query bit set until the platform does not mask any of the capabilities. Then it should run it with query bit clear in order to actually commit the changes. Linux has not been doing this for the reasons that there has not been anything to commit, until now. The ACPI 6.4 introduced _OSC for USB4 to allow the OS to negotiate native control over USB4 tunneling. The platform might implement this so that it only activates the software connection manager path when the OS calls the _OSC with the query bit clear. Otherwise it may default to the firmware connection manager, for instance. For this reason modify the _OSC support so that we first execute it with query bit set, then use the returned value as base of the features we want to control and run the _OSC again with query bit clear. This also follows what Windows is doing. Also rename the function to better match what it does. Signed-off-by: Mario Limonciello <mario.limonciello@dell.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-02-01ACPI: scan: Fix battery devices sometimes never bindingHans de Goede1-5/+5
With the new 2 step scanning process, which defers instantiating some ACPI-devices based on their _DEP to the second step, the following may happen: 1. During the first acpi_walk_namespace(acpi_bus_check_add) call acpi_scan_check_dep() gets called on the Battery ACPI dev handle and adds one or more deps for this handle to the acpi_dep_list 2. During the first acpi_bus_attach() call one or more of the suppliers of these deps get their driver attached and acpi_walk_dep_device_list(supplier_handle) gets called. At this point acpi_bus_get_device(dep->consumer) get called, but since the battery has DEPs it has not been instantiated during the first acpi_walk_namespace(acpi_bus_check_add), so the acpi_bus_get_device(dep->consumer) call fails. Before this commit, acpi_walk_dep_device_list() would now continue *without* removing the acpi_dep_data entry for this supplier,consumer pair from the acpi_dep_list. 3. During the second acpi_walk_namespace(acpi_bus_check_add) call an acpi_device gets instantiated for the battery and acpi_scan_dep_init() gets called to initialize its dep_unmet val. Before this commit, the dep_unmet count would include DEPs for suppliers for which acpi_walk_dep_device_list(supplier_handle) has already been called, so it will never become 0 and the ACPI battery driver will never get attached / bind. Fix the ACPI battery driver never binding in this scenario by making acpi_walk_dep_device_list() always remove matching acpi_dep_data entries independent of the acpi_bus_get_device(dep->consumer) call succeeding or not. Fixes: 71da201f38df ("ACPI: scan: Defer enumeration of devices with _DEP lists") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-02-01Merge tag 'v5.11-rc6' into patchworkMauro Carvalho Chehab7-50/+69
Linux 5.11-rc6 * tag 'v5.11-rc6': (1466 commits) Linux 5.11-rc6 leds: rt8515: Add Richtek RT8515 LED driver dt-bindings: leds: Add DT binding for Richtek RT8515 leds: trigger: fix potential deadlock with libata leds: leds-ariel: convert comma to semicolon leds: leds-lm3533: convert comma to semicolon dt-bindings: Cleanup standard unit properties soc: litex: Properly depend on HAS_IOMEM tty: avoid using vfs_iocb_iter_write() for redirected console writes null_blk: cleanup zoned mode initialization cifs: fix dfs domain referrals drm/nouveau/kms/gk104-gp1xx: Fix > 64x64 cursors drm/nouveau/kms/nv50-: Report max cursor size to userspace drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes drm/nouveau/svm: fail NOUVEAU_SVM_INIT ioctl on unsupported devices drm/nouveau/dispnv50: Restore pushing of all data. io_uring: reinforce cancel on flush during exit cifs: returning mount parm processing errors correctly rxrpc: Fix memory leak in rxrpc_lookup_local mlxsw: spectrum_span: Do not overwrite policer configuration ...
2021-01-29Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linuxLinus Torvalds1-2/+12
Pull arm64 fixes from Catalin Marinas: - Fix the virt_addr_valid() returning true for < PAGE_OFFSET addresses. - Do not blindly trust the DMA masks from ACPI/IORT. * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: ACPI/IORT: Do not blindly trust DMA masks from firmware arm64: Fix kernel address detection of __is_lm_address()
2021-01-29ACPI: tables: introduce support for FPDT tableZhang Rui3-0/+273
ACPI Firmware Performance Data Table (FPDT) provides information about firmware performance during system boot, S3 suspend and S3 resume. Have the kernel parse the FPDT table, and expose the firmware performance data to userspace as sysfs attributes under /sys/firmware/acpi/fpdt/. Tested-by: Todd Brandt <todd.e.brandt@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-29Merge branch 'acpi-sysfs'Rafael J. Wysocki1-14/+6
* acpi-sysfs: ACPI: sysfs: Prefer "compatible" modalias
2021-01-27ACPI: APEI: Add is_generic_error() to identify GHES sourcesYazen Ghannam1-4/+8
Refactor duplicated GHES identity logic into is_generic_error(). Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Reviewed-by: Robert Richter <rrichter@amd.com> Co-developed-by: Terry Bowman <terry.bowman@amd.com> Signed-off-by: Terry Bowman <terry.bowman@amd.com> Acked-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-27ACPI: platform-profile: Fix possible deadlock in platform_profile_remove()Hans de Goede1-6/+2
After a rmmod thinkpad_acpi, lockdep pointed out this possible deadlock: Our _show and _store sysfs attr functions get called with the kn->active lock held for the sysfs attr and then take the profile_lock. sysfs_remove_group() also takes the kn->active lock for the sysfs attr, so if we call it with the profile_lock held, then we get an ABBA deadlock. platform_profile_remove() must only be called by drivers which have first *successfully* called platform_profile_register(). Anything else is a driver bug. So the check for cur_profile being set before calling sysfs_remove_group() is not necessary and it can be dropped. It is safe to call sysfs_remove_group() without holding the profile_lock since the attr-group group cannot be re-added until after we clear cur_profile. Change platform_profile_remove() to only hold the profile_lock while clearing the cur_profile, fixing the deadlock. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-27ACPI: platform-profile: Introduce object pointers to callbacksJiaxun Yang1-2/+2
Add an object pointer to handler callbacks to avoid the need for drivers to have a global variable to get to their driver-data struct. Link: https://lore.kernel.org/linux-acpi/6a29f338-d9e4-150c-81dd-2ffb54f5bc35@redhat.com/ Link: https://lore.kernel.org/r/20210114073429.176462-3-jiaxun.yang@flygoat.com Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Suggested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-27PCI/ACPI: Clarify message about _OSC failureBjorn Helgaas1-4/+3
This message: acpi PNP0A08:02: _OSC failed (AE_NOT_FOUND); disabling ASPM is alarming and slightly misleading. Per the PCI Firmware Spec, r3.2, sec 4.5.1, _OSC is required for PCIe hierarchies. If _OSC is absent or fails, the OS must not attempt to use any of the features defined for _OSC. That includes native hotplug, native PME, AER, and other things as well as ASPM. Rephrase the message to: acpi PNP0A08:02: _OSC: platform retains control of PCIe features (AE_NOT_FOUND) Previous discussion at https://lore.kernel.org/r/20200602223618.GA845676@bjorn-Precision-5520/ Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Yicong Yang <yangyicong@hisilicon.com>
2021-01-27PCI/ACPI: Remove unnecessary osc_lockBjorn Helgaas1-20/+10
9778c14b4ca2 ("ACPI/PCI: Fix possible race condition on _OSC evaluation") added locking around _OSC calls to protect the acpi_osc_data_list that stored the results. 63f10f0f6df4 ("PCI/ACPI: move _OSC code to pci_root.c") moved the results from acpi_osc_data_list to the struct acpi_pci_root, where it no longer needs locking, but did not remove the lock. Remove the unnecessary locking around _OSC calls. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-27PCI/ACPI: Make acpi_pci_osc_control_set() staticBjorn Helgaas1-2/+1
acpi_pci_osc_control_set() is only called from pci_root.c, so stop exporting it and make it static. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-27ACPI/IORT: Do not blindly trust DMA masks from firmwareMoritz Fischer1-2/+12
Address issue observed on real world system with suboptimal IORT table where DMA masks of PCI devices would get set to 0 as result. iort_dma_setup() would query the root complex'/named component IORT entry for a DMA mask, and use that over the one the device has been configured with earlier. Ideally we want to use the minimum mask of what the IORT contains for the root complex and what the device was configured with. Fixes: 5ac65e8c8941 ("ACPI/IORT: Support address size limit for root complexes") Signed-off-by: Moritz Fischer <mdf@kernel.org> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Link: https://lore.kernel.org/r/20210122012419.95010-1-mdf@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2021-01-26media: ACPI / bus: Add acpi_dev_get_next_match_dev() and helper macroDaniel Scally1-4/+26
To ensure we handle situations in which multiple sensors of the same model (and therefore _HID) are present in a system, we need to be able to iterate over devices matching a known _HID but unknown _UID and _HRV - add acpi_dev_get_next_match_dev() to accommodate that possibility and change acpi_dev_get_first_match_dev() to simply call the new function with a NULL starting point. Add an iterator macro for convenience. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Daniel Scally <djrscally@gmail.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2021-01-25ACPI: scan: Rearrange code related to acpi_get_device_data()Rafael J. Wysocki1-18/+17
There are two callers of acpi_get_device_data(), acpi_bus_get_device() and acpi_bus_get_acpi_device(), but only one of them takes the int return value into account. Moreover, the latter knows that it passes a valid return pointer to acpi_get_device_data() and it properly clears that pointer upfront, so it doesn't need acpi_get_device_data() to do that. For this reason, rearrange acpi_get_device_data() to return a strct acpi_device pointer instead of an int and adapt its callers to that. While at it, rename acpi_get_device_data() to handle_to_device(), because the old name does not really reflect the functionality provided by that function. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2021-01-25ACPI: scan: Adjust white space in acpi_device_add()Rafael J. Wysocki1-2/+7
Add empty lines in some places in acpi_device_add() to help readability and drop leading spaces before the labels in there. No functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2021-01-25ACPI: scan: Rearrange memory allocation in acpi_device_add()Rafael J. Wysocki1-31/+26
The upfront allocation of new_bus_id is done to avoid allocating memory under acpi_device_lock, but it doesn't really help, because (1) it leads to many unnecessary memory allocations for _ADR devices, (2) kstrdup_const() is run under that lock anyway and (3) it complicates the code. Rearrange acpi_device_add() to allocate memory for a new struct acpi_device_bus_id instance only when necessary, eliminate a redundant local variable from it and reduce the number of labels in there. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2021-01-25ACPI: platform-profile: Drop const qualifier for cur_profileJiaxun Yang1-2/+2
Drop the const qualifier from the static global cur_profile pointer declaration. This is a preparation patch for passing the cur_profile pointer as parameter to the profile_get() and profile_set() callbacks so that drivers dynamically allocating their driver-data struct, with their platform_profile_handler struct embedded, can use this pointer to get to their driver-data. Note this also requires dropping the const from the pprof platform_profile_register() function argument. Dropping this const is not a problem, non of the queued up consumers of platform_profile_register() actually pass in a const pointer. Link: https://lore.kernel.org/linux-acpi/5e7a4d87-52ef-e487-9cc2-8e7094beaa08@redhat.com/ Link: https://lore.kernel.org/r/20210114073429.176462-2-jiaxun.yang@flygoat.com Suggested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> [ hdegoede@redhat.com: Also remove const from platform_profile_register() ] Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-25ACPI: thermal: Do not call acpi_thermal_check() directlyRafael J. Wysocki1-13/+33
Calling acpi_thermal_check() from acpi_thermal_notify() directly is problematic if _TMP triggers Notify () on the thermal zone for which it has been evaluated (which happens on some systems), because it causes a new acpi_thermal_notify() invocation to be queued up every time and if that takes place too often, an indefinite number of pending work items may accumulate in kacpi_notify_wq over time. Besides, it is not really useful to queue up a new invocation of acpi_thermal_check() if one of them is pending already. For these reasons, rework acpi_thermal_notify() to queue up a thermal check instead of calling acpi_thermal_check() directly and only allow one thermal check to be pending at a time. Moreover, only allow one acpi_thermal_check_fn() instance at a time to run thermal_zone_device_update() for one thermal zone and make it return early if it sees other instances running for the same thermal zone. While at it, fold acpi_thermal_check() into acpi_thermal_check_fn(), as it is only called from there after the other changes made here. [This issue appears to have been exposed by commit 6d25be5782e4 ("sched/core, workqueues: Distangle worker accounting from rq lock"), but it is unclear why it was not visible earlier.] BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208877 Reported-by: Stephen Berman <stephen.berman@gmx.net> Diagnosed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Tested-by: Stephen Berman <stephen.berman@gmx.net> Cc: All applicable <stable@vger.kernel.org>
2021-01-25ACPI: sysfs: Prefer "compatible" modaliasKai-Heng Feng1-14/+6
Commit 8765c5ba1949 ("ACPI / scan: Rework modalias creation when "compatible" is present") may create two "MODALIAS=" in one uevent file if specific conditions are met. This breaks systemd-udevd, which assumes each "key" in one uevent file to be unique. The internal implementation of systemd-udevd overwrites the first MODALIAS with the second one, so its kmod rule doesn't load the driver for the first MODALIAS. So if both the ACPI modalias and the OF modalias are present, use the latter to ensure that there will be only one MODALIAS. Link: https://github.com/systemd/systemd/pull/18163 Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Fixes: 8765c5ba1949 ("ACPI / scan: Rework modalias creation when "compatible" is present") Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: 4.1+ <stable@vger.kernel.org> # 4.1+ [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-22ACPI: configfs: add missing check after configfs_register_default_group()Qinglang Miao1-1/+6
A list_add corruption is reported by Hulk Robot like this: ============== list_add corruption. Call Trace: link_obj+0xc0/0x1c0 link_group+0x21/0x140 configfs_register_subsystem+0xdb/0x380 acpi_configfs_init+0x25/0x1000 [acpi_configfs] do_one_initcall+0x149/0x820 do_init_module+0x1ef/0x720 load_module+0x35c8/0x4380 __do_sys_finit_module+0x10d/0x1a0 do_syscall_64+0x34/0x80 It's because of the missing check after configfs_register_default_group, where configfs_unregister_subsystem should be called once failure. Fixes: 612bd01fc6e0 ("ACPI: add support for loading SSDTs via configfs") Reported-by: Hulk Robot <hulkci@huawei.com> Suggested-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Cc: 4.10+ <stable@vger.kernel.org> # 4.10+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-22ACPI: CPPC: initialise vaddr pointers to NULLIonela Voinescu1-2/+2
Properly initialise vaddr pointers in cpc_read() and cpc_write() to NULL instead of 0. This fixes the following sparse warnings: drivers/acpi/cppc_acpi.c:937:31: warning: Using plain integer as NULL pointer drivers/acpi/cppc_acpi.c:982:31: warning: Using plain integer as NULL pointer Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-22ACPI: CPPC: add __iomem annotation to generic_comm_base pointerIonela Voinescu1-2/+2
ppc_comm_addr is a virtual address to the PCC space and it's annotated with __iomem. Therefore, generic_comm_base which gets assigned the value of pcc_comm_address should be annotated as well. This already happens in check_pcc_chan(), but not in send_pcc_cmd(), which results in the following sparse warnings: drivers/acpi/cppc_acpi.c:237:18: warning: cast removes address space '__iomem' of expression drivers/acpi/cppc_acpi.c:299:9: warning: incorrect type in argument 2 (different address spaces) drivers/acpi/cppc_acpi.c:299:9: expected void volatile [noderef] __iomem *addr drivers/acpi/cppc_acpi.c:299:9: got unsigned short * drivers/acpi/cppc_acpi.c:302:9: warning: incorrect type in argument 2 (different address spaces) drivers/acpi/cppc_acpi.c:302:9: expected void volatile [noderef] __iomem *addr drivers/acpi/cppc_acpi.c:302:9: got unsigned short * Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-22ACPI: Use DEVICE_ATTR_<RW|RO|WO> macrosDwaipayan Ray6-71/+66
Instead of open coding DEVICE_ATTR(), use the DEVICE_ATTR_RW(), DEVICE_ATTR_RO() and DEVICE_ATTR_WO() macros wherever possible. This required a few functions to be renamed but the functionality itself is unchanged. Signed-off-by: Dwaipayan Ray <dwaipayanray1@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-22ACPICA: Updated all copyrights to 2021Bob Moore142-143/+143
This affects all ACPICA source code modules. ACPICA commit c570953c914437e621dd5f160f26ddf352e0d2f4 Link: https://github.com/acpica/acpica/commit/c570953c Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-22ACPICA: add type casts for string functionsBob Moore2-4/+4
Detected by gcc 10.2.0. ACPICA commit 608559800e1ad48b819744aeb1866d94335e2655 Link: https://github.com/acpica/acpica/commit/60855980 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-22ACPICA: fix -WfallthroughNick Desaulniers9-12/+11
ACPICA commit 4b9135f5774caa796ddf826448811e8e7f08ef2f GCC 7.1 gained -Wimplicit-fallthrough to warn on implicit fallthrough, as well as __attribute__((__fallthrough__)) and comments to explicitly denote that cases of fallthrough were intentional. Clang also supports this warning and statement attribute, but not the comment form. Robert Moore provides additional context about the lint comments being removed. They were for "an old version of PC-Lint, which we don't use anymore." Drop those. This will help us enable -Wimplicit-fallthrough throughout the Linux kernel. Suggested-by: Robert Moore <robert.moore@intel.com> Reported-by: Jon Hunter <jonathanh@nvidia.com> Link: https://github.com/acpica/acpica/commit/4b9135f5 Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-20ACPI: scan: Make acpi_bus_get_device() clear return pointer on errorHans de Goede1-0/+2
Set the acpi_device pointer which acpi_bus_get_device() returns-by- reference to NULL on errors. We've recently had 2 cases where callers of acpi_bus_get_device() did not properly error check the return value, so set the returned- by-reference acpi_device pointer to NULL, because at least some callers of acpi_bus_get_device() expect that to be done on errors. [ rjw: This issue was exposed by commit 71da201f38df ("ACPI: scan: Defer enumeration of devices with _DEP lists") which caused it to be much more likely to occur on some systems, but the real defect had been introduced by an earlier commit. ] Fixes: 40e7fcb19293 ("ACPI: Add _DEP support to fix battery issue on Asus T100TA") Fixes: bcfcd409d4db ("usb: split code locating ACPI companion into port and device") Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Diagnosed-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: All applicable <stable@vger.kernel.org> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-19acpi/drivers/thermal: Remove TRIPS_NONE cooling device bindingDaniel Lezcano1-19/+0
The loop is here to create default cooling device binding on the THERMAL_TRIPS_NONE number which is used to be the 'forced_passive' feature. However, we removed all code dealing with that in the thermal core, thus this binding does no longer make sense. Remove it. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Zhang Rui <rui.zhang@intel.com> Reviewed-by: Thara Gopinath <thara.gopinath@linaro.org> Link: https://lore.kernel.org/r/20201214233811.485669-4-daniel.lezcano@linaro.org
2021-01-18ACPICA: Clean up exception code class checksMaximilian Luz4-5/+4
ACPICA commit 5a8390fbd4c5c60da0b6d4ba53b5ee34fda9a0cb With the exception code class check macros fixed in the previous commit, let us now use those to simplify exception class checks across ACPICA. Link: https://github.com/acpica/acpica/commit/5a8390fb Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Kaneda <erik.kaneda@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-11ACPI: NFIT: Fix flexible_array.cocci warningsDan Williams1-47/+28
Julia and 0day report: Zero-length and one-element arrays are deprecated, see Documentation/process/deprecated.rst Flexible-array members should be used instead. However, a straight conversion to flexible arrays yields: drivers/acpi/nfit/core.c:2276:4: error: flexible array member in a struct with no named members drivers/acpi/nfit/core.c:2287:4: error: flexible array member in a struct with no named members Instead, just use plain arrays not embedded flexible arrays. Cc: Denis Efremov <efremov@linux.com> Reported-by: kernel test robot <lkp@intel.com> Reported-by: Julia Lawall <julia.lawall@inria.fr> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2021-01-11ACPI: scan: Harden acpi_device_add() against device ID overflowsDexuan Cui2-2/+15
Linux VM on Hyper-V crashes with the latest mainline: [ 4.069624] detected buffer overflow in strcpy [ 4.077733] kernel BUG at lib/string.c:1149! .. [ 4.085819] RIP: 0010:fortify_panic+0xf/0x11 ... [ 4.085819] Call Trace: [ 4.085819] acpi_device_add.cold.15+0xf2/0xfb [ 4.085819] acpi_add_single_object+0x2a6/0x690 [ 4.085819] acpi_bus_check_add+0xc6/0x280 [ 4.085819] acpi_ns_walk_namespace+0xda/0x1aa [ 4.085819] acpi_walk_namespace+0x9a/0xc2 [ 4.085819] acpi_bus_scan+0x78/0x90 [ 4.085819] acpi_scan_init+0xfa/0x248 [ 4.085819] acpi_init+0x2c1/0x321 [ 4.085819] do_one_initcall+0x44/0x1d0 [ 4.085819] kernel_init_freeable+0x1ab/0x1f4 This is because of the recent buffer overflow detection in the commit 6a39e62abbaf ("lib: string.h: detect intra-object overflow in fortified string functions") Here acpi_device_bus_id->bus_id can only hold 14 characters, while the the acpi_device_hid(device) returns a 22-char string "HYPER_V_GEN_COUNTER_V1". Per ACPI Spec v6.2, Section 6.1.5 _HID (Hardware ID), if the ID is a string, it must be of the form AAA#### or NNNN####, i.e. 7 chars or 8 chars. The field bus_id in struct acpi_device_bus_id was originally defined as char bus_id[9], and later was enlarged to char bus_id[15] in 2007 in the commit bb0958544f3c ("ACPI: use more understandable bus_id for ACPI devices") Fix the issue by changing the field bus_id to const char *, and use kstrdup_const() to initialize it. Signed-off-by: Dexuan Cui <decui@microsoft.com> Tested-By: Jethro Beekman <jethro@fortanix.com> [ rjw: Subject change, whitespace adjustment ] Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-08Merge branches 'acpi-scan' and 'acpi-misc'Rafael J. Wysocki1-6/+0
* acpi-scan: ACPI: scan: add stub acpi_create_platform_device() for !CONFIG_ACPI * acpi-misc: ACPI: Update Kconfig help text for items that are no longer modular
2021-01-07thermal/drivers/acpi: Use hot and critical opsDaniel Lezcano1-16/+14
The acpi driver wants to do a netlink notification in case of a hot or critical trip point. Implement the corresponding ops to be used for the thermal zone and use them instead of the notify ops. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20201210121514.25760-3-daniel.lezcano@linaro.org
2021-01-07ACPI: Update Kconfig help text for items that are no longer modularPeter Robinson1-6/+0
The CONTAINER and HOTPLUG_MEMORY options mention modules but are bool only, so if selected are always built in. Drop the help text about modules. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-01-07ACPI: PM: s2idle: Drop unused local variables and related codeRafael J. Wysocki1-13/+1
Two local variables in drivers/acpi/x86/s2idle.c are never read, so drop them along with the code updating their values (in vain). Fixes: fef98671194b ("ACPI: PM: s2idle: Move x86-specific code to the x86 directory") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-30ACPI: platform: Add platform profile supportMark Pearson3-0/+199
This is the initial implementation of the platform-profile feature. It provides the details discussed and outlined in the sysfs-platform_profile document. Many modern systems have the ability to modify the operating profile to control aspects like fan speed, temperature and power levels. This module provides a common sysfs interface that platform modules can register against to control their individual profile options. Signed-off-by: Mark Pearson <markpearson@lenovo.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> [ rjw: Use full words in enum values names ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-24Merge tag 'libnvdimm-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimmLinus Torvalds1-5/+10
Pull libnvdimm updates from Dan Williams: "Twas the day before Christmas and the only thing stirring in libnvdimm / device-dax land is a pile of miscellaneous fixups and cleanups. The bulk of it has appeared in -next save the last two patches to device-dax that have passed my build and unit tests. - Fix a long standing block-window-namespace issue surfaced by the ndctl change to attempt to preserve the kernel device name over a 'reconfigure' - Fix a few error path memory leaks in nfit and device-dax - Silence a smatch warning in the ioctl path - Miscellaneous cleanups" * tag 'libnvdimm-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: device-dax: Avoid an unnecessary check in alloc_dev_dax_range() device-dax: Fix range release device-dax: delete a redundancy check in dev_dax_validate_align() libnvdimm/label: Return -ENXIO for no slot in __blk_label_update device-dax/core: Fix memory leak when rmmod dax.ko device-dax/pmem: Convert comma to semicolon libnvdimm: Cleanup include of badblocks.h ACPI: NFIT: Fix input validation of bus-family libnvdimm/namespace: Fix reaping of invalidated block-window-namespace labels ACPI/nfit: avoid accessing uninitialized memory in acpi_nfit_ctl()
2020-12-22Merge tag 'acpi-5.11-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds6-330/+598
Pull more ACPI updates from Rafael Wysocki: "These make the ACPI enumeration of devices take _DEP information into account more aggressively, fix device IDs matching in the ACPI part of the PNP devices framework and update the ACPI code related to suspend-to-idle to take systems based on AMD hardware into account properly. Specifics: - Modify the ACPI device enumeration code to defer the enumeration of devices with an _HID whose lists of operation region dependencies returned by _DEP are not empty after eliminating the entries representing known-benign dependencies from them (Rafael Wysocki, Hans de Goede). - Make the ACPI PNP code mathing device IDs also take the length of the given ID string into account (Hui Wang). - Add AMD systems support to the ACPI code handling suspend-to-idle via the PNP0D80 (System Power Management Controller) device _DSM interface (Shyam Sundar). - Move the suspend-to-idle handling code related to the PNP0D80 device _DSM interface, which is x86-specific, to a separate file in the x86/ subdirectory (Rafael Wysocki)" * tag 'acpi-5.11-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: PM: s2idle: Move x86-specific code to the x86 directory ACPI: scan: Add Intel Baytrail Mailbox Device to acpi_ignore_dep_ids ACPI: scan: Avoid unnecessary second pass in acpi_bus_scan() ACPI: scan: Defer enumeration of devices with _DEP lists ACPI: scan: Evaluate _DEP before adding the device ACPI: PM: s2idle: Add AMD support to handle _DSM ACPI: PNP: compare the string length in the matching_id()
2020-12-22Merge tag 'pm-5.11-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds2-82/+61
Pull more power management updates from Rafael Wysocki: "These update the CPPC cpufreq driver and intel_pstate (which involves updating the cpufreq core and the schedutil governor) and make janitorial changes in the ACPI code handling processor objects. Specifics: - Rework the passive-mode "fast switch" path in the intel_pstate driver to allow it receive the minimum (required) and target (desired) performance information from the schedutil governor so as to avoid running some workloads too fast (Rafael Wysocki). - Make the intel_pstate driver allow the policy max limit to be increased after the guaranteed performance value for the given CPU has increased (Rafael Wysocki). - Clean up the handling of CPU coordination types in the CPPC cpufreq driver and make it export frequency domains information to user space via sysfs (Ionela Voinescu). - Fix the ACPI code handling processor objects to use a correct coordination type when it fails to map frequency domains and drop a redundant CPU map initialization from it (Ionela Voinescu, Punit Agrawal)" * tag 'pm-5.11-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: intel_pstate: Use most recent guaranteed performance values cpufreq: intel_pstate: Implement the ->adjust_perf() callback cpufreq: Add special-purpose fast-switching callback for drivers cpufreq: schedutil: Add util to struct sg_cpu cppc_cpufreq: replace per-cpu data array with a list cppc_cpufreq: expose information on frequency domains cppc_cpufreq: clarify support for coordination types cppc_cpufreq: use policy->cpu as driver of frequency setting ACPI: processor: fix NONE coordination for domain mapping failure
2020-12-22Merge branch 'pm-cpufreq'Rafael J. Wysocki2-83/+61
* pm-cpufreq: cpufreq: intel_pstate: Use most recent guaranteed performance values cpufreq: intel_pstate: Implement the ->adjust_perf() callback cpufreq: Add special-purpose fast-switching callback for drivers cpufreq: schedutil: Add util to struct sg_cpu cppc_cpufreq: replace per-cpu data array with a list cppc_cpufreq: expose information on frequency domains cppc_cpufreq: clarify support for coordination types cppc_cpufreq: use policy->cpu as driver of frequency setting ACPI: processor: fix NONE coordination for domain mapping failure ACPI: processor: Drop duplicate setting of shared_cpu_map
2020-12-22Merge branches 'acpi-scan', 'acpi-pnp' and 'acpi-sleep'Rafael J. Wysocki6-330/+598
* acpi-scan: ACPI: scan: Add Intel Baytrail Mailbox Device to acpi_ignore_dep_ids ACPI: scan: Avoid unnecessary second pass in acpi_bus_scan() ACPI: scan: Defer enumeration of devices with _DEP lists ACPI: scan: Evaluate _DEP before adding the device * acpi-pnp: ACPI: PNP: compare the string length in the matching_id() * acpi-sleep: ACPI: PM: s2idle: Move x86-specific code to the x86 directory ACPI: PM: s2idle: Add AMD support to handle _DSM
2020-12-17ACPI: PM: s2idle: Move x86-specific code to the x86 directoryRafael J. Wysocki4-441/+489
Some code in drivers/acpi/sleep.c (which is regarded as a generic file) related to suspend-to-idle support has grown direct dependencies on x86, but in fact it has been specific to x86 (which is the only user of it) anyway for a long time. For this reason, move that code to a separate file under acpi/x86/ and make it build and run as before under the right conditions. While at it, rename a vendor checking function in that code and consistently use acpi_handle_debug() for printing debug-related information in it. No expected functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-17ACPI: scan: Add Intel Baytrail Mailbox Device to acpi_ignore_dep_idsHans de Goede1-0/+1
Linux does not have a driver for / does not use the "Intel Baytrail Mailbox Device" (ACIP HID INT33BD). Add it to the acpi_ignore_dep_ids list, so that we do not defer probing ACPI devices which depend on another ACPI device with this HID. Specifically this makes us not defer the probing of the GPO1 ACPI device / GPIO controller on the Acer Switch 10E SW3-016. On this tablet model the _HID method of the ACPI node for the UART attached Bluetooth, reads GPIOs to detect the installed wifi chip and updates the reported _HID for the Bluetooth's ACPI node accordingly. For the Bluetooth's ACPI node to report the correct _HID the GPO1 device must be probed and attached during the first scan pass. Adding the "INT33BD" HID to the acpi_ignore_dep_ids list makes this all work. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-12-17ACPI: scan: Avoid unnecessary second pass in acpi_bus_scan()Rafael J. Wysocki1-1/+10
If there are no devices whose enumeration has been deferred after the first pass in acpi_bus_scan(), the second pass is not necssary, so avoid it with the help of a new static variable. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-12-17ACPI: scan: Defer enumeration of devices with _DEP listsRafael J. Wysocki1-25/+78
In some cases ACPI control methods used during device enumeration (such as _HID or _STA) may rely on Operation Region handlers supplied by the drivers of other devices [1]: An example of this is the Acer Switch 10E SW3-016 model. The _HID method of the ACPI node for the UART attached Bluetooth, reads GPIOs to detect the installed wifi chip and update the _HID for the Bluetooth's ACPI node accordingly. The current ACPI scan code calls _HID before the GPIO controller's OpRegions are available, leading to the wrong _HID being used and Bluetooth not working. In principle, in those cases there should be a _DEP control method under the device object with OpRegion enumeration dependencies, so deferring the enumeration of devices with _DEP returning a non-empty list of suppliers of OpRegions depended on by the given device (modulo some known exceptions that don't really supply any OpRegions and are listed by _DEP for other reasons irrelevant for Linux) should at least address the first-order dependencies by allowing the OpRegion suppliers to be enumerated before their consumers. Implement the above idea by modifying acpi_bus_scan() to enumerate devices in the given scope of the ACPI namespace in two passes, where the first pass covers the devices without "significant" lists of dependencies coming from _DEP only and the second pass covers all of the devices that were not enumerated in the first pass. Take _DEP into account only for device objects with _HID, mostly in order to avoid deferring the creation of ACPI device objects that represent PCI devices and must be present during the enumeration of the PCI bus (which takes place during the processing of the ACPI device object that represents the host bridge), so that they can be properly associated with the corresponding PCI devices. Link: https://lore.kernel.org/linux-acpi/20201121203040.146252-1-hdegoede@redhat.com/ # [1] Reported-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-12-17ACPI: scan: Evaluate _DEP before adding the deviceRafael J. Wysocki1-19/+25
Evaluate _DEP before calling acpi_add_single_object() from acpi_bus_check_add() and do that only for ACPI_BUS_TYPE_DEVICE objects. While at it, rename acpi_device_dep_initialize() to acpi_scan_check_dep(), fix up a memory allocation statement in that function, consistently treat memory allocation failures in there as intermittent errors and make some related janitorial changes in it. This change will help to avoid calling acpi_add_single_object() if there are unmet _DEP dependencies in the future, as that may cause some control methods, potentially depending on the presence of operation regions supplied by other devices, to be evaluated prematurely. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.