linux-kernel - Re: [PATCH v2 2/7] acpi: utils: Add function to fetch dependent acpi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c4875559-d735-67ff-66a2-8fd2bc1eceab@gmail.com>
Date:   Mon, 18 Jan 2021 13:37:15 +0000
From:   Daniel Scally <djrscally@...il.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
        linux-gpio@...r.kernel.org, linux-i2c@...r.kernel.org,
        platform-driver-x86@...r.kernel.org, devel@...ica.org,
        rjw@...ysocki.net, lenb@...nel.org, andy@...nel.org,
        mika.westerberg@...ux.intel.com, linus.walleij@...aro.org,
        bgolaszewski@...libre.com, wsa@...nel.org, lee.jones@...aro.org,
        hdegoede@...hat.com, mgross@...ux.intel.com,
        robert.moore@...el.com, erik.kaneda@...el.com,
        sakari.ailus@...ux.intel.com, laurent.pinchart@...asonboard.com,
        kieran.bingham@...asonboard.com
Subject: Re: [PATCH v2 2/7] acpi: utils: Add function to fetch dependent
 acpi_devices


On 18/01/2021 12:33, Andy Shevchenko wrote:
> On Mon, Jan 18, 2021 at 12:34:23AM +0000, Daniel Scally 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.
> Fix prefix to be "ACPI / utils: " and rebase on top of function name changes as
> suggested by Laurent.


OK.

>> +/**
>> + * acpi_dev_get_next_dep_dev - Return next ACPI device dependent on input dev
> Are you expecting some kind of for_each_*() macro to be added and used?
> Otherwise there is probably no need to have it "_next_" in the name as it will
> be a bit confusing.


I thought that somebody might want to do that in the future yes,
although I've no need for it at the minute because each of the dummy
INT3472 devices only has one dependent sensor that we've seen so far.
But for the INT3472 devices representing a physical TPS68470, there are
platforms where 2 sensors are called out as dependent on the same PMIC
ACPI device (Surface Go2 for example).

It can be renamed and just cross that bridge when we come to it though,
I have no problem with that.

>
>> + * @adev: Pointer to the dependee device
>> + * @prev: Pointer to the previous dependent device (or NULL for first match)
>> + *
>> + * Return the next ACPI device which declares itself dependent on @adev in
>> + * the _DEP buffer.
>> + *
>> + * The caller is responsible to call put_device() on the returned device.
>> + */