[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200331230602.GC2967489@ulmo>
Date: Wed, 1 Apr 2020 01:06:02 +0200
From: Thierry Reding <thierry.reding@...il.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: John Stultz <john.stultz@...aro.org>,
Stephen Boyd <sboyd@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] clocksource: Add debugfs support
On Wed, Apr 01, 2020 at 01:01:49AM +0200, Thomas Gleixner wrote:
> Thierry Reding <thierry.reding@...il.com> writes:
> > On Wed, Apr 01, 2020 at 12:06:37AM +0200, Thomas Gleixner wrote:
> >> It does not provide any information about the clocksource, it provides
> >> an interface to read the counter - nothing else.
> >
> > The counter is part of the information about a clocksource, isn't it?
>
> Sorry to be pedantic, but no. Information about a clocksource is the
> name, the type, the frequency, bitwidth etc.
>
> The counter file is not providing information about the
> clocksource. It's exposing an accessor to the clocksource itself.
Okay, fair enough.
> > I can also add some information about what I intend to use this for,
> > though it'll be a bit boring because I really only want this as a way
> > of testing that I'm reading from the right registers and that these
> > counters are running. A debugfs interface seemed like a better and more
> > widely useful way to achieve that than implementing some one-off hack to
> > poll those registers.
>
> But how much value has this interface beyond the 'hack a driver for a
> new clocksource' experience?
>
> To me none, but that might be my personal skewed view.
No, that's the only intended purpose. I just thought that would be nicer
than everyone having to write their own debug messages to do the same
thing.
If nobody else thinks this is useful I'll just stash it somewhere in
case I ever need it again.
Thierry
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists