linux-kernel - Re: [PATCH 0/2 v3] Add pl031 RTC support for Hi6220

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:	Wed, 6 Jul 2016 00:20:15 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Olof Johansson <olof@...om.net>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	"arm@...nel.org" <arm@...nel.org>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>, Wei Xu <xuwei5@...ilicon.com>,
	Guodong Xu <guodong.xu@...aro.org>,
	Zhangfei Gao <zhangfei.gao@...aro.org>
Subject: Re: [PATCH 0/2 v3] Add pl031 RTC support for Hi6220

On Wed, Jul 6, 2016 at 12:04 AM, Olof Johansson <olof@...om.net> wrote:
> On Tue, Jul 5, 2016 at 11:55 PM, John Stultz <john.stultz@...aro.org> wrote:
>> On Tue, Jul 5, 2016 at 10:22 PM, Olof Johansson <olof@...om.net> wrote:
>>> On Wed, Jun 29, 2016 at 05:48:43PM -0700, John Stultz wrote:
>>>> This patchset enables the pl031 RTC on the Hi6220 SoC.
>>>>
>>>> I'd like to submit it to be merged.
>>>>
>>>> Wei has acked the second patch (modulo a whitespace fix which
>>>> I've included in this v3), so it seems like both could go
>>>> through the clk tree.
>>>>
>>>> But Wei also seemed open to pulling in a clk tree branch
>>>> as it goes through arm-soc.
>>>>
>>>> Michael/Stephen: If there's no other objections, could you
>>>> queue the first patch and make it avilable via the branch for
>>>> Wei, or just take both patches?
>>>
>>> I happen to dread these kind of patchsets these days. There's added
>>> dependencies across trees just because a defined name for the clock
>>> number is added to a header file.
>>>
>>> I much prefer to use numerical clocks for one release, and then once
>>> everything is in, switch over to the defines in the DTS.
>>>
>>> That way there are no dependencies, no need to setup a shared branch
>>> for a simple 3-line patch, etc.
>>>
>>> So, mind respinning the DTS piece?
>>
>> Huh..
>
> Sorry if it appeared random, I've complained about it for a while to
> submaintainers. :)

No.. I get it, the cross-maintainer shared branch is complex enough to
want to avoid. I figured it would be easier to just take a maintainer
acked patch in via the clk tree, but its not my tree, so I'll leave it
to you maintainers to resolve.

>> But trying to boot w/ the numerical clock in the DTS, without the clk
>> change results in lots of noise:
>> [  116.491458] of_clk_src_onecell_get: invalid clock index 37
>> [  116.511627] of_clk_src_onecell_get: invalid clock index 38
>>
>> Is that acceptable?
>
> Grmbl. Is it a lot of those? That's definitely not ideal either. If
> it's one or two during probe (since clk_gets should ideally fail at
> probe time) then I'd be less worried.

Its a fair amount of noise, and seems to go beyond probe time. I'm not
sure why the probe didn't fail, but its getting late so I'll have to
look into it tomorrow.

thanks
-john