Hi Steve,
your commit 4068e5182ada ("regulator: da9062: DA9062 regulator
driver") is in today's linux-next tree (i.e., next-20150522) and adds
the following lines of code to drivers/regulator/Kconfig:
+config REGULATOR_DA9062
+ tristate "Dialog Semiconductor DA9062 regulators"
+ depends on MFD_DA9062
MFD_DA9062 is not defined in Kconfig, so that the dependency is always
false. Hence, the da9062-regulator driver cannot be compiled at the
current state.
Is there a patch queued somewhere to add the missing Kconfig option?
I detected this issue with scripts/checkkconfigsymbols.py by diffing
yesterday's and today's linux-next tree.
Kind regards,
Valentin
On 22 May 2015 09:20 Valentin Rothberg wrote:
> To: Opensource [Steve Twiss]
> Cc: [email protected]; [email protected]; Support Opensource; linux-
> [email protected]; Paul Bolle; Andreas Ruprecht; hengelein Stefan
> Subject: regulator: da9062: undefined Kconfig option MFD_DA9062
>
> Hi Steve,
>
> your commit 4068e5182ada ("regulator: da9062: DA9062 regulator
> driver") is in today's linux-next tree (i.e., next-20150522) and adds
> the following lines of code to drivers/regulator/Kconfig:
>
> +config REGULATOR_DA9062
> + tristate "Dialog Semiconductor DA9062 regulators"
> + depends on MFD_DA9062
>
> MFD_DA9062 is not defined in Kconfig, so that the dependency is always
> false. Hence, the da9062-regulator driver cannot be compiled at the
> current state.
>
> Is there a patch queued somewhere to add the missing Kconfig option?
Hi Valentin,
Mark applied the DA9062 regulator patch into linux-next yesterday, but looking at my
e-mail history the MFD components are still waiting to be applied I think. The MFD
component has been reviewed in earlier threads ...
[PATCH V1 1/6] mfd: da9062: DA9062 MFD core driver -- https://lkml.org/lkml/2015/4/17/519
[PATCH V2 1/4] mfd: da9062: DA9062 MFD core driver -- https://lkml.org/lkml/2015/5/14/531
[PATCH V3 1/4] mfd: da9062: DA9062 MFD core driver -- https://lkml.org/lkml/2015/5/19/523
And the last patch V3 for the MFD seems to have been a little quiet.
But, also there were three other patches with this set,
mfd: da9062: DA9062 MFD core driver
watchdog: da9062: DA9062 watchdog driver
devicetree: da9062: Add bindings for DA9062 driver
Hi Lee/Mark,
I'm not sure if the MFD part was missed or if I have not followed the rules properly
on my submissions for DA9062 MFD & regulators. Could I ask if you would take a
quick look please?
Regards,
Steve
> I detected this issue with scripts/checkkconfigsymbols.py by diffing
> yesterday's and today's linux-next tree.
>
> Kind regards,
> Valentin
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Fri, May 22, 2015 at 10:20:15AM +0200, Valentin Rothberg wrote:
> MFD_DA9062 is not defined in Kconfig, so that the dependency is always
> false. Hence, the da9062-regulator driver cannot be compiled at the
> current state.
> Is there a patch queued somewhere to add the missing Kconfig option?
This is totally normal for merging MFDs where the MFD goes in via the
MFD tree and the subsystem drivers go in via their trees. This way
subsystem maintainers don't have to sit through endless resends of the
core driver.
On Fri, 2015-05-22 at 10:35 +0100, Mark Brown wrote:
> > Is there a patch queued somewhere to add the missing Kconfig option?
>
> This is totally normal for merging MFDs where the MFD goes in via the
> MFD tree and the subsystem drivers go in via their trees. This way
> subsystem maintainers don't have to sit through endless resends of the
> core driver.
But we have to mention these things, for reasons like:
- the unknown symbol might simply be caused by a typo;
- the unknown symbol might change name while drivers depending on it are
already merged (we had such a situation last year, didn't we?);
- the symbol might not make it into the tree at all (or take _very_ long
to get there).
So every time a driver is added to linux-next that depends on an unknown
symbol a boring message like this will be sent. And people can simply
respond to it with a link to the patch that adds the missing symbol.
It's a bit annoying. But it helps in catching errors as early as
possible. And it gives the people looking into these kconfig oddities
the info they need to keep track of things.
Paul Bolle
On Fri, May 22, 2015 at 11:52:24AM +0200, Paul Bolle wrote:
> On Fri, 2015-05-22 at 10:35 +0100, Mark Brown wrote:
> > > Is there a patch queued somewhere to add the missing Kconfig option?
> > This is totally normal for merging MFDs where the MFD goes in via the
> > MFD tree and the subsystem drivers go in via their trees. This way
> > subsystem maintainers don't have to sit through endless resends of the
> > core driver.
> So every time a driver is added to linux-next that depends on an unknown
> symbol a boring message like this will be sent. And people can simply
> respond to it with a link to the patch that adds the missing symbol.
> It's a bit annoying. But it helps in catching errors as early as
> possible. And it gives the people looking into these kconfig oddities
> the info they need to keep track of things.
For the common cases like new things being added over multiple trees I
would expect people to be making some effort to filter these things
before reporting manually - for example here a couple of moments of
searching would have shown the rest of the series under review, or most
likely waiting a few weeks before reporting would allow the MFD to get
merged.
One effect of being too keen to report things is that a high false
positive rate will cause people to pay less attention, if the source is
usually just generating noise then it gets tuned out.
Hi Mark,
On Fri, May 22, 2015 at 12:12 PM, Mark Brown <[email protected]> wrote:
> On Fri, May 22, 2015 at 11:52:24AM +0200, Paul Bolle wrote:
>> On Fri, 2015-05-22 at 10:35 +0100, Mark Brown wrote:
>
>> > > Is there a patch queued somewhere to add the missing Kconfig option?
>
>> > This is totally normal for merging MFDs where the MFD goes in via the
>> > MFD tree and the subsystem drivers go in via their trees. This way
>> > subsystem maintainers don't have to sit through endless resends of the
>> > core driver.
>
>> So every time a driver is added to linux-next that depends on an unknown
>> symbol a boring message like this will be sent. And people can simply
>> respond to it with a link to the patch that adds the missing symbol.
>
>> It's a bit annoying. But it helps in catching errors as early as
>> possible. And it gives the people looking into these kconfig oddities
>> the info they need to keep track of things.
>
> For the common cases like new things being added over multiple trees I
> would expect people to be making some effort to filter these things
> before reporting manually - for example here a couple of moments of
> searching would have shown the rest of the series under review, or most
> likely waiting a few weeks before reporting would allow the MFD to get
> merged.
That was my initial approach, but it turned out that mailing lists are
not a good indicator if something is/will be/has been applied in the
big jungle of git trees. In many cases, the missing option is part of
some series somewhere but, for various reasons, got lost on the way.
Catching those also entails the noise.
> One effect of being too keen to report things is that a high false
> positive rate will cause people to pay less attention, if the source is
> usually just generating noise then it gets tuned out.
Note, that we keep a list of all reported items. If we know (for
certain) that something will be applied, we won't report anything
similar for a longer period of time.
I don't want those reports to be seen as spam, so I guess we need to
find a less noisy approach. It's something I do as a hobby besides my
PhD, so the only intention is to help, not to annoy people.
Kind regards,
Valentin
On Fri, May 22, 2015 at 12:53:16PM +0200, Valentin Rothberg wrote:
> > One effect of being too keen to report things is that a high false
> > positive rate will cause people to pay less attention, if the source is
> > usually just generating noise then it gets tuned out.
> Note, that we keep a list of all reported items. If we know (for
> certain) that something will be applied, we won't report anything
> similar for a longer period of time.
> I don't want those reports to be seen as spam, so I guess we need to
> find a less noisy approach. It's something I do as a hobby besides my
> PhD, so the only intention is to help, not to annoy people.
I'd expect that holding off on the initial report for a while (at least
a week but I'd guess longer) would probably avoid a lot of noise. Doing
it immediately is likely to generate lots of false positives simply
because coordinating down to a single day is a lot of effort.
On Fri, 2015-05-22 at 14:07 +0100, Mark Brown wrote:
> I'd expect that holding off on the initial report for a while (at least
> a week but I'd guess longer) would probably avoid a lot of noise.
I have data on roughly a year worth of linux-next and mainline releases.
I might try to see if I can extract from it things like:
- how often this (ie, pre merged drivers) happens;
- how long it takes for those issue to disappear; and
- what made these issue disappear (that might be hard, because it
probably requires cross checking my (incomplete) mail archive.)
This will take quite some time, I'm afraid. Provided it actually works,
that is.
> Doing
> it immediately is likely to generate lots of false positives simply
> because coordinating down to a single day is a lot of effort.
False positives is a bit ambiguous here. I don't think we often, if
ever, sent out notifications that were flat out wrong. But yes, some
issues can be expected to get resolved given a bit of time. The hard
part is knowing beforehand which issues will be resolved quickly and
which won't.
Thanks,
Paul Bolle
On Fri, 22 May 2015, Opensource [Steve Twiss] wrote:
> On 22 May 2015 09:20 Valentin Rothberg wrote:
>
> > To: Opensource [Steve Twiss]
> > Cc: [email protected]; [email protected]; Support Opensource; linux-
> > [email protected]; Paul Bolle; Andreas Ruprecht; hengelein Stefan
> > Subject: regulator: da9062: undefined Kconfig option MFD_DA9062
> >
> > Hi Steve,
> >
> > your commit 4068e5182ada ("regulator: da9062: DA9062 regulator
> > driver") is in today's linux-next tree (i.e., next-20150522) and adds
> > the following lines of code to drivers/regulator/Kconfig:
> >
> > +config REGULATOR_DA9062
> > + tristate "Dialog Semiconductor DA9062 regulators"
> > + depends on MFD_DA9062
> >
> > MFD_DA9062 is not defined in Kconfig, so that the dependency is always
> > false. Hence, the da9062-regulator driver cannot be compiled at the
> > current state.
> >
> > Is there a patch queued somewhere to add the missing Kconfig option?
>
> Hi Valentin,
>
> Mark applied the DA9062 regulator patch into linux-next yesterday, but looking at my
> e-mail history the MFD components are still waiting to be applied I think. The MFD
> component has been reviewed in earlier threads ...
>
> [PATCH V1 1/6] mfd: da9062: DA9062 MFD core driver -- https://lkml.org/lkml/2015/4/17/519
> [PATCH V2 1/4] mfd: da9062: DA9062 MFD core driver -- https://lkml.org/lkml/2015/5/14/531
> [PATCH V3 1/4] mfd: da9062: DA9062 MFD core driver -- https://lkml.org/lkml/2015/5/19/523
>
> And the last patch V3 for the MFD seems to have been a little quiet.
> But, also there were three other patches with this set,
>
> mfd: da9062: DA9062 MFD core driver
> watchdog: da9062: DA9062 watchdog driver
> devicetree: da9062: Add bindings for DA9062 driver
>
> Hi Lee/Mark,
>
> I'm not sure if the MFD part was missed or if I have not followed the rules properly
> on my submissions for DA9062 MFD & regulators. Could I ask if you would take a
> quick look please?
Nothing has been missed. I have been very busy, but I will get round
to reviewing. Your patch is marked as 'important' and is stilling in
my inbox. My plan is to clear my back-log today.
> > I detected this issue with scripts/checkkconfigsymbols.py by diffing
> > yesterday's and today's linux-next tree.
> >
> > Kind regards,
> > Valentin
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog