linux-kernel - Re: [PATCH] clk: samsung: allow compile testing of Exynos, S3C64xx and S5Pv210

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]

Date:   Sun, 22 Nov 2020 12:34:25 +0100
From:   Krzysztof Kozlowski <krzk@...nel.org>
To:     Sylwester Nawrocki <snawrocki@...nel.org>
Cc:     Sylwester Nawrocki <s.nawrocki@...sung.com>,
        Tomasz Figa <tomasz.figa@...il.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        linux-samsung-soc@...r.kernel.org, linux-clk@...r.kernel.org,
        linux-kernel@...r.kernel.org
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<krzk@...nel.org>
> 
> The patch look good to me, thanks.
> Acked-by: Sylwester Nawrocki <s.nawrocki@...sung.com>
> 
> 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
branch.

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
linus/master.

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

I propose you should take it via clk tree.

Best regards,
Krzysztof