linux-kernel - Re: [PATCH AUTOSEL for 4.9 109/219] clk: sunxi-ng: a33: Add offset and minimum value for DDR1 PLL N factor

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] [day] [month] [year] [list]

Message-ID: <20180321171656.gowdpnetqkyy666n@sasha-lappy>
Date:   Wed, 21 Mar 2018 17:17:05 +0000
From:   Sasha Levin <Alexander.Levin@...rosoft.com>
To:     Chen-Yu Tsai <wens@...e.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Maxime Ripard <maxime.ripard@...e-electrons.com>
Subject: Re: [PATCH AUTOSEL for 4.9 109/219] clk: sunxi-ng: a33: Add offset
 and minimum value for DDR1 PLL N factor

On Thu, Mar 22, 2018 at 12:19:18AM +0800, Chen-Yu Tsai wrote:
>On Thu, Mar 22, 2018 at 12:14 AM, Sasha Levin
><Alexander.Levin@...rosoft.com> wrote:
>> On Tue, Mar 20, 2018 at 11:10:42AM +0800, Chen-Yu Tsai wrote:
>>>Hi,
>>>
>>>On Sun, Mar 4, 2018 at 6:28 AM, Sasha Levin
>>><Alexander.Levin@...rosoft.com> wrote:
>>>> From: Chen-Yu Tsai <wens@...e.org>
>>>>
>>>> [ Upstream commit 68f37d862403e8f95337b2eca90af15d0b8cd5d7 ]
>>>>
>>>> The DDR1 PLL on the A33 is an oddball amongst the A33 CCU clocks.
>>>> It is a clock multiplier, with the effective multiplier in the
>>>> range of 12 ~ 255 and no offset between the multiplier value and
>>>> the value programmed into the register.
>>>>
>>>> Implement the zero offset and minimum value of 12 for this clock.
>>>>
>>>> Fixes: d05c748bd730 ("clk: sunxi-ng: Add A33 CCU support")
>>>> Signed-off-by: Chen-Yu Tsai <wens@...e.org>
>>>> Signed-off-by: Maxime Ripard <maxime.ripard@...e-electrons.com>
>>>> Signed-off-by: Sasha Levin <alexander.levin@...rosoft.com>
>>>> ---
>>>>  drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 18 +++++++++++-------
>>>>  1 file changed, 11 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
>>>> index e1dc4e5b34e1..bdbaf26f551f 100644
>>>> --- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
>>>> +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
>>>> @@ -159,13 +159,17 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_de_clk, "pll-de",
>>>>                                         BIT(28),        /* lock */
>>>>                                         CLK_SET_RATE_UNGATE);
>>>>
>>>> -/* TODO: Fix N */
>>>> -static SUNXI_CCU_N_WITH_GATE_LOCK(pll_ddr1_clk, "pll-ddr1",
>>>> -                                 "osc24M", 0x04c,
>>>> -                                 8, 6,                 /* N */
>>>> -                                 BIT(31),              /* gate */
>>>> -                                 BIT(28),              /* lock */
>>>> -                                 CLK_SET_RATE_UNGATE);
>>>> +static struct ccu_mult pll_ddr1_clk = {
>>>> +       .enable = BIT(31),
>>>> +       .lock   = BIT(28),
>>>
>>>As you undoubtedly noticed, this does not build. It needs commit
>>>cf719012b232 ("clk: sunxi-ng: mult: Support PLL lock detection")
>>>to be applied first. They were part of the same series.
>>
>> Thanks for the heads up!
>>
>>>Incidentally, how can we note these kinds of dependencies to make
>>>life easier for stable kernel maintainers?
>>
>> Yes! There are more details in Documentation/process/stable-kernel-rules.rst:
>>
>>
>> """
>> Additionally, some patches submitted via Option 1 may have additional patch
>> prerequisites which can be cherry-picked. This can be specified in the following
>> format in the sign-off area:
>>
>>      Cc: <stable@...r.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
>>      Cc: <stable@...r.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
>>      Cc: <stable@...r.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
>>      Cc: <stable@...r.kernel.org> # 3.3.x
>>      Signed-off-by: Ingo Molnar <mingo@...e.hu>
>>
>> The tag sequence has the meaning of:
>>
>>      git cherry-pick a1f84a3
>>      git cherry-pick 1b9508f
>>      git cherry-pick fd21073
>>      git cherry-pick <this commit>
>> """
>
>I know about these, and add them when I can. What I'm asking about is
>if a fix and its prerequisites are sent as part of a larger series for
>-next, then none of the prerequisites would be in Linus' tree, and I
>can't use this format. What then? Mention the prerequisite patches'
>subjects in the commit log?
>
>We tend to bunch fixes into -next if they aren't critical (such as
>a faulty clock that doesn't have any in tree users yet) or related
>to the current -rc series.

Just including the subjects would be fine too.

-- 

Thanks,
Sasha