[not urgent] ROHM PMIC/Charger IC driver maintenance.

[not urgent] ROHM PMIC/Charger IC driver maintenance.

[Vaittinen, Matti]

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)

Re: [not urgent] ROHM PMIC/Charger IC driver maintenance.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [not urgent] ROHM PMIC/Charger IC driver maintenance.

[Lee Jones]

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

Re: [not urgent] ROHM PMIC/Charger IC driver maintenance.

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 4986 bytes --]

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 <afd@ti.com>
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" <afd@ti.com> (reviewer:TI BQ27XXX POWER SUPPLY DRIVER)
"Pali Rohár" <pali@kernel.org> (reviewer:NOKIA N900 POWER SUPPLY DRIVERS)
Sebastian Reichel <sre@kernel.org> (maintainer:POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS)
linux-pm@vger.kernel.org (open list:POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS)
linux-kernel@vger.kernel.org (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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [not urgent] ROHM PMIC/Charger IC driver maintenance.

[Vaittinen, Matti]

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 <broonie@kernel.org>
R:      Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
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

Re: [not urgent] ROHM PMIC/Charger IC driver maintenance.

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

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 <broonie@kernel.org>
> R:      Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [not urgent] ROHM PMIC/Charger IC driver maintenance.

[Vaittinen, Matti]

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

Re: [not urgent] ROHM PMIC/Charger IC driver maintenance.

[Vaittinen, Matti]

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 <afd@ti.com>
> 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" <afd@ti.com> (reviewer:TI BQ27XXX POWER SUPPLY
> DRIVER)
> "Pali Rohár" <pali@kernel.org> (reviewer:NOKIA N900 POWER SUPPLY
> DRIVERS)
> Sebastian Reichel <sre@kernel.org> (maintainer:POWER SUPPLY
> CLASS/SUBSYSTEM and DRIVERS)
> linux-pm@vger.kernel.org (open list:POWER SUPPLY CLASS/SUBSYSTEM and
> DRIVERS)
> linux-kernel@vger.kernel.org (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