Hello All,
In short - I consider adding myself in MAINTAINERs for the ROHM IC
drivers I've authored. I would like to get your opinion as subsystem
maintainers on the area where these driver belong. If you don't care -
then no need to read further :) If you do read, then I would appreciate
hearing about your expectations regarding reviews, ACKs etc.
Longer story, I have contributed drivers for ROHM PMICs
BD71837/BD71847/BD71850, BD70528, BD71828/BD71878 and ROHM charger IC
BD99954. I did also refactor the linear_ranges code out of the
regulator framework. Now I am working on with another PMIC driver
(regulators/watchdog) which I hope to end up in upstream at autumn
after the proper testing. There is also some pieces in regmap-irq which
I have added.
I would like to participate in reviewing work for patches to these
drivers (and perhaps the linear_ranges) and possibly set up some test
jobs where I can run some tests involving some of the PMICs. I hope
this helps the community too.
I would also benefit from being informed when a fix is sent to one of
these areas as I am anyways paid to be hosting some out-of-tree
additions to these drivers. So my git tree would benefit from getting
the odd fixes upstream is getting. Reviewing mails would serve as a
heads up for me.
Thus I consider adding few entries to MAINTAINERs in order to be
getting the patches for review/test. What I don't consider doing is
integrating the patches in "official Linux" - Eg. all patches should
still go upstream via your trees.
What kind of participation would you expect/appreciate from me if I
added myself in MAINTAINERS for these drivers I authored? Any
objections to that? (I don't really know how MAINTAINERs entries should
be added - and I didn't [easily] find up-to-date explanation to that).
For where I can be of help - I believe I am technically competent for
reviewing C-code. I am not competent for reviewing all styling details
- and I am not too useful what comes to YAML - this syntax is still
really alien to me. Yet I think I have some insight to things the DT
yaml is describing (meaning ROHM HW) :)
I add below the list of files / subsystem.
Regulator:
bd70528-regulator.c
bd71828-regulator.c
bd718x7-regulator.c
rohm-regulator.c
(lib/linear_ranges.c
lib/test_linear_ranges.c?
include/linux/linear_range.h - Who should maintain these?)
Power-supply:
bd70528-charger.c
bd71827-power.c
bd99954-charger.c
bd99954-charger.h
MFD:
rohm-bd70528.c
rohm-bd71828.c
rohm-bd718x7.c
include/linux/mfd/rohm-shared.h
include/linux/mfd/rohm-bd71828.h
include/linux/mfd/rohm-bd70528.h
include/linux/mfd/rohm-generic.h
include/linux/mfd/rohm-bd718x7.h
GPIO:
gpio-bd70528.c
gpio-bd71828.c
RTC:
rtc-bd70528.c
Watchdog:
bd70528_wdt.c
Clk:
clk-bd718x7.c
DT:
Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml
Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml
Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml
Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml
Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml
Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml
Documentation/devicetree/bindings/mfd/rohm,bd70528-pmic.txt
Documentation/devicetree/bindings/regulator/rohm,bd70528-regulator.txt
Best Regards
Matti Vaittinen
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
"non cogito me" dixit Rene Descarte, deinde evanescavit
(Thanks for the translation Simon)
On Mon, May 18, 2020 at 07:38:25AM +0000, Vaittinen, Matti wrote:
> What kind of participation would you expect/appreciate from me if I
> added myself in MAINTAINERS for these drivers I authored? Any
Mainly just reviewing patches.
> objections to that? (I don't really know how MAINTAINERs entries should
> be added - and I didn't [easily] find up-to-date explanation to that).
Send a patch, often along with other stuff that's going on. I'd guess
MFD would be as good a tree as any for it to go via.
On Mon, 18 May 2020, Vaittinen, Matti wrote:
> Hello All,
>
> In short - I consider adding myself in MAINTAINERs for the ROHM IC
> drivers I've authored. I would like to get your opinion as subsystem
> maintainers on the area where these driver belong. If you don't care -
> then no need to read further :) If you do read, then I would appreciate
> hearing about your expectations regarding reviews, ACKs etc.
It's fine to add yourself to MAINTAINERS for this purpose.
Either as M (mail-to) or R (designated reviewer) is fine.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hi,
On Mon, May 18, 2020 at 07:38:25AM +0000, Vaittinen, Matti wrote:
> Hello All,
>
> In short - I consider adding myself in MAINTAINERs for the ROHM IC
> drivers I've authored. I would like to get your opinion as subsystem
> maintainers on the area where these driver belong. If you don't care -
> then no need to read further :) If you do read, then I would appreciate
> hearing about your expectations regarding reviews, ACKs etc.
>
> Longer story, I have contributed drivers for ROHM PMICs
> BD71837/BD71847/BD71850, BD70528, BD71828/BD71878 and ROHM charger IC
> BD99954. I did also refactor the linear_ranges code out of the
> regulator framework. Now I am working on with another PMIC driver
> (regulators/watchdog) which I hope to end up in upstream at autumn
> after the proper testing. There is also some pieces in regmap-irq which
> I have added.
>
> I would like to participate in reviewing work for patches to these
> drivers (and perhaps the linear_ranges) and possibly set up some test
> jobs where I can run some tests involving some of the PMICs. I hope
> this helps the community too.
>
> I would also benefit from being informed when a fix is sent to one of
> these areas as I am anyways paid to be hosting some out-of-tree
> additions to these drivers. So my git tree would benefit from getting
> the odd fixes upstream is getting. Reviewing mails would serve as a
> heads up for me.
>
> Thus I consider adding few entries to MAINTAINERs in order to be
> getting the patches for review/test. What I don't consider doing is
> integrating the patches in "official Linux" - Eg. all patches should
> still go upstream via your trees.
>
> What kind of participation would you expect/appreciate from me if I
> added myself in MAINTAINERS for these drivers I authored? Any
> objections to that? (I don't really know how MAINTAINERs entries should
> be added - and I didn't [easily] find up-to-date explanation to that).
> For where I can be of help - I believe I am technically competent for
> reviewing C-code. I am not competent for reviewing all styling details
> - and I am not too useful what comes to YAML - this syntax is still
> really alien to me. Yet I think I have some insight to things the DT
> yaml is describing (meaning ROHM HW) :)
>
> I add below the list of files / subsystem.
>
> Regulator:
> bd70528-regulator.c
> bd71828-regulator.c
> bd718x7-regulator.c
> rohm-regulator.c
> (lib/linear_ranges.c
> lib/test_linear_ranges.c?
> include/linux/linear_range.h - Who should maintain these?)
>
> Power-supply:
> bd70528-charger.c
> bd71827-power.c
> bd99954-charger.c
> bd99954-charger.h
>
> MFD:
> rohm-bd70528.c
> rohm-bd71828.c
> rohm-bd718x7.c
> include/linux/mfd/rohm-shared.h
> include/linux/mfd/rohm-bd71828.h
> include/linux/mfd/rohm-bd70528.h
> include/linux/mfd/rohm-generic.h
> include/linux/mfd/rohm-bd718x7.h
>
> GPIO:
> gpio-bd70528.c
> gpio-bd71828.c
>
> RTC:
> rtc-bd70528.c
>
> Watchdog:
> bd70528_wdt.c
>
> Clk:
> clk-bd718x7.c
>
> DT:
> Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml
> Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
> Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml
> Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml
> Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml
> Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
> Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml
> Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml
> Documentation/devicetree/bindings/mfd/rohm,bd70528-pmic.txt
> Documentation/devicetree/bindings/regulator/rohm,bd70528-regulator.txt
>
> Best Regards
> Matti Vaittinen
I suggest to just send something like this entry adapted to the ROHM
drivers:
------------------------------------------------------------
TI BQ27XXX POWER SUPPLY DRIVER
R: Andrew F. Davis <[email protected]>
F: drivers/power/supply/bq27xxx_battery.c
F: drivers/power/supply/bq27xxx_battery_i2c.c
F: include/linux/power/bq27xxx_battery.h
------------------------------------------------------------
It will result in get_maintainer.pl to output this:
$ ./scripts/get_maintainer.pl -f drivers/power/supply/bq27xxx_battery.c
"Andrew F. Davis" <[email protected]> (reviewer:TI BQ27XXX POWER SUPPLY DRIVER)
"Pali Roh?r" <[email protected]> (reviewer:NOKIA N900 POWER SUPPLY DRIVERS)
Sebastian Reichel <[email protected]> (maintainer:POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS)
[email protected] (open list:POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS)
[email protected] (open list)
For drivers with a dedicated reviewer I wait some time for their
feedback.
For the DT YAML bindings you don't need to do anything:
https://lore.kernel.org/lkml/e85006456d9dbae55286c67ac5263668a72f5b58.1588022228.git.joe@perches.com/
-- Sebastian
Thanks for reply Mark,
On Mon, 2020-05-18 at 11:28 +0100, Mark Brown wrote:
> On Mon, May 18, 2020 at 07:38:25AM +0000, Vaittinen, Matti wrote:
>
> > What kind of participation would you expect/appreciate from me if I
> > added myself in MAINTAINERS for these drivers I authored? Any
>
> Mainly just reviewing patches.
I can do that :)
>
> > objections to that? (I don't really know how MAINTAINERs entries
> > should
> > be added - and I didn't [easily] find up-to-date explanation to
> > that).
>
> Send a patch, often along with other stuff that's going on. I'd
> guess
> MFD would be as good a tree as any for it to go via.
Ah, yes :] I was guessing this is the technical way of adding the
entry. I was more wondering what is expected from maintainer (you
answered that above) and whether there is some criteria as to who can
be a maintainer.
While we are at it - Mark, would you consider following to be fully
inappropriate:
LINEAR RANGES HELPERS
M: Mark Brown <[email protected]>
R: Matti Vaittinen <[email protected]>
F: lib/linear_ranges.c
F: lib/test_linear_ranges.c
F: include/linux/linear_range.h
I think that regulators being the main user for linear_ranges the
changes there should go in via your tree - and you should probably be
watching over them anyways :)
Best Regards
Matti Vaittinen
On Mon, May 18, 2020 at 11:36:56AM +0000, Vaittinen, Matti wrote:
> On Mon, 2020-05-18 at 11:28 +0100, Mark Brown wrote:
> While we are at it - Mark, would you consider following to be fully
> inappropriate:
> LINEAR RANGES HELPERS
> M: Mark Brown <[email protected]>
> R: Matti Vaittinen <[email protected]>
> F: lib/linear_ranges.c
> F: lib/test_linear_ranges.c
> F: include/linux/linear_range.h
> I think that regulators being the main user for linear_ranges the
> changes there should go in via your tree - and you should probably be
> watching over them anyways :)
Sure, that's fine.
Hello Lee,
On Mon, 2020-05-18 at 11:41 +0100, Lee Jones wrote:
> On Mon, 18 May 2020, Vaittinen, Matti wrote:
>
> > Hello All,
> >
> > In short - I consider adding myself in MAINTAINERs for the ROHM IC
> > drivers I've authored. I would like to get your opinion as
> > subsystem
> > maintainers on the area where these driver belong. If you don't
> > care -
> > then no need to read further :) If you do read, then I would
> > appreciate
> > hearing about your expectations regarding reviews, ACKs etc.
>
> It's fine to add yourself to MAINTAINERS for this purpose.
>
> Either as M (mail-to) or R (designated reviewer) is fine.
Thanks! Appreciate your help. So, if I understand this correctly the
difference between M and R is that M implies the patches go to upstream
via person listed in M. So in my case - as I hope patches to these
drivers are still going to your tree - the R would be more appropriate,
right? M sounds nice though - it's a good letter (says someone whose
name is Matti ;] )
Br,
Matti Vaittinen
Hello Sebastian,
On Mon, 2020-05-18 at 13:00 +0200, Sebastian Reichel wrote:
> Hi,
>
> On Mon, May 18, 2020 at 07:38:25AM +0000, Vaittinen, Matti wrote:
> > Hello All,
> >
> > In short - I consider adding myself in MAINTAINERs for the ROHM IC
> > drivers I've authored. I would like to get your opinion as
> > subsystem
> > maintainers on the area where these driver belong. If you don't
> > care -
> > then no need to read further :) If you do read, then I would
> > appreciate
> > hearing about your expectations regarding reviews, ACKs etc.
> >
> > Longer story, I have contributed drivers for ROHM PMICs
> > BD71837/BD71847/BD71850, BD70528, BD71828/BD71878 and ROHM charger
> > IC
> > BD99954. I did also refactor the linear_ranges code out of the
> > regulator framework. Now I am working on with another PMIC driver
> > (regulators/watchdog) which I hope to end up in upstream at autumn
> > after the proper testing. There is also some pieces in regmap-irq
> > which
> > I have added.
> >
> > I would like to participate in reviewing work for patches to these
> > drivers (and perhaps the linear_ranges) and possibly set up some
> > test
> > jobs where I can run some tests involving some of the PMICs. I hope
> > this helps the community too.
> >
> > I would also benefit from being informed when a fix is sent to one
> > of
> > these areas as I am anyways paid to be hosting some out-of-tree
> > additions to these drivers. So my git tree would benefit from
> > getting
> > the odd fixes upstream is getting. Reviewing mails would serve as a
> > heads up for me.
> >
> > Thus I consider adding few entries to MAINTAINERs in order to be
> > getting the patches for review/test. What I don't consider doing is
> > integrating the patches in "official Linux" - Eg. all patches
> > should
> > still go upstream via your trees.
> >
> > What kind of participation would you expect/appreciate from me if I
> > added myself in MAINTAINERS for these drivers I authored? Any
> > objections to that? (I don't really know how MAINTAINERs entries
> > should
> > be added - and I didn't [easily] find up-to-date explanation to
> > that).
> > For where I can be of help - I believe I am technically competent
> > for
> > reviewing C-code. I am not competent for reviewing all styling
> > details
> > - and I am not too useful what comes to YAML - this syntax is still
> > really alien to me. Yet I think I have some insight to things the
> > DT
> > yaml is describing (meaning ROHM HW) :)
> >
> > I add below the list of files / subsystem.
> >
> > Regulator:
> > bd70528-regulator.c
> > bd71828-regulator.c
> > bd718x7-regulator.c
> > rohm-regulator.c
> > (lib/linear_ranges.c
> > lib/test_linear_ranges.c?
> > include/linux/linear_range.h - Who should maintain these?)
> >
> > Power-supply:
> > bd70528-charger.c
> > bd71827-power.c
> > bd99954-charger.c
> > bd99954-charger.h
> >
> > MFD:
> > rohm-bd70528.c
> > rohm-bd71828.c
> > rohm-bd718x7.c
> > include/linux/mfd/rohm-shared.h
> > include/linux/mfd/rohm-bd71828.h
> > include/linux/mfd/rohm-bd70528.h
> > include/linux/mfd/rohm-generic.h
> > include/linux/mfd/rohm-bd718x7.h
> >
> > GPIO:
> > gpio-bd70528.c
> > gpio-bd71828.c
> >
> > RTC:
> > rtc-bd70528.c
> >
> > Watchdog:
> > bd70528_wdt.c
> >
> > Clk:
> > clk-bd718x7.c
> >
> > DT:
> > Documentation/devicetree/bindings/power/supply/rohm,bd99954.yaml
> > Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
> > Documentation/devicetree/bindings/mfd/rohm,bd71847-pmic.yaml
> > Documentation/devicetree/bindings/regulator/rohm,bd71837-
> > regulator.yaml
> > Documentation/devicetree/bindings/regulator/rohm,bd71847-
> > regulator.yaml
> > Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
> > Documentation/devicetree/bindings/leds/rohm,bd71828-leds.yaml
> > Documentation/devicetree/bindings/regulator/rohm,bd71828-
> > regulator.yaml
> > Documentation/devicetree/bindings/mfd/rohm,bd70528-pmic.txt
> > Documentation/devicetree/bindings/regulator/rohm,bd70528-
> > regulator.txt
> >
> > Best Regards
> > Matti Vaittinen
>
> I suggest to just send something like this entry adapted to the ROHM
> drivers:
>
> ------------------------------------------------------------
> TI BQ27XXX POWER SUPPLY DRIVER
> R: Andrew F. Davis <[email protected]>
> F: drivers/power/supply/bq27xxx_battery.c
> F: drivers/power/supply/bq27xxx_battery_i2c.c
> F: include/linux/power/bq27xxx_battery.h
> ------------------------------------------------------------
>
> It will result in get_maintainer.pl to output this:
>
> $ ./scripts/get_maintainer.pl -f
> drivers/power/supply/bq27xxx_battery.c
> "Andrew F. Davis" <[email protected]> (reviewer:TI BQ27XXX POWER SUPPLY
> DRIVER)
> "Pali Rohár" <[email protected]> (reviewer:NOKIA N900 POWER SUPPLY
> DRIVERS)
> Sebastian Reichel <[email protected]> (maintainer:POWER SUPPLY
> CLASS/SUBSYSTEM and DRIVERS)
> [email protected] (open list:POWER SUPPLY CLASS/SUBSYSTEM and
> DRIVERS)
> [email protected] (open list)
>
> For drivers with a dedicated reviewer I wait some time for their
> feedback.
Thanks for your kind response :) I do appreciate your help!
> For the DT YAML bindings you don't need to do anything:
>
> https://lore.kernel.org/lkml/e85006456d9dbae55286c67ac5263668a72f5b58.1588022228.git.joe@perches.com/
Oh, this makes file-list much shorter :) Thanks for pointing it out! It
leaves me to just list the two old bd70528 binding txt documents until
they'll be yamlified.
Best regards:
Matti