linux-kernel - Re: [PATCH v1] hid-playstation: DS4: Update rumble and lightbar together

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <rktgvill7zgcggiir54ixh3ele4zeqatoxwshamebtvvcnz4z5@nmmh5wgwnqmf>
Date: Mon, 22 Jul 2024 18:49:02 +0200
From: Benjamin Tissoires <bentiss@...nel.org>
To: Max Staudt <max@...as.org>
Cc: Roderick Colenbrander <thunderbird2k@...il.com>, 
	Jiri Kosina <jikos@...nel.org>, Benjamin Tissoires <benjamin.tissoires@...hat.com>, 
	Roderick Colenbrander <roderick.colenbrander@...y.com>, linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] hid-playstation: DS4: Update rumble and lightbar
 together

On Jul 22 2024, Max Staudt wrote:
> On second thought, maybe we can sidestep this discussion entirely by using a
> new Kconfig to have both states configurable.
> 
> Something like:
> 
>   CONFIG_HID_PLAYSTATION_V6_6_ANDROID_TEST_COMPAT

Please don't. As explained in the other email, we don't care about
downstream, so we can not take these never ending ifdef.

> 
> Improvements such as my patch would be turned off when this flag is enabled,
> and the driver behaviour reverted to the v6.6 LTS behaviour. So Android
> kernels would enable it, and everyone else (especially desktop
> distributions) can leave it off.
> 
> Then, once the Android test suite is fixed, the Kconfig can be removed.
> Looking at the Android release cadence in recent years, and the timeline of
> DS4 support in hid-playstation and in the v6.6 LTS kernel, I presume this
> would be in 1-2 years.
> 
> This way, upstream can continue improving the driver, without triggering
> Android test failures.

Is there anyway to detect that the device can not support the current
behavior? And if so then dynamically switch to the new behaviour?

Cheers,
Benjamin

> 
> 
> How does this sound?
> 
> Max
>