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

Message-ID: <CAGb2v67fYPAXV5PoriJO+PLjVOJQ3QisQsQL9BGYMv0itGFQvQ@mail.gmail.com>
Date:   Thu, 22 Mar 2018 00:19:18 +0800
From:   Chen-Yu Tsai <wens@...e.org>
To:     Sasha Levin <Alexander.Levin@...rosoft.com>
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: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.

Thanks
ChenYu