Re: [PATCH] lib: linear_ranges: Add missing MODULE_LICENSE()

[Vaittinen, Matti]

Morning folks,

On Sun, 2020-05-10 at 21:50 +0200, Sebastian Reichel wrote:
> Hi,
> 
> On Sat, May 09, 2020 at 06:15:19PM +0300, Matti Vaittinen wrote:
> > When linear_ranges is compiled as module we get warning
> > about missing MODULE_LICENSE(). Fix it by adding
> > MODULE_LICENSE("GPL") as is suggested by SPDX and EXPORTs.
> > 
> > Signed-off-by: Matti Vaittinen <matti.vaittinen@xxxxxxxxxxxxxxxxx>
> > ---
> > 
> > I saw Mark applied the linear-ranges patch. So I sent this fix as
> > incremental patch - but I still use the same Linus tree as a base
> > of
> > this fix - the linear-ranges file should be unchanged in regulator
> > tree.
> > If this does not apply I can clone regulator tree and create this
> > fix on
> > it.
> > 
> > I don't know if this is the correct way to fix this as the linear-
> > ranges
> > should be merged to power-supply tree.
> > 
> > I guess we can either:
> > - Use this patch to fix regulator tree and create fixed tag for
> >   power-supply(?)
> > - Add this fix in the original series and resend whole series(?)
> > - re-create the series and drop the already applied patches. Add
> > this
> >   fix as a fixup patch in new series and apply it to power-supply
> > tree
> >   after the linear-ranges from regulator is merged to power-supply.
> > 
> >  Please adviece me if this patch is not the way to go.
> > 
> > Oh, and I am really sorry for the trouble. I saw I had regulators=y
> > in all of my compilations due to some pincontrol dependencies. So
> > linear-ranges was not built as module in any of my test
> > compilations :(
> > 
> > Thanks for testing Mark!
> 
> Reviewed-by: Sebastian Reichel <sebastian.reichel@xxxxxxxxxxxxx>
> 
> I think it makes sense to just queue this through the regulator tree.

That's absolutely fine with me. It just means that the power-supply
tree has this compilation issue until fix applied to regulator tree
gets merged. But as I said in another mail, this issue is expected to
be triggered only in limited number of test builds.

> Apart from that you should add a MAINTAINERS file entry for the
> linear_ranges lib. Main user is regulators, so future patches should
> probably be queued through its tree.

This is something I have been thinking in general. I feel a tiny bit
bad about adding all my ROHM component drivers to be maintained by
others. I have recently polluted the kernel with few drivers and I feel
I should help by reviewing patches for those.

I might be able to set-up some machinery to compile (and also do some
_really_ limited testing) of the changes to these ROHM drivers - and
possibly set-up a git tree for them. Do you think it would be
beneficial? I think we can at some point consider having separate
maintainer entries for BD718x7, BD70528, BD71828 and BD99954 (+ some
coming driver(s) if it helps.

What comes to linear_ranges - Mark, could you be added as a maintainer
for linear_ranges.c and test_linear_ranges.c (at least for now?) I can
try do some reviewing too if it helps.

--Matti