From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Rob Herring <robh@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: linux-next: build failure after merge of the devicetree tree
Date: Fri, 8 Dec 2023 07:58:47 +1100 [thread overview]
Message-ID: <20231208075847.6bbd23b8@canb.auug.org.au> (raw)
In-Reply-To: <CAL_JsqKXo+Cr=9s=dt1kCQeMadJ_cnuSpm06zmvK8yd-vd2X3g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]
Hi Rob,
On Thu, 7 Dec 2023 09:11:22 -0600 Rob Herring <robh@kernel.org> wrote:
>
> I'm sending out fixes for all these. I want to get the final patch
> ("of: Stop circularly including of_device.h and of_platform.h") for
> all this in next to get some better build coverage and catch any new
> drivers added. But if it is dropped for every new driver that breaks,
> I'll never get it in. Can you fix these up or just leave them broken?
> I can keep the fixes in my tree until they get applied by the
> corresponding subsystem.
These dependencies between trees are impossible to handle. Please if
you really need the final patch in, then you must put all the necessary
fixes in the same branch. There is no telling what order Linus (or I)
will merge the interdependent branches.
The alternative is to spray the needed fixes out to the other
subsystems and then put the final patch in after the merge window
closes or the next release.
I cannot "just leave them broken" because that will interfere with
other's trying to get their work done. I will try fix up the newly
added drivers if they are obvious, but in the case of these include file
cleanups, that can be quite difficult sometimes.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-12-07 20:58 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-07 1:57 linux-next: build failure after merge of the devicetree tree Stephen Rothwell
2023-12-07 15:11 ` Rob Herring
2023-12-07 20:58 ` Stephen Rothwell [this message]
2023-12-07 22:05 ` Rob Herring
2023-12-08 3:11 ` Stephen Rothwell
-- strict thread matches above, loose matches on Subject: below --
2025-11-17 4:13 Stephen Rothwell
2023-12-11 5:05 Stephen Rothwell
2023-12-12 9:04 ` Sibi Sankar
2024-01-19 0:58 ` Stephen Rothwell
2024-01-19 14:07 ` Rob Herring
2023-12-08 2:51 Stephen Rothwell
2023-12-08 7:34 ` Krzysztof Kozlowski
2023-04-11 2:28 Stephen Rothwell
2014-05-26 5:05 Stephen Rothwell
2014-05-26 7:22 ` Thomas Petazzoni
2011-10-05 5:24 Stephen Rothwell
2011-10-05 5:54 ` Grant Likely
2010-07-30 3:57 Stephen Rothwell
2010-07-30 6:11 ` Grant Likely
2010-07-15 2:15 Stephen Rothwell
2010-07-15 6:06 ` Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231208075847.6bbd23b8@canb.auug.org.au \
--to=sfr@canb.auug.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox