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@xxxxxxxxx> wrote: > > > > > > On Sat, Sep 11, 2021 at 4:32 AM Takashi Iwai <tiwai@xxxxxxx> 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
