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

Message-ID: <1736252.WAIVArieDJ@wuerfel>
Date:	Fri, 15 Jul 2016 10:06:32 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Michael Turquette <mturquette@...libre.com>
Cc:	John Stultz <john.stultz@...aro.org>,
	Olof Johansson <olof@...om.net>,
	lkml <linux-kernel@...r.kernel.org>,
	"arm@...nel.org" <arm@...nel.org>,
	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 Thursday, July 7, 2016 7:21:51 PM CEST Michael Turquette wrote:
> Quoting Arnd Bergmann (2016-07-07 01:22:30)
> > On Wednesday, July 6, 2016 5:58:14 PM CEST John Stultz wrote:

> > 
> > We typically have it easier for other subsystems like irqchip or gpio
> > where nobody would consider writing a driver that can only handle
> > the I/O lines that are used on their board with a minimal set of
> > drivers, but for some reason it seems acceptable to do it for clock
> > controllers just because they are harder to describe.
> 
> gpio and irqchip are interesting analogues. It makes pretty good sense
> to expose all of those lines via DT, since those are resources that
> consumer drivers may be interested in. But is the same true for clock
> signals?
> 
> Clearly drivers will care about their input clocks, which are often leaf
> gates. But the mess and tangle of "root" and "branch" clocks above that?
> Why expose it to DT if we don't need to? These are resources that are
> often internal to the clock controller IP block. In an ideal world we
> would never need to provide a way for clock consumer drivers to get at
> these root and branch clocks, just the peripheral leaf clocks.
> 
> As an example of this, ccf has tried to be smart about propagating rate
> requests up the chain of parents since it was originally merged, and
> that directly has led to lots of consolidation around the cpufreq-dt.c
> driver, where a single leaf clock can ultimately affect a PLL or
> post-divider without the cpufreq driver needing to know the details of
> the clock hierarchy internal to the clock controller IP block.
> 
> (in reality we do need to expose root and branch clocks for drivers some
> times, but I disagree that we should expose every single clock signal
> just because it is there)

(sorry for coming back to this late)

I still don't fully understand how we ended up with the missing
clk in the specific example here, but it seems to me that what
was missing here is indeed a leaf clock, not one of the clocks
above it. This is a simple gate that is controlled by a bit in the
same register as a number of other clocks, so if I understand you
right, it should have been there even if we don't want to expose
the internal clocks, correct?

	Arnd