Re: [PULL] memory: tegra: Changes for v5.14-rc1

[Dmitry Osipenko]

07.06.2021 16:26, Thierry Reding пишет:
> 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.

I see now that for-5.14/soc has the "Bump voltages on system reboot"
patch, so it should be okay.