linux-kernel - Re: [PATCH v2 3/3] MAINTAINERS: Add maintainer for ROHM BH1745

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]

Date: Tue, 4 Jun 2024 16:38:28 +0300
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Javier Carrasco <javier.carrasco.cruz@...il.com>,
 Mudit Sharma <muditsharma.info@...il.com>, ivan.orlov0322@...il.com,
 jic23@...nel.org, lars@...afoo.de, krzk+dt@...nel.org, conor+dt@...nel.org,
 robh@...nel.org
Cc: linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
 devicetree@...r.kernel.org
Subject: Re: [PATCH v2 3/3] MAINTAINERS: Add maintainer for ROHM BH1745

On 6/4/24 15:53, Javier Carrasco wrote:
> On 04/06/2024 12:44, Mudit Sharma wrote:
>> On 03/06/2024 23:37, Javier Carrasco wrote:
>>> On 03/06/2024 18:21, Mudit Sharma wrote:
>>>> Add myself as maintainer for ROHM BH1745 colour sensor driver.
>>>>
>>>
>>> is there any special reason to have a separate patch for this? The
>>> addition to MAINTANERS for new drives is usually included in the patch
>>> that provides the driver itself.
>>
>> Adding this in a separate commit was just a pattern I notices with some
>> other drivers, for instance 3b4e0e9.
>>
>> If necessary and/or considered good practice, I can squash this in the
>> patch that brings in the driver.
> 
> Although there might be some cases where it was added separately, it is
> much more common that it is added to the patch that provides the driver.
> Some perfectionists even include the entry in the dt-bindings patch, and
> then add the link to the driver code in the driver patch. I believe that
> a simple squash would be ok, though.

I believe there is a notable case where having MAINTAINERS updates as a 
separate patch makes sense. When one creates drivers for a device which 
touches multiple subsystems, typically a set of MFD drivers. This is 
usually done as a set of subsystem specific patches, each adding 
subsystem specific file(s). In this case adding MAINTAINER info 
separately for each sub-driver will create unnecessary churn in the 
MAINTAINERS file - which I believe is already now a major source of 
merge conflicts. I am not sure of this is a reason to have MAINTAINERS 
updates in own patch though.

Furthermore, I've been instructed by Rob (AFAIR) to omit the dt-binding 
files from the MAINTAINERS because the maintainer information is already 
contained in the bindings itself.

Yours,
	-- Matti

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~