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] [day] [month] [year] [list]

Message-ID: <20140222024709.GK25940@sirena.org.uk>
Date:	Sat, 22 Feb 2014 11:47:09 +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 Fri, Feb 21, 2014 at 09:38:55AM +0000, Charles Keepax wrote:

> I guess there are two parts here applying the hardware patch and
> the manual application of the register patch. Applying the
> hardware patch restores registers once it is finished anyway, and
> the actual patch is applied by the write sequencer so will go
> straight to the hardware. So that really doesn't need the
> cache_bypass.

Yeah, it's only the manually applied bit that cares.

> > 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.

> I had considered adding bypassed versions of regmap_write and
> read. That way you could ensure that the bypass was only active
> whilst the regmap lock was held and avoid the problem that way.
> What do you think to that idea?

I think that's a reasonable idea, though I see you actually did
something slightly different (which is sensible and in fact there
already).

Thinking about this stuff there's also some ideas I discussed with
Dimitris for the DSP memories where if it were possible to mark only a
section of the register map as cache only the DSP download could be sped
up a little by making the DSP memories cache only during download and
then syncing at the end to do the actual writes.  That way coefficient
writes that change defaults in the firmware would get coalesced and
possibly some writes to adjacent blocks could be combined too.  Probably
not a massive win but it'd be nice.

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