linux-kernel - Re: [PATCH] mfd: wm5102: Remove cache_bypass from manual register patching

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]

Date:	Fri, 21 Feb 2014 08:30:58 +0900
From:	Mark Brown <broonie@...nel.org>
To:	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
Cc:	lee.jones@...aro.org, sameo@...ux.intel.com,
	patches@...nsource.wolfsonmicro.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mfd: wm5102: Remove cache_bypass from manual register
 patching

On Thu, Feb 20, 2014 at 04:26:48PM +0000, Charles Keepax wrote:

> As the cache_bypass is not strictly necessary for applying the patches
> (the device is always powered on whilst it is applied) remove the calls
> to regcache_cache_bypass to avoid this situation.

That's not why the cache bypass is there, the cache bypass is there to
make sure we don't cache the writes and hence reapply them while
restoring the cache.  This would cause breakage with writes which change
register defaults (where it would overwrite previously cached writes) or
need to be done in that specific sequence.  A bypassed write goes
straight to the hardware so it can't work if the device is powered off.

Given that this is happening on resume I expect you can achieve
sufficient exclusion by making sure that everything that writes to the
device holds a runtim PM reference which you ought to be doing anyway,
the PM infrastructure makes sure that only one resume can run at once.
However I expect that's going to be annoying with ASoC where you don't
really want to boot the device just to change controls (but perhaps with
autosuspend it's not too bad, most likely the device will be getting
powered up shortly anyway if userspace is fiddling with the controls).

Being able to use the regular patch infrastructure would of course be
nicer but you're going to need to add a callback to allow you to run the
hardware patch in that case.

You probably also want to be applying the patch using async writes to
improve performance but that's separate and just an optimisation.

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