lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9f1fe71e-3900-fa8a-8c09-4bc2dc084156@canonical.com>
Date:   Mon, 7 Jun 2021 10:28:14 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
To:     Dmitry Osipenko <digetx@...il.com>,
        Thierry Reding <thierry.reding@...il.com>
Cc:     linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PULL] memory: tegra: Changes for v5.14-rc1

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?

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ