Merge an ACPICA fix and a core ACPI support code fix for 7.0-rc5:
- Update the format of the last argument of _DSM to avoid printing
confusing error messages in some cases (Saket Dumbre)
- Fix MFD child automatic modprobe issue by removing a stale check
from acpi_companion_match() (Pratap Nirujogi)
* acpica:
ACPICA: Update the format of Arg3 of _DSM
* acpi-bus:
ACPI: bus: Fix MFD child automatic modprobe issue
Merge a fix for a race condition related to device removal (Bart Van
Assche) for 7.0-rc5.
* pm-runtime:
PM: runtime: Fix a race condition related to device removal
There are two special cases in the idle loop that are handled
inconsistently even though they are analogous.
The first one is when a cpuidle driver is absent and the default CPU
idle time power management implemented by the architecture code is used.
In that case, the scheduler tick is stopped every time before invoking
default_idle_call().
The second one is when a cpuidle driver is present, but there is only
one idle state in its table. In that case, the scheduler tick is never
stopped at all.
Since each of these approaches has its drawbacks, reconcile them with
the help of one simple heuristic. Namely, stop the tick if the CPU has
been woken up by it in the previous iteration of the idle loop, or let
it tick otherwise.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Reviewed-by: Qais Yousef <qyousef@layalina.io>
Reviewed-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Fixes: ed98c34919 ("sched: idle: Do not stop the tick before cpuidle_idle_call()")
[ rjw: Added Fixes tag, changelog edits ]
Link: https://patch.msgid.link/4741364.LvFx2qVVIh@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge cpupower utility updates, including a fix and improvements of the
existing functionality, for 7.0-rc4.
* pm-tools:
cpupower: Add intel_pstate turbo boost support for Intel platforms
cpupower: Add support for setting EPP via systemd service
cpupower: fix swapped power/energy unit labels
Merge an ACPI OS services layer (OSL) fix that addresses sparse warnings
in acpi_os_initialize() (Ben Dooks)
* acpi-osl:
ACPI: OSL: fix __iomem type on return from acpi_os_map_generic_address()
Commit 02c057ddef ("ACPI: video: Convert the driver to a platform one")
switched over the ACPI video bus driver from an ACPI driver to a platform
driver, but that change introduced an unwanted and unexpected side effect.
Namely, on some systems, the ACPI device object of the ACPI video bus
device is an ACPI companion of multiple platform devices and, after
adding video_device_ids[] as an acpi_match_table to the acpi_video_bus
platform driver, all of those devices started to match that driver and
its probe callback is invoked for all of them (it fails, but it leaves
a confusing message in the log). Moreover, the MODULE_DEVICE_TABLE()
of the ACPI video driver module matches all of the devices sharing the
ACPI companion with the ACPI video bus device.
To address this, make the core ACPI device enumeration code create an
auxiliary device for the ACPI video bus device object instead of a
platform device and switch over the ACPI video bus driver (once more)
to an auxiliary driver.
Auxiliary driver generally is a better match for ACPI video bus than
platform driver, among other things because the ACPI video bus device
does not require any resources to be allocated for it during
enumeration. It also allows the ACPI video bus driver to stop abusing
device matching based on ACPI device IDs and it allows a special case
to be dropped from acpi_create_platform_device() because that function
need not worry about the ACPI video bus device any more.
Fixes: 02c057ddef ("ACPI: video: Convert the driver to a platform one")
Reported-by: Pratap Nirujogi <pratap.nirujogi@amd.com>
Closes: https://lore.kernel.org/linux-acpi/007e3390-6b2b-457e-83c7-c794c5952018@amd.com/
Tested-by: Pratap Nirujogi <pratap.nirujogi@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Added AUXILIARY_BUS selection to CONFIG_ACPI to fix build issue ]
[ rjw: Fixed error path in acpi_create_video_bus_device() ]
Link: https://patch.msgid.link/5986516.DvuYhMxLoT@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pull cpupower utility updates for 7.0-rc4 from Shuah Khan:
"linux-cpupower-7.0-rc4
- Adds support for setting EPP via systemd service
- Fixes swapped power/energy unit labels
- Adds intel_pstate turbo boost support for Intel platforms"
* tag 'linux-cpupower-7.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux:
cpupower: Add intel_pstate turbo boost support for Intel platforms
cpupower: Add support for setting EPP via systemd service
cpupower: fix swapped power/energy unit labels
Merge a fix updating the _CPC object definition in ACPICA to avoid
printing a false-positive output package format warning on new
platforms (Saket Dumbre)
* acpica:
ACPICA: Update the _CPC definition to match ACPI 6.6
Revert commit 88fad6ce09 ("ACPI: PM: Let acpi_dev_pm_attach() skip
devices without ACPI PM") that introduced a SoundWire suspend regression
[1].
It is actually not true that the commit above doesn't make a functional
difference because acpi_subsys_suspend(), for example, may resume
devices in runtime-suspend which affects the subsequent handling of
those devices during the suspend transition. For this reason, the
devices that were handled by the ACPI PM domain before that commit may
be handled differently now which may lead to suspend-resume issues.
Fixes: 88fad6ce09 ("ACPI: PM: Let acpi_dev_pm_attach() skip devices without ACPI PM")
Reported-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Closes: https://github.com/thesofproject/linux/pull/5677#issuecomment-3984375077 [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/2829615.mvXUDI8C0e@rafael.j.wysocki
Merge cpufreq and runtime PM updates for 7.0-rc2:
- Fix two issues in the intel_pstate driver causing it to crash when
its sysfs interface is used on a system with some offline CPUs (David
Arcari, Srinivas Pandruvada)
- Update the last user of the pm_runtime_put() return value to discard
it and turn pm_runtime_put() into a void function (Rafael Wysocki)
* pm-cpufreq:
cpufreq: intel_pstate: Fix crash during turbo disable
cpufreq: intel_pstate: Fix NULL pointer dereference in update_cpu_qos_request()
* pm-runtime:
PM: runtime: Change pm_runtime_put() return type to void
pmdomain: imx: gpcv2: Discard pm_runtime_put() return value
The primary role of pm_runtime_put() is to decrement the runtime PM
usage counter of the given device. It always does that regardless of
the value returned by it later.
In addition, if the runtime PM usage counter after decrementation turns
out to be zero, a work item is queued up to check whether or not the
device can be suspended. This is not guaranteed to succeed though and
even if it is successful, the device may still not be suspended going
forward.
There are multiple valid reasons why pm_runtime_put() may not decide to
queue up the work item mentioned above, including, but not limited to,
the case when user space has written "on" to the device's runtime PM
"control" file in sysfs. In all of those cases, pm_runtime_put()
returns a negative error code (even though the device's runtime PM
usage counter has been successfully decremented by it) which is very
confusing. In fact, its return value should only be used for debug
purposes and care should be taken when doing it even in that case.
Accordingly, to avoid the confusion mentioned above, change the return
type of pm_runtime_put() to void.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Link: https://patch.msgid.link/14387202.RDIVbhacDa@rafael.j.wysocki
Passing pm_runtime_put() return value to the callers is not particularly
useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example.
Accordingly, update imx_pgc_domain_suspend() to simply discard the
return value of pm_runtime_put() and always return success to the
caller.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/15658107.tv2OnDr8pf@rafael.j.wysocki
Merge additional updates of multiple core ACPI device drivers (battery,
button, video, EC, SMBUS HC) for 7.0-rc1:
- Drop redundant checks from the ACPI notify handler and the driver
remove callback in the ACPI battery driver (Rafael Wysocki)
- Move the creation of the wakeup source during the ACPI button driver
probe to an earlier point to avoid missing a wakeup event due to a
race and clean up system wakeup handling and remove callback in that
driver (Rafael Wysocki)
- Drop unnecessary driver_data pointer clearing from the ACPI EC and
SMBUS HC drivers and make the ACPI backlight (video) driver clear the
device's driver_data pointer on remove (Rafael Wysocki)
* acpi-battery:
ACPI: battery: Drop redundant checks from acpi_battery_remove()
ACPI: battery: Drop redundant check from acpi_battery_notify()
* acpi-button:
ACPI: button: Tweak acpi_button_remove()
ACPI: button: Tweak system wakeup handling
ACPI: button: Call device_init_wakeup() earlier during probe
* acpi-driver:
ACPI: driver: Drop driver_data pointer clearing from two drivers
ACPI: video: Clear driver_data pointer on remove
Merge an ACPI power management update and an ACPI CPPC library update
for 7.0-rc1:
- Add an unused power resource handling quirk for THUNDEROBOT ZERO (Zhai
Can)
- Fix remaining for_each_possible_cpu() in the ACPI CPPC library to use
online CPUs (Sean V Kelley)
* acpi-pm:
ACPI: PM: Add unused power resource quirk for THUNDEROBOT ZERO
* acpi-cppc:
ACPI: CPPC: Fix remaining for_each_possible_cpu() to use online CPUs
Merge additional power capping and cpuidle updates for 7.0-rc1:
- Fix the handling of package-scope MSRs in the intel_rapl power
capping driver when called from the PMU subsystem and make it add all
package CPUs to the PMU cpumask to allow tools to read RAPL events
from any CPU in the package (Kuppuswamy Sathyanarayanan)
- Rework the invalid version check in the intel_rapl_tpmi power capping
driver to account for the fact that on partitioned systems, multiple
TPMI instances may exist per package, but RAPL registers are only
valid on one instance (Kuppuswamy Satharayananyan)
- Describe the new intel_idle.table command line option in the
admin-guide intel_idle documentation (Artem Bityutskiy)
- Fix a crash in the ladder cpuidle governor on systems with only one
(polling) idle state available by making the cpuidle core bypass the
governor in those cases and adjust the other existing governors to
that change (Aboorva Devarajan, Christian Loehle)
* pm-powercap:
powercap: intel_rapl_tpmi: Remove FW_BUG from invalid version check
powercap: intel_rapl: Expose all package CPUs in PMU cpumask
powercap: intel_rapl: Remove incorrect CPU check in PMU context
* pm-cpuidle:
cpuidle: menu: Remove single state handling
cpuidle: teo: Remove single state handling
cpuidle: haltpoll: Remove single state handling
cpuidle: Skip governor when only one idle state is available
Documentation: PM: Document intel_idle.table command line option
It is not necessary to clear the driver_data pointer in the ACPI
companion device object on driver remove in the EC and SMBUS HC
ACPI drivers because that pointer is not used there any more after
recent changes.
Drop the unnecessary statements.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/6242843.lOV4Wx5bFT@rafael.j.wysocki
After commit 02c057ddef ("ACPI: video: Convert the driver to a
platform one") the driver_data pointer in the ACPI companion device
object is not cleared automatically on driver remove any more, so
clear it directly in acpi_video_bus_remove().
Fixes: 02c057ddef ("ACPI: video: Convert the driver to a platform one")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/12840288.O9o76ZdvQC@rafael.j.wysocki
Modify acpi_button_remove() to get the ACPI device object pointer
from button->adev instead of retrieving it with the help of the
ACPI_COMPANION() macro to reduce overhead slightly.
While at it, rename the struct acpi_device pointer variable in
acpi_button_remove() to adev.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/13948466.uLZWGnKmhe@rafael.j.wysocki
Modify struct acpi_button to hold a struct device pointer instead
of a struct platform_device one to avoid unnecessary pointer
dereferences and use that pointer consistently for system wakeup
initialization, handling and cleanup.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/1948258.tdWV9SEqCh@rafael.j.wysocki
In acpi_battery_remove(), "battery" cannot be NULL because it is the
driver data of the platform device passed to that function and it has
been set by acpi_battery_probe(), so drop the redundant check of it
against NULL.
Moreover, getting the ACPI device pointer from battery->device is
slightly less overhead than using the ACPI_COMPANION() macro on the
platform device to retrieve it, so do that and drop the check of that
pointer against NULL which is also redundant.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/12836976.O9o76ZdvQC@rafael.j.wysocki
Calling device_init_wakeup() after installing a notify handler in which
wakeup events are signaled may cause a wakeup event to be missed if the
device is probed right before a system suspend.
To avoid this, move the device_init_wakeup() call in acpi_button_probe()
before the notify handler installation and add a corresponding cleanup
to the error path.
Also carry out wakeup cleanup for the button in acpi_button_remove()
because after that point the notify handler will not run for it and
wakeup events coming from it will not be signaled.
Fixes: 0d51157dfa ("ACPI: button: Eliminate the driver notify callback")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/12854922.O9o76ZdvQC@rafael.j.wysocki
Merge ACPI APEI support updates for 6.20-rc1/7.0-rc1:
- Make read-only array non_mmio_desc[] static const (Colin Ian King)
- Prevent the APEI GHES support code on ARM from accessing memory out
of bounds or going past the ARM processor CPER record buffer (Mauro
Carvalho Chehab)
- Prevent cper_print_fw_err() from dumping the entire memory on systems
with defective firmware (Mauro Carvalho Chehab)
- Improve ghes_notify_nmi() status check to avoid unnecessary overhead
in the NMI handler by carrying out all of the requisite preparations
and the NMI registration time (Tony Luck)
- Refactor the GHES driver by extracting common functionality into
reusable helper functions to reduce code duplication and improve
the ghes_notify_sea() status check in analogy with the previous
ghes_notify_nmi() status check improvement (Shuai Xue)
- Make ELOG and GHES log and trace consistently and support the CPER
CXL protocol analogously (Fabio De Francesco)
- Disable KASAN instrumentation in the APEI GHES driver when compile
testing with clang < 18 (Nathan Chancellor)
- Let ghes_edac be the preferred driver to load on __ZX__ and _BYO_
systems by extending the platform detection list in the APEI GHES
driver (Tony W Wang-oc)
* acpi-apei:
ACPI: APEI: GHES: Add ghes_edac support for __ZX__ and _BYO_ systems
ACPI: APEI: GHES: Disable KASAN instrumentation when compile testing with clang < 18
ACPI: extlog: Trace CPER CXL Protocol Error Section
ACPI: APEI: GHES: Add helper to copy CPER CXL protocol error info to work struct
ACPI: APEI: GHES: Add helper for CPER CXL protocol errors checks
ACPI: extlog: Trace CPER PCI Express Error Section
ACPI: extlog: Trace CPER Non-standard Section Body
ACPI: APEI: GHES: Improve ghes_notify_sea() status check
ACPI: APEI: GHES: Extract helper functions for error status handling
ACPI: APEI: GHES: Improve ghes_notify_nmi() status check
EFI/CPER: don't dump the entire memory region
APEI/GHES: ensure that won't go past CPER allocated record
EFI/CPER: don't go past the ARM processor CPER record buffer
APEI/GHES: ARM processor Error: don't go past allocated memory
ACPI: APEI: EINJ: make read-only array non_mmio_desc static const
Merge ACPI processor driver changes for 6.20-rc1/7.0-rc1:
- Rework the ACPI idle driver initialization to register it directly
from the common initialization code instead of doing that from a
CPU hotplug "online" callback and clean it up (Huisong Li, Rafael
Wysocki)
- Fix a possible NULL pointer dereference in
acpi_processor_errata_piix4() (Tuo Li)
* acpi-processor:
ACPI: processor: idle: Rework the handling of acpi_processor_ffh_lpi_probe()
ACPI: processor: idle: Convert acpi_processor_setup_cpuidle_dev() to void
ACPI: processor: idle: Convert acpi_processor_setup_cpuidle_states() to void
ACPI: processor: idle: Add debug log for states with invalid entry methods
ACPI: processor: Fix NULL-pointer dereference in acpi_processor_errata_piix4()
ACPI: processor: Do not expose global variable acpi_idle_driver
ACPI: processor: idle: Rearrange declarations in header file
ACPI: processor: idle: Redefine two functions as void
ACPI: processor: Update cpuidle driver check in __acpi_processor_start()
ACPI: processor: Remove unused empty stubs of some functions
ACPI: processor: idle: Optimize ACPI idle driver registration
Merge ACPI battery driver changes and a generic ACPI watchdog device
driver change for 6.20-rc1/7.0-rc1:
- Convert the generic ACPI battery driver to a proper platform driver
using struct platform_driver for device binding (Rafael Wysocki)
- Fix incorrect charging status when current is zero in the generic
ACPI battery driver (Ata İlhan Köktürk)
- Use LIST_HEAD() for initializing a stack-allocated list in the
generic ACPI watchdog device driver (Can Peng)
* acpi-battery:
ACPI: battery: fix incorrect charging status when current is zero
ACPI: battery: Convert the driver to a platform one
ACPI: battery: Reduce code duplication related to cleanup
ACPI: battery: Adjust event notification routine
* acpi-misc:
ACPI: acpi_watchdog: use LIST_HEAD for stack-allocated list
Merge updates of drivers handling devices defined in the ACPI
specification and other generic devices with ACPI interfaces for
6.20-rc1/7.0-rc1:
- Add a piece of documentation explaining why binding drivers directly
to ACPI device objects is not a good idea in general and why it is
desirable to convert drivers doing so into proper platform drivers
that use struct platform_driver for device binding (Rafael Wysocki)
- Convert multiple "core ACPI" drivers, including the NFIT ACPI device
driver, the generic ACPI button drivers, the generic ACPI thermal
zone driver, the ACPI hardware event device (HED) driver, the ACPI EC
driver, the ACPI SMBUS HC driver, the ACPI Smart Battery Subsystem
(SBS) driver, and the ACPI backlight (video) driver to proper platform
drivers that use struct platform_driver for device binding (Rafael
Wysocki)
- Use acpi_get_local_u64_address() in the ACPI backlight (video) driver
to evaluate _ADR instead of evaluating that object directly (Andy
Shevchenko)
* acpi-driver: (25 commits)
ACPI: video: simplify code with acpi_get_local_u64_address()
ACPI: scan: Clean up after recent changes
ACPI: scan: Use acpi_setup_gpe_for_wake() for buttons
ACPI: PM: Let acpi_dev_pm_attach() skip devices without ACPI PM
ACPI: Documentation: driver-api: Disapprove of using ACPI drivers
ACPI: video: Convert the driver to a platform one
ACPI: video: Adjust event notification routine
ACPI: scan: Register platform devices for backlight device objects
ACPI: SBS: Convert the driver to a platform one
ACPI: SMBUS HC: Convert the driver to a platform one
ACPI: EC: Convert the driver to a platform one
ACPI: EC: Register a platform device for ECDT EC
ACPI: HED: Convert the driver to a platform one
ACPI: thermal: Rework system suspend and resume handling
ACPI: thermal: Convert the driver to a platform one
ACPI: thermal: Adjust event notification routine
ACPI: scan: Register platform devices for thermal zones
ACPI: scan: Do not mark button ACPI devices as wakeup-capable
ACPI: scan: Do not bind ACPI drivers to fixed event buttons
ACPI: tiny-power-button: Convert the driver to a platform one
...
Merge ACPI support updates related to _OSC evaluation, the handling of
"system resource" device objects, and ACPI-based device enumeration
for 6.20-rc1/7.0-rc1:
- Fix handling of _OSC errors in acpi_run_osc() to avoid failures on
systems where _OSC error bits are set even though the _OSC return
buffer contains acknowledged feature bits (Rafael Wysocki)
- Clean up and rearrange \_SB._OSC handling for general platform
features and USB4 features to avoid code duplication and unnecessary
memory management overhead (Rafael Wysocki)
- Make the ACPI core device enumeration code handle PNP0C01 and PNP0C02
("system resource") device objects directly instead of letting the
legacy PNP system driver handle them to avoid device enumeration
issues on systems where PNP0C02 is present in the _CID list under
ACPI device objects with a _HID matching a proper device driver in
Linux (Rafael Wysocki)
- Drop workarounds for the known device enumeration issues related to
_CID lists containing PNP0C02 (Rafael Wysocki)
- Drop outdated comment regarding removed function in the ACPI-based
device enumeration code (Julia Lawall)
- Make PRP0001 device matching work as expected for ACPI device objects
using it as a _HID for board development and similar purposes (Kartik
Rajput)
- Use async schedule function in acpi_scan_clear_dep_fn() to avoid
races with user space initialization on some systems (Yicong Yang)
* acpi-bus:
ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()
ACPI: bus: Align acpi_device_get_match_data() with driver match order
ACPI: scan: Drop outdated comment regarding removed function
ACPI: scan: Use resource_type() for resource type checking
ACPI: bus: Fix typo under sizeof() in acpi_run_osc()
ACPI: bus: Adjust acpi_osc_handshake() parameter list
ACPI: bus: Rework the handling of \_SB._OSC USB4 features
ACPI: bus: Adjust feature mask creation for \_SB._OSC
ACPI: bus: Rework the handling of \_SB._OSC platform features
ACPI: bus: Rename label and use ACPI_FREE() in acpi_run_osc()
ACPI: bus: Split _OSC error processing out of acpi_run_osc()
ACPI: bus: Split _OSC evaluation out of acpi_run_osc()
ACPI: bus: Rework printing debug messages on _OSC errors
ACPI: bus: Fix handling of _OSC errors in acpi_run_osc()
ACPI: PNP: Drop acpi_nonpnp_device_ids[]
platform/x86/intel/vbtn: Stop creating a platform device
platform/x86/intel/hid: Stop creating a platform device
ACPI: PNP: Drop PNP0C01 and PNP0C02 from acpi_pnp_device_ids[]
Merge ACPI power management updates, ACPI sysfs interface updates, an
ACPI support update related to PCI, and an ACPI device resources
management update for 6.20-rc1/7.0-rc1:
- Rework ACPI PM notification setup for PCI root buses and modify the
ACPI PM setup for devices to register wakeup source objects under
physical (that is, PCI, platform, etc.) devices instead of doing that
under their ACPI companions (Rafael Wysocki)
- Adjust debug messages regarding postponed ACPI PM printed during
system resume to be more accurate (Rafael Wysocki)
- Remove dead code from lps0_device_attach() (Gergo Koteles)
- Start to invoke Microsoft Function 9 (Turn On Display) of the Low-
Power S0 Idle (LPS0) _DSM in the suspend-to-idle resume flow on
systems with ACPI LPS0 support to address a functional issue on
Lenovo Yoga Slim 7i Aura (15ILL9), where system fans and keyboard
backlights fail to resume after suspend (Jakob Riemenschneider)
- Add sysfs attribute cid for exposing _CID lists under ACPI device
objects (Rafael Wysocki)
- Replace sprintf() with sysfs_emit() in all of the core ACPI sysfs
interface code (Sumeet Pawnikar)
- Use acpi_get_local_u64_address() in the code implementing ACPI
support for PCI to evaluate _ADR instead of evaluating that object
directly (Andy Shevchenko)
- Add JWIPC JVC9100 to irq1_level_low_skip_override[] to unbreak
serial IRQs on that system (Ai Chao)
* acpi-pm:
ACPI: x86: s2idle: Invoke Microsoft _DSM Function 9 (Turn On Display)
ACPI: PM: Adjust messages regarding postponed ACPI PM
ACPI: x86: s2idle: Remove dead code in lps0_device_attach()
ACPI: PM: Register wakeup sources under physical devices
ACPI: PCI: PM: Rework root bus notification setup
* acpi-sysfs:
ACPI: sysfs: Replace sprintf() with sysfs_emit()
ACPI: sysfs: Add device cid attribute for exposing _CID lists
* acpi-pci:
ACPI: PCI: simplify code with acpi_get_local_u64_address()
* acpi-resource:
ACPI: resource: Add JWIPC JVC9100 to irq1_level_low_skip_override[]
Merge ARM-related irq subsystem changes based on the recent ACPICA
updates for 6.20-rc1/7.0-rc1:
- Add support for GICv5 ACPI probing on ARM which is based on the
GICv5 MADT structures and ARM IORT IWB node definitions recently
added to ACPICA (Lorenzo Pieralisi)
* acpi-irq:
irqchip/gic-v5: Add ACPI IWB probing
irqchip/gic-v5: Add ACPI ITS probing
irqchip/gic-v5: Add ACPI IRS probing
irqchip/gic-v5: Split IRS probing into OF and generic portions
PCI/MSI: Make the pci_msi_map_rid_ctlr_node() interface firmware agnostic
irqdomain: Add parent field to struct irqchip_fwid
Merge ACPICA changes for 6.20-rc1/7.0-rc1:
- Update the ACPICA code in the kernel to upstream version 20251212
which includes the following changes:
* Add support for new ACPI table DTPR (Michal Camacho Romero)
* Release objects with acpi_ut_delete_object_desc() (Zilin Guan)
* Add UUIDs for Microsoft fan extensions and UUIDs associated with
TPM 2.0 devices (Armin Wolf)
* Fix NULL pointer dereference in acpi_ev_address_space_dispatch()
(Alexey Simakov)
* Add KEYP ACPI table definition (Dave Jiang)
* Add support for the Microsoft display mux _OSI string (Armin Wolf)
* Add definitions for the IOVT ACPI table (Xianglai Li)
* Abort AML bytecode execution on AML_FATAL_OP (Armin Wolf)
* Include all fields in subtable type1 for PPTT (Ben Horgan)
* Add GICv5 MADT structures and Arm IORT IWB node definitions (Jose
Marinho)
* Update Parameter Block structure for RAS2 and add a new flag in
Memory Affinity Structure for SRAT (Pawel Chmielewski)
* Add _VDM (Voltage Domain) object (Pawel Chmielewski)
* acpica: (26 commits)
ACPICA: Refactor for TPR Base/Limit registers bitmasks
ACPICA: Replace TPRn Base and Limit registers
ACPICA: Logfile: Changes for version 20251212
ACPICA: Align comments in TPRn-related structures
ACPICA: Cleanup comments and DTPR Table handle functions
ACPICA: Verify DTPR and TPR Instance buffer pointers
ACPICA: Fix Segmentation Fault error related to DTPR
ACPICA: Create auxiliary ACPI_TPR_AUX_SR structure for iASL compiler
ACPICA: ACPI 6.6: Add _VDM (Voltage Domain) object
ACPICA: actbl3.h: ACPI 6.6: SRAT: New flag in Memory Affinity Structure
ACPICA: actbl2.h: ACPI 6.6: RAS2: Update Parameter Block structure
ACPICA: Add Arm IORT IWB node definitions
ACPICA: Add GICv5 MADT structures
ACPICA: Fix asltests using the Fatal() opcode
ACPICA: ACPI 6.4: PPTT: include all fields in subtable type1
ACPICA: Abort AML bytecode execution when executing AML_FATAL_OP
ACPICA: Define DTPR structure related info tables and data template
ACPICA: Add DTPR table support for the ASL compiler
ACPICA: iASL: Add definitions for the IOVT table
ACPICA: Add support for the Microsoft display mux _OSI string
...
Merge cpupower utility updates for 6.20-rc1/7.0-rc1:
- Fix miscellaneous problems in cpupower (Kaushlendra Kumar):
* idle_monitor: Fix incorrect value logged after stop
* Fix inverted APERF capability check
* Use strcspn() to strip trailing newline
* Reset errno before strtoull()
* Show C0 in idle-info dump
- Improve cpupower installation procedure by making the systemd step
optional and allowing users to disable the installation of systemd's
unit file (João Marcos Costa)
* pm-tools:
cpupower: make systemd unit installation optional
tools/power cpupower: Show C0 in idle-info dump
tools/power cpupower: Reset errno before strtoull()
tools/cpupower: Use strcspn() to strip trailing newline
tools/cpupower: Fix inverted APERF capability check
cpupower: idle_monitor: fix incorrect value logged after stop
Merge power capping updates, OPP (operating performance points) updates
and energy model management documentation updates for 6.20-rc1/7.0-rc1:
- Add PL4 support for Ice Lake to the Intel RAPL power capping
driver (Daniel Tang)
- Replace sprintf() with sysfs_emit() in power capping sysfs show
functions (Sumeet Pawnikar)
- Make dev_pm_opp_get_level() return value match the documentation
after a previous update of the latter (Aleks Todorov)
- Use scoped for each OF child loop in the OPP code (Krzysztof
Kozlowski)
- Fix a bug in an example code snippet and correct typos in the energy
model management documentation (Patrick Little)
* pm-powercap:
powercap: intel_rapl: Add PL4 support for Ice Lake
powercap: Replace sprintf() with sysfs_emit() in sysfs show functions
* pm-opp:
OPP: Return correct value in dev_pm_opp_get_level
OPP: of: Simplify with scoped for each OF child loop
* pm-em:
PM: EM: Documentation: Fix bug in example code snippet
Documentation: Fix typos in energy model documentation
Merge updates related to runtime PM for 6.20-rc1/7.0-rc1:
- Make several drivers discard pm_runtime_put() return value in
preparation for converting that function to a void one (Rafael
Wysocki)
* pm-runtime:
drm: Discard pm_runtime_put() return value
genirq/chip: Change irq_chip_pm_put() return type to void
scsi: ufs: core: Discard pm_runtime_put() return values
platform/chrome: cros_hps_i2c: Discard pm_runtime_put() return value
coresight: Discard pm_runtime_put() return values
hwspinlock: omap: Discard pm_runtime_put() return value
watchdog: rzv2h_wdt: Discard pm_runtime_put() return value
watchdog: rz: Discard pm_runtime_put() return values
media: ccs: Discard pm_runtime_put() return value
drm/imagination: Discard pm_runtime_put() return value
USB: core: Discard pm_runtime_put() return value
Merge updates related to system suspend and hibernation for
6.20-rc1/7.0-rc1:
- Stop flagging the PM runtime workqueue as freezable to avoid system
suspend and resume deadlocks in subsystems that assume asynchronous
runtime PM to work during system-wide PM transitions (Rafael Wysocki)
- Drop redundant NULL pointer checks before acomp_request_free() from
the hibernation code handling image saving (Rafael Wysocki)
- Update wakeup_sources_walk_start() to handle empty lists of wakeup
sources as appropriate (Samuel Wu)
- Make dev_pm_clear_wake_irq() check the power.wakeirq value under
power.lock to avoid race conditions (Gui-Dong Han)
- Avoid bit field races related to power.work_in_progress in the core
device suspend code (Xuewen Yan)
* pm-sleep:
PM: sleep: core: Avoid bit field races related to work_in_progress
PM: sleep: wakeirq: harden dev_pm_clear_wake_irq() against races
PM: wakeup: Handle empty list in wakeup_sources_walk_start()
PM: hibernate: Drop NULL pointer checks before acomp_request_free()
PM: sleep: Do not flag runtime PM workqueue as freezable
Merge cpuidle updates for 6.20-rc1/7.0-rc1:
- Add a command line option to adjust the C-states table in the
intel_idle driver, remove the 'preferred_cstates' module parameter
from it, add C-states validation to it and clean it up (Artem
Bityutskiy)
- Make the menu cpuidle governor always check the time till the closest
timer event when the scheduler tick has been stopped to prevent it
from mistakenly selecting the deepest available idle state (Rafael
Wysocki)
- Update the teo cpuidle governor to avoid making suboptimal decisions
in certain corner cases and generally improve idle state selection
accuracy (Rafael Wysocki)
- Remove an unlikely() annotation on the early-return condition in
menu_select() that leads to branch misprediction 100% of the time
on systems with only 1 idle state enabled, like ARM64 servers (Breno
Leitao)
- Add Christian Loehle to MAINTAINERS as a cpuidle reviewer (Christian
Loehle)
* pm-cpuidle:
cpuidle: governors: teo: Refine intercepts-based idle state lookup
cpuidle: governors: teo: Adjust the classification of wakeup events
cpuidle: governors: teo: Refine tick_intercepts vs total events check
cpuidle: governors: teo: Avoid fake intercepts produced by tick
cpuidle: governors: teo: Avoid selecting states with zero-size bins
cpuidle: governors: menu: Always check timers with tick stopped
MAINTAINERS: Add myself as cpuidle reviewer
cpuidle: menu: Remove incorrect unlikely() annotation
intel_idle: Add C-states validation
intel_idle: Add cmdline option to adjust C-states table
intel_idle: Initialize sysfs after cpuidle driver initialization
intel_idle: Remove the 'preferred_cstates' parameter
intel_idle: Remove unused driver version constant
Merge updates of Intel thermal drivers for 6.20/7.0:
- Add Panther Lake, Wildcat Lake and Nova Lake processor IDs to the
list of supported processors in the intel_tcc_cooling thermal
driver (Srinivas Pandruvada)
- Drop unnecessary explicit driver data clearing on removal from the
intel_pch_thermal driver (Kaushlendra Kumar)
- Add support for "slow" workload type hints to the int340x
processor_thermal driver and enable it on the Panther Lake
platform (Srinivas Pandruvada)
- Use sysfs_emit{_at}() in sysfs show functions in Intel thermal
drivers (Thorsten Blum)
- Update the x86_pkg_temp_thermal driver to handle THERMAL_TEMP_INVALID
that can be passed to it via sysfs as expected (Rafael Wysocki)
- Drop a redundant local variable from the intel_tcc_cooling thermal
driver and fix a kerneldoc comment typo in the TCC library (Sumeet
Pawnikar)
* thermal-intel:
drivers: thermal: intel: tcc_cooling: Drop redundant local variable
thermal: intel: x86_pkg_temp_thermal: Handle invalid temperature
thermal: intel: Use sysfs_emit() in a sysfs show function
thermal: intel: fix typo "nagative" in comment for cpu argument
thermal: intel: int340x: Use sysfs_emit{_at}() in sysfs show functions
thermal: intel: selftests: workload_hint: Support slow workload hints
thermal: int340x: processor_thermal: Enable slow workload type hints
thermal: intel: intel_pch_thermal: Drop explicit driver data clearing
thermal: intel: intel_tcc_cooling: Add CPU models in the support list
The acpi_power_meter driver's .notify() callback function,
acpi_power_meter_notify(), calls hwmon_device_unregister() under a lock
that is also acquired by callbacks in sysfs attributes of the device
being unregistered which is prone to deadlocks between sysfs access and
device removal.
Address this by moving the hwmon device removal in
acpi_power_meter_notify() outside the lock in question, but notice
that doing it alone is not sufficient because two concurrent
METER_NOTIFY_CONFIG notifications may be attempting to remove the
same device at the same time. To prevent that from happening, add a
new lock serializing the execution of the switch () statement in
acpi_power_meter_notify(). For simplicity, it is a static mutex
which should not be a problem from the performance perspective.
The new lock also allows the hwmon_device_register_with_info()
in acpi_power_meter_notify() to be called outside the inner lock
because it prevents the other notifications handled by that function
from manipulating the "resource" object while the hwmon device based
on it is being registered. The sending of ACPI netlink messages from
acpi_power_meter_notify() is serialized by the new lock too which
generally helps to ensure that the order of handling firmware
notifications is the same as the order of sending netlink messages
related to them.
In addition, notice that hwmon_device_register_with_info() may fail
in which case resource->hwmon_dev will become an error pointer,
so add checks to avoid attempting to unregister the hwmon device
pointer to by it in that case to acpi_power_meter_notify() and
acpi_power_meter_remove().
Fixes: 16746ce8ad ("hwmon: (acpi_power_meter) Replace the deprecated hwmon_device_register")
Closes: https://lore.kernel.org/linux-hwmon/CAK8fFZ58fidGUCHi5WFX0uoTPzveUUDzT=k=AAm4yWo3bAuCFg@mail.gmail.com/
Reported-by: Jaroslav Pulchart <jaroslav.pulchart@gooddata.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
There are cases in which decisions made by the teo governor are
arguably overly conservative.
For instance, suppose that there are 4 idle states and the values of
the intercepts metric for the first 3 of them are 400, 250, and 251,
respectively. If the total sum computed in teo_update() is 1000, the
governor will select idle state 1 (provided that all idle states are
enabled and the scheduler tick has not been stopped) although arguably
idle state 0 would be a better choice because the likelihood of getting
an idle duration below the target residency of idle state 1 is greater
than the likelihood of getting an idle duration between the target
residency of idle state 1 and the target residency of idle state 2.
To address this, refine the candidate idle state lookup based on
intercepts to start at the state with the maximum intercepts metric,
below the deepest enabled one, to avoid the cases in which the search
may stop before reaching that state.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
[ rjw: Fixed typo "intercetps" in new comments (3 places) ]
Link: https://patch.msgid.link/2417298.ElGaqSPkdT@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
If differences between target residency values of adjacent idle states
of a given CPU are relatively large, the corresponding idle state bins
used by the teo governors are large either and the rule by which hits
are distinguished from intercepts is inaccurate.
Namely, by that rule, a wakeup event is classified as a hit if the
sleep length (the time till the closest timer other than the tick)
and the measured idle duration, adjusted for the entered idle state
exit latency, fall into the same idle state bin. However, if that bin
is large enough, the actual difference between the sleep length and
the measured idle duration may be significant. It may in fact be
significantly greater than the analogous difference for an event where
the sleep length and the measured idle duration fall into different
bins.
For this reason, amend the rule in question with a check that will only
allow a wakeup event to be counted as a hit if the sleep length is less
than the "raw" measured idle duration (which means that the wakeup
appears to have occurred after the anticipated timer event). Otherwise,
the event will be counted as an intercept.
Also update the documentation part explaining the difference between
"hits" and "intercepts" to take the above change into account.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
Link: https://patch.msgid.link/5093379.31r3eYUQgx@rafael.j.wysocki
Pull thermal control updates for 6.20/7.0 from Daniel Lezcano:
"- Fix CFLAGS and LDFLAGS in the pkg-config template fir the libthermal
(Romain Gantois)
- Support multiple temp to raw conversion functions for the Mediatek
LVTS thermal driver and add the MT8196 and MT6991 support (Laura
Nao)
- Add support for the Mediatek LVTS driver for MT7987 (Frank
Wunderlich)
- Use the existing HZ_PER_MHZ macro on STM32 (Andy Shevchenko)
- Use the existing clamp() macro in BCM2835 (Thorsten Blum)
- Make the reset line optional in order to support new Renesas Soc
where it is not available. Add the RZ/T2H and RZ/N2H suppport
(Cosmin Tanislav)"
* tag 'thermal-v7.0' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/thermal/linux:
thermal: renesas: rzg3e: add support for RZ/T2H and RZ/N2H
dt-bindings: thermal: r9a09g047-tsu: document RZ/T2H and RZ/N2H
thermal: renesas: rzg3e: make calibration value retrieval per-chip
thermal: renesas: rzg3e: make min and max temperature per-chip
thermal: renesas: rzg3e: make reset optional
dt-bindings: thermal: r9a09g047-tsu: Document RZ/V2N TSU
thermal/drivers/broadcom: Use clamp to simplify bcm2835_thermal_temp2adc
thermal/drivers/stm32: Use predefined HZ_PER_MHZ instead of a custom one
thermal/drivers/mediatek/lvts_thermal: Add mt7987 support
dt-bindings: thermal: mediatek: Add LVTS thermal controller definition for MT7987
dt-bindings: nvmem: mediatek: efuse: Add support for MT8196
thermal/drivers/mediatek/lvts_thermal: Add MT8196 support
thermal/drivers/mediatek/lvts: Support MSR offset for 16-bit calibration data
thermal/drivers/mediatek/lvts: Add support for ATP mode
thermal/drivers/mediatek/lvts: Add lvts_temp_to_raw variant
thermal/drivers/mediatek/lvts: Add platform ops to support alternative conversion logic
thermal/drivers/mediatek/lvts: Make number of calibration offsets configurable
dt-bindings: thermal: mediatek: Add LVTS thermal controller support for MT8196
tools: lib: thermal: Correct CFLAGS and LDFLAGS in pkg-config template
Since acomp_request_free() checks its argument against NULL, the NULL
pointer checks before calling it added by commit ("7966cf0ebe32 PM:
hibernate: Fix crash when freeing invalid crypto compressor") are
redundant, so drop them.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/6233709.lOV4Wx5bFT@rafael.j.wysocki
In a few places in the Classmate laptop driver, code using the accel
object may run before that object's address is stored in the driver
data of the input device using it.
For example, cmpc_accel_sensitivity_store_v4() is the "show" method
of cmpc_accel_sensitivity_attr_v4 which is added in cmpc_accel_add_v4(),
before calling dev_set_drvdata() for inputdev->dev. If the sysfs
attribute is accessed prematurely, the dev_get_drvdata(&inputdev->dev)
call in in cmpc_accel_sensitivity_store_v4() returns NULL which
leads to a NULL pointer dereference going forward.
Moreover, sysfs attributes using the input device are added before
initializing that device by cmpc_add_acpi_notify_device() and if one
of them is accessed before running that function, a NULL pointer
dereference will occur.
For example, cmpc_accel_sensitivity_attr_v4 is added before calling
cmpc_add_acpi_notify_device() and if it is read prematurely, the
dev_get_drvdata(&acpi->dev) call in cmpc_accel_sensitivity_show_v4()
returns NULL which leads to a NULL pointer dereference going forward.
Fix this by adding NULL pointer checks in all of the relevant places.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/12825381.O9o76ZdvQC@rafael.j.wysocki
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Pull OPP updates for 7.0 from Viresh Kumar:
"- Return correct value in dev_pm_opp_get_level (Aleks Todorov).
- Use scoped for each OF child loop (Krzysztof Kozlowski)."
* tag 'opp-updates-7.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
OPP: Return correct value in dev_pm_opp_get_level
OPP: of: Simplify with scoped for each OF child loop
Pull CPUFreq Arm updates for 7.0 from Viresh Kumar:
"- Update cpufreq-dt-platdev list for tegra, qcom, TI (Aaron Kling,
Dhruva Gole, and Konrad Dybcio).
- Minor improvements to the cpufreq / cpumask rust implementation
(Alexandre Courbot, Alice Ryhl, Tamir Duberstein, and Yilin Chen).
- Add support for AM62L3 SoC to ti-cpufreq driver (Dhruva Gole).
- Update FIE arch_freq_scale in ticks for non-PCC regs (Jie Zhan).
- Other minor cleanups / improvements (Felix Gu, Juan Martinez, Luca
Weiss, and Sergey Shtylyov)."
* tag 'cpufreq-arm-updates-7.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
cpufreq: scmi: Fix device_node reference leak in scmi_cpu_domain_id()
cpufreq: ti-cpufreq: add support for AM62L3 SoC
cpufreq: dt-platdev: Add ti,am62l3 to blocklist
cpufreq/amd-pstate: Add comment explaining nominal_perf usage for performance policy
cpufreq: scmi: correct SCMI explanation
cpufreq: dt-platdev: Block the driver from probing on more QC platforms
rust: cpumask: rename methods of Cpumask for clarity and consistency
cpufreq: CPPC: Update FIE arch_freq_scale in ticks for non-PCC regs
cpufreq: CPPC: Factor out cppc_fie_kworker_init()
ACPI: CPPC: Factor out and export per-cpu cppc_perf_ctrs_in_pcc_cpu()
rust: cpufreq: replace `kernel::c_str!` with C-Strings
cpufreq: Add Tegra186 and Tegra194 to cpufreq-dt-platdev blocklist
dt-bindings: cpufreq: qcom-hw: document Milos CPUFREQ Hardware
rust: cpufreq: add __rust_helper to helpers
rust: cpufreq: always inline functions using build_assert with arguments
Pull a CPUFreq driver fix for 6.19 from Viresh Kumar:
- Add sentinel to qcom_cpufreq_ipq806x_match_list (Pei Xiao).
* tag 'cpufreq-arm-fixes-6.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
cpufreq: qcom-nvmem: add sentinel to qcom_cpufreq_ipq806x_match_list
toshiba_haps_add() leaks the haps object allocated by it if it returns
an error after allocating that object successfully.
toshiba_haps_remove() does not free the object pointed to by
toshiba_haps before clearing that pointer, so it becomes unreachable
allocated memory.
Address these memory leaks by using devm_kzalloc() for allocating
the memory in question.
Fixes: 23d0ba0c90 ("platform/x86: Toshiba HDD Active Protection Sensor")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After commit be0a3600aa ("thermal: sysfs: Rework the handling of trip
point updates"), THERMAL_TEMP_INVALID can be passed to sys_set_trip_temp()
and it is treated as a regular temperature value there, so the sysfs
write fails even though it is expected to succeed and disable the given
trip point.
Address this by making sys_set_trip_temp() clear its temp variable when
it is equal to THERMAL_TEMP_INVALID.
Fixes: be0a3600aa ("thermal: sysfs: Rework the handling of trip point updates")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/2815400.mvXUDI8C0e@rafael.j.wysocki
Use 2/3 as the proportion coefficient in the check comparing
cpu_data->tick_intercepts with cpu_data->total because it is close
enough to the current one (5/8) and it allows of more straightforward
interpretation (on average, intercepts within the tick period length
are twice as frequent as other events).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
Link: https://patch.msgid.link/10793374.nUPlyArG6x@rafael.j.wysocki
Tick wakeups can lead to fake intercepts that may skew idle state
selection towards shallow states, so it is better to avoid counting
them as intercepts.
For this purpose, add a check causing teo_update() to only count
tick wakeups as intercepts if intercepts within the tick period
range are at least twice as frequent as any other events.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
Link: https://patch.msgid.link/3404606.44csPzL39Z@rafael.j.wysocki
If the last two enabled idle states have the same target residency which
is at least equal to TICK_NSEC, teo may select the next-to-last one even
though the size of that state's bin is 0, which is confusing.
Prevent that from happening by adding a target residency check to the
relevant code path.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
[ rjw: Fixed a typo in the changelog ]
Link: https://patch.msgid.link/3033265.e9J7NaK4W3@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After commit 5484e31bbb ("cpuidle: menu: Skip tick_nohz_get_sleep_length()
call in some cases"), if the return value of get_typical_interval()
multiplied by NSEC_PER_USEC is not greater than RESIDENCY_THRESHOLD_NS,
the menu governor will skip computing the time till the closest timer.
If that happens when the tick has been stopped already, the selected
idle state may be too deep due to the subsequent check comparing
predicted_ns with TICK_NSEC and causing its value to be replaced with
the expected time till the closest timer, which is KTIME_MAX in that
case. That will cause the deepest enabled idle state to be selected,
but the time till the closest timer very well may be shorter than the
target residency of that state, in which case a shallower state should
be used.
Address this by making menu_select() always compute the time till the
closest timer when the tick has been stopped.
Also move the predicted_ns check mentioned above into the branch in
which the time till the closest timer is determined because it only
needs to be done in that case.
Fixes: 5484e31bbb ("cpuidle: menu: Skip tick_nohz_get_sleep_length() call in some cases")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
Link: https://patch.msgid.link/5959091.DvuYhMxLoT@rafael.j.wysocki
Pull one more cpuidle utility update for 6.20 from Shuah Khan:
"Improve the installation procedure by making this systemd step optional
enabling users to disable installation of systemd's unit file."
* tag 'linux-cpupower-6.20-update-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux:
cpupower: make systemd unit installation optional
The debug messages added by commit f7599be2bb ("ACPI: PM: postpone
bringing devices to D0 unless we need them") in acpi_subsys_resume_early()
and acpi_subsys_resume() are not quite accurate because what is postponed
is not just a transition to D0, but also an adjustment of the device's
wakeup setting (which may involve disabling a GPE among other things).
Moreover, these messages don't even mention ACPI.
Rephrase them and adjust the style to match other messages in device_pm.c.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/5969819.DvuYhMxLoT@rafael.j.wysocki
Printing error messages on pm_runtime_put() returning negative values
is not particularly useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example.
Accordingly, update rkisp1_vb2_stop_streaming() to simply discard the
return value of pm_runtime_put().
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patch.msgid.link/2356323.iZASKD2KPV@rafael.j.wysocki
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Failing device probe due to pm_runtime_put() returning an error is not
particularly useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example. It also happens when the kernel is
configured with CONFIG_PM unset.
Accordingly, update rzt2h_wdt_wdtdcr_init() to simply discard the return
value of pm_runtime_put() and return success to the caller after
invoking that function.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Failing a watchdog stop due to pm_runtime_put() returning a negative
value is not particularly useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example. It also happens when the kernel is
configured with CONFIG_PM unset.
Accordingly, update rzg2l_wdt_stop() and rzv2h_wdt_stop() to simply
discard the return value of pm_runtime_put().
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
Multiple DRM drivers use the pm_runtime_put() return value for printing
debug or even error messages and all of those messages are at least
somewhat misleading.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example. It also happens when the kernel
has been configured with CONFIG_PM unset.
For this reason, modify all of those drivers to simply discard the
pm_runtime_put() return value which is what they should be doing.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patch.msgid.link/2256082.irdbgypaU6@rafael.j.wysocki
The irq_chip_pm_put() return value is only used in __irq_do_set_handler()
to trigger a WARN_ON() if it is negative, but doing so is not useful
because irq_chip_pm_put() simply passes the pm_runtime_put() return value
to its callers.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example.
For this reason, modify irq_chip_pm_put() to discard the pm_runtime_put()
return value, change its return type to void, and drop the WARN_ON()
around the irq_chip_pm_put() invocation from __irq_do_set_handler().
Also update the irq_chip_pm_put() kerneldoc comment to be more accurate.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/5075294.31r3eYUQgx@rafael.j.wysocki
Merge fixes related to the energy model management for 6.19-rc6:
- Fix a memory leak in em_create_pd() error path (Malaya Kumar Rout)
- Fix stale description of the cost field in struct em_perf_state to
reflect the current code (Yaxiong Tian)
- Fix and revamp the energy model YNL specification added recently
along with the energy model netlink interface (Changwoo Min)
* pm-em:
PM: EM: Add dump to get-perf-domains in the EM YNL spec
PM: EM: Change cpus' type from string to u64 array in the EM YNL spec
PM: EM: Rename em.yaml to dev-energymodel.yaml
PM: EM: Fix yamllint warnings in the EM YNL spec
PM: EM: Fix memory leak in em_create_pd() error path
PM: EM: Fix incorrect description of the cost field in struct em_perf_state
After starting to use platform devices for representing buttons
enumerated via ACPI, acpi_mark_gpe_for_wake() is insufficient for
preparing their GPEs to wake up the system from sleep because it
does not change the "dispatch type" of the given GPE to
ACPI_GPE_DISPATCH_NOTIFY. Subsequently, this causes acpi_enable_gpe()
in __acpi_device_wakeup_enable() to fail and system suspend transitions
to be aborted.
Address this by updating acpi_wakeup_gpe_init() to use
acpi_setup_gpe_for_wake() for buttons like for any other devices.
This allows acpi_setup_gpe_for_wake() to be simplified further because
buttons are not a special case in it any more, so do that as well.
Fixes: 52d8640196 ("ACPI: button: Convert the driver to a platform one")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Xi Pardee <xi.pardee@linux.intel.com>
Link: https://patch.msgid.link/2259694.irdbgypaU6@rafael.j.wysocki
It is pointless to attach the generic ACPI PM domain to devices whose
ACPI companions don't support ACPI power management and don't have a
wakeup GPE, so update acpi_dev_pm_attach() to skip such devices.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/5050298.GXAFRqVoOG@rafael.j.wysocki
Sadly, there is quite a bit of technical debt related to the
kernel's ACPI support subsystem and one of the most significant
pieces of it is the existence and use of ACPI drivers represented
by struct acpi_driver objects.
Those drivers are bound directly to struct acpi_device objects, also
referred to as "ACPI device nodes", representing device objects in the
ACPI namespace defined as:
A hierarchical tree structure in OS-controlled memory that contains
named objects. These objects may be data objects, control method
objects, bus/device package objects, and so on.
according to the ACPI specification [1].
The above definition implies, although rather indirectly, that the
objects in question don't really represent hardware. They are just
"device package objects" containing some information on the devices
present in the given platform that is known to the platform firmware.
Although the platform firmware can be the only source of information on
some devices, the information provided by it alone may be insufficient
for device enumeration in general. If that is the case, binding a
driver directly to a given ACPI device node clearly doesn't make sense.
If the device in question is enumerated through a hardware interface, it
will be represented by a device object matching that interface, like
a struct pci_dev, and the ACPI device node corresponding to it will be
treated as its "ACPI companions" whose role is to amend the "native"
enumeratiom mechanism.
For the sake of consistency and confusion avoidance, it is better to
treat ACPI device nodes in general as ACPI companions of other device
objects representing hardware. In some cases though it appeared easier
to take a shortcut and use an ACPI driver binding directly to an ACPI
device node. Moreover, there were corner cases in which that was the
only choice, but they all have been addressed now.
In all cases in which an ACPI driver might be used, the ACPI device
node it might bind to is an ACPI companion of another device object
representing a piece of hardware. It is thus better to use a driver
binding to the latter than to use an ACPI driver and leave the other
device object alone, not just because doing so is more consistent and
less confusing, but also because using ACPI drivers may lead to
potential functional deficiencies, like possible ordering issues
related to power management.
Unfortunately, there are quite a few ACPI drivers in use and, as a rule,
they bind to ACPI device nodes that are ACPI companions of platform
devices, so in fact they play the role of platform drivers although in
a kind of convoluted way. An effort has been under way to replace them
with platform drivers, which is relatively straightforward in the vast
majority of cases, but it has not been pursued very aggressively so far,
mostly due to the existence of the corner cases mentioned above.
However, since those corner cases are gone now, it makes sense to spend
more time on driver conversions with the ultimate goal to get rid of
struct acpi_driver and the related code from the kernel.
To that end, add a document explaining why using ACPI drivers is not
a good idea, so it need not be explained from scratch on every attempt
to convert an ACPI driver to a platform one.
Link: https://uefi.org/specs/ACPI/6.6/02_Definition_of_Terms.html#term-ACPI-Namespace [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/2396510.ElGaqSPkdT@rafael.j.wysocki
While binding drivers directly to struct acpi_device objects allows
basic functionality to be provided, at least in the majority of cases,
there are some problems with it, related to general consistency, sysfs
layout, power management operation ordering, and code cleanliness.
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert the ACPI video driver to a platform one.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/1957556.tdWV9SEqCh@rafael.j.wysocki
Adjust acpi_video_bus_notify() to cast its "data" argument to a struct
acpi_video_bus pointer instead of a struct acpi_device one, which allows
the use of acpi_driver_data() to be limited and will facilitate
subsequent changes.
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/2409089.ElGaqSPkdT@rafael.j.wysocki
ACPI device objects associated with backlight interfaces are special
because they are ACPI companions of PCI devices (GPUs), but the
interfaces exposed by them resemble platform device one.
Currently, the ACPI video driver binds to them with the help of a
special "synthetic" device ID regardless of the pairing with the PCI
devices, but since it is generally better to use platform drivers for
handling such interfaces, the plan is to convert that drviver into a
platform one.
However, for this purpose, platform devices corresponding to the
ACPI backlight device objects need to be registered, so update
acpi_bus_attach() to apply the default ACPI enumeration to them
and modify acpi_create_platform_device() to avoid bailing out early
if a "physical" device is already attached to a backlight ACPI device
object.
In addition, update acpi_companion_match() to return a valid struct
acpi_device pointer if the ACPI companion of the given device is a
backlight ACPI device object, which will facilitate driver matching
for platform devices corresponding to those objects.
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/5081593.31r3eYUQgx@rafael.j.wysocki
Commit 32ece31db4 ("ACPI: PM: s2idle: Only retrieve constraints when
needed") attempted to avoid useless evaluation of LPS0 _DSM Function 1
in lps0_device_attach() because pm_debug_messages_on might never be set
(and that is the case on production systems most of the time), but it
turns out that LPS0 _DSM Function 1 is generally problematic on some
platforms and causes suspend issues to occur when pm_debug_messages_on
is set now.
In Linux, LPS0 _DSM Function 1 is only useful for diagnostics and only
in the cases when the system does not reach the deepest platform idle
state during suspend-to-idle for some reason. If such diagnostics is
not necessary, evaluating it is a loss of time, so using it along with
the other pm_debug_messages_on diagnostics is questionable because the
latter is expected to be suitable for collecting debug information even
during production use of system suspend.
For this reason, add a module parameter called check_lps0_constraints
to control whether or not the list of LPS0 constraints will be checked
in acpi_s2idle_prepare_late_lps0() and so whether or not to evaluate
LPS0 _DSM Function 1 (once) in acpi_s2idle_begin_lps0().
Fixes: 32ece31db4 ("ACPI: PM: s2idle: Only retrieve constraints when needed")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/2827214.mvXUDI8C0e@rafael.j.wysocki
Printing error messages on pm_runtime_put() returning negative values
is not particularly useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example.
Accordingly, update mtk_vcodec_enc_pw_off() and mtk_vcodec_dec_pw_off()
to simply discard the return value of pm_runtime_put().
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Commit 32ece31db4 ("ACPI: PM: s2idle: Only retrieve constraints
when needed"), that attempted to avoid useless evaluation of LPS0 _DSM
Function 1 in lps0_device_attach(), forgot to add checks for
lps0_device_handle and sleep_no_lps0 to acpi_s2idle_begin_lps0()
where they should be done before calling lpi_device_get_constraints()
or lpi_device_get_constraints_amd().
Add the missing checks.
Fixes: 32ece31db4 ("ACPI: PM: s2idle: Only retrieve constraints when needed")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/2818730.mvXUDI8C0e@rafael.j.wysocki
Notice that acpi_processor_power_init() and acpi_processor_power_exit()
don't need to return any values because their callers don't check them
anyway, so redefine those functions as void.
While at it, rearrange the code in acpi_processor_power_init() to
reduce the indentation level, get rid of a redundant local variable
in that function, and rephrase a code comment in it.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20251223100914.2407069-5-lihuisong@huawei.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit 7a8c994cbb ("ACPI: processor: idle: Optimize ACPI idle
driver registration") moved the ACPI idle driver registration to
acpi_processor_driver_init() and acpi_processor_power_init() does
not register an idle driver any more.
Accordingly, the cpuidle driver check in __acpi_processor_start() needs
to be updated to avoid calling acpi_processor_power_init() without a
cpuidle driver, in which case the registration of the cpuidle device
in that function would lead to a NULL pointer dereference in
__cpuidle_register_device().
Fixes: 7a8c994cbb ("ACPI: processor: idle: Optimize ACPI idle driver registration")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20251223100914.2407069-4-lihuisong@huawei.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ufshcd driver defines ufshcd_rpm_put() to return an int, but that
return value is never used. It also passes the return value of
pm_runtime_put() to the caller which is not very useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example.
Modify ufshcd_rpm_put() to discard the pm_runtime_put() return value
and change its return type to void.
No intentional functional impact.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Link: https://patch.msgid.link/2781685.BddDVKsqQX@rafael.j.wysocki
Passing pm_runtime_put() return value to the callers is not particularly
useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example. It also happens when the kernel is
configured with CONFIG_PM unset.
Accordingly, update hps_release() to simply discard the return value of
pm_runtime_put() and always return success to the caller.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/2302270.NgBsaNRSFp@rafael.j.wysocki
Failing a debugfs write due to pm_runtime_put() returning a negative
value is not particularly useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example. It also happens when the kernel
has been configured with CONFIG_PM unset, in which case
debug_disable_func() in the coresight driver will always return an
error.
For this reason, update debug_disable_func() to simply discard the
return value of pm_runtime_put(), change its return type to void, and
propagate that change to debug_func_knob_write().
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://patch.msgid.link/2058657.yKVeVyVuyW@rafael.j.wysocki
Failing driver probe due to pm_runtime_put() returning a negative value
is not particularly useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example. It also happens when the kernel
has been configured with CONFIG_PM unset.
Accordingly, update omap_hwspinlock_probe() to simply discard the
return value of pm_runtime_put().
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Andersson <andersson@kernel.org>
Link: https://patch.msgid.link/883243465.0ifERbkFSE@rafael.j.wysocki
Failing device probe due to pm_runtime_put() returning an error is not
particularly useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example. It also happens when the kernel is
configured with CONFIG_PM unset.
Accordingly, update rzt2h_wdt_wdtdcr_init() to simply discard the return
value of pm_runtime_put() and return success to the caller after
invoking that function.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://patch.msgid.link/1867890.VLH7GnMWUR@rafael.j.wysocki
Failing a watchdog stop due to pm_runtime_put() returning a negative
value is not particularly useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example. It also happens when the kernel is
configured with CONFIG_PM unset.
Accordingly, update rzg2l_wdt_stop() and rzv2h_wdt_stop() to simply
discard the return value of pm_runtime_put().
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://patch.msgid.link/3340071.5fSG56mABF@rafael.j.wysocki
Passing the pm_runtime_put() return value to callers is not particularly
useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example. It also happens when the kernel is
configured with CONFIG_PM unset.
Accordingly, update ccs_post_streamoff() to simply discard the return
value of pm_runtime_put() and always return success to the caller.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://patch.msgid.link/22966634.EfDdHjke4D@rafael.j.wysocki
The framer driver defines framer_pm_runtime_put() to return an int,
but that return value is never used. It also passes the return value
of pm_runtime_put() to the caller which is not very useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example.
Modify phy_pm_runtime_put() to discard the pm_runtime_put() return
value and change its return type to void.
No intentional functional impact.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/3027916.e9J7NaK4W3@rafael.j.wysocki
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Passing pm_runtime_put() return value to the callers is not particularly
useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example. It also happens when the kernel is
configured with CONFIG_PM unset.
Accordingly, update at91ether_close() to simply discard the return
value of pm_runtime_put() and always return success to the caller.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://patch.msgid.link/2252292.irdbgypaU6@rafael.j.wysocki
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Printing error messages on pm_runtime_put() returning negative values
is not particularly useful.
Returning an error code from pm_runtime_put() merely means that it has
not queued up a work item to check whether or not the device can be
suspended and there are many perfectly valid situations in which that
can happen, like after writing "on" to the devices' runtime PM "control"
attribute in sysfs for one example.
Accordingly, update am65_cpsw_ethtool_op_begin() and cpsw_ethtool_op_begin()
to simply discard the return value of pm_runtime_put().
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/5042490.GXAFRqVoOG@rafael.j.wysocki
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The Imagination DRM driver defines pvr_power_put() to pass the return
value of pm_runtime_put() to the caller, but then it never uses the
return value of pvr_power_put().
Modify pvr_power_put() to discard the pm_runtime_put() return value and
change its return type to void.
No intentional functional impact.
This will facilitate a planned change of the pm_runtime_put() return
type to void in the future.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Matt Coster <matt.coster@imgtec.com>
Link: https://patch.msgid.link/8642685.T7Z3S40VBb@rafael.j.wysocki
To allow the return type of pm_runtime_put() to be changed to void in the
future, modify usb_autopm_put_interface_async() to discard the return
value of pm_runtime_put().
That value is merely used in a debug comment printed by the function in
question and it is not a particularly useful piece of information
because pm_runtime_put() does not guarantee that the device will be
suspended even if it successfully queues up a work item to check
whether or not the device can be suspended.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/5058509.GXAFRqVoOG@rafael.j.wysocki
Pull a cpupower utility update for Linux 6.20-rc1 from Shuah Khan:
"Fixes to miscellaneous problems in cpupower tool:
- idle_monitor: fix incorrect value logged after stop
- Fix inverted APERF capability check
- Use strcspn() to strip trailing newline
- Reset errno before strtoull()
- Show C0 in idle-info dump"
* tag 'linux-cpupower-6.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux:
tools/power cpupower: Show C0 in idle-info dump
tools/power cpupower: Reset errno before strtoull()
tools/cpupower: Use strcspn() to strip trailing newline
tools/cpupower: Fix inverted APERF capability check
cpupower: idle_monitor: fix incorrect value logged after stop
For the sake of interface cleanliness, it is better to avoid using
ACPICA data types in the parameter lists of helper functions that
don't belong to ACPICA, so adjust the parameter list of recently
introduced acpi_osc_handshake() to take a capabilities buffer pointer
and the size of the buffer (in u32 size units) as parameters directly
instead of a struct acpi_buffer pointer.
This is also somewhat more straightforward on the caller side because
they won't need to create struct acpi_buffer objects themselves to pass
them to the helper function and it guarantees that the size of the
buffer in bytes will always be a multiple of 4 (the size of u32).
Moreover, it addresses a premature cap pointer dereference and
eliminates a sizeof(32) that should have been sizeof(u32) [1].
Fixes: e5322888e6 ("ACPI: bus: Rework the handling of \_SB._OSC platform features")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/linux-acpi/202512242052.W4GhDauV-lkp@intel.com/
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
[ rjw: Fixed typo under sizeof(), used ARRAY_SIZE() in two places ]
Link: https://patch.msgid.link/12833187.O9o76ZdvQC@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
While binding drivers directly to struct acpi_device objects allows
basic functionality to be provided, at least in the majority of cases,
there are some problems with it, related to general consistency, sysfs
layout, power management operation ordering, and code cleanliness.
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert the ACPI smart battery subsystem (SBS)
driver to a platform one.
After this conversion, acpi_smbus_hc_probe() does not need to populate the
driver_data pointer of the SMBUS HC platform device's ACPI companion any
more, so update it accordingly.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/3390477.aeNJFYEL58@rafael.j.wysocki
While binding drivers directly to struct acpi_device objects allows
basic functionality to be provided, at least in the majority of cases,
there are some problems with it, related to general consistency, sysfs
layout, power management operation ordering, and code cleanliness.
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert the ACPI SMBUS HC driver to a platform one.
After this conversion, acpi_ec_probe() does not need to populate the
driver_data pointer of the EC platform device's ACPI companion any
more, so update it accordingly.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/13909645.uLZWGnKmhe@rafael.j.wysocki
While binding drivers directly to struct acpi_device objects allows
basic functionality to be provided, at least in the majority of cases,
there are some problems with it, related to general consistency, sysfs
layout, power management operation ordering, and code cleanliness.
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert the ACPI embedded controller (EC) driver
to a platform one.
After this conversion, acpi_bus_register_early_device() does not need
to attempt to bind an ACPI driver to the struct acpi_device created by
it, so update it accordingly.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[ rjw: Removed excess semicolon ]
Link: https://patch.msgid.link/1946304.tdWV9SEqCh@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Rafael J. Wysocki