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  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]
Date:   Sun, 22 Nov 2020 12:34:25 +0100
From:   Krzysztof Kozlowski <>
To:     Sylwester Nawrocki <>
Cc:     Sylwester Nawrocki <>,
        Tomasz Figa <>,
        Chanwoo Choi <>,
        Michael Turquette <>,
        Stephen Boyd <>,,,
Subject: Re: [PATCH] clk: samsung: allow compile testing of Exynos, S3C64xx
 and S5Pv210

On Fri, Nov 20, 2020 at 05:36:35PM +0100, Sylwester Nawrocki wrote:
> On 11/19/20 17:45, Krzysztof Kozlowski wrote:
> > So far all Exynos, S3C64xx and S5Pv210 clock units were selected by
> > respective SOC/ARCH Kconfig option.  On a kernel built for selected
> > SoCs, this allowed to build only limited set of matching clock drivers.
> > However compile testing was not possible in such case as Makefile object
> > depent on SOC/ARCH option.
> "objects depend" or "object depends" ?

"object depends"

> > Add separate Kconfig options for each of them to be able to compile
> > test.
> > 
> > Signed-off-by: Krzysztof Kozlowski<>
> The patch look good to me, thanks.
> Acked-by: Sylwester Nawrocki <>
> I guess it's best now to merge it through your tree as it depends on 
> patches already sent to arm-soc? Next time it might be better to use 
> immutable branches right away to keep the clk changes in the clk 
> maintainer's tree.

At that time I had only one clk patch so I did not put it on separate

Anyway, this does not depend on the clkout patches and only minor patch
adjustement is needed. Cherry-pick can solve it (you would need to apply
on next/master and then cherry pick) or I can resend you one rebased on

There should be no conflicts when merging later into next or linus.

I propose you should take it via clk tree.

Best regards,

Powered by blists - more mailing lists