Re: Delaying i8042 probe?

[Takashi Iwai <tiwai@suse.de>]

On Sun, 12 Sep 2021 00:54:55 +0200,
Dmitry Torokhov wrote:
> 
> Hi Fabio,
> 
> On Sat, Sep 11, 2021 at 03:50:25PM -0300, Fabio Estevam wrote:
> > On Sat, Sep 11, 2021 at 3:43 PM Fabio Estevam <festevam@gmail.com> wrote:
> > >
> > > On Sat, Sep 11, 2021 at 4:32 AM Takashi Iwai <tiwai@suse.de> wrote:
> > >
> > > > OK, I'll update and let the reporter testing it.
> > >
> > > Sorry, platform_device_alloc() and platform_device_add() were missing
> > > in the earlier patch.
> > >
> > > New patch atached.
> > >
> > > Dmitry, does this look correct?
> > 
> > Please consider this one instead.
> 
> This is unfortunately is a band-aid. I wonder what other driver pokes
> the embedded controller on these devices for it to start responding to
> 8042 queries...
> 
> Does the laptop have the latest BIOS? I wonder what ACPI tables look
> like.

ACPI dump is included in hwinfo output,
  https://bugzilla.suse.com/show_bug.cgi?id=1190256#c1

If other format is required, let me know.  I thought this could be a
typical pinctrl thing, alas it doesn't look so.  The pinctrl-amd is
also built-in, and it's initialized before the input stuff...

And about BIOS: I don't think we can expect every user updates BIOS.
This report is not alone; as I checked through net, there have been a
few other reports for other distros like Arch.  On Arch, they "fixed"
the problem by reverting the config from built-in to modules (the bug
surfaced after their kconfig changes).

That said, even if it's a band-aid, we need some fix.  Can the
deferred probe be applied in some restricted manner, e.g. only for the
known buggy devices (and/or module option) and cap the max repeats?


thanks,

Takashi