Merge branch 'acpi-bus'

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
This commit is contained in:
Rafael J. Wysocki 2023-10-26 15:04:49 +02:00
commit 3660e641ef
9 changed files with 52 additions and 9 deletions

View File

@ -64,6 +64,49 @@ If the driver needs to perform more complex initialization like getting and
configuring GPIOs it can get its ACPI handle and extract this information
from ACPI tables.
ACPI device objects
===================
Generally speaking, there are two categories of devices in a system in which
ACPI is used as an interface between the platform firmware and the OS: Devices
that can be discovered and enumerated natively, through a protocol defined for
the specific bus that they are on (for example, configuration space in PCI),
without the platform firmware assistance, and devices that need to be described
by the platform firmware so that they can be discovered. Still, for any device
known to the platform firmware, regardless of which category it falls into,
there can be a corresponding ACPI device object in the ACPI Namespace in which
case the Linux kernel will create a struct acpi_device object based on it for
that device.
Those struct acpi_device objects are never used for binding drivers to natively
discoverable devices, because they are represented by other types of device
objects (for example, struct pci_dev for PCI devices) that are bound to by
device drivers (the corresponding struct acpi_device object is then used as
an additional source of information on the configuration of the given device).
Moreover, the core ACPI device enumeration code creates struct platform_device
objects for the majority of devices that are discovered and enumerated with the
help of the platform firmware and those platform device objects can be bound to
by platform drivers in direct analogy with the natively enumerable devices
case. Therefore it is logically inconsistent and so generally invalid to bind
drivers to struct acpi_device objects, including drivers for devices that are
discovered with the help of the platform firmware.
Historically, ACPI drivers that bound directly to struct acpi_device objects
were implemented for some devices enumerated with the help of the platform
firmware, but this is not recommended for any new drivers. As explained above,
platform device objects are created for those devices as a rule (with a few
exceptions that are not relevant here) and so platform drivers should be used
for handling them, even though the corresponding ACPI device objects are the
only source of device configuration information in that case.
For every device having a corresponding struct acpi_device object, the pointer
to it is returned by the ACPI_COMPANION() macro, so it is always possible to
get to the device configuration information stored in the ACPI device object
this way. Accordingly, struct acpi_device can be regarded as a part of the
interface between the kernel and the ACPI Namespace, whereas device objects of
other types (for example, struct pci_dev or struct platform_device) are used
for interacting with the rest of the system.
DMA support
===========

View File

@ -257,7 +257,7 @@ static int acpi_ac_add(struct acpi_device *device)
register_acpi_notifier(&ac->battery_nb);
result = acpi_dev_install_notify_handler(device, ACPI_ALL_NOTIFY,
acpi_ac_notify);
acpi_ac_notify, device);
if (result)
goto err_unregister;

View File

@ -2062,7 +2062,7 @@ static int acpi_video_bus_add(struct acpi_device *device)
goto err_del;
error = acpi_dev_install_notify_handler(device, ACPI_DEVICE_NOTIFY,
acpi_video_bus_notify);
acpi_video_bus_notify, device);
if (error)
goto err_remove;

View File

@ -1214,7 +1214,7 @@ static int acpi_battery_add(struct acpi_device *device)
device_init_wakeup(&device->dev, 1);
result = acpi_dev_install_notify_handler(device, ACPI_ALL_NOTIFY,
acpi_battery_notify);
acpi_battery_notify, device);
if (result)
goto fail_pm;

View File

@ -556,12 +556,12 @@ static void acpi_device_remove_notify_handler(struct acpi_device *device,
int acpi_dev_install_notify_handler(struct acpi_device *adev,
u32 handler_type,
acpi_notify_handler handler)
acpi_notify_handler handler, void *context)
{
acpi_status status;
status = acpi_install_notify_handler(adev->handle, handler_type,
handler, adev);
handler, context);
if (ACPI_FAILURE(status))
return -ENODEV;

View File

@ -57,7 +57,7 @@ static int acpi_hed_add(struct acpi_device *device)
hed_handle = device->handle;
err = acpi_dev_install_notify_handler(device, ACPI_DEVICE_NOTIFY,
acpi_hed_notify);
acpi_hed_notify, device);
if (err)
hed_handle = NULL;

View File

@ -3340,7 +3340,7 @@ static int acpi_nfit_add(struct acpi_device *adev)
int rc = 0;
rc = acpi_dev_install_notify_handler(adev, ACPI_DEVICE_NOTIFY,
acpi_nfit_notify);
acpi_nfit_notify, adev);
if (rc)
return rc;

View File

@ -970,7 +970,7 @@ static int acpi_thermal_add(struct acpi_device *device)
acpi_device_bid(device), deci_kelvin_to_celsius(tz->temperature));
result = acpi_dev_install_notify_handler(device, ACPI_DEVICE_NOTIFY,
acpi_thermal_notify);
acpi_thermal_notify, device);
if (result)
goto flush_wq;

View File

@ -520,7 +520,7 @@ int acpi_bus_attach_private_data(acpi_handle, void *);
void acpi_bus_detach_private_data(acpi_handle);
int acpi_dev_install_notify_handler(struct acpi_device *adev,
u32 handler_type,
acpi_notify_handler handler);
acpi_notify_handler handler, void *context);
void acpi_dev_remove_notify_handler(struct acpi_device *adev,
u32 handler_type,
acpi_notify_handler handler);