| Age | Commit message (Collapse) | Author |
|---|
|
* pnp:
PNP: Detach device after resource transition failure
* acpi-sbs:
ACPI: SBS: Fix NULL pointer dereference on allocation failure
* acpi-video:
ACPI: video: add backlight=native DMI quirk on Acer Nitro AN515-58
|
|
The Acer Nitro AN515-58 requires the same quirk entry as AN515-46, since
its firmware also advertises the NVIDIA WMI EC backlight GUID. However,
on this hybrid graphics setup, the internal display is wired to the
Integrated GPU (Intel Iris Xe Graphics).
As a result, the nvidia_wmi_ec_backlight driver fails to probe, leaving
no backlight device registered and rendering the brightness keys and
desktop brightness slider non-functional.
Setting acpi_backlight=native allows intel_backlight to register its
backlight interface and restoring brightness control. Add a DMI
quirk entry so this model uses the native backlight by default.
Signed-off-by: Dirga Yuza <dirgayuza123@gmail.com>
Link: https://patch.msgid.link/20260911143306.49015-1-dirgayuza123@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
acpi_sbs_probe() jumps to the common error path when kzalloc_obj()
fails, but platform_set_drvdata() is only called after the allocation
succeeds.
The error path calls acpi_sbs_remove(), which retrieves the unset
driver data and dereferences the resulting NULL pointer when locking
sbs->lock, causing a NULL pointer dereference.
Return -ENOMEM directly when the allocation fails, since no resources
have been initialized at that point and there is nothing to clean up.
This issue was found by manual code inspection.
Fixes: 9460eaae2ee42 ("ACPI: SBS: Convert the driver to a platform one")
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Link: https://patch.msgid.link/20260912113355.644238-1-lgs201920130244@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
* acpi-thermal:
ACPI: fan: Use more suitable cooling device data
ACPI: fan: Store ACPI device pointer in struct acpi_fan
ACPI: processor: thermal: Use more suitable cooling device data
ACPI: thermal: Use cooling device parent for thermal zone binding
ACPI: fan: Use thermal_cooling_device_create()
ACPI: video: Use thermal_cooling_device_create()
ACPI: processor: thermal: Use thermal_cooling_device_create()
thermal: core: Introduce thermal_cooling_device_create()
ACPI: video: Fix backlight unregistration ordering
ACPI: fan: Fix memory leak due to leftover devm_kcalloc() argument
|
|
* acpi-battery:
ACPI: battery: Fix bogus cycle count values on systems without _BIX
* acpi-sbs:
ACPI: SBS: report relative state of charge as CAPACITY
* acpi-button:
ACPI: button: Add lid_init_state quirk for Razer Blade Stealth 13 (Early 2020) RZ09-0310
|
|
* acpi-tables:
ACPI: MRRM: Use for_each_populated_zone() in get_node_num()
* acpi-utils:
ACPI: utils: Ignore leading root scope prefix in string _UID match
ACPI: utils: Adjust message printing macros for ACPI objects
* acpi-pfrut:
ACPI: pfr_update: zero-initialize capability query result
|
|
* acpi-apei:
Documentation: ACPI: EINJ: Update stale driver source reference
cxl/ras: Make cxl_cper_handle_prot_err() static
ACPI: APEI: GHES: Bound AER info copy and sanitize software metadata
ACPI: APEI: GHES: Validate memory error section length before payload access
efi/cper: Read only validated fields in cper_mem_err_pack()
ACPI: APEI: GHES: Validate CXL protocol error section length before RAS cap copy
ACPI: APEI: GHES: Bound CXL event record copy to the firmware section length
ACPI: extlog: Fix CONFIG_ACPI_APEI_PCIEAER guard typo
ACPI: extlog: Validate PCIe error section length before payload access
ACPI: extlog: Avoid populating software AER metadata from raw hardware buffer
ACPI: extlog: Defer CXL protocol error handling to avoid lock inversion
ACPI: extlog: Validate elog record length before walking sections
efi/cper: Reject an error status block length that wraps a u32
efi/cper: Reject CPER records with an out-of-range error_data_length
* acpi-osl:
ACPI: OSL: Use vsnprintf() in acpi_os_vprintf()
|
|
* acpi-scan:
ACPI: scan: Combine two conditionals in acpi_bus_attach()
ACPI: PM: Move acpi_bus_init_power() declaration to internal header file
ACPI: scan: Stop calling acpi_bus_init_power() early
ACPI: PM: Drop parent state update from acpi_device_get_power()
ACPI: scan: Drop useless and noisy debug statement
* acpi-glue:
ACPI: glue: Skip devices with no type in acpi_device_notify()
ACPI: glue: Fix up and adjust acpi_unbind_one()
ACPI: glue: Rearrange acpi_bind_one() to avoid breakage
ACPI: glue: Carry out companion lookup under bus_type_sem
ACPI: glue: Rework the success message in acpi_device_notify()
ACPI: glue: Reduce debug noise from acpi_device_notify()
* acpi-bus:
ACPI: bus: Reduce runtime memory footprint of struct acpi_device
|
|
Instead of passing an ACPI device object pointer as devdata to
thermal_cooling_device_create(), make acpi_fan_probe() pass a pointer
to struct acpi_fan to it, which allows the callback functions in
fan_cooling_ops to be simplified.
Also avoid using acpi_driver_data() in two functions invoked by the
cooling device callbacks by passing struct acpi_fan pointers instead
of struct acpi_device pointers to them.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/3631084.QJadu78ljV@rafael.j.wysocki
|
|
In preparation for subsequent changes, instead of storing a fan ACPI
handle in struct acpi_fan, store a pointer to the corresponding struct
acpi_device in it.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/8772267.NyiUUSuA9g@rafael.j.wysocki
|
|
Instead of passing an ACPI device object pointer as devdata to
thermal_cooling_device_create(), make acpi_processor_thermal_init()
pass a pointer to the struct acpi_processor representing the given CPU
to it, which allows the callback functions in processor_cooling_ops to
be simplified and the second argument of acpi_processor_thermal_init()
and acpi_processor_thermal_exit() to be dropped.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/6192780.MhkbZ0Pkbq@rafael.j.wysocki
|
|
The ACPI thermal zone .should_bind() callback function,
acpi_thermal_should_bind_cdev(), expects the given cooling device's
devdata to point to an ACPI device object whose ACPI handle should be
compared with ACPI handles in a list associated with the given trip
point. That is not particularly straightforward and it effectively
requires the drivers of ACPI cooling devices to populate the devdata
with addresses of the ACPI companions of the devices they bind to.
Consequently, the devdata cannot be used by the driver for its own
needs which is its intended purpose.
That can be overcome with the help of the observation that the
ACPI device objects to be matched against the lists of ACPI handles
associated with trip points are in fact the ACPI companions of the
parents of cooling devices. Thus instead of using the given cooling
device's devdata, it is sufficient to obtain the ACPI handle of its
parent and compare that ACPI handle with the ones in the list
associated with the given trip point.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
[ rjw: Added parent_handle check against NULL ]
Link: https://patch.msgid.link/9672996.CDJkKcVGEf@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Instead of using thermal_cooling_device_register() for
registering a cooling device in the ACPI fan driver, make it use
thermal_cooling_device_create() and pass a pointer to the platform
device representing the given fan to that function as the cooling
device's parent. That will cause the cooling device's sysfs directory
to be created under the parent's sysfs directory (among other things).
Since creating a class device under a parent causes a "device" symbolic
link from the sysfs directory of the class device to the sysfs directory
of the parent to appear automatically, remove the code creating that
symbolic link manually.
Moreover, since the cooling device is now located in sysfs under its
parent and it can be easily identified as a cooling device, there is
no need to create a "thermal_cooling" symbolic link from its parent
to it. Accordingly, also remove the code creating that symbolic link.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/3969045.kQq0lBPeGt@rafael.j.wysocki
|
|
Instead of using thermal_cooling_device_register() for registering a
backlight cooling device in the ACPI video bus driver, make it use
thermal_cooling_device_create() and pass a pointer to the LCD device
to that function as the cooling class device's parent. That will
cause the cooling device's sysfs directory to be created under
the parent's sysfs directory (among other things).
Since creating a class device under a parent causes a "device" symbolic
link from the sysfs directory of the class device to the sysfs directory
of the parent to appear automatically, remove the code creating the
"device" symbolic link from the sysfs directory of the cooling device
in question to the sysfs directory of the parent's ACPI companion
device. That companion device is reachable through the "firmware_node"
symbolic link in the parent's sysfs directory regardless.
Moreover, since the cooling class device is now located in sysfs under
its parent and it can be easily identified as a cooling device, there is
no need to create a "thermal_cooling" symbolic link from its parent's
ACPI companion to it. Accordingly, also remove the code creating that
symbolic link.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/23237491.EfDdHjke4D@rafael.j.wysocki
|
|
Instead of using thermal_cooling_device_register() for registering
a cooling device in the ACPI processor driver, make it use
thermal_cooling_device_create() and pass a pointer to the processor
device representing the given CPU to that function as the cooling
device's parent. That will cause the cooling device's sysfs directory
to be created under the parent's sysfs directory (among other things).
Since creating a class device under a parent causes a "device" symbolic
link from the sysfs directory of the class device to the sysfs directory
of the parent to appear automatically, remove the code creating the
"device" symbolic link from the sysfs directory of the cooling device
in question to the sysfs directory of the parent's companion ACPI
device. That ACPI device is reachable through the "firmware_node"
symbolic link in the parent's sysfs directory regardless.
Moreover, since the cooling device is now located in sysfs under its
parent and it can be easily identified as a cooling device, there is
no need to create a "thermal_cooling" symbolic link from its parent's
ACPI companion to it. Accordingly, also remove the code creating that
symbolic link.
While at it, check for error pointer values in addition to checking
for NULL in acpi_processor_thermal_exit() to avoid dereferencing them
mistakenly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
[ rjw: Corrected typo in the changelog ]
Link: https://patch.msgid.link/2362345.iZASKD2KPV@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
In acpi_video_dev_unregister_backlight(), the sysfs interface of the
cooling class device may access the brightness object under the
backlight device's ACPI companion, so that object cannot be freed
before unregistering the cooling class device.
Adjust the code to take that into account.
Fixes: 67b662e189f4 ("ACPI / video: seperate backlight control and event interface")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
[ rjw: Fixed the Fixes: tag ]
Link: https://patch.msgid.link/3429468.aeNJFYEL58@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
An ACPI device object's dev field in passed as the first argument to
devm_kcalloc() in acpi_fan_get_fps() which is incorrect and leads to
a memory leak on driver probe errors and removal because the driver
is not bound to that ACPI device.
Address this by replacing that pointer with a pointer to the device the
driver is actually bound to.
While at it, drop a redundant error message after a memory allocation
failure (that also gets printed relative to the ACPI device).
Fixes: d91a1d129b63 ("ACPI: fan: Use platform device for devres-related actions")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/14089663.uLZWGnKmhe@rafael.j.wysocki
|
|
Since all of the users of struct acpi_bus_type use the device type
for matching, devices without a type will not be matched by any of
them, so they can be skipped early in acpi_device_notify().
Update the code accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/2078562.PYKUYFuaPT@rafael.j.wysocki
|
|
Since none of the acpi_unbind_one() callers check its return value and
it always returns 0 anyway, make it void.
Also notice that unlocking physical_node_lock for the given ACPI device
should be carried out before dropping the reference to it in case that
reference is the last one (highly unlikely), so rearrange the code to
make that happen.
Fixes: 3e3327837c18 ("ACPI: Use list_for_each_entry() in acpi_unbind_one()")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/10940500.nUPlyArG6x@rafael.j.wysocki
|
|
Rearange the code in acpi_bind_one() to avoid situations in which the
existing ACPI companion of the given device would be replaced with NULL
due to a memory allocation error or because somebody tries to bind a
physical device with an ACPI companion to a different ACPI device
erroneously.
Fixes: 7b1998116bbb ("ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[ rjw: Merged two conditionals to avoid redundant check ]
Link: https://patch.msgid.link/3465482.44csPzL39Z@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
When acpi_device_notify() looks up an ACPI companion for the given
device, it invokes callbacks from struct acpi_bus_type() without
synchronization which may lead to a use-after-free if the driver
module containing those callbacks is unloaded at the same time.
Address this by holding bus_type_sem throughout the entire ACPI
companion lookup and the execution of the .setup() callback in
struct acpi_bus_type (if present) instead of dropping the semaphore
(prematurely) after finding a matching struct acpi_bus_type.
For this purpose, rename acpi_get_bus_type() to acpi_companion_lookup(),
make it return a struct acpi_device pointer, and move the relevant code
from acpi_device_notify() to it.
Also notice that the only case in which the .bind() callback from an
ACPI scan handler may need to be invoked is when the given device is
a platform one, so adjust acpi_device_notify() accordingly and drop
the "done" label that is not used any more from it.
Fixes: 2ef5236660b6 ("ACPI: glue: Look for ACPI bus type only if ACPI companion is not known")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/3089807.e9J7NaK4W3@rafael.j.wysocki
|
|
Using an ACPI handle in the acpi_device_notify() success message is
somewhat misleading because the "physical" device is not bound to an
ACPI namespace object in that function, but to an ACPI device object
attached to it. Moreover, the message is outright confusing for the
"physical" devices bound to ACPI devices without ACPI namespace
objects (for example, fixed event buttons).
Address this by turning that message into a dev_dbg() one printed for
the "physical" device and mentioning the name of the ACPI companion.
Fixes: ab06eb920401 ("ACPI: scan: Register platform devices for fixed event buttons")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/2448150.ElGaqSPkdT@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
When debug is enabled in the ACPI glue code that handles binding
devices to ACPI companions, acpi_device_notify() produces a lot of
message noise related to devices that have no ACPI companions.
Reduce that noise by checking the most obvious case, ACPI device
objects, directly and returning from acpi_device_notify() in that
case without printing any debug messages. Also avoid printing a
debug message when there is no matching ACPI bus type definition for
the given device, which is the case for the vast majority of devices.
Additionally, make the debug messages that get printed more informative.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/6325978.lOV4Wx5bFT@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
There are two conditionals in acpi_bus_attach() that can be combined,
which slightly reduces the overhead and makes the code a bit easier
to follow, so do that.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Peixin Xie <peixin.xie@linux.spacemit.com>
Tested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://patch.msgid.link/8746939.T7Z3S40VBb@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Since acpi_bus_init_power() is only used internally in the core ACPI
device enumeration and power management code, it need not be visible
outside, so move its declaration to an internal header file.
No functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Peixin Xie <peixin.xie@linux.spacemit.com>
Tested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://patch.msgid.link/3079955.e9J7NaK4W3@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
There is a problem, introduced by commit 9d9bcae47fd5 ("ACPI: delay
enumeration of devices with a _DEP pointing to an INT3472 device")
inadvertently, that devices with missing dependencies may be put
into power state D0 prematurely [1].
Namely, acpi_bus_init_power() called by acpi_bus_get_power_flags()
during the early initialization of ACPI device objects, may discover
that all of the power resources needed by the given device to be in
power state D0 are initially on, so it will reference count those
power resources and transition the device into D0. Later, if
acpi_bus_attach() running for that device notices that it has missing
dependencies, the enumeration of it will be deferred and its
power_manageable flag will be cleared, even though it is still in D0
at that point.
After the dependencies in question have been met, acpi_bus_attach()
runs again for the device and now it calls acpi_bus_init_power() that
takes additional references to the power resources used by the device
in D0. These additional references prevent the power resources from
being turned off when the device goes into D3hot/D3cold.
Another problem, related to the previous one, is that ACPI power state
initialization may be carried out for devices whose parents are not
ready for enumeration which may lead to initialization ordering issues.
To address both, stop calling acpi_bus_init_power() from
acpi_bus_get_power_flags(), but also take the initialization of
PCI devices into account, which needs to be done because they
are initialized and bound to their ACPI companions before
acpi_bus_attach() is called for the latter.
To that end, notice that acpi_power_up_if_adr_present() is used for
powering-up PCI devices in D3cold before walking the bus in order to
discover them and the initial ACPI power state of those devices needs
to be known for this purpose, so add an acpi_bus_init_power() invocation
to that function. [The debug statement printed by it duplicates the
debug statements printed during the acpi_bus_init_power() execution, so
drop it.]
Moreover, since the ACPI companions of PCI devices are associated with
the corresponding PCI devices found on the bus before acpi_bus_attach()
is called for them, it is not necessary or even useful to skip them in
acpi_bus_attach() due to an ACPI status mismatch, so avoid doing that
and complain if the ACPI status does not match the observed situation.
Also use the ACPI power state tracking to decide whether or not
the device's power state needs to be initialized in acpi_bus_attach()
instead of using the "initialized" flag of the ACPI device object
for this purpose, which is fragile and inconvenient, and clear the
power_manageable flag on failure in acpi_bus_init_power() (additionally,
poison the device ACPI power state as "invalid" if the initialization of
it fails). That allows the clearing of the power_manageable flag for
devices with unmet dependencies to be dropped.
While at it, add a debug message pringing statement to
acpi_bus_init_power() to facilitate diagnostics.
Fixes: 9d9bcae47fd5 ("ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device")
Link: https://lore.kernel.org/linux-acpi/20260820-acpi-power-resource-ref-fix-v2-1-29818173ea13@linux.spacemit.com/ [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Peixin Xie <peixin.xie@linux.spacemit.com>
Tested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://patch.msgid.link/2295263.irdbgypaU6@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The parent state update in acpi_device_get_power(), that occurs when the
child device turns out to be in D0 and the parent's power state is still
unknown, is highly questionable because it may cause the reference
counters of the power resources used by the parent in D0 (if any) to
underflow when the parent goes into a low-power state later. Moreover,
there is no reason to do it on reads from the real_power_state sysfs
attribute of the child.
That check had been added by commit 8f7412a792bc ("ACPI / PM: Infer
parent power state from child if unknown, v2") before starting to
handle the "missing _PSC and no power resources" case directly in
acpi_bus_init_power(), as of commit b3785492268f ("ACPI / PM: Do not
power manage devices in unknown initial states"). It is not necessary
any more and commit b3785492268f should have removed it.
Drop it now.
Fixes: b3785492268f ("ACPI / PM: Do not power manage devices in unknown initial states")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Peixin Xie <peixin.xie@linux.spacemit.com>
Tested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://patch.msgid.link/5147279.31r3eYUQgx@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
acpi_sbs reads SBS command 0x0e (AbsoluteStateOfCharge) into
battery->state_of_charge, which is exported unmodified as
POWER_SUPPLY_PROP_CAPACITY.
Per the Smart Battery Data Specification 1.1, 0x0e is expressed as a
percentage of DesignCapacity and is explicitly permitted to exceed 100%.
Documentation/ABI/testing/sysfs-class-power specifies the capacity
attribute as "Valid values: 0 - 100 (percent)", so any pack whose
FullChargeCapacity exceeds its DesignCapacity - the normal state of a
new or recently replaced battery - makes the driver report out of range.
The correct source is 0x0d (RelativeStateOfCharge), a percentage of
FullChargeCapacity, which the specification bounds to 0..100.
This is the same defect that was fixed in the i2c SBS driver by commit
b1f092f6480e ("sbs-battery.c: Capacity attr = remaining relative
capacity"), whose reasoning applies verbatim here; drivers/acpi/sbs.c was
not updated at the time. drivers/power/supply/sbs-battery.c has used 0x0d
since, so the two SBS drivers currently disagree about what CAPACITY
means.
Observed on a MacBookPro11,1 with an SMP/bq20z451 pack
(FullChargeCapacity 6775 mAh, DesignCapacity 6400 mAh). Both registers
read back-to-back from the pack at a full charge:
0x0d RelativeStateOfCharge = 100 %
0x0e AbsoluteStateOfCharge = 106 %
/sys/class/power_supply/BAT0/capacity reported 106 while upower, which
computes charge_now/charge_full itself rather than trusting the driver,
reported 100.
battery->state_of_charge has no other consumer, so no other property
changes behaviour.
Signed-off-by: Itay Shem-tov <itayst@gmail.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://patch.msgid.link/20260903104244.25556-1-itayst@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The debug message printing statement in handle_to_device() is
super-noisy because it triggers whenever the presence of an
attached struct acpi_device is checked for the given object in
the ACPI namespace and it turns out that there is none. That
is a perfectly valid situation and the lack of an attached
struct acpi_device is not particularly interesting, so drop
that message.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/2861358.mvXUDI8C0e@rafael.j.wysocki
|
|
acpi_os_vprintf() formats every ACPICA diagnostic into a 512-byte static
buffer with an unbounded vsprintf():
static char buffer[512];
vsprintf(buffer, fmt, args);
ACPICA interpolates table-derived namespace paths into its messages, so the
length is driven by table content. A malformed ACPI table can therefore
produce a diagnostic longer than the buffer and overwrite whatever follows
it.
From the System.map of an x86_64_defconfig build, acpi_ioremap_lock sits 624
bytes into that buffer - 112 bytes past its end - so bytes 624..631 of an
over-long message land on the mutex's owner field, which __mutex_lock() then
dereferences.
The overwritten bytes are attacker-influenced but not attacker-controlled:
they are printable ASCII from a NUL-terminated string, so the resulting
pointer is always non-canonical and always faults. This is a reliable denial
of service, not a demonstrated pointer-control primitive.
Because acpi_tb_load_namespace() parses the DSDT and every SSDT during
acpi_init(), a table supplied by firmware triggers this in PID 1 inside
do_one_initcall(), panicking the kernel before userspace exists.
Bound the write with vsnprintf(). Truncating a diagnostic is strictly better
than corrupting adjacent kernel objects.
Tested on pristine Linux 7.2.2 - tag: v7.2.2., Stock x86_64_defconfig
(no KASAN, no debug options), table supplied by firmware via
"qemu -acpitable":
[ 0.022259] ACPI: SSDT 0x000000003FFE1C52 000640 (v01 _ASUS_
Notebook 00000005 MSFT 0100000D)
[ 0.353684] Oops: general protection fault, probably for
non-canonical address
0x41435f2e345f2e64: 0000 [#1] SMP NOPTI
[ 0.353727] RIP: 0010:__mutex_lock.constprop.0+0xbd/0xa40
[ 0.353727] RAX: 41435f2e345f2e30 RBX: 00000000fed00000
[ 0.353727] R15: ffffffff8c248530
[ 0.353727] Call Trace:
[ 0.353727] acpi_os_map_iomem
[ 0.353727] acpi_ex_system_memory_space_handler
[ 0.353727] acpi_ev_address_space_dispatch
[ 0.353727] acpi_ex_access_region
[ 0.353727] acpi_ex_read_data_from_field
[ 0.353727] acpi_ex_resolve_node_to_value
[ 0.353727] acpi_ds_evaluate_name_path
[ 0.353727] acpi_ps_parse_loop
[ 0.353727] acpi_ps_execute_method
[ 0.354729] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000009
RAX is the corrupted owner; the faulting address is RAX + 0x34.
R15 matches acpi_ioremap_lock. On a KASAN build the overflow is
reported directly as:
BUG: KASAN: global-out-of-bounds in string.
Signed-off-by: Vlatko Kosturjak <vlatko.kosturjak@gmail.com>
[ rjw: Subject tweak ]
Link: https://patch.msgid.link/CAPAw8HEMdsNN6WhizHkv2Orp2pkQ2-g009XCGFnKnhXoRhcKZQ@mail.gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
2020) RZ09-0310
This patch adds a quirk mapping for the "Blade Stealth 13 (Early 2020) -
RZ09-0310" laptop, which exhibits the same issue as the following two
related products already accounted for in this file.
- Razer Blade Stealth 13 Late 2019
- Blade Pro 17 (Early 2020) - RZ09-0329
Summary of the issue this fixes:
The firmware's _LID method still returns "closed" after resume when the
lid was opened during S3, causing systemd-logind to suspend the system
again within several seconds (15-40) after waking.
Signed-off-by: Ian Gallagher <cdine@cdine.org>
Link: https://patch.msgid.link/90ab9b58-da8b-4ffc-bd4b-adf7590545a9@app.fastmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
query_capability() copies four ACPI buffers into fixed-size fields using
the firmware-supplied lengths. The existing overflow guard rejects
oversized buffers, but shorter buffers are accepted and leave trailing
bytes of the stack-allocated cap_hdr uninitialized. PFRU_IOC_QUERY_CAP
then copies the entire structure to userspace.
Zero-initialize cap_hdr before querying the firmware. This preserves the
existing handling of short firmware responses while preventing disclosure
of kernel stack data. Oversized buffers remain rejected.
A QEMU _DSM returning one-byte buffers reproduced nonzero stack suffix
bytes in all four fields. With this change, the ioctl still succeeds and
each unwritten suffix is zero-filled, while 64-byte buffers continue to
return -EINVAL.
Fixes: 0db89fa243e5 ("ACPI: Introduce Platform Firmware Runtime Update device driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/1a001e1fee9.637da6dc3533246.238498880682901704%40a0rg.com
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Link: https://patch.msgid.link/20260827053741.79425-1-kmehltretter@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
get_node_num() iterates over the populated zones of every online node
with a nested loop. for_each_populated_zone() iterates over the same
zones in the same order.
So use for_each_populated_zone() instead and remove the unused
variable.
No functional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Link: https://patch.msgid.link/20260821131530.3375820-1-ekffu200098@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Devices supporting only the legacy _BIF ACPI control method cannot
know the cycle count of the associated battery, so cycle_count always
remains 0. Claiming support for POWER_SUPPLY_PROP_CYCLE_COUNT on
such devices can thus mislead userspace applications and prevents
power supply extensions from supplying correct cycle count values.
Fix this by not claiming support for POWER_SUPPLY_PROP_CYCLE_COUNT
on devices without _BIX.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260806233817.622975-1-W_Armin@gmx.de
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This is another run of the Coccinelle script for converting kmalloc()
family of allocations to kmalloc_obj() via the existing rules in
scripts/coccinelle/api/kmalloc_objs.cocci
This catches both the set of kmalloc() uses added since the first
kmalloc_obj() conversions in v7.0 and adds a large group missed in the
first pass due to Coccinelle not interacting well with the cleanup.h
scoped_...() family of macros[1]. I worked around this with spatch's
"--macro-file" argument to a file with all the scoped_...() macros mapped
to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control
flow indicator I could find.
Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc,
riscv, and s390 with no new warnings.
Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1]
Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2]
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
|
|
ghes_handle_aer() copies sizeof(struct aer_capability_regs) out of the
fixed 96-byte pcie_err->aer_info. The struct is larger, so the copy reads
past the section, and it fills the software-only header_len and flit fields
of the embedded struct pcie_tlp_log from firmware bytes.
pcie_print_tlp_log() uses both to bound a loop over dw[], so a large value
walks past the array. Nothing checks the section can hold a struct
cper_sec_pcie either.
Validate error_data_length, zero the destination, and map aer_info onto the
struct as extlog_print_pcie() does: copy up to the four Header Log DWORDs,
then place the TLP Prefix Log from its own offset. The rest stays zero,
covering header_len and flit.
Reported-by: sashiko-bot@kernel.org
Closes: https://sashiko.dev/#/patchset/20260714231835.303081-1-dave.jiang@intel.com?part=3
Fixes: 7e077e6707b3 ("PCI/ERR: Handle TLP Log in Flit mode")
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/20260904172337.1409775-13-dave.jiang@intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
ghes_do_proc() hands the CPER_SEC_PLATFORM_MEM payload to the report chain,
arch_apei_report_mem_error() and ghes_handle_memory_failure() without
checking gdata->error_data_length. All three read validation_bits and
physical_addr, at offsets 0 and 16, so a shorter section reads past the
record.
Check the length once in ghes_do_proc(), before any consumer runs. Take the
73-byte struct cper_sec_mem_err_old as the floor: older firmware
legitimately emits that UEFI 2.1/2.2 layout, and it makes validation_bits
safe to read.
The fields from "extended" on are absent from that layout, so also require
whatever length the validation bits claim. Derive it per field rather than
demanding the full 80 bytes: rank needs only 76, and the BANK_GROUP and
BANK_ADDRESS bits describe "bank" at offset 38, which every record carries.
Testing the whole mask against one size, as cper_print_mem() does, gets it
wrong both ways.
Reported-by: sashiko-bot@kernel.org
Closes: https://sashiko.dev/#/patchset/20260714231835.303081-1-dave.jiang@intel.com?part=7
Fixes: ca104edc1784 ("ACPI, APEI, GHES: Cleanup ghes memory error handling")
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/20260904172337.1409775-12-dave.jiang@intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
cxl_cper_setup_prot_err_work_data() locates the RAS Capability block at
prot_err + sizeof(*prot_err) + dvsec_len and copies it, but dvsec_len is
firmware controlled and never validated, so it can point the copy outside
the section.
Extend cxl_cper_sec_prot_err_valid() to check that the section can hold
the header, and that the header, DVSEC and RAS Capability block together
fit the reported section length.
Reported-by: sashiko-bot@kernel.org
Link: https://sashiko.dev/#/patchset/20260617-topics-ahmtib01-ras_ffh_arm_internal_review-v6-0-91f725174aa0@arm.com?part=6
Link: https://lore.kernel.org/linux-cxl/20260709165457.8BA181F000E9@smtp.kernel.org/
Fixes: 315c2f0b53ba ("acpi/ghes, cper: Recognize and cache CXL Protocol errors")
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/20260904172337.1409775-10-dave.jiang@intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
cxl_cper_post_event() copies a fixed sizeof(struct cxl_cper_event_rec)
out of the firmware CPER section without checking how long the section
actually is, so a short one reads past the record.
Pass gdata->error_data_length in and reject a section too small to hold
the record before the copy.
Reported-by: sashiko-bot@kernel.org
Link: https://sashiko.dev/#/patchset/20260617-topics-ahmtib01-ras_ffh_arm_internal_review-v6-0-91f725174aa0@arm.com?part=6
Fixes: 5e4a264bf8b5 ("acpi/ghes: Process CXL Component Events")
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/20260904172337.1409775-9-dave.jiang@intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The guard reads "#ifdef ACPI_APEI_PCIEAER" rather than
"#ifdef CONFIG_ACPI_APEI_PCIEAER". That symbol is never defined, so the
extlog PCIe AER handling is always compiled out.
Use the CONFIG_ prefixed symbol.
Fixes: e778ffefa34d ("ACPI: extlog: Trace CPER PCI Express Error Section")
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/20260904172337.1409775-8-dave.jiang@intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
extlog_print_pcie() reads pcie_err->validation_bits and device_id and
copies the 96-byte aer_info buffer without checking that
gdata->error_data_length is big enough for a struct cper_sec_pcie. The
cper_estatus_check() call added earlier keeps the read inside the estatus
block, but a short section still gets stale adjacent bytes treated as PCIe
error data.
Reject a section too small to hold the record before touching any field,
and warn: a truncated section means firmware is emitting malformed records.
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/linux-cxl/20260709165457.8BA181F000E9@smtp.kernel.org/
Fixes: e778ffefa34d ("ACPI: extlog: Trace CPER PCI Express Error Section")
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/20260904172337.1409775-7-dave.jiang@intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
extlog_print_pcie() casts pcie_err->aer_info straight to struct
aer_capability_regs *. That struct embeds struct pcie_tlp_log, whose
software-only header_len and flit fields sit at offset 84 - inside the
96-byte aer_info buffer - so the cast fills them with raw firmware bytes.
pcie_print_tlp_log() uses both to bound a loop over dw[], and a large
header_len walks past the end of the array.
Copy into a zeroed local struct, and only as far as aer_info maps onto it:
the leading registers and the four Header Log DWORDs. Place the TLP Prefix
Log separately, from the offset the hardware keeps it at. The rest stays
zero, which covers header_len and flit and keeps the Root Error registers
out of the prefix log, where pcie_print_tlp_log() would print them as
end-to-end prefixes.
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/linux-cxl/20260709165457.8BA181F000E9@smtp.kernel.org/
Fixes: e778ffefa34d ("ACPI: extlog: Trace CPER PCI Express Error Section")
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/20260904172337.1409775-6-dave.jiang@intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
extlog_print() calls cxl_cper_handle_prot_err() synchronously while the
MCE notifier chain rwsem is held, and that path takes the PCI device_lock
via guard(device)(). The probe path takes the two in the opposite order,
holding device_lock while mce_register_decode_chain() takes the rwsem, so
they can deadlock AB-BA.
ghes.c already avoids this by posting protocol errors to a kfifo and
handling them from a workqueue via cxl_cper_post_prot_err(). Export that
function and call it instead.
Declare it with the other CONFIG_ACPI_APEI_GHES exports rather than at the
end of the header. No #else stub: ACPI_EXTLOG selects ACPI_APEI_GHES, so
the only caller cannot exist without it.
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/linux-cxl/20260709165457.8BA181F000E9@smtp.kernel.org/
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/20260904172337.1409775-5-dave.jiang@intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
extlog_print() copies a fixed ELOG_ENTRY_LEN (4096) bytes from the elog
record into elog_buf, then walks the sections using the firmware-controlled
data_length. Nothing keeps data_length inside the buffer, so a malformed
record walks the section pointer past elog_buf and reads adjacent memory.
Unlike the GHES paths, extlog never calls cper_estatus_check().
Reject a record longer than ELOG_ENTRY_LEN and run cper_estatus_check()
before walking the sections. The length test alone is not enough: a wrapped
length reads back short and passes it, which cper_estatus_check() catches
via the header check added earlier. Drop a malformed record with
NOTIFY_DONE and without MCE_HANDLED_EXTLOG, since extlog did not consume
it.
Reported-by: sashiko-bot@kernel.org
Closes: https://sashiko.dev/#/patchset/20260714231835.303081-1-dave.jiang@intel.com?part=6
Fixes: f6ec01da40e4 ("ACPI: extlog: Handle multiple records")
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://patch.msgid.link/20260904172337.1409775-4-dave.jiang@intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
There are two fields in struct acpi_device_pnp, device_name and
device_class, that were supposed to be populated and used by device
drivers, but they have never been used consistently and now they
are only set for the bus object in acpi_set_pnp_ids() (and never
read afterward).
Drop them along with all of the associated symbols except for
MAX_ACPI_CLASS_NAME_LEN and the acpi_device_class typedef that
are used by the ACPI netlink messaging code. Move those two
definitions closer to the struct acpi_bus_event that refers to
the acpi_device_class type.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/6314925.lOV4Wx5bFT@rafael.j.wysocki
|
|
Revert commit dc948f8b384a ("ACPI: scan: Defer device power
initialization") that is incomplete and may cause ACPI power
management of devices to fail.
The problem is that PCI devices are associated with the
corresponding ACPI device objects before acpi_bus_attach()
runs for them, so after commit dc948f8b384a, ACPI power
management will not be initialized for them before making
that association. Consequently, the reference counting of
ACPI power resources may not work as expected going forward
and power management issues may appear. If they appear, they
may be elusive and hard to diagnose.
While this is fixable, I am not sure if fixing it on top of
commit dc948f8b384a is the best way to go, so it is better to
revert that commit for now and revisit the whole thing in the
next cycle.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/6029658.DvuYhMxLoT@rafael.j.wysocki
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull more ACPI support updates from Rafael Wysocki:
"These update documentation to reflect recent changes in the upstream
ACPICA project, fix issues in the core ACPI device enumeration code
(one of which has been introduced recently), improve the primary
"physical" device lookup for ACPI device objects in that code, and
update ACPI device drivers:
- Update MAINTAINERS, CREDITS and ACPI subsystem documentation to
reflect recent changes in the upstream ACPICA project (Rafael
Wysocki)
- Prevent the core ACPI enumeration code from combining device
resources that overlap completely in order to avoid resource
conflicts during platform device registration because there are
drivers that expect such resources to be present (Rafael Wysocki)
- Defer device power initialization during ACPI-based device
enumeration to the point when the given device is known to be
present and functional and all of its dependencies have been met
(Peixin Xie)
- Fix bus ID cleanup on device_add() failures during ACPI device
object registration (Hongyan Xu)
- Introduce a new helper function for looking up the primary
"physical" device for a given ACPI device object and update the
core ACPI device enumeration code to use that function (Rafael
Wysocki)
- Protect all battery properties with a separated mutex in the ACPI
battery driver to prevent race conditions from occurring and avoid
evaluating the _BST ACPI control method multiple times in parallel
for the same battery device (Rong Zhang)
- Add DMI quirk for the Razer Blade Pro 17 early 2020 lid switch to
the ACPI button driver (Robin Everaars)
- Convert fixed clock rates in the ACPI driver for AMD SoCs (APD) to
use HZ_PER_MHZ and add a clock frequency for the HJMC01 I2C
controller to it (Hongnan Li and Xiangyang Yu)
- Fix a stack buffer overflow in query_capability() in the ACPI
platform firmware runtime update driver (Anirudh Prasad)"
* tag 'acpi-7.3-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: button: Add DMI quirk for Razer Blade Pro 17 early 2020 lid switch
ACPI: scan: Do not combine resources that overlap completely
ACPI: Update upstream ACPICA repository URL in documentation
ACPI: Update MAINTAINERS entry for ACPICA
ACPI: Add Bob Moore to CREDITS
ACPI: pfr_update: fix stack buffer overflow in query_capability()
ACPI: scan: Defer device power initialization
ACPI: APD: Add clock frequency for HJMC01 I2C controller
ACPI: APD: Convert fixed clock rates to use HZ_PER_MHZ
ACPI: scan: Use acpi_bus_get_primary_device()
ACPI: platform: Use acpi_bus_get_primary_device()
ACPI: bus: Introduce acpi_bus_get_primary_device()
ACPI: scan: fix bus ID cleanup on device_add() failures
ACPI: battery: Protect all properties with a separated mutex
|
|
Merge updates of assorted ACPI drivers for 7.3-rc1:
- Protect all battery properties with a separated mutex in the ACPI
battery driver to prevent race conditions from occurring and avoid
evaluating the _BST ACPI control method multiple times in parallel
for the same battery device (Rong Zhang)
- Add DMI quirk for Razer Blade Pro 17 early 2020 lid switch to the
ACPI button driver (Robin Everaars)
- Convert fixed clock rates in the ACPI driver for AMD SoCs (APD) to
use HZ_PER_MHZ and add a clock frequency for the HJMC01 I2C
controller to it (Hongnan Li and Xiangyang Yu)
- Fix a stack buffer overflow in query_capability() in the ACPI
platform firmware runtime update driver (Anirudh Prasad)
* acpi-battery:
ACPI: battery: Protect all properties with a separated mutex
* acpi-button:
ACPI: button: Add DMI quirk for Razer Blade Pro 17 early 2020 lid switch
* acpi-soc:
ACPI: APD: Add clock frequency for HJMC01 I2C controller
ACPI: APD: Convert fixed clock rates to use HZ_PER_MHZ
* acpi-pfrut:
ACPI: pfr_update: fix stack buffer overflow in query_capability()
|
|
Merge changes related to primary "physical" device lookup for a given
ACPI device object that include the introduction of a new lookup helper
function and core ACPI device enumeration code updates putting that new
function to use (Rafael Wysocki)
* acpi-bus:
ACPI: scan: Use acpi_bus_get_primary_device()
ACPI: platform: Use acpi_bus_get_primary_device()
ACPI: bus: Introduce acpi_bus_get_primary_device()
|
|
Merge core ACPI device enumeration code changes for 7.3-rc1:
- Prevent the core ACPI enumeration code from combining device
resources that overlap completely in order to avoid resource
conflicts during platform device registration because there are
drivers that expect such resources to be present (Rafael Wysocki)
- Defer device power initialization during ACPI-based device
enumeration to the point when the given device is known to be present
and functional and all of its dependencies have been met (Peixin Xie)
- Fix bus ID cleanup on device_add() failures during ACPI device object
registration (Hongyan Xu)
* acpi-scan:
ACPI: scan: Do not combine resources that overlap completely
ACPI: scan: Defer device power initialization
ACPI: scan: fix bus ID cleanup on device_add() failures
|
