Date:   Mon, 7 Jun 2021 15:26:15 +0200
From:   Thierry Reding <thierry.reding@...il.com>
To:     Dmitry Osipenko <digetx@...il.com>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PULL] memory: tegra: Changes for v5.14-rc1

On Mon, Jun 07, 2021 at 10:28:14AM +0200, Krzysztof Kozlowski wrote:
> On 04/06/2021 14:51, Dmitry Osipenko wrote:
> > 04.06.2021 12:32, Thierry Reding пишет:
> >> On Thu, Jun 03, 2021 at 10:56:29PM +0300, Dmitry Osipenko wrote:
> >>> 03.06.2021 17:37, Thierry Reding пишет:
> >>>> memory: tegra: Changes for v5.14-rc1
> >>>>
> >>>> This stable tag contains Dmitry's power domain work, including all the
> >>>> necessary dependencies from the regulator, clock and ARM SoC trees.
> >>>>
> >>>> ----------------------------------------------------------------
> >>>> Dmitry Osipenko (18):
> >>>>       clk: tegra30: Use 300MHz for video decoder by default
> >>>>       clk: tegra: Fix refcounting of gate clocks
> >>>>       clk: tegra: Ensure that PLLU configuration is applied properly
> >>>>       clk: tegra: Halve SCLK rate on Tegra20
> >>>>       clk: tegra: Don't allow zero clock rate for PLLs
> >>>>       clk: tegra: cclk: Handle thermal DIV2 CPU frequency throttling
> >>>>       clk: tegra: Mark external clocks as not having reset control
> >>>>       clk: tegra: Don't deassert reset on enabling clocks
> >>>>       regulator: core: Add regulator_sync_voltage_rdev()
> >>>
> >>>>       soc/tegra: regulators: Bump voltages on system reboot
> >>>
> >>> This patch is a build dependency prerequisite for the "soc/tegra:
> >>> regulators: Support core domain state syncing" patch. Will you send a
> >>> new PR to Krzysztof with the remaining soc/tegra patches?
> >>
> >> soc/tegra patches usually go in through ARM SoC. This is merely included
> >> here because it was part of the set of patches that were needed to
> >> enable compile testing for the memory controller drivers.
> >>
> >> I've applied the remaining soc/tegra patches (12-14 of the series) to my
> >> for-5.14/soc branch but ended up not pulling that part in because it was
> >> unnecessary for the memory controller patches.
> > 
> > Does this mean that if for-5.14/soc will be pulled first into mainline,
> > then the patches will be applied in a wrong order?
> 
> All of the branches of each maintainer should be bisectable, so order of
> pulling by Linus' should not matter. Assuming current Thierry's branches
> are bisectable, how Linus' tree can be broken after specific pull order?

Yeah, I don't see how there could be issues. The for-5.14/soc does have
all the dependencies that it needs, as far as I can tell, as does the
for-5.14/memory branch. If for-5.14/soc gets pulled first, then the
sub-branch that's included in for-5.14/memory will end up in ARM SoC
before for-5.14/memory, but that should be harmless. Once
for-5.14/memory is then pulled in, it'll pull in all the dependencies
with it, except that part of them will be there already from
for-5.14/soc.

The only way this could break is if either the original series wasn't
bisectible, or if some of the later SoC patches rely on patches from the
memory portion of that, which rely on the earlier SoC patches. That'd be
a very odd circular dependency and would add to the complexity on how to
handle this. But given that all these branches seem to be building fine,
I don't think that's the case.

If something like that ever happens within a series, please make sure to
point that out. In general a good way to manage such circular
dependencies is to post subseries separately and make a note of the
dependencies in the cover letter to make that clearer. That's also why
it's usually a good idea to send series such that the patches within are
ordered by tree. That way it's trivial to find out if there are any such
circular dependencies by doing a bisectibility build on the branch.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists