linux-kernel - Re: regulator: da9062: undefined Kconfig option MFD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 May 2015 12:53:16 +0200
From:	Valentin Rothberg <valentinrothberg@...il.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Paul Bolle <pebolle@...cali.nl>, stwiss.opensource@...semi.com,
	lgirdwood@...il.com, support.opensource@...semi.com,
	linux-kernel@...r.kernel.org,
	Andreas Ruprecht <andreas.ruprecht@....de>,
	hengelein Stefan <stefan.hengelein@....de>
Subject: Re: regulator: da9062: undefined Kconfig option MFD_DA9062

Hi Mark,

On Fri, May 22, 2015 at 12:12 PM, Mark Brown <broonie@...nel.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/