MFD child devices sharing parent's ACPI Companion fails to probe as
acpi_companion_match() returns incompatible ACPI Companion handle for
binding with the check for pnp.type.backlight added recently. Remove this
pnp.type.backlight check in acpi_companion_match() to fix the automatic
modprobe issue.
Fixes: 7a7a7ed5f8bdb ("ACPI: scan: Register platform devices for backlight device objects")
Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com>
Link: https://patch.msgid.link/20260318034842.1216536-1-pratap.nirujogi@amd.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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[]
On ARM64 ACPI systems GICv5 IRSes are described in MADT sub-entries.
Add the required plumbing to parse MADT IRS firmware table entries and
probe the IRS components in ACPI.
Augment the irqdomain_ops.translate() for PPI and SPI IRQs in order to
provide support for their ACPI based firmware translation.
Implement an irqchip ACPI based callback to initialize the global GSI
domain upon an MADT IRS detection.
The IRQCHIP_ACPI_DECLARE() entry in the top level GICv5 driver is only used
to trigger the IRS probing (ie the global GSI domain is initialized once on
the first call on multi-IRS systems); IRS probing takes place by calling
acpi_table_parse_madt() in the IRS sub-driver, that probes all IRSes
in sequence.
Add a new ACPI interrupt model so that it can be detected at runtime and
distinguished from previous GIC architecture models.
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Acked-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260115-gicv5-host-acpi-v3-4-c13a9a150388@kernel.org
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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
During pre-production development, drivers may provide both ACPI and OF
match tables while a formal ACPI HID for the device is not yet
allocated. Such devices are enumerated via PRP0001. In this case,
acpi_device_get_match_data() consults only the driver’s ACPI match table
and returns NULL, even though the device was successfully matched via
PRP0001.
This behavior also risks breaking existing PRP0001 setups if a driver
later gains an ACPI HID, as the presence of an ACPI match table changes
the match-data lookup path.
Make acpi_device_get_match_data() use the same precedence as driver
matching by using __acpi_match_device(). Return match data from the
acpi_id or of_id that was actually matched.
Remove now-unused acpi_of_device_get_match_data().
Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://patch.msgid.link/20260114082306.48119-1-kkartik@nvidia.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The sizeof(32) in acpi_run_osc() should be sizeof(u32), so fix it.
Fixes: e5322888e6 ("ACPI: bus: Rework the handling of \_SB._OSC platform features")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/2817106.mvXUDI8C0e@rafael.j.wysocki
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>
Use acpi_osc_handshake() introduced previously for implementing the
\_SB._OSC USB4 features control negotiation.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/3879947.MHq7AAxBmi@rafael.j.wysocki
The feature mask creation for \_SB._OSC is messy and hard to follow,
so clean it up and make all of the CPPC-related features depend on
CONFIG_ACPI_CPPC_LIB as they will not work if it is not set anyway.
Also make acpi_bus_osc_negotiate_platform_control() print a message
including a bit mask representig the features for which control has
been granted.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/4495088.ejJDZkT8p0@rafael.j.wysocki
Both acpi_bus_osc_negotiate_platform_control() and
acpi_bus_osc_negotiate_usb_control() first call acpi_run_osc() to
evaluate _OSC in "query mode", with OSC_QUERY_ENABLE set in the
capabilities buffer, and then use the resultant feature mask as
the input buffer for requesting control of those features by
calling acpi_run_osc() to evaluate _OSC with OSC_QUERY_ENABLE clear.
This involves some code duplication and unnecessary memory
allocations, so introduce a new helper function carrying out an
_OSC handshake along the lines of the above description in a simpler
way and update acpi_bus_osc_negotiate_platform_control() to use it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/1966378.CQOukoFCf9@rafael.j.wysocki
Use ACPI_FREE() for freeing an object coming from acpi_eval_osc()
and rename the "out_free" to "out" because it does not involve
kfree() any more.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/8682086.NyiUUSuA9g@rafael.j.wysocki
Split a function for processing _OSC errors called acpi_osc_error_check()
out of acpi_run_osc() to facilitate subsequent changes.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/6135328.MhkbZ0Pkbq@rafael.j.wysocki
Split a function for evaluating _OSC called acpi_eval_osc() out of
acpi_run_osc() to facilitate subsequent changes and add some more
parameters sanity checks to the latter.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/22963770.EfDdHjke4D@rafael.j.wysocki
Instead of using one function, acpi_print_osc_error(), for printing a
debug message and dumping the _OSC request data in one go, use
acpi_handle_debug() directly for printing messages and a separate
function called acpi_dump_osc_data() for dumping the _OSC request data
before printing one or more of them.
This avoids
* dumping _OSC request data multiple times when there are
multiple error bits set in the return buffer,
* wrapping message lines on terminals with 80 character line width,
* mixing up unrelated messages by printing full lines only,
and generally helps to make the messages easier to parse.
Also, use %pUL for UUID printing instead of printing UUIDs as strings
and include the revision number into the dumped _OSC request data.
This is how the debug printout looks like when the
OSC_REQUEST_ERROR and OSC_INVALID_REVISION_ERROR bits
are set in the return buffer before the change:
ACPI: \_SB_: ACPI: (0811B06E-4A27-44F9-8D60-3CBBC22E7B48): _OSC request failed
ACPI: _OSC request data:
ACPI: 1
ACPI: 2e7eff
ACPI:
ACPI: \_SB_: ACPI: (0811B06E-4A27-44F9-8D60-3CBBC22E7B48): _OSC invalid revision
ACPI: _OSC request data:
ACPI: 1
ACPI: 2e7eff
ACPI:
and this is how it is going to look like afterward:
ACPI: \_SB_: ACPI: _OSC: UUID: 0811B06E-4A27-44F9-8D60-3CBBC22E7B48, rev: 1
ACPI: \_SB_: ACPI: _OSC: capabilities DWORD 0: [00000001]
ACPI: \_SB_: ACPI: _OSC: capabilities DWORD 1: [002e7eff]
ACPI: \_SB_: ACPI: _OSC: request failed
ACPI: \_SB_: ACPI: _OSC: invalid revision
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/10794028.nUPlyArG6x@rafael.j.wysocki
The handling of _OSC errors in acpi_run_osc() is inconsistent and
arguably not compliant with the _OSC definition (cf. Section 6.2.12 of
ACPI 6.6 [1]).
Namely, if OSC_QUERY_ENABLE is not set in the capabilities buffer and
any of the error bits are set in the _OSC return buffer, acpi_run_osc()
returns an error code and the _OSC return buffer is discarded. However,
in that case, depending on what error bits are set, the return buffer
may contain acknowledged bits for features that need to be controlled by
the kernel going forward.
If the OSC_INVALID_UUID_ERROR bit is set, the request could not be
processed at all and so in that particular case discarding the _OSC
return buffer and returning an error is the right thing to do regardless
of whether or not OSC_QUERY_ENABLE is set in the capabilities buffer.
If OSC_QUERY_ENABLE is set in the capabilities buffer and the
OSC_REQUEST_ERROR or OSC_INVALID_REVISION_ERROR bits are set in the
return buffer, acpi_run_osc() may return an error and discard the _OSC
return buffer because in that case the platform configuration does not
change. However, if any of them is set in the return buffer when
OSC_QUERY_ENABLE is not set in the capabilities buffer, the feature
mask in the _OSC return buffer still represents a set of acknowleded
features as per the _OSC definition:
The platform acknowledges the Capabilities Buffer by returning a
buffer of DWORDs of the same length. Set bits indicate acknowledgment
that OSPM may take control of the capability and cleared bits indicate
that the platform either does not support the capability or that OSPM
may not assume control.
which is not conditional on the error bits being clear, so in that case,
discarding the _OSC return buffer is questionable. There is also no
reason to return an error and discard the _OSC return buffer if the
OSC_CAPABILITIES_MASK_ERROR bit is set in it, but printing diagnostic
messages is appropriate when that happens with OSC_QUERY_ENABLE clear
in the capabilities buffer.
Adress this issue by making acpi_run_osc() follow the rules outlined
above.
Moreover, make acpi_run_osc() only take the defined _OSC error bits into
account when checking _OSC errors.
Link: https://uefi.org/specs/ACPI/6.6/06_Device_Configuration.html#osc-operating-system-capabilities [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
[ rjw: Corrected typo in the changelog ]
Link: https://patch.msgid.link/3042649.e9J7NaK4W3@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ACPI sysfs code will fail to initialize if acpi_kobj is NULL,
together with some ACPI drivers.
Follow the other firmware subsystems and bail out if the kobject
cannot be registered.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20250518185111.3560-2-W_Armin@gmx.de
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
To avoid arch-specific code in general ACPI initialization flow,
introduce a weak symbol acpi_arch_init().
Currently, arm64 and riscv can utillize this to insert their
arch-specific flow.
In the future, other architectures can also have a chance to define
their own arch-specific ACPI initialization process if necessary.
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
Link: https://patch.msgid.link/20241121-intro-acpi-arch-init-v4-1-b1fb517e7d8b@gmail.com
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add the IRQ model for RISC-V INTC so that acpi_set_irq_model can use this
for RISC-V.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Tested-by: Björn Töpel <bjorn@rivosinc.com>
Link: https://patch.msgid.link/20240812005929.113499-8-sunilvl@ventanamicro.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add a new function for RISC-V to do architecture specific initialization
similar to acpi_arm_init(). Some of the ACPI tables are architecture
specific and there is no reason trying to find them on other
architectures. So, add acpi_riscv_init() similar to acpi_arm_init().
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Tested-by: Björn Töpel <bjorn@rivosinc.com>
Link: https://patch.msgid.link/20240812005929.113499-4-sunilvl@ventanamicro.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Here is the big set of driver core changes for 6.11-rc1.
Lots of stuff in here, with not a huge diffstat, but apis are evolving
which required lots of files to be touched. Highlights of the changes
in here are:
- platform remove callback api final fixups (Uwe took many releases to
get here, finally!)
- Rust bindings for basic firmware apis and initial driver-core
interactions. It's not all that useful for a "write a whole driver
in rust" type of thing, but the firmware bindings do help out the
phy rust drivers, and the driver core bindings give a solid base on
which others can start their work. There is still a long way to go
here before we have a multitude of rust drivers being added, but
it's a great first step.
- driver core const api changes. This reached across all bus types,
and there are some fix-ups for some not-common bus types that
linux-next and 0-day testing shook out. This work is being done to
help make the rust bindings more safe, as well as the C code, moving
toward the end-goal of allowing us to put driver structures into
read-only memory. We aren't there yet, but are getting closer.
- minor devres cleanups and fixes found by code inspection
- arch_topology minor changes
- other minor driver core cleanups
All of these have been in linux-next for a very long time with no
reported problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZqH+aQ8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymoOQCfVBdLcBjEDAGh3L8qHRGMPy4rV2EAoL/r+zKm
cJEYtJpGtWX6aAtugm9E
=ZyJV
-----END PGP SIGNATURE-----
Merge tag 'driver-core-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg KH:
"Here is the big set of driver core changes for 6.11-rc1.
Lots of stuff in here, with not a huge diffstat, but apis are evolving
which required lots of files to be touched. Highlights of the changes
in here are:
- platform remove callback api final fixups (Uwe took many releases
to get here, finally!)
- Rust bindings for basic firmware apis and initial driver-core
interactions.
It's not all that useful for a "write a whole driver in rust" type
of thing, but the firmware bindings do help out the phy rust
drivers, and the driver core bindings give a solid base on which
others can start their work.
There is still a long way to go here before we have a multitude of
rust drivers being added, but it's a great first step.
- driver core const api changes.
This reached across all bus types, and there are some fix-ups for
some not-common bus types that linux-next and 0-day testing shook
out.
This work is being done to help make the rust bindings more safe,
as well as the C code, moving toward the end-goal of allowing us to
put driver structures into read-only memory. We aren't there yet,
but are getting closer.
- minor devres cleanups and fixes found by code inspection
- arch_topology minor changes
- other minor driver core cleanups
All of these have been in linux-next for a very long time with no
reported problems"
* tag 'driver-core-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (55 commits)
ARM: sa1100: make match function take a const pointer
sysfs/cpu: Make crash_hotplug attribute world-readable
dio: Have dio_bus_match() callback take a const *
zorro: make match function take a const pointer
driver core: module: make module_[add|remove]_driver take a const *
driver core: make driver_find_device() take a const *
driver core: make driver_[create|remove]_file take a const *
firmware_loader: fix soundness issue in `request_internal`
firmware_loader: annotate doctests as `no_run`
devres: Correct code style for functions that return a pointer type
devres: Initialize an uninitialized struct member
devres: Fix memory leakage caused by driver API devm_free_percpu()
devres: Fix devm_krealloc() wasting memory
driver core: platform: Switch to use kmemdup_array()
driver core: have match() callback in struct bus_type take a const *
MAINTAINERS: add Rust device abstractions to DRIVER CORE
device: rust: improve safety comments
MAINTAINERS: add Danilo as FIRMWARE LOADER maintainer
MAINTAINERS: add Rust FW abstractions to FIRMWARE LOADER
firmware: rust: improve safety comments
...
In the match() callback, the struct device_driver * should not be
changed, so change the function callback to be a const *. This is one
step of many towards making the driver core safe to have struct
device_driver in read-only memory.
Because the match() callback is in all busses, all busses are modified
to handle this properly. This does entail switching some container_of()
calls to container_of_const() to properly handle the constant *.
For some busses, like PCI and USB and HV, the const * is cast away in
the match callback as those busses do want to modify those structures at
this point in time (they have a local lock in the driver structure.)
That will have to be changed in the future if they wish to have their
struct device * in read-only-memory.
Cc: Rafael J. Wysocki <rafael@kernel.org>
Reviewed-by: Alex Elder <elder@kernel.org>
Acked-by: Sumit Garg <sumit.garg@linaro.org>
Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The ACPI battery driver can handle the "charge limiting" state
of the battery, so the platform can advertise this state.
Indicate this by setting bit 19 ("Battery Charge Limiting Support")
when evaluating _OSC.
Tested on a Lenovo Ideapad S145-14IWL.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20240620191410.3646-2-W_Armin@gmx.de
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge ACPI device enumeration changes and ACPI data-only tables support
updates for 6.10:
- Rearrange fields in several structures to effectively eliminate
computations from container_of() in some cases (Andy Shevchenko).
- Do some assorted cleanups of the ACPI device enumeration code (Andy
Shevchenko).
- Make the ACPI device enumeration code skip devices with _STA values
clearly identified by the specification as invalid (Rafael Wysocki).
- Rework the handling of the NHLT table to simplify and clarify it and
drop some obsolete pieces (Cezary Rojewski).
* acpi-scan:
ACPI: scan: Avoid enumerating devices with clearly invalid _STA values
ACPI: scan: Introduce typedef:s for struct acpi_hotplug_context members
ACPI: scan: Use standard error checking pattern
ACPI: scan: Move misleading comment to acpi_dma_configure_id()
ACPI: scan: Use list_first_entry_or_null() in acpi_device_hid()
ACPI: bus: Don't use "proxy" headers
ACPI: bus: Make container_of() no-op where it makes sense
* acpi-tables:
ACPI: NHLT: Streamline struct naming
ACPI: NHLT: Drop redundant types
ACPI: NHLT: Introduce API for the table
ACPI: NHLT: Reintroduce types the table consists of
The return value of _STA with the "present" bit unset and the "enabled"
bit set is clearly invalid as per the ACPI specification, Section 6.3.7
"_STA (Device Status)", so make the ACPI device enumeration code
disregard devices with such _STA return values.
Also, because this implies that status.enabled will only be set if
status.present is set too, acpi_device_is_enabled() can be modified
to simply return the value of the former.
Link: https://uefi.org/specs/ACPI/6.5/06_Device_Configuration.html#sta-device-status
Link: https://lore.kernel.org/linux-acpi/88179311a503493099028c12ca37d430@huawei.com/
Suggested-by: Salil Mehta <salil.mehta@huawei.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Modules registering driver with acpi_bus_register_driver() often forget to
set .owner field. The field is used by some of other kernel parts for
reference counting (try_module_get()), so it is expected that drivers
will set it.
Solve the problem by moving this task away from the drivers to the core
ACPI bus code, just like we did for platform_driver in
commit 9447057eaf ("platform_device: use a macro instead of
platform_driver_register").
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ACPI IRQ mapping code supports parsing of ResourceSource,
but this is not reported thru _OSC.
Fix this by setting bit 13 ("Interrupt ResourceSource support")
when evaluating _OSC.
Fixes: d44fa3d460 ("ACPI: Add support for ResourceSource/IRQ domain mapping")
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
A device driver for the Generic Event Device (ACPI0013) already
exists for quite some time, but support for it was never reported
thru _OSC.
Fix this by setting bit 11 ("Generic Event Device support") when
evaluating _OSC.
Fixes: 3db80c230d ("ACPI: implement Generic Event Device")
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The code responsible for parsing the available p-states should
have no problems handling more than 16 p-states.
Indicate this by setting bit 10 ("Greater Than 16 p-state support")
when evaluating _OSC.
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The ACPI thermal driver already uses the _TPF ACPI method to retrieve
precise sampling time values, but this is not reported thru _OSC.
Fix this by setting bit 9 ("Fast Thermal Sampling support") when
evaluating _OSC.
Fixes: a2ee7581af ("ACPI: thermal: Add Thermal fast Sampling Period (_TFP) support")
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Now that the driver core can properly handle constant struct bus_type,
move the acpi_bus_type variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The platform can deny certain tunneling from the OS and it does that by
clearing the control bits it does not want the OS to get and returning
with OSC_CAPABILITIES_MASK_ERROR bit set. Currently we do not handle
this properly so if this happens, for example when the platform denies
PCIe tunneling, we just fail the whole negotiation and revert back to
what the Thunderbolt driver is doing to figure out whether the
controller is running firmware connection manager or not. However, we
should honor what the platform returns.
For this reason run the USB4 _OSC() first with query bit set, and then
use the returned control double word (that may contain some of the bits
cleared by the platform) and run it second time with query bit clear.
While there, remove an extra space from the assignment of the control
double word.
Reported-by: NaamaX Shachar <naamax.shachar@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge ACPI bus type driver updates for 6.7-rc1:
- Add context argument to acpi_dev_install_notify_handler() (Rafael
Wysocki).
- Clarify ACPI bus concepts in the ACPI device enumeration
documentation (Rafael Wysocki).
* acpi-bus:
ACPI: bus: Add context argument to acpi_dev_install_notify_handler()
ACPI: docs: enumeration: Clarify ACPI bus concepts
acpi_agdi_init() in acpi_arm_init() will register a SDEI event, so
it needs the SDEI subsystem to be initialized (which is done in
acpi_ghes_init()) before the AGDI driver probing.
In commit fcea0ccf4f ("ACPI: bus: Consolidate all arm specific
initialisation into acpi_arm_init()"), the acpi_agdi_init() was
called before acpi_ghes_init() and it causes following failure:
| [ 0.515864] sdei: Failed to create event 1073741825: -5
| [ 0.515866] agdi agdi.0: Failed to register for SDEI event 1073741825
| [ 0.515867] agdi: probe of agdi.0 failed with error -5
| ...
| [ 0.516022] sdei: SDEIv1.0 (0x0) detected in firmware.
Fix it by moving acpi_arm_init() to the place of after
acpi_ghes_init().
Fixes: fcea0ccf4f ("ACPI: bus: Consolidate all arm specific initialisation into acpi_arm_init()")
Reported-by: D Scott Phillips <scott@os.amperecomputing.com>
Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: D Scott Phillips <scott@os.amperecomputing.com>
Cc: 6.5+ <stable@vger.kernel.org> # 6.5+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add void *context arrgument to the list of arguments of
acpi_dev_install_notify_handler() and modify it to pass that argument
as context to acpi_install_notify_handler() instead of its first
argument which is problematic in general (for example, if platform
drivers used it, they would rather get struct platform_device pointers
or pointers to their private data from the context arguments of their
notify handlers).
Make all of the current callers of acpi_dev_install_notify_handler()
take this change into account so as to avoid altering the general
functionality.
Co-developed-by: Michal Wilczynski <michal.wilczynski@intel.com>
Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge ACPI processor driver changes for 6.6-rc1:
- Support obtaining physical CPU ID from MADT on LoongArch (Bibo Mao).
- Convert ACPI CPU initialization to using _OSC instead of _PDC that
has been depreceted since 2018 and dropped from the specification in
ACPI 6.5 (Michal Wilczynski, Rafael Wysocki).
* acpi-processor:
ACPI: processor: LoongArch: Get physical ID from MADT
ACPI: processor: Refine messages in acpi_early_processor_control_setup()
ACPI: processor: Remove acpi_hwp_native_thermal_lvt_osc()
ACPI: processor: Use _OSC to convey OSPM processor support information
ACPI: processor: Introduce acpi_processor_osc()
ACPI: processor: Set CAP_SMP_T_SWCOORD in arch_acpi_set_proc_cap_bits()
ACPI: processor: Clear C_C2C3_FFH and C_C1_FFH in arch_acpi_set_proc_cap_bits()
ACPI: processor: Rename ACPI_PDC symbols
ACPI: processor: Refactor arch_acpi_set_pdc_bits()
ACPI: processor: Move processor_physically_present() to acpi_processor.c
ACPI: processor: Move MWAIT quirk out of acpi_processor.c
Change acpi_early_processor_osc() to return a value in case of a
failure and make it static.
Also make it run acpi_processor_osc() for every processor object or
processor device found in the ACPI Namespace (previously, its only purpose
was to work around platform firmware defects on Skylake systems).
Introduce a new function called acpi_early_processor_control_setup() that
will invoke acpi_early_processor_osc() first in order to convey the OS
processor support information to the platform firmware and if that fails,
it will fall back to using _PDC.
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
[ rjw: Subject and changelog edits, change function return value to bool,
add missing 'static', change messages ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Most ACPI drivers set driver_data in their .add() callbacks, but usually
they don't clear it in the error code path.
Set driver_data to NULL in acpi_device_probe() to prevent stale pointers
from staying around.
Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Introduce new functions acpi_dev_install_notify_handler() and
acpi_dev_remove_notify_handler(), to install and remove, respectively,
a handler for AML Notify() operations targeted at a given ACPI device
object. They will allow drivers to install Notify() handlers directly
instead of providing an ACPI driver .notify() callback to be invoked
in the context of a Notify() handler installed by the ACPI bus type
code. In particular, this will help platform drivers to provide
Notify() handlers for the ACPI companions of the platform devices
they bind to.
These functions are replacements for acpi_device_install_notify_handler()
and acpi_device_remove_notify_handler(), respectively, and after all
drivers switch over to using them, the old ones will be dropped.
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com>
[ rjw: Subject and changelog edits, whitespace adjustments ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge additional ACPI device enumeration code changes for 6.5-rc1.
- Make acpi_companion_match() return a const pointer and update its
callers accordingly (Andy Shevchenko).
- Move the extern declaration of the acpi_root variable to a header
file so as to address a compiler warning (Andy Shevchenko).
- Address compiler warnings in the ACPI device enumeration code by
adding a missing header file include to it (Ben Dooks).
- Refine the SMB0001 quirk in the ACPI device enumeration code so as to
address an i2c-scmi driver regression (Andy Shevchenko).
- Clean up two pieces of the ACPI device enumeration code (Andy
Shevchenko).
* acpi-bus:
ACPI: bus: Constify acpi_companion_match() returned value
* acpi-scan:
ACPI: scan: Use the acpi_match_acpi_device() helper
ACPI: platform: Move SMB0001 HID to the header and reuse
ACPI: platform: Ignore SMB0001 only when it has resources
ACPI: bus: Introduce acpi_match_acpi_device() helper
ACPI: scan: fix undeclared variable warnings by including sleep.h
ACPI: scan: Move acpi_root to internal header
Match the ACPI device against a given list of ACPI IDs.
Subsequent changes will make use of this.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
[ rjw: Changelog edit ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
acpi_companion_match() doesn't alter the contents of the passed
parameter, so we don't expect that returned value can be altered
either. So constify it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
- Reduce ACPI device enumeration overhead related to devices with
dependencies (Rafael Wysocki).
- Fix the handling of Microsoft LPS0 _DSM for suspend-to-idle (Mario
Limonciello).
- Fix section mismatch warning in the ACPI suspend-to-idle code (Arnd
Bergmann).
- Drop several ACPI resource management quirks related to IRQ ovverides
on AMD "Zen" systems (Mario Limonciello).
- Modify the ACPI EC driver to make it only clear the EC GPE status
when handling the GPE (Jeremy Compostella).
- Add quirks to work around ACPI tables defects on Lenovo Yoga Book
yb1-x90f/l and Nextbook Ares 8A (Hans de Goede).
- Add ACPi backlight quirks for Dell Studio 1569, Lenovo ThinkPad X131e
(3371 AMD version) and Apple iMac11,3 and stop trying to use vendor
backlight control on relatively recent systems (Hans de Goede).
- Add pwm_lookup_table entry for second PWM on CHT/BSW devices in the
ACPI LPSS (Intel SoC) driver (Hans de Goede).
- Add nfit_intel_shutdown_status() declaration to a local header to
avoid a "missing prototypes" build warning (Arnd Bergmann).
- Clean up the ACPI thermal driver and drop some dead or otherwise
unneded code from it (Rafael Wysocki).
- Rework the handling of notifications in the ACPI button drivers so
as to allow the common notification handling code for devices to be
simplified (Rafael Wysocki).
- Make ghes_get_devices() return NULL to indicate that there are no
GHES devices so as to allow vendor-specific EDAC drivers to probe
then (Li Yang).
- Mark bert_disable() as __initdata and drop an unused function from
the APEI GHES code (Miaohe Lin).
- Make the ACPI PAD (Processor Aggregator Device) driver realize that
Zhaoxin CPUs support nonstop TSC (Tony W Wang-oc).
- Drop the certainly unnecessary and likely incorrect inclusion of
linux/arm-smccc.h from acpi_ffh.c (Sudeep Holla).
-----BEGIN PGP SIGNATURE-----
iQJGBAABCAAwFiEE4fcc61cGeeHD/fCwgsRv/nhiVHEFAmSZv6MSHHJqd0Byand5
c29ja2kubmV0AAoJEILEb/54YlRxdy4QAJ1kT5uMjWTRvadaOL0N9M1IOqEKI77a
QW/hC1QLbOMY79c7O8wEhF2La872b4fYCjaFaA98dzEu+/ISSDXUis7qb2cys/Ss
EHVwNVGungCQJ5axaio593av0dttFk/PTZVpHp93swCpR9QME8Gxx+Vf48Gg7zzq
BFVGc36KAgTmnh82s9VCSFnYJIS87yQ57eys+aW4R2HGsYPKPnsfMx95nwPGM+z/
e5Li4DLlF47IA8Fi8i+ZvqWy4iRC7iGuFTn/3gPPcUIWsKlL3VEhWuT3fXSqPZTO
VkXTg8bxKZMaPgg4ckM4V++Lkx4E6gO1rEIw0/8IANULvscBG4k6cgBwXfxJDCk3
+oiXHO3t3s+9mKZP3tAad5yPGDN1i7d96/68frPt8ESTQ206o2j7s/mjqyZmh2bJ
Ox5rI2HPDOpl6wT70DLEXB6O5kdI+EOMrJ/1w7Mmsc3oeQKlR8RLlNuRElTVrxfp
Fw5neWzKeqAKXTBgW+uIN4gtcwyXTtCOmP6a53T+xlFZAJHtTaJGBKpJA4Aa7oRf
VbVoGpeatXqvrsTwVsQ01qhZp46gzO8obzyLvincX69wkwqLJ4hbLBEdCEjPnbJK
y5FasTQrVPR1t3Lk0PfRooC+iq+c1JtYgnkrRzjfKEN0K2/ywygrzx14Fo6vEaF+
OF6hIbipYKgP
=46Do
-----END PGP SIGNATURE-----
Merge tag 'acpi-6.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI updates from Rafael Wysocki:
"These rework the handling of notifications in ACPI button drivers (to
enable future simplifications and cleanups), clean up the ACPI thermal
driver, update the ACPI backlight driver, add quirks working around
AML bugs on some systems, fix some assorted issues and clean up code.
Specifics:
- Reduce ACPI device enumeration overhead related to devices with
dependencies (Rafael Wysocki)
- Fix the handling of Microsoft LPS0 _DSM for suspend-to-idle (Mario
Limonciello)
- Fix section mismatch warning in the ACPI suspend-to-idle code (Arnd
Bergmann)
- Drop several ACPI resource management quirks related to IRQ
ovverides on AMD "Zen" systems (Mario Limonciello)
- Modify the ACPI EC driver to make it only clear the EC GPE status
when handling the GPE (Jeremy Compostella)
- Add quirks to work around ACPI tables defects on Lenovo Yoga Book
yb1-x90f/l and Nextbook Ares 8A (Hans de Goede)
- Add ACPi backlight quirks for Dell Studio 1569, Lenovo ThinkPad
X131e (3371 AMD version) and Apple iMac11,3 and stop trying to use
vendor backlight control on relatively recent systems (Hans de
Goede)
- Add pwm_lookup_table entry for second PWM on CHT/BSW devices in the
ACPI LPSS (Intel SoC) driver (Hans de Goede)
- Add nfit_intel_shutdown_status() declaration to a local header to
avoid a "missing prototypes" build warning (Arnd Bergmann)
- Clean up the ACPI thermal driver and drop some dead or otherwise
unneded code from it (Rafael Wysocki)
- Rework the handling of notifications in the ACPI button drivers so
as to allow the common notification handling code for devices to be
simplified (Rafael Wysocki)
- Make ghes_get_devices() return NULL to indicate that there are no
GHES devices so as to allow vendor-specific EDAC drivers to probe
then (Li Yang)
- Mark bert_disable() as __initdata and drop an unused function from
the APEI GHES code (Miaohe Lin)
- Make the ACPI PAD (Processor Aggregator Device) driver realize that
Zhaoxin CPUs support nonstop TSC (Tony W Wang-oc)
- Drop the certainly unnecessary and likely incorrect inclusion of
linux/arm-smccc.h from acpi_ffh.c (Sudeep Holla)"
* tag 'acpi-6.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (30 commits)
ACPI: video: Add backlight=native DMI quirk for Dell Studio 1569
ACPI: thermal: Drop struct acpi_thermal_flags
ACPI: thermal: Drop struct acpi_thermal_state
ACPI: bus: Simplify installation and removal of notify callback
ACPI: tiny-power-button: Eliminate the driver notify callback
ACPI: button: Use different notify handlers for lid and buttons
ACPI: button: Eliminate the driver notify callback
ACPI: thermal: Eliminate struct acpi_thermal_state_flags
ACPI: thermal: Move acpi_thermal_driver definition
ACPI: thermal: Move symbol definitions to one place
ACPI: thermal: Drop redundant ACPI_TRIPS_REFRESH_DEVICES symbol
ACPI: thermal: Use BIT() macro for defining flags
APEI: GHES: correctly return NULL for ghes_get_devices()
ACPI: FFH: Drop the inclusion of linux/arm-smccc.h
ACPI: PAD: mark Zhaoxin CPUs NONSTOP TSC correctly
ACPI: APEI: mark bert_disable as __initdata
ACPI: EC: Clear GPE on interrupt handling only
ACPI: video: Stop trying to use vendor backlight control on laptops from after ~2012
ACPI: x86: s2idle: Adjust Microsoft LPS0 _DSM handling sequence
ACPI: resource: Remove "Zen" specific match and quirks
...
Because the only drivers that cared about button fixed events take care
of those events by themselves now, eliminate the code related to them
from acpi_device_install_notify_handler() and
acpi_device_remove_notify_handler().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Move all of the ARM-specific initialization into one function namely
acpi_arm_init(), so it is not necessary to modify/update bus.c every
time a new piece of it is added.
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Link: https://lore.kernel.org/r/CAJZ5v0iBZRZmV_oU+VurqxnVMbFN_ttqrL=cLh0sUH+=u0PYsw@mail.gmail.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Reviewed-by: Shaoqin Huang <shahuang@redhat.com>
Link: https://lore.kernel.org/r/20230606093531.2746732-1-sudeep.holla@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Here is the "big" set of char/misc and other driver subsystems for
6.4-rc1.
It's pretty big, but due to the removal of pcmcia drivers, almost breaks
even for number of lines added vs. removed, a nice change.
Included in here are:
- removal of unused PCMCIA drivers (finally!)
- Interconnect driver updates and additions
- Lots of IIO driver updates and additions
- MHI driver updates
- Coresight driver updates
- NVMEM driver updates, which required some OF updates
- W1 driver updates and a new maintainer to manage the subsystem
- FPGA driver updates
- New driver subsystem, CDX, for AMD systems
- lots of other small driver updates and additions
All of these have been in linux-next for a while with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZEp5Eg8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ynSXgCg0kSw3vUYwpsnhAsQkoPw1QVA23sAn2edRCMa
GEkPWjrROueCom7xbLMu
=eR+P
-----END PGP SIGNATURE-----
Merge tag 'char-misc-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc drivers updates from Greg KH:
"Here is the "big" set of char/misc and other driver subsystems for
6.4-rc1.
It's pretty big, but due to the removal of pcmcia drivers, almost
breaks even for number of lines added vs. removed, a nice change.
Included in here are:
- removal of unused PCMCIA drivers (finally!)
- Interconnect driver updates and additions
- Lots of IIO driver updates and additions
- MHI driver updates
- Coresight driver updates
- NVMEM driver updates, which required some OF updates
- W1 driver updates and a new maintainer to manage the subsystem
- FPGA driver updates
- New driver subsystem, CDX, for AMD systems
- lots of other small driver updates and additions
All of these have been in linux-next for a while with no reported
issues"
* tag 'char-misc-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (196 commits)
mcb-lpc: Reallocate memory region to avoid memory overlapping
mcb-pci: Reallocate memory region to avoid memory overlapping
mcb: Return actual parsed size when reading chameleon table
kernel/configs: Drop Android config fragments
virt: acrn: Replace obsolete memalign() with posix_memalign()
spmi: Add a check for remove callback when removing a SPMI driver
spmi: fix W=1 kernel-doc warnings
spmi: mtk-pmif: Drop of_match_ptr for ID table
spmi: pmic-arb: Convert to platform remove callback returning void
spmi: mtk-pmif: Convert to platform remove callback returning void
spmi: hisi-spmi-controller: Convert to platform remove callback returning void
w1: gpio: remove unnecessary ENOMEM messages
w1: omap-hdq: remove unnecessary ENOMEM messages
w1: omap-hdq: add SPDX tag
w1: omap-hdq: allow compile testing
w1: matrox: remove unnecessary ENOMEM messages
w1: matrox: use inline over __inline__
w1: matrox: switch from asm to linux header
w1: ds2482: do not use assignment in if condition
w1: ds2482: drop unnecessary header
...
Currently, acpi_device_remove_notify_handler() may return while the
notify handler being removed is still running which may allow the
module holding that handler to be torn down prematurely.
Address this issue by making acpi_device_remove_notify_handler() wait
for the handling of all the ACPI events in progress to complete before
returning.
Fixes: 5894b0c46e ("ACPI / scan: Move bus operations and notification routines to bus.c")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
