[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6cc724a6fe5b84f74b381904d16b04b55a7c0a64.camel@fi.rohmeurope.com>
Date: Mon, 11 May 2020 06:55:22 +0000
From: "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To: "sebastian.reichel@...labora.com" <sebastian.reichel@...labora.com>
CC: "brendanhiggins@...gle.com" <brendanhiggins@...gle.com>,
"mazziesaccount@...il.com" <mazziesaccount@...il.com>,
"broonie@...nel.org" <broonie@...nel.org>,
"Okada, Koki" <Koki.Okada@...rohmeurope.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Pakanen, Risto" <Risto.Pakanen@...rohmeurope.com>,
"lgirdwood@...il.com" <lgirdwood@...il.com>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [PATCH] lib: linear_ranges: Add missing MODULE_LICENSE()
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@...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@...labora.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
Powered by blists - more mailing lists