linux-kernel - Re: [PATCH 3/3] ASoC: fsl_ssi: remove register 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]

Date:	Tue, 12 Jan 2016 01:34:21 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Timur Tabi <timur@...i.org>
Cc:	"Maciej S. Szmigiero" <mail@...iej.szmigiero.name>,
	Fabio Estevam <festevam@...il.com>,
	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
	Nicolin Chen <nicoleotsuka@...il.com>,
	Xiubo Li <Xiubo.Lee@...il.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

On Mon, Jan 11, 2016 at 07:23:54PM -0600, Timur Tabi wrote:
> Mark Brown wrote:

> >regcache handles this fine, it's perfectly happy to just go and allocate
> >the cache as registers get used (this is why the code that's doing the
> >allocation exists...).  What is causing problems here is that the first
> >access to the register is happening in interrupt context so we can't do
> >a GFP_KERNEL allocation for it.

> Considering how small and not-sparse the SSI register space is, would using
> REGCACHE_FLAT be appropriate?

Quite possibly (it'll be more efficient and it's intended for such use
cases) but as I said in my other reply that then has the issue that it
implicitly gives default values to all the registers so I'd expect we
still need to handle the cache initialisation explicitly (or
alternatively the hardware sync with the cache on startup).

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