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]

Message-ID: <5693B7CC.8000905@maciej.szmigiero.name>
Date:	Mon, 11 Jan 2016 15:10:20 +0100
From:	"Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
To:	Mark Brown <broonie@...nel.org>, Fabio Estevam <festevam@...il.com>
CC:	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
	Timur Tabi <timur@...i.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 11.01.2016 15:00, Mark Brown wrote:
> On Mon, Jan 11, 2016 at 10:10:56AM -0200, Fabio Estevam wrote:
>> On Mon, Jan 11, 2016 at 10:04 AM, Fabio Estevam <festevam@...il.com> wrote:
> 
>>> [    2.526984] ------------[ cut here ]------------
>>> [    2.531632] WARNING: CPU: 1 PID: 1 at kernel/locking/lockdep.c:2755
>>> lockdep_trace_alloc+0xf4/0x124()
> 
>> This fixes the warning:
> 
>> --- a/sound/soc/fsl/fsl_ssi.c
>> +++ b/sound/soc/fsl/fsl_ssi.c
>> @@ -180,7 +180,6 @@ static const struct regmap_config fsl_ssi_regconfig = {
>>         .volatile_reg = fsl_ssi_volatile_reg,
>>         .precious_reg = fsl_ssi_precious_reg,
>>         .writeable_reg = fsl_ssi_writeable_reg,
>> -       .cache_type = REGCACHE_RBTREE,
>>  };
> 
>> Is this the correct fix?
> 
> I suspect not, it looks like the driver is using the cache for
> suspend/resume handling.  I've dropped the patch for now.  Either the
> driver should explicitly write to the relevant registers outside of
> interrupt context to ensure the cache entry exists or it should keep the
> defaults and explicitly write them to hardware at startup to ensure
> sync (the former is more likely to be safe).

Is it acceptable to switch it to flat cache instead to not keep the register
defaults in driver?

Maciej