linux-kernel - Re: [PATCH V2 1/4] regmap: cache: Add "was_reset" argument to regcache_sync

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:	Wed, 29 Apr 2015 18:34:02 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Kevin Cernekee <cernekee@...omium.org>
Cc:	Liam Girdwood <lgirdwood@...il.com>,
	Lars-Peter Clausen <lars@...afoo.de>, dgreid@...omium.org,
	Andrew Bresticker <abrestic@...omium.org>,
	Olof Johansson <olofj@...omium.org>,
	alsa-devel@...a-project.org, devicetree@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V2 1/4] regmap: cache: Add "was_reset" argument to
 regcache_sync_region()

On Wed, Apr 29, 2015 at 10:02:03AM -0700, Kevin Cernekee wrote:
> On Wed, Apr 29, 2015 at 9:46 AM, Mark Brown <broonie@...nel.org> wrote:

> > We just need a single boolean?

> Right, so if we add a per-regmap bool that tells us whether the device
> has been reset, then in the case of "not reset" we will have to write
> every regcache entry out to the device.  Even the ones that weren't
> touched while in cache_only mode.  This makes the "not reset" case
> much less efficient than the "reset" case.

The immediate point is to provide a useful external interface, the
internal optimisation is much less urgent (and it's less clear to me how
often we're going to need to do that at all - generally cache only and
power loss go together.

> BTW, any preferences on naming for the bool or for the renamed
> mark_dirty function?

Not urgently.  Note that I'm *not* suggesting an immediate rename,
that's definitely a separate change (which will be a lot more painful to
merge due to cross tree issues).

> >> i.e. regcache_sync() finds a register value marked "present".  How do
> >> we know whether we need to write it back to the hardware?  For the
> >> special case of "cached non default register values immediately after
> >> a HW reset" you can mostly figure this out, but if there was no HW
> >> reset how do we know which entries changed while the HW was
> >> inaccessible?

> > In the first instance do we care?

> I'm not sure I understand the question.

Do we actually care about getting a list of the changed registers that
much?

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)