On 8/5/20 3:19 PM, Saravana Kannan wrote: > On Wed, Aug 5, 2020 at 12:44 AM John Stultz <john.stultz@xxxxxxxxxx> wrote: >> <sigh> >> So this is where I bashfully admit I didn't get a chance to try this >> patch series out, as I had success with a much older version of >> Saravana's macro magic. >> >> But unfortunately, now that this has landed in mainline, I'm seeing >> boot regressions on db845c. :( This is in the non-modular case, >> building the driver in. > Does that mean the modular version is working? Or you haven't tried > that yet? I'll wait for your reply before I try to fix it. I don't > have the hardware, but it should be easy to guess this issue looking > at the code delta. For what it's worth, I saw this too on the Lenovo C630 (started on -next around 20200727, but I didn't track it down as, well, there's less way to get debug output on the C630. In my testing, module or built-in doesn't matter, but reverting does allow me to boot again. > The only significant change from what your probe function is doing is > this snippet. But it'd be surprising if this only affects the builtin > case. > > + if (par_np == np) > + par_np = NULL; > + > + /* > + * If there's a parent interrupt controller and none of the parent irq > + * domains have been registered, that means the parent interrupt > + * controller has not been initialized yet. it's not time for this > + * interrupt controller to initialize. So, defer probe of this > + * interrupt controller. The actual initialization callback of this > + * interrupt controller can check for specific domains as necessary. > + */ > + if (par_np && !irq_find_matching_host(np, DOMAIN_BUS_ANY)) > + return -EPROBE_DEFER; > >> I managed to bisect it down to this patch, and reverting it avoids the >> issue. I don't see what is wrong right off, but I really need to get >> to bed, so I'll dig further tomorrow. >> >> Saravana: Apologies for not getting around to testing this beforehand! > No worries. Apologies for breaking it accidentally. > > -Saravana
