Re: ACPI scan regression -> Boot fail on Cherrytrail w/ 5.11-rc3

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

>>> [    0.516336] ACPI: \_SB_.PCI0.BRCM: Dependencies found
>>
>> Ah, that is enlightening, that is not supposed to happen, that device
>> has both an _ADR and an _HID method which is not allowed according
>> to the spec.

it's not an uncommon issue for audio codecs, here's three examples:

             Device (RTK1)
             {
                 Name (_ADR, Zero)  // _ADR: Address
                 Name (_HID, "10EC5670")  // _HID: Hardware ID
                 Name (_CID, "10EC5670")  // _CID: Compatible ID
                 Name (_DDN, "ALC5642")  // _DDN: DOS Device Name

         Device (MAXM)
         {
             Name (_ADR, Zero)  // _ADR: Address
             Name (_HID, "193C9890")  // _HID: Hardware ID
             Name (_CID, "193C9890")  // _CID: Compatible ID
             Name (_DDN, "Maxim 98090 Codec  ")  // _DDN: DOS Device Name

         Device (TISW)
         {
             Name (_ADR, Zero)  // _ADR: Address
             Name (_HID, "104C227E")  // _HID: Hardware ID
             Name (_CID, "104C227E")  // _CID: Compatible ID

It's been that way for years...

>> Can you try a clean 5.11 kernel (so none of the previous
>> debug patches) with the following change added:
>>
>> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>> index 1f27f74cc83c..93954ac3bfcc 100644
>> --- a/drivers/acpi/scan.c
>> +++ b/drivers/acpi/scan.c
>> @@ -1854,7 +1854,8 @@ static u32 acpi_scan_check_dep(acpi_handle handle)
>>           * 2. ACPI nodes describing USB ports.
>>           * Still, checking for _HID catches more then just these cases ...
>>           */
>> -       if (!acpi_has_method(handle, "_DEP") || !acpi_has_method(handle, "_HID"))
>> +       if (!acpi_has_method(handle, "_DEP") || !acpi_has_method(handle, "_HID") ||
>> +           acpi_has_method(handle, "_ADR"))
>>                  return 0;
>>
>>          status = acpi_evaluate_reference(handle, "_DEP", NULL, &dep_devices);
>>
>>
>>> [    0.517490] ACPI: \_SB_.PCI0.LNPW: Dependencies found
>>
>> And idem. for this one.
>>
>> That might very well fix this.

Nope, no luck with this patch. boot still stuck.

> It might.
> 
> That said, there are "interesting" dependencies in those ACPI tables
> (like on the PMIC which is deferred, because it depends on I2C7 and
> GP01 and even some power resources depend on it).
>