Re: [PATCH v3] platform/x86: ideapad-laptop: do not poke keyboard controller

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Sun, Oct 25, 2026 at 09:52:27AM +0800, Rong Zhang wrote:
> Hi Dmitry,
> 
> On Sat, 2026-10-24 at 16:13 -0700, Dmitry Torokhov wrote:
> > Hi Rong,
> > 
> > On Sat, Oct 24, 2026 at 11:30:06PM +0800, Rong Zhang wrote:
> > > However, the methodology has been changed from hardware-based to
> > > software-based. Because of the fundamental change, it has the potential
> > > to break something if some users depends on the side-effect of toggling
> > > the aux port.
> > > 
> > > While my device never needs the quirk, I can think of several useful
> > > side-effects:
> > > 
> > > - pause the interrupt (and hence pause event handling) to save some
> > > energy
> > > - prevent the touchpad from waking up the platform
> > > - reset faulty touchpads
> > > 
> > > By switching to the software-based methodology, all these capabilities
> > > have gone. Of course, relying on these side-effects is a misuse, but
> > > relying on the parameter itself without reporting it to the mailing list
> > > is also a misuse! More below.
> > 
> > This reminds me of https://xkcd.com/1172/ ("Workflow").
> > 
> > Also note that I8042_CMD_AUX_DISABLE / I8042_CMD_AUX_ENABLE only toggles
> > the AUX clock inhibit bit in the 8042 controller; it does not power down
> > or reset the touchpad (psmouse is unaware that ideapad-laptop poked the
> > controller behind its back, which is the whole problem), and i8042
> > already manages the AUX port and wakeup state across suspend and resume.
> 
> Thanks for the detailed explanation. I agree that there should be no
> outstanding spacebar-heating workflow depending on I8042_CMD_AUX_DISABLE.
> 
> > 
> > > A completely new behavior reusing an old knob is always prone to break
> > > *something* in a obscure way unless users are notified about the change.
> > > Breaking something with a visible warning [1] in kmsg is much better than
> > > potentially breaking something in radio silence. 
> > > 
> > > We don't want to support poking i8042 anymore, so the use of
> > > 'ctrl_ps2_aux_port' is anyway becoming unsupported. The parameter was
> > > introduced only for debugging and is expected to be removed at any time.
> > > If users don't report their use of the parameter to the mailing list,
> > > they are already relying on a broken setup.
> > > 
> > > By renaming it and breaking the unsupported setup loudly, we encourage
> > > users to report quirky devices, as well as getting rid of an outdated
> > > parameter name.
> > > 
> > > [1]: ideapad_laptop: unknown parameter 'ctrl_ps2_aux_port' ignored
> > 
> > We already have DMI matching for this quirk (ctrl_ps2_aux_port_list[],
> > which has only ever contained the 2011 IdeaPad Z570 since commit
> > c69e7d843d2c added it in 2022), and the module parameter simply sets the
> > exact same priv->features.ctrl_ps2_aux_port flag as the DMI table.
> > 
> > Intentionally breaking the module parameter for anyone who might be
> > using it for its intended purpose (making the touchpad toggle hotkey
> > work on an older IdeaPad) 
> > 
> 
> It's the flag's intended purpose, and never the module parameter's.
> 
> The module parameter's intended purpose is only for debugging and bug
> reporting. And its name and description describe the intended behavior.
> 
> Renaming it does not change either of them, while reusing the knob makes
> its name mismatch the intended behavior.
> 
> > just because of hypothetical spacebar-heating
> > workflows does not make sense to me.
> 
> Using the parameter without reporting is also a spacebar-heating
> workflow. That's why the description asks users to report to the pdx86
> mailing list, so that we can add a new entry to the DMI quirk table. It's
> similar to sysfs bind/unbind to a certain extent, which recently gained
> TAINT_FORCED_BIND.
> 
> We shouldn't create a divergence between the intended behavior and the
> parameter's name simply because such a workflow either.

OK, I'll just defer to Ilpo here. If he wants to rename module option I
can do that. I still believe that this gratuitously breaks users that
happen to use this module parameters. While we would like them to report
their systems they are under no obligation to do so.

Thanks.

-- 
Dmitry