On Fri, Jan 15, 2021 at 9:56 AM Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
>
> Hi,
>
> On 1/15/21 1:49 AM, Pierre-Louis Bossart wrote:
> > Thanks Hans for your reply, much appreciated.
> >
> >> Pierre-Louis, can you see if the following hack helps? :
> >>
> >> --- a/drivers/acpi/scan.c
> >> +++ b/drivers/acpi/scan.c
> >> @@ -1939,7 +1939,6 @@ static acpi_status acpi_bus_check_add(acpi_handle handle, bool check_dep,
> >> /* Bail out if the number of recorded dependencies is not 0. */
> >> if (count > 0) {
> >> acpi_bus_scan_second_pass = true;
It would be good to add
+ acpi_handle_info(handle, "Enumeration deferred\n");
here on top of the previous debug changes so we know which device(s) to look at.
> >> - return AE_CTRL_DEPTH;
> >> }
> >> }
> >> @@ -1948,8 +1947,7 @@ static acpi_status acpi_bus_check_add(acpi_handle handle, bool check_dep,
> >> return AE_CTRL_DEPTH;
> >> acpi_scan_init_hotplug(device);
> >> - if (!check_dep)
> >> - acpi_scan_dep_init(device);
> >> + acpi_scan_dep_init(device);
I think that this change can be made without issues anyway.
AFAICS, this part of acpi_bus_check_add() will only be called once for
every given device anyway and initializing dep_unmet for the devices
for which acpi_scan_check_dep() above returns 0 shouldn't hurt.
> >> out:
> >> if (!*adev_p)
> >
> > Yep, those 'hacks' solve the boot problem on my device. I tried multiple times and it's completely reproducible.
>
> Ok, so this confirms my earlier findings (with my personal 5.10 + cherry pick tree)
> that the problem is not doing 2 scan "rounds" and thus calling e.g.
> acpi_bus_attach twice. But the problem is rather with deferring the device-creation
> of some devices to the second step.
That would be my expectation.
