On 01/12/2020 15:10, Andy Shevchenko wrote: > On Mon, Nov 30, 2020 at 11:54:44PM +0000, Dan Scally wrote: >> Hi Andy >> >> On 30/11/2020 18:23, Andy Shevchenko wrote: >>> On Mon, Nov 30, 2020 at 01:31:25PM +0000, Daniel Scally wrote: >>>> ACPI devices declare themselves dependent on other devices via the _DEP >>>> buffer. Fetching the dependee from dependent is a matter of parsing >>>> _DEP, but currently there's no method to fetch dependent from dependee. >>>> Add one, so we can parse sensors dependent on a PMIC from the PMIC's >>>> acpi_driver. >>> Do I understand correctly that it's an existing table provided by firmware that >>> (ab)uses _DEP in such way? Note, the specification doesn't tell we may use it >>> in this way, OTOH I don't remember if it strictly forbids such use. >>> >>> So, please elaborate in the commit message why you need this and pint out to >>> the 6.5.8 "_DEP (Operation Region Dependencies)" which clearly says about >>> OpRegions and that part already supported by ACPI in the Linux, if I'm not >>> mistaken, need to refresh my memory. >> >> Laurent's reply is good explanation, but for example see my Lenovo Miix >> 510's DSDT: >> >> >> https://gist.githubusercontent.com/djrscally/e64d112180517352fa3392878b0f4a7d/raw/88b90b3ea4204fd7845257b6666fdade47cc2981/dsdt.dsl >> >> >> Search OVTI2680 and OVTI5648 for the cameras. Both are dependent on >> IN3472 devices (PMI0 and PMI1) which are the discrete type that we're >> attempting to handle here. > Yes, it seems since PMIC is kinda "power resource" (don't mix with real power > resource as by ACPI specifications) and that's why they decided to include it > into _DEP. So, it seems a de facto common practice. Thus, it would be nice to > have the above in the commit message in some form. Can you do it? > Sure, no problem. I'll include that in the next version
