regulator: da9062: undefined Kconfig option MFD_DA9062

regulator: da9062: undefined Kconfig option MFD_DA9062

[Valentin Rothberg]

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

RE: regulator: da9062: undefined Kconfig option MFD_DA9062

[Opensource [Steve Twiss]]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2150 bytes --]

On 22 May 2015 09:20 Valentin Rothberg wrote:

> To: Opensource [Steve Twiss]
> Cc: broonie@kernel.org; lgirdwood@gmail.com; Support Opensource; linux-
> kernel@vger.kernel.org; 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Ç+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: regulator: da9062: undefined Kconfig option MFD_DA9062

[Mark Brown]

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

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: regulator: da9062: undefined Kconfig option MFD_DA9062

[Paul Bolle]

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

Re: regulator: da9062: undefined Kconfig option MFD_DA9062

[Mark Brown]

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

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: regulator: da9062: undefined Kconfig option MFD_DA9062

[Valentin Rothberg]

Hi Mark,

On Fri, May 22, 2015 at 12:12 PM, Mark Brown <broonie@kernel.org> 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

Re: regulator: da9062: undefined Kconfig option MFD_DA9062

[Mark Brown]

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

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: regulator: da9062: undefined Kconfig option MFD_DA9062

[Paul Bolle]

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

Re: regulator: da9062: undefined Kconfig option MFD_DA9062

[Lee Jones]

On Fri, 22 May 2015, Opensource [Steve Twiss] wrote:

> On 22 May 2015 09:20 Valentin Rothberg wrote:
> 
> > To: Opensource [Steve Twiss]
> > Cc: broonie@kernel.org; lgirdwood@gmail.com; Support Opensource; linux-
> > kernel@vger.kernel.org; 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

RE: regulator: da9062: undefined Kconfig option MFD_DA9062

[Opensource [Steve Twiss]]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1488 bytes --]


On 26 May 2015 11:37 Lee Jones wrote:

> To: Opensource [Steve Twiss]
> Subject: Re: regulator: da9062: undefined Kconfig option MFD_DA9062
> 
> > On 22 May 2015 09:20 Valentin Rothberg wrote:
> > > To: Opensource [Steve Twiss]
> > > 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 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.

Thanks for looking at this,
Regards,
Steve
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥