[ 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).
