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

Message-ID: <e1d25f8d-5d33-3dc9-1af4-4afca7a8a967@kernel.org>
Date:   Mon, 23 Nov 2020 11:10:44 +0100
From:   Sylwester Nawrocki <snawrocki@...nel.org>
To:     Krzysztof Kozlowski <krzk@...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 11/22/20 12:34, Krzysztof Kozlowski wrote:
> 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.

Indeed, the conflict is minimal, I should have checked with git cherry-pick
once I found a branch where the patch applied cleanly. I have corrected
the typo an applied, thank you!

--
Regards,
Sylwester