Re: [GIT PULL] RISC-V Devicetrees for v6.10

From: "Arnd Bergmann" <arnd@arndb.de>
To: "Conor.Dooley" <conor.dooley@microchip.com>
Cc: "Conor Dooley" <conor@kernel.org>,
	soc@kernel.org, linux-riscv@lists.infradead.org
Subject: Re: [GIT PULL] RISC-V Devicetrees for v6.10
Date: Tue, 07 May 2024 14:15:39 +0200	[thread overview]
Message-ID: <9031c5c8-1e93-491d-b756-5794cb87d1cb@app.fastmail.com> (raw)
In-Reply-To: <20240507-concrete-come-2899fab0888e@wendy>

On Tue, May 7, 2024, at 12:21, Conor Dooley wrote:
> On Tue, May 07, 2024 at 12:08:13PM +0200, Arnd Bergmann wrote:
>> On Tue, May 7, 2024, at 11:58, Conor Dooley wrote:
>> > On Tue, May 07, 2024 at 11:27:36AM +0200, Arnd Bergmann wrote:
>> >> On Fri, May 3, 2024, at 17:24, Conor Dooley wrote:
>
>> >> If you are able to extract the DT bits that don't depend
>> >> on other branches (jh7xxx, microchip, bindings and
>> >> new files) and resend those, I could still add them to the
>> >> same dt-late branch.
>> >
>> > The jh7xxx stuff does actually depend on another branch, although that
>> > branch is fixes. Do you want that removed too? If you do, I'd say to
>> > just drop the whole PR.
>> 
>> As I wrote below, it's fine to have a branch based on a
>> fixes branch, so please keep that part.
>
> Cool, just wasn't sure if you were intentionally contradicting yourself
> or if the "below" part had just been some general remarks. I'll try to
> get a "revised" PR sent tomorrow.

Ok. To clarify: basing on a bugfix pull request is always fine
since those are already in Linus' tree by the time I send my
pull requests to him for the merge window, so the branch contents
as seen by 'git request-pull' are clean.

For dependencies between the branches that are meant for the
merge window, I don't mind taking them when there is a good
reason and we have discussed it in advance. It means a little
extra work for me as I have to be careful about the order of
my own pull requests to ensure that the branch that contains
the dependency gets merged first, and the commit log on Linus'
side is what's actually meant to be in the branch.

I also try hard (in general) to avoid dependencies between the
soc/dt branch and any of the other branches, to be sure that
there are no incompatible binding changes. This wasn't a
problem here (I think), but if you send something late in the
cycle, I pretty much don't want to have to think about that.

      Arnd

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv