Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 10 Oct 2022 08:42:41 +0100
From:   Lee Jones <lee@kernel.org>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Mark Brown <broonie@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Backlight for v6.1
Message-ID: <Y0PM8fGW+8rxNlwU@google.com>
References: <Yz18QA27+gN0oaM3@google.com>
 <CAHk-=whK-q1W-X0q0f_nBJ9sKyta-DVJhEAS4BF_oKAVAUQ4Jw@mail.gmail.com>
 <Y0AmmR2NfKc/Y7Mb@google.com>
 <CAHk-=wg=hh8xkPjiySnjAyR66AG64eyZ1Y9gHw+MCs8uuSZReA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAHk-=wg=hh8xkPjiySnjAyR66AG64eyZ1Y9gHw+MCs8uuSZReA@mail.gmail.com>
Precedence: bulk

On Fri, 07 Oct 2022, Linus Torvalds wrote:

> On Fri, Oct 7, 2022 at 6:16 AM Lee Jones <lee@kernel.org> wrote:
> >
> > PR satisfying this dependency was submitted the following day:
> 
> .. you ignored the whole "another driver hit v6.0 without ever getting
> the dependency".

Not ignored.  I provided you with a response applicable to the
situation surrounding *this* pull-request.  As for the actions /
motives of other maintainers, I cannot / should not comment.

Admittedly, that is not to say this could not have happened solely
between 2 subsystems that I maintain!  The other subsystem maintainers
and I work together regularly, utilising immutable branches to ensure
we do not cause build breakage at merge-time, but we (clearly) do not
work to the same levels of due diligence with respect to dependencies
preventing full build test / coverage.

> In particular, there was a silent semantic conflict in the Crystal
> Cove (intel PMIC) driver with the i2c changes. I noticed it because
> there were other things going on, and I went and looked.

It appears as though, Andy, Hans and yourself are having a nice
conversation about this particular instance already - I'll leave you
to it.

> So I caught this particular issue, but I really think that code that
> cannot be enabled at all even for build testing - or code that is
> quite hard to enable either intentionally or by mistake - is a
> problem.

Unbuildable / untestable code is an interesting problem.  One which, I
must say, I haven't taken a particularly deep look into.  Even though 
MFDs (and their associated children) are particularly susceptible to
dependency issues that would otherwise prevent testing, I very much
doubt this problem is unique to MFD.

To your knowledge, has there been any research into unbuildable
drivers (/ subsystems!)?  There must have been some notable studies on
(static / running) code coverage analysis, but I'd be surprised if
these cover code that simply cannot be built / executed.

Until this point, I assumed my build-coverage was rather good.  It
covers varying compilers, 7 architectures, and many different
*_defconfigs which include allmodconfig and allyesconfig, totalling 70
unique kernel builds.

You have been mentioning allmodconfig a fair bit.  Are you also
including allyesconfig in your observations?  Does that not alleviate 
some of the angst around what should be built-in vs modules in terms
of buildability?

If this is as big of an issue as you say, perhaps we should invest
a little time to investigate some sound method(s) to scan for similar
instances.  Tricky to do, seeing how many different architectures /
platforms the kernel supports.

-- 
Lee Jones [李琼斯]