Message ID | db45c0ee76c3205b9253cb2200a79119c2f2b946.1666350457.git.mazziesaccount@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4242:0:0:0:0:0 with SMTP id s2csp645138wrr; Fri, 21 Oct 2022 04:35:18 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6jouPBG/1XIG6DCqoYiUdczneyMd8x6pFU6/Du96Me03rNYncPev1Xff9mYSu1VNDTm2R2 X-Received: by 2002:a63:5425:0:b0:450:738:9a78 with SMTP id i37-20020a635425000000b0045007389a78mr15543390pgb.429.1666352117740; Fri, 21 Oct 2022 04:35:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666352117; cv=none; d=google.com; s=arc-20160816; b=OnymFpDycoyIlgZ3CmdXDwEB4edZse8oHwXdsPW8BX4QryA874zsU2GXH2jJNiRjxI ohWk9RPJMs/JmYIAcvqqbrkzUfIDfU6mp5pfpp8VyDISdfP/ija+WVMA6oV/rD/T3eUV VWLTVv2HC4PABalTFHBenKDgl60wO5eHbosGzeh0A/qQOnMy/70MmujOYqjei0MZg0pD 34S0kAyxRA3dK1RXil4N7xKcSd2hHWBQ44bnj6edbybM/jJW/J+NVCi2AoDTCAnSIoIc s2CpLvslbJlyZHwzqsPFhIhPL9Ld5+Bbruy6SNdiJDXS/QBMW7UfZGlAz0Wku3R1UXB1 0o3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Aqpdzxh11piHyrsdYH/hMiJ+aTKND0zUJe+5TRJCoCA=; b=I6EkIU+uGedID5n36Spw+KHzHgCyxsWOE7XUuh55BjrS1DsohGmHoF1WDDd6v2bpv1 KGNAKbi1DW4QF/4DlDjFLVY7eMjVsNHCbJFfbuu24k/JRviFiLuKYAhNiiyKuglEl/kM rx3bRrrqZDs6fClKJ9QelFriakg55SR5whLuM0V/0GRCnTzo2ir67beKUgY/w3/VXkSb 1AqHxvBp122cRXKzvBX4qOBaLkkDfmN7+2mvlYahB4yERuHdU9SbGr52HtAVsu7MDrUa NZmYlAHalYUJzMJetQ1uW0sU1ATZSlgSRzXUJDwCiUSKBP2xGyP/0v4uUOb5kCGjNgjj eBqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Z0bH4IF8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j14-20020a170903024e00b001783ba6f79dsi30245533plh.494.2022.10.21.04.35.03; Fri, 21 Oct 2022 04:35:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Z0bH4IF8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229965AbiJULXa (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Fri, 21 Oct 2022 07:23:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229604AbiJULX2 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 21 Oct 2022 07:23:28 -0400 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C2BB1263093; Fri, 21 Oct 2022 04:23:21 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id g7so4550943lfv.5; Fri, 21 Oct 2022 04:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Aqpdzxh11piHyrsdYH/hMiJ+aTKND0zUJe+5TRJCoCA=; b=Z0bH4IF8UY8KyFRVfg89Ce9qfemn10tWWyc9UKPS5DUGTeX+mCHfG1Rl9Akl6r/MCx YeLIDU5fEhR1wlP2osDsN8bXKglWOOBIj7dL+Il5+JKJc8pD0poBJZUgXi9n4JrxcLqo IRtelBKZIP0czN0m0WulZbOhzyRuTIsnZTChhBVu7NRDtpj76wqDx9WsIL5lYVsT9W/m 40njxh8s1iO91waXHneCSNnRvnkYaW+Q0HS8p/VcTLMDWdv82I5iBkNNWxSDVbOg9IYe cJ5pUj4QCBKAWbUp3AeizEpFR3ikXcAkMowHS+/o8N7Df1mmduCtAG6x5Tto04Hu0sp0 KurQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Aqpdzxh11piHyrsdYH/hMiJ+aTKND0zUJe+5TRJCoCA=; b=39n9HEWBtPCQM3gQT9g/ojO/H97uaT01E10LwkwSGX25iI/3pakwQMnp9EDp22cy/j wRFc/I+RPg2wqhEaXO8PhrKt1YanDFTmqHgnQeC7/pOMANGSFbCWwF0/slaeEnl6VV7o moKDsifkYAyv9ityGIX0XtZYoKwlGj5eWUwl4QpFNesEuie5YAeBAs/NMMTBmZZqcXpz J2mX2WXONNnmPTg4qhJejasXRsanxL7w/AIf4InHYg+REJImRQQ3nWNdBOfc/01CGgzN xrveznXfwu8at31yt/CX96DG0FG17p6utP9KzVxVlwC30slLLp4wLYBMIV6uNn/daGLb FT2Q== X-Gm-Message-State: ACrzQf3LIlgAaGAtZRevbZZhz9WT8IxHOnCE/lIf361SfY2FCH5RYdkK VXjRKD3R9veB/OOX9Lmf450= X-Received: by 2002:a19:6558:0:b0:4a4:7fc2:7927 with SMTP id c24-20020a196558000000b004a47fc27927mr7038375lfj.674.1666351399998; Fri, 21 Oct 2022 04:23:19 -0700 (PDT) Received: from dc75zzyyyyyyyyyyyyyby-3.rev.dnainternet.fi (dc75zzyyyyyyyyyyyyyby-3.rev.dnainternet.fi. [2001:14ba:16f3:4a00::2]) by smtp.gmail.com with ESMTPSA id l2-20020a2e3e02000000b0026be1de1500sm3341009lja.79.2022.10.21.04.23.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Oct 2022 04:23:18 -0700 (PDT) Date: Fri, 21 Oct 2022 14:23:13 +0300 From: Matti Vaittinen <mazziesaccount@gmail.com> To: Matti Vaittinen <mazziesaccount@gmail.com>, Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Cc: Jonathan Cameron <jic23@kernel.org>, Lars-Peter Clausen <lars@metafoo.de>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Matti Vaittinen <mazziesaccount@gmail.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Dmitry Rokosov <DDRokosov@sberdevices.ru>, Nikita Yushchenko <nikita.yoush@cogentembedded.com>, Cosmin Tanislav <demonsingur@gmail.com>, Jagath Jog J <jagathjog1996@gmail.com>, linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v4 3/3] MAINTAINERS: Add KX022A maintainer entry Message-ID: <db45c0ee76c3205b9253cb2200a79119c2f2b946.1666350457.git.mazziesaccount@gmail.com> References: <cover.1666350457.git.mazziesaccount@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T137bSOkmQEtsLas" Content-Disposition: inline In-Reply-To: <cover.1666350457.git.mazziesaccount@gmail.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747296838184907458?= X-GMAIL-MSGID: =?utf-8?q?1747296838184907458?= |
Series |
iio: Support ROHM/Kionix kx022a
|
|
Commit Message
Matti Vaittinen
Oct. 21, 2022, 11:23 a.m. UTC
Add maintainer entry for ROHM/Kionix KX022A accelerometer sensor driver.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
---
MAINTAINERS | 5 +++++
1 file changed, 5 insertions(+)
Comments
On Fri, 2022-10-21 at 14:23 +0300, Matti Vaittinen wrote: > Add maintainer entry for ROHM/Kionix KX022A accelerometer sensor driver. > > Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> > --- > MAINTAINERS | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index cf0f18502372..3ab9c5f97dfe 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11435,6 +11435,11 @@ F: drivers/mfd/khadas-mcu.c > F: include/linux/mfd/khadas-mcu.h > F: drivers/thermal/khadas_mcu_fan.c > > +KIONIX/ROHM KX022A ACCELEROMETER > +R: Matti Vaittinen <mazziesaccount@gmail.com> > +S: Supported > +F: drivers/iio/accel/kionix-kx022a* How is this "S: Supported" without an M: maintainer? > + > KMEMLEAK > M: Catalin Marinas <catalin.marinas@arm.com> > S: Maintained > -- > 2.37.3 > >
Hi Joe, On 10/24/22 09:52, Joe Perches wrote: > On Fri, 2022-10-21 at 14:23 +0300, Matti Vaittinen wrote: >> Add maintainer entry for ROHM/Kionix KX022A accelerometer sensor driver. >> >> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> >> --- >> MAINTAINERS | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index cf0f18502372..3ab9c5f97dfe 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -11435,6 +11435,11 @@ F: drivers/mfd/khadas-mcu.c >> F: include/linux/mfd/khadas-mcu.h >> F: drivers/thermal/khadas_mcu_fan.c >> >> +KIONIX/ROHM KX022A ACCELEROMETER >> +R: Matti Vaittinen <mazziesaccount@gmail.com> >> +S: Supported >> +F: drivers/iio/accel/kionix-kx022a* > > How is this "S: Supported" without an M: maintainer? I am currently paid to work with the Kionix/ROHM upstream drivers. Hence I add 'S:' to ones I am looking after. The ideology why I have 'R' and not 'M' is summarized by my earlier patch: >> I can also add myself as a maintainer instead of a reviewer if it better >> suits iio maintainer. I however don't plan setting up my own public >> repository and hope the further patches will be merged via IIO tree. >> >> So, as Geert once explained to me - In that case the difference between >> me as a maintainer vs. a reviewer would be only really relevant to the >> subsystem (in this case IIO) maintainer. The subsystem maintainer who >> merges patches is allowed to take in changes acked by downstream >> maintainer w/o obligation to do thorough review. (Downstream maintainer is >> to be blamed if things explode :]). If ack is given by a reviewer, then >> the subsystem maintainer has the full responsibility and should always >> do the review. Or - this is how I remember our discussion went - feel >> free to correct me if I am wrong :] In any case - please let me know if >> you'd rather see M: not R: in front of my name for the kx022a. This seemed to be fine with Jonathan: https://lore.kernel.org/all/87ac9a5e-b5ba-82f3-c00c-75d5e6f01597@gmail.com/ I've also written a longer version of this in an LinkedIn article: https://www.linkedin.com/pulse/should-you-linux-kernel-maintainer-matti-vaittinen/ (I enjoy writing small stories. So doing an occasional small LinkedIn articles on working with the upstream is kind of an hobby for me.) Anyways, I don't see a contradiction with 'S + R' compared to 'S + M'. Well, please educate me if I am wrong :] Yours -- Matti -- Matti Vaittinen Linux kernel developer at ROHM Semiconductors Oulu Finland ~~ When things go utterly wrong vim users can always type :help! ~~
On Mon, 2022-10-24 at 07:24 +0000, Vaittinen, Matti wrote: > Hi Joe, > > On 10/24/22 09:52, Joe Perches wrote: > > On Fri, 2022-10-21 at 14:23 +0300, Matti Vaittinen wrote: > > > Add maintainer entry for ROHM/Kionix KX022A accelerometer sensor driver. > > > > > > Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> > > > --- > > > MAINTAINERS | 5 +++++ > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index cf0f18502372..3ab9c5f97dfe 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -11435,6 +11435,11 @@ F: drivers/mfd/khadas-mcu.c > > > F: include/linux/mfd/khadas-mcu.h > > > F: drivers/thermal/khadas_mcu_fan.c > > > > > > +KIONIX/ROHM KX022A ACCELEROMETER > > > +R: Matti Vaittinen <mazziesaccount@gmail.com> > > > +S: Supported > > > +F: drivers/iio/accel/kionix-kx022a* > > > > How is this "S: Supported" without an M: maintainer? > > I am currently paid to work with the Kionix/ROHM upstream drivers. Hence > I add 'S:' to ones I am looking after. > > The ideology why I have 'R' and not 'M' is summarized by my earlier patch: > > >> I can also add myself as a maintainer instead of a reviewer if it better > >> suits iio maintainer. I however don't plan setting up my own public > >> repository and hope the further patches will be merged via IIO tree. > >> > >> So, as Geert once explained to me - In that case the difference between > >> me as a maintainer vs. a reviewer would be only really relevant to the > >> subsystem (in this case IIO) maintainer. The subsystem maintainer who > >> merges patches is allowed to take in changes acked by downstream > >> maintainer w/o obligation to do thorough review. (Downstream > maintainer is > >> to be blamed if things explode :]). If ack is given by a reviewer, then > >> the subsystem maintainer has the full responsibility and should always > >> do the review. Or - this is how I remember our discussion went - feel > >> free to correct me if I am wrong :] In any case - please let me know if > >> you'd rather see M: not R: in front of my name for the kx022a. > > This seemed to be fine with Jonathan: > > https://lore.kernel.org/all/87ac9a5e-b5ba-82f3-c00c-75d5e6f01597@gmail.com/ > > I've also written a longer version of this in an LinkedIn article: > https://www.linkedin.com/pulse/should-you-linux-kernel-maintainer-matti-vaittinen/ > > (I enjoy writing small stories. So doing an occasional small LinkedIn > articles on working with the upstream is kind of an hobby for me.) > > Anyways, I don't see a contradiction with 'S + R' compared to 'S + M'. > Well, please educate me if I am wrong :] The subsystem is one thing, someone outside of KIONIX/ROHM may be supporting the subsystem. If this _particular_ driver is "supported" there should be an individual listed as its actual maintainer, not just a person that might review submitted patches. S: *Status*, one of the following: Supported: Someone is actually paid to look after this. Maintained: Someone actually looks after it. "this" is this particular driver, not any subsystem "above" it.
On 10/24/22 13:40, Joe Perches wrote: > On Mon, 2022-10-24 at 07:24 +0000, Vaittinen, Matti wrote: >> Hi Joe, >> >> On 10/24/22 09:52, Joe Perches wrote: >>> On Fri, 2022-10-21 at 14:23 +0300, Matti Vaittinen wrote: >>>> Add maintainer entry for ROHM/Kionix KX022A accelerometer sensor driver. >>>> >>>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> >>>> --- >>>> MAINTAINERS | 5 +++++ >>>> 1 file changed, 5 insertions(+) >>>> >>>> diff --git a/MAINTAINERS b/MAINTAINERS >>>> index cf0f18502372..3ab9c5f97dfe 100644 >>>> --- a/MAINTAINERS >>>> +++ b/MAINTAINERS >>>> @@ -11435,6 +11435,11 @@ F: drivers/mfd/khadas-mcu.c >>>> F: include/linux/mfd/khadas-mcu.h >>>> F: drivers/thermal/khadas_mcu_fan.c >>>> >>>> +KIONIX/ROHM KX022A ACCELEROMETER >>>> +R: Matti Vaittinen <mazziesaccount@gmail.com> >>>> +S: Supported >>>> +F: drivers/iio/accel/kionix-kx022a* >>> >>> How is this "S: Supported" without an M: maintainer? >> >> I am currently paid to work with the Kionix/ROHM upstream drivers. Hence >> I add 'S:' to ones I am looking after. >> >> The ideology why I have 'R' and not 'M' is summarized by my earlier patch: >> >> >> I can also add myself as a maintainer instead of a reviewer if it better >> >> suits iio maintainer. I however don't plan setting up my own public >> >> repository and hope the further patches will be merged via IIO tree. >> >> >> >> So, as Geert once explained to me - In that case the difference between >> >> me as a maintainer vs. a reviewer would be only really relevant to the >> >> subsystem (in this case IIO) maintainer. The subsystem maintainer who >> >> merges patches is allowed to take in changes acked by downstream >> >> maintainer w/o obligation to do thorough review. (Downstream >> maintainer is >> >> to be blamed if things explode :]). If ack is given by a reviewer, then >> >> the subsystem maintainer has the full responsibility and should always >> >> do the review. Or - this is how I remember our discussion went - feel >> >> free to correct me if I am wrong :] In any case - please let me know if >> >> you'd rather see M: not R: in front of my name for the kx022a. >> >> This seemed to be fine with Jonathan: >> >> https://lore.kernel.org/all/87ac9a5e-b5ba-82f3-c00c-75d5e6f01597@gmail.com/ >> >> I've also written a longer version of this in an LinkedIn article: >> https://www.linkedin.com/pulse/should-you-linux-kernel-maintainer-matti-vaittinen/ >> >> (I enjoy writing small stories. So doing an occasional small LinkedIn >> articles on working with the upstream is kind of an hobby for me.) >> >> Anyways, I don't see a contradiction with 'S + R' compared to 'S + M'. >> Well, please educate me if I am wrong :] > > The subsystem is one thing, someone outside of KIONIX/ROHM may be > supporting the subsystem. If this _particular_ driver is "supported" Yes. I am supporting this particular driver, assuming the support means ability and willingness to review and even occsionally test some changes - or to occasionally even discuss with the ASIC designers. Basically, what I don't do (and what in my head distinguishes me from "real" maintainers) is hosting the a public git tree. > there should be an individual listed as its actual maintainer, not > just a person that might review submitted patches. I don't think listing me as Maintainer or Reviewer will in practice change how I am looking after the code. I will get the patches/questions regarding the driver even if I am listed as a reviewer and not a as a maintainer, right? Besides, "a person that might review" is not any worse than "a person that might maintain"... I think there are quite a few MAINTAINER entries with 'M: <foo@bar>' who are absent these days. I would not value 'M' over 'R'. > > S: *Status*, one of the following: > Supported: Someone is actually paid to look after this. > Maintained: Someone actually looks after it. > > "this" is this particular driver, not any subsystem "above" it. Yes. And as I wrote, I am paid to look after this driver as well as other drivers I've submitted upstream for ROHM components (Kionix being part of ROHM these days). I have used this Supported + Reviewer combination for all other IC drivers as well. This is why, by definition, the S eg. supported is correct. Question is whether one supporting a driver must be a maintainer? If this is the case, then I'd better review all of my MAINTAINER entries. However, I (still) don't see the problem of having a reviewer supporting the IC. Yours -- Matti -- Matti Vaittinen Linux kernel developer at ROHM Semiconductors Oulu Finland ~~ When things go utterly wrong vim users can always type :help! ~~
On Mon, 2022-10-24 at 10:56 +0000, Vaittinen, Matti wrote: > On 10/24/22 13:40, Joe Perches wrote: [] > > > > S: *Status*, one of the following: > > Supported: Someone is actually paid to look after this. > Maintained: Someone actually looks after it. > > > > "this" is this particular driver, not any subsystem "above" it. > > Yes. And as I wrote, I am paid to look after this driver as well as > other drivers I've submitted upstream for ROHM components (Kionix being > part of ROHM these days). I have used this Supported + Reviewer > combination for all other IC drivers as well. This is why, by > definition, the S eg. supported is correct. Question is whether one > supporting a driver must be a maintainer? If this is the case, then I'd > better review all of my MAINTAINER entries. However, I (still) don't see > the problem of having a reviewer supporting the IC. Please do not conflate a "reviewer", someone that "might" look at a patch and offer comments, and a "supporter", someone that actively supports the driver/subsystem. I don't have a tree that is pulled yet I am the get_maintainer and checkpatch maintainer.
On 10/24/22 14:08, Joe Perches wrote: > On Mon, 2022-10-24 at 10:56 +0000, Vaittinen, Matti wrote: >> On 10/24/22 13:40, Joe Perches wrote: > [] >>> >>> S: *Status*, one of the following: >>> Supported: Someone is actually paid to look after this. > Maintained: Someone actually looks after it. >>> >>> "this" is this particular driver, not any subsystem "above" it. >> >> Yes. And as I wrote, I am paid to look after this driver as well as >> other drivers I've submitted upstream for ROHM components (Kionix being >> part of ROHM these days). I have used this Supported + Reviewer >> combination for all other IC drivers as well. This is why, by >> definition, the S eg. supported is correct. Question is whether one >> supporting a driver must be a maintainer? If this is the case, then I'd >> better review all of my MAINTAINER entries. However, I (still) don't see >> the problem of having a reviewer supporting the IC. > > Please do not conflate a "reviewer", someone that "might" look at > a patch and offer comments, and a "supporter", someone that actively > supports the driver/subsystem. I don't have a tree that is pulled > yet I am the get_maintainer and checkpatch maintainer. I'd like to ask what the "actively support a driver" means in practice as I am pretty sure that is what I do. So perhaps I should change myself from a reviewer to a maintainer for these drivers then. Yours -- Matti -- Matti Vaittinen Linux kernel developer at ROHM Semiconductors Oulu Finland ~~ When things go utterly wrong vim users can always type :help! ~~
diff --git a/MAINTAINERS b/MAINTAINERS index cf0f18502372..3ab9c5f97dfe 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11435,6 +11435,11 @@ F: drivers/mfd/khadas-mcu.c F: include/linux/mfd/khadas-mcu.h F: drivers/thermal/khadas_mcu_fan.c +KIONIX/ROHM KX022A ACCELEROMETER +R: Matti Vaittinen <mazziesaccount@gmail.com> +S: Supported +F: drivers/iio/accel/kionix-kx022a* + KMEMLEAK M: Catalin Marinas <catalin.marinas@arm.com> S: Maintained