linux-kernel - Re: [PATCH 46/58] clocksource/drivers: Add a new driver for the Atmel ARM TC blocks

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:   Thu, 8 Jun 2017 10:57:10 +0200
From:   Boris Brezillon <boris.brezillon@...e-electrons.com>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>
Cc:     Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
        Rob Herring <robh@...nel.org>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH 46/58] clocksource/drivers: Add a new driver for the
 Atmel ARM TC blocks

On Thu, 8 Jun 2017 10:40:26 +0200
Daniel Lezcano <daniel.lezcano@...aro.org> wrote:

> > > 
> > > Alexandre, Boris, have a look at https://www.spinics.net/lists/arm-kernel/msg572652.html
> > > 
> > > That will tell you the story.  
> > 
> > Then we're in a deadlock situation here. I'm tired of hearing this kind
> > of argument "DT is only supposed to describe HW, not configuration, bla
> > bla". The truth is, we already have plenty of bindings that do not
> > strictly describe HW.
> > 
> > A simple example: ECC configuration on NAND devices. This is clearly a
> > configuration thing, the NAND controller is usually able to support
> > several kind of strength+ECC-block-size config, but we are able to
> > overload this with the nand-ecc-xxx properties. Another example, still
> > MTD related: MTD partitions, this is purely a software configuration,
> > still we allow users to pass this information in the DT. You want
> > another one? What about the linux,code and linux,input-type properties
> > described here [1]?
> > 
> > So please, let's not use these "this is not decribing HW" or "this is
> > linux specific" arguments every time someone tries to encode something
> > that can be considered a configuration detail.
> > 
> > Let's be pragmatic. How you want to use your timer counter blocks (I'm
> > talking about atmel TCBs) is clearly board specific. Whether you want
> > to use the PIT for your clocksource or use one or 2 channels of a TCB
> > at a specific resolution is again board specific. We need a solution to
> > assign timer channels to a linux function, and I'm not convinced
> > passing this information through the command line makes much more sense
> > than specifying it in the DT (and it's definitely less intuitive, since
> > you have to reference something defined in the DT from the cmdline).
> > 
> > Now, in his review, Mark says:
> > 
> > "
> > To me it sounds like what we need is Linux infrastructure that allows
> > one to register a device as having both clockevent/clocksource
> > functionality.
> > 
> > That way, we can choose to do something sane at boot time, and if the
> > user really wants specific devices used in specific ways, they can
> > request that.
> > "
> > 
> > Does that mean that, after adding this "HW timer" infrastructure, we
> > would have a standard way to assign a function to a specific timer
> > block from the DT? How is this different from what I suggest below
> > (note the linux, prefix on my linux,timer-function property, which
> > clearly shows that this is Linux specific)?  
> 
> I like the 'chosen' approach with the nodes you are proposing below. Thanks for
> the constructive suggestion. The binding description matches perfectly what we
> are trying to achieve.

Actually, this is Alexandre who initially suggested the chosen
approach (I thought it was important to mention that ;-)).