From: Thierry Reding <thierry.reding@gmail.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>,
Stephen Boyd <sboyd@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clocksource: Add debugfs support
Date: Wed, 1 Apr 2020 01:06:02 +0200 [thread overview]
Message-ID: <20200331230602.GC2967489@ulmo> (raw)
In-Reply-To: <87d08suo0y.fsf@nanos.tec.linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]
On Wed, Apr 01, 2020 at 01:01:49AM +0200, Thomas Gleixner wrote:
> Thierry Reding <thierry.reding@gmail.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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2020-03-31 23:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-31 21:40 [PATCH] clocksource: Add debugfs support Thierry Reding
2020-03-31 21:50 ` John Stultz
2020-03-31 22:25 ` Thierry Reding
2020-03-31 22:44 ` John Stultz
2020-03-31 23:02 ` Thierry Reding
2020-03-31 22:06 ` Thomas Gleixner
2020-03-31 22:29 ` Thierry Reding
2020-03-31 22:49 ` Thierry Reding
2020-03-31 23:01 ` Thomas Gleixner
2020-03-31 23:06 ` Thierry Reding [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200331230602.GC2967489@ulmo \
--to=thierry.reding@gmail.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sboyd@kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox