linux-kernel - Re: [PATCH v3] ARM: at91: Document new TCB bindings

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: <20160704141733.5d931a7f@bbrezillon>
Date:	Mon, 4 Jul 2016 14:17:33 +0200
From:	Boris Brezillon <boris.brezillon@...e-electrons.com>
To:	Alexandre Belloni <alexandre.belloni@...e-electrons.com>
Cc:	Nicolas Ferre <nicolas.ferre@...el.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Thierry Reding <thierry.reding@...il.com>,
	linux-pwm@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
	devicetree@...r.kernel.org
Subject: Re: [PATCH v3] ARM: at91: Document new TCB bindings

On Mon, 4 Jul 2016 14:11:27 +0200
Alexandre Belloni <alexandre.belloni@...e-electrons.com> wrote:

> On 04/07/2016 at 14:03:58 +0200, Boris Brezillon wrote :
> > On Mon, 4 Jul 2016 12:36:31 +0200
> > Alexandre Belloni <alexandre.belloni@...e-electrons.com> wrote:
> >   
> > > On 04/07/2016 at 12:24:52 +0200, Boris Brezillon wrote :  
> > > > On Fri,  1 Jul 2016 23:52:05 +0200
> > > > Alexandre Belloni <alexandre.belloni@...e-electrons.com> wrote:    
> > > > > +One interrupt per TC block:
> > > > > +	tcb0: timer@...7c000 {
> > > > > +		compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon";
> > > > > +		#address-cells = <1>;
> > > > > +		#size-cells = <0>;
> > > > > +		reg = <0xfff7c000 0x100>;
> > > > > +		interrupts = <18 4>;
> > > > > +		clocks = <&tcb0_clk>, <&clk32k>;
> > > > > +		clock-names = "t0_clk", "slow_clk";
> > > > > +
> > > > > +		timer@0 {
> > > > > +			compatible = "atmel,tcb-timer";
> > > > > +			reg = <0>, <1>;
> > > > > +		};
> > > > > +
> > > > > +		timer@2 {
> > > > > +			compatible = "atmel,tcb-timer";
> > > > > +			reg = <2>;
> > > > > +		};    
> > > > 
> > > > And how can you differentiate the clocksource from the clkevent?
> > > >     
> > > 
> > > It doesn't really matter actually, I'll do the selection in the driver,
> > > as suggested by Rob.
> > >   
> > 
> > Yes, I've read Rob's review, but then what's the point of defining 2
> > timer nodes, just do the detection based on the number of channels
> > you've reserved for the timer and define a single node.  
> 
> I agree this is a really hypothetical use case but one may want to have
> the clocksource on one TCB and the clockevent on another. This would
> allow to have for example a quadrature decoder and the clocksource on
> one TCB and another quadrature decoder and the clockevent device on
> another TCB.
> 
> 

Hm, that sounds like a valid but unlikely use case, but it makes the
DT bindinds even more obscure. When should one define a single timer
node, when to define two, how many channels per timer depending on the
type of timer you want to instantiate, etc. That should probably be
documented.

ITOH, by choosing the single timer-node approach, you hide everything in
the driver, and let the implementation choose the correct channels for
the clkevent and clksource devices.