linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: linux-kernel@vger.kernel.org, Lars-Peter Clausen <lars@metafoo.de>
Subject: Re: [RFC 2/2] regmap: make use of cached entries in debugfs
Date: Mon, 30 Jan 2012 16:11:16 +0000	[thread overview]
Message-ID: <20120130161116.GK4882@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20120130153427.GH15596@pengutronix.de>

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

On Mon, Jan 30, 2012 at 04:34:27PM +0100, Wolfram Sang wrote:
> On Mon, Jan 30, 2012 at 02:56:28PM +0000, Mark Brown wrote:

> > > -		if (!regmap_readable(map, i))
> > > +		if (map->cache_type == REGCACHE_NONE && !regmap_readable(map, i))

> > This isn't quite what you said in the changelog

> Sorry, I reread and can't find the diff?

Oh, right, you're not actually saying you'll only give cached values
back - my mistake.

> > and isn't going to play nicely with sparse register maps

> sparse == RBTREE? What does "play nicely" mean here? Too slow?

A sparse register map is one that doesn't contain all possible register
addresses, it's orthogonal to the cache - you can have an uncached
device where we know some addresses don't exist or for a cached device
the cache could be any type.

The check for regmap_readable() is there because it causes the debugfs
code to not display registers that don't exist, otherwise we could
easily DoS the output to the point of illegibility by including large
numbers (potentially thousands) of nonexistant registers in the
output making it hard for humans to find the ones that actually exist.

> > - it should be

> > 	if (regmap_cached(map, i) || regmap_readable(map, i))

> > or so (regmap_cached() doesn't exist at present but it seems reasonable
> > that it should).

> Sigh, I have to give up for now. Sadly, I am already way beyond my
> schedule regarding the amplifier driver and need to work on other things
> now.

Oh well.  I might get round to it sometime but essentially all the chips
I work with have read/write support so the issue never comes up.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-01-30 16:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-30 14:08 [RFC 1/2] regmap: if format_write is used, declare all registers as "unreadable" Wolfram Sang
2012-01-30 14:08 ` [RFC 2/2] regmap: make use of cached entries in debugfs Wolfram Sang
2012-01-30 14:56   ` Mark Brown
2012-01-30 15:34     ` Wolfram Sang
2012-01-30 16:11       ` Mark Brown [this message]
2012-01-30 16:25 ` [RFC 1/2] regmap: if format_write is used, declare all registers as "unreadable" Mark Brown

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=20120130161116.GK4882@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=lars@metafoo.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=w.sang@pengutronix.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;
as well as URLs for NNTP newsgroup(s).