Re: Delaying i8042 probe?

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:

quoted

On Sat, Sep 11, 2021 at 3:43 PM Fabio Estevam [off-list ref] wrote:

quoted

On Sat, Sep 11, 2021 at 4:32 AM Takashi Iwai [off-list ref] wrote:

quoted

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