linux-kernel - Re: [PATCH] ARM: dts: artpec: update clock bindings in artpec6.dtsi

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: <56E67421.4030405@axis.com>
Date:	Mon, 14 Mar 2016 09:19:45 +0100
From:	Lars Persson <lars.persson@...s.com>
To:	Olof Johansson <olof@...om.net>
CC:	<arm@...nel.org>, <linux-arm-kernel@...ts.infradead.org>,
	<linux@....linux.org.uk>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ARM: dts: artpec: update clock bindings in artpec6.dtsi



On 03/13/2016 01:14 AM, Olof Johansson wrote:
> On Thu, Feb 25, 2016 at 10:34:14AM +0100, Lars Persson wrote:
>> The clock bindings for the main clock controller was changed to an
>> indexed controller style binding on request of the clk
>> maintainers. This updates the dtsi to use the new bindings.
>>
>> Signed-off-by: Lars Persson <larper@...s.com>
>> ---
>> Note: This patch depends on a header file delivered through the clk tree in
>> "clk: add device tree binding for Artpec-6 clock controller".
>
> This is a bit painful for us. It works when we get contents sent as pull
> requests, since then we can share a branch with the clk header file on it.
>
> However, when we apply patches that's harder.
>
> I suggest we merge this after both trees have been picked up instead. Please
> resend after that if we for some reason forget.
>
>
> The alternative is to just use the numerical constants now, and switch to the
> symbols after the merge window (or in the next release). I'm getting tempted to
> propose that solution for more and more of these in the future, since it's a
> somewhat annoying dependency to have (and we often have them).
>
> Either way, we're close to the merge window opening, so let's aim to do this
> patch towards the end. Since it's a new platform, risk for regression doesn't
> exist, etc.
>
>
> -Olof
>

Hi

So let's be flexible :) We will submit a new patch with numerical clock 
indexes today.


- Lars