Messages in this thread | | | From | "Vaittinen, Matti" <> | Subject | Re: [PATCH] lib: linear_ranges: Add missing MODULE_LICENSE() | Date | Mon, 11 May 2020 06:55:22 +0000 |
| |
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@fi.rohmeurope.com> > > --- > > > > 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@collabora.com> > > 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
| |