linux-kernel - Re: [PATCH v4 0/6] clocksource: rework Atmel TCB timer driver

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]

Date:   Tue, 15 May 2018 19:26:51 +0200
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc:     Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Boris Brezillon <boris.brezillon@...tlin.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 0/6] clocksource: rework Atmel TCB timer driver

On 2018-05-02 20:10:46 [+0200], Alexandre Belloni wrote:
> > > As said below, this is solving multiple issues, including the one for
> > > SoCs that don't have the PIT.
> > will the PIT be removed? Where it needs the PIT?
> > 
> 
> The last patch is unselecting the PIT driver so by default it is not
> enabled. The PIT driver will stay just in case someone has to use it
> e.g. when they are using all the TCB channels for something else.
> However, recent Atmel SoC have a TCB without any output so it can ony be
> used as a timer. Some other SoCs don't have a PIT at all.

The question was more "does it make sense to keep the 'old' PIT driver
around or can it be removed and the TCB driver will be used by
everyone"?

> > > The remaining one would be "clocksource: TCLIB: Allow higher clock rates
> > > for clock events"
> > 
> > I see. So I would need to keep that patch in queue after it was
> > dismissed from duty…
> 
> Boris suggested a DT binding to allow changing the rate but it didn't
> reach consensus at the time. this is something that will ne to be
> revived at some point and I would very much like having that upstream
> too.

Does make sense to have a low frequency clock here? I think from
clocksource point of view it makes sense to have it (highres) enabled
and not having to adjust the DT first (not to mention to learn about
it).

Sebastian