linux-kernel - Re: [PATCH 2/2] regmap: Allow caches for devices with no defaults

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]

Message-ID: <20111009193424.GA24008@opensource.wolfsonmicro.com>
Date:	Sun, 9 Oct 2011 20:34:24 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Valdis.Kletnieks@...edu
Cc:	dp@...nsource.wolfsonmicro.com, linux-kernel@...r.kernel.org,
	patches@...nsource.wolfsonmicro.com
Subject: Re: [PATCH 2/2] regmap: Allow caches for devices with no defaults

On Sun, Oct 09, 2011 at 01:43:42PM -0400, Valdis.Kletnieks@...edu wrote:
> On Sun, 09 Oct 2011 14:44:36 BST, Mark Brown said:

> > We only really need the defaults in order to cut down the number of
> > registers we sync and to satisfy reads while the device is powered off

> So let me get this straight - we cache the values so that if there's a read,
> we can return our best guess as to what the device would return if it was
> in fact powered on, instead of notifying the caller that the device is off?

> I think I just sprained my brain trying to parse the logic there :)

It's not a guess, it's very solid information which comes from a
combination of knowing the default register values, knowing that the
registers we cache won't be changed except by writes and caching writes.
We're not really doing the caching for this particular feature, having a
cache is really useful anyway and once you're doing register caching
it's a small step to be able to skip the actual device interaction.

Having a register cache is useful where you don't need much abstraction
between the register and the upper layers that talk to the driver - you
can end up with large chunks of driver which are just data tables saying
"this bitfield in this register has these semantics" which is obviously
a substantial win.

However, not all devices have readback support (on older analogue
processes digital was very expensive and there were a few other issues
for some buses) and this can get very read heavy (both from
read/modify/write cycles and from upper layers querying state) so when
your device is on a slow bus it's really useful to be able to cache the
register values rather than actually read from the device.

Once you've got a cache it's a simple matter to skip the step where we
actually interact with the device for non-volatile registers.  In
situations where the device is idle and we've got the sort of thin
mapping described above we don't really want to have to keep the device
powered on just for the mapping and the register values are about all
the abstraction we need so we don't want another layer. If there a lot
of updates being made this can give a further performance boost as upper
layers can update things in any order they see fit as often as they like
and then we can coalesce the actual writes into a minimal subset when
powering the device up for actual use.

For a concrete example think of an audio CODEC - there's lots of
controls like volume settings which can be mapped very directly to what
users interact with and which have no practical impact unless the device
is actually doing something other than to store the setting which will
be used then.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/