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! ~~
