linux-kernel - Re: [PATCH 00/11] HID: playstation: Add support for audio jack handling on DualSense

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: <6adf1ea5-53c3-47eb-ba4d-6c7e58dd05dd@collabora.com>
Date: Thu, 12 Jun 2025 11:00:38 +0300
From: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>
To: Roderick Colenbrander <thunderbird2k@...il.com>
Cc: Roderick Colenbrander <roderick.colenbrander@...y.com>,
 Jiri Kosina <jikos@...nel.org>, Benjamin Tissoires <bentiss@...nel.org>,
 Henrik Rydberg <rydberg@...math.org>, kernel@...labora.com,
 linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/11] HID: playstation: Add support for audio jack
 handling on DualSense

Hi Roderick,

On 6/10/25 7:01 AM, Roderick Colenbrander wrote:
> Hi Cristian,
> 
> Thanks for sharing your patches around audio. I need to have a closer
> look at some of those and how the console also behaves (we try to keep
> things in-sync'ish when possible). I need to double check the
> datasheets as well.

No worries, take your time!

> The series does contain some other patches around style and stuff.
> Some of them for me are entering that slippery slope of what to
> change. There are some different styles in use around the kernel (e.g.
> uint32_t etcetera is fine). But then if you use super strict mode on
> checkpatch half the kernel almost needs to be touched. I'm a bit
> skeptical on those kind of patches.

While I can understand that some of these patches might be perceived as
unnecessary noise, I still think the sooner we do this type of cleanup,
the better.  And the rationale is that we should aim for consistency, at
least for the actively maintained code.  This should also encourage any
new contributor who might touch the code to comply with the recommended
style and/or best practices, instead of potentially falling into the
trap of taking as reference some obsolete or non-conformant constructs,
which would only bring additional mess.

As a matter of fact, I initially planned to just focus on fixing up the
patches introduced as part of this series, in order to make checkpatch
happy.  While doing it, I quickly realized some additional
inconsistencies, hence I extended a bit the scope of the cleanup.  That
highlighted even more issues and after a few iterations I eventually
ended up fixing them all.

I'm aware that some of these checkpatch reports could be silenced by
operating in non-strict mode, by I don't really like the idea.  The
reason is that some (or most?!) maintainers prefer or even demand using
the strict mode, hence it's hard or impossible to always have then right
switch set, particularly when touching multiple subsystems.

Thanks,
Cristian