linux-kernel - Re: PM regression in next

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, 12 Jan 2018 22:11:26 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Tony Lindgren <tony@...mide.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-omap@...r.kernel.org,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        linux-pm@...r.kernel.org
Subject: Re: PM regression in next

On Fri, Jan 12, 2018 at 01:50:10PM -0800, Tony Lindgren wrote:

> > I rather suspect someone would've noticed by now TBH - I suspect this is
> > more likely to be an issue with the rather baroque code that the TWL
> > drivers have possibly coupled with the whole multiple I2C devices issue.

> Hmm these calls are in sound/soc/soc-core.c though? But yeah, sure
> it could be some legacy code issue somewhere..

Most devices have one regmap per device which can be retrieved with
dev_get_regmap(), it's the attempt to use that which I suspect is
broken.  Like I said snd_soc_codec_init_regmap() ought to fix things if
that's the issue.

> sound/soc/codecs/cx20442.c
> sound/soc/codecs/tlv320dac33.c
> sound/soc/codecs/twl4030.c
> sound/soc/codecs/twl6040.c
> sound/soc/codecs/uda1380.c
> sound/soc/fsl/fsl_ssi.c

> Can you confirm that some of these are still working?

Most of the non-TWL ones have no active users I'm aware of but fsl_ssi.c
is under active development at the minute, one series was getting some
successful testing earlier today so if it's broken I'd hope someone
would have noticed although since it doesn't use DAPM or anything
snd_soc_read()/write() will never get used.  cx20442 was only in a
single archaic consumer product, uda1380 has been legacy since before I
was ever involved in ASoC.

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