[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17b23723-d0d0-4744-9828-cef316cf3fb7@gmail.com>
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! ~~
Powered by blists - more mailing lists