Messages in this thread | | | Subject | Re: [PATCH v2 2/7] acpi: utils: Add function to fetch dependent acpi_devices | From | Daniel Scally <> | Date | Thu, 21 Jan 2021 12:04:30 +0000 |
| |
On 21/01/2021 11:58, Rafael J. Wysocki wrote: > On Thu, Jan 21, 2021 at 10:47 AM Daniel Scally <djrscally@gmail.com> wrote: >> Hi Rafael >> >> On 19/01/2021 13:15, Rafael J. Wysocki wrote: >>> On Mon, Jan 18, 2021 at 9:51 PM Daniel Scally <djrscally@gmail.com> wrote: >>>> On 18/01/2021 16:14, Rafael J. Wysocki wrote: >>>>> On Mon, Jan 18, 2021 at 1:37 AM Daniel Scally <djrscally@gmail.com> wrote: >>>>>> In some ACPI tables we encounter, devices use the _DEP method to assert >>>>>> a dependence on other ACPI devices as opposed to the OpRegions that the >>>>>> specification intends. We need to be able to find those devices "from" >>>>>> the dependee, so add a function to parse all ACPI Devices and check if >>>>>> the include the handle of the dependee device in their _DEP buffer. >>>>> What exactly do you need this for? >>>> So, in our DSDT we have devices with _HID INT3472, plus sensors which >>>> refer to those INT3472's in their _DEP method. The driver binds to the >>>> INT3472 device, we need to find the sensors dependent on them. >>>> >>> Well, this is an interesting concept. :-) >>> >>> Why does _DEP need to be used for that? Isn't there any other way to >>> look up the dependent sensors? >>> >>>>> Would it be practical to look up the suppliers in acpi_dep_list instead? >>>>> >>>>> Note that supplier drivers may remove entries from there, but does >>>>> that matter for your use case? >>>> Ah - that may work, yes. Thank you, let me test that. >>> Even if that doesn't work right away, but it can be made work, I would >>> very much prefer that to the driver parsing _DEP for every device in >>> the namespace by itself. >> >> This does work; do you prefer it in scan.c, or in utils.c (in which case >> with acpi_dep_list declared as external var in internal.h)? > Let's put it in scan.c for now, because there is the lock protecting > the list in there too. > > How do you want to implement this? Something like "walk the list and > run a callback for the matching entries" or do you have something else > in mind?
Something like this (though with a mutex_lock()). It could be simplified by dropping the prev stuff, but we have seen INT3472 devices with multiple sensors declaring themselves dependent on the same device
struct acpi_device * acpi_dev_get_next_dependent_dev(struct acpi_device *supplier, struct acpi_device *prev) { struct acpi_dep_data *dep; struct acpi_device *adev; int ret;
if (!supplier) return ERR_PTR(-EINVAL);
if (prev) { /* * We need to find the previous device in the list, so we know * where to start iterating from. */ list_for_each_entry(dep, &acpi_dep_list, node) if (dep->consumer == prev->handle && dep->supplier == supplier->handle) break;
dep = list_next_entry(dep, node); } else { dep = list_first_entry(&acpi_dep_list, struct acpi_dep_data, node); }
list_for_each_entry_from(dep, &acpi_dep_list, node) { if (dep->supplier == supplier->handle) { ret = acpi_bus_get_device(dep->consumer, &adev); if (ret) return ERR_PTR(ret);
return adev; } }
return NULL; }
| |