linux-kernel - Re: [EXTERNAL] Re: [PATCH] ASoC: max98373: Mark cache dirty before entering sleep

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:   Mon, 27 Sep 2021 18:10:33 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc:     Ryan Lee <RyanS.Lee@...imintegrated.com>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "perex@...ex.cz" <perex@...ex.cz>,
        "tiwai@...e.com" <tiwai@...e.com>,
        "yung-chuan.liao@...ux.intel.com" <yung-chuan.liao@...ux.intel.com>,
        "guennadi.liakhovetski@...ux.intel.com" 
        <guennadi.liakhovetski@...ux.intel.com>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "sathya.prakash.m.r@...el.com" <sathya.prakash.m.r@...el.com>,
        "ryan.lee.maxim@...il.com" <ryan.lee.maxim@...il.com>
Subject: Re: [EXTERNAL] Re: [PATCH] ASoC: max98373: Mark cache dirty before
 entering sleep

On Mon, Sep 27, 2021 at 11:48:56AM -0500, Pierre-Louis Bossart wrote:
> On 9/27/21 11:06 AM, Mark Brown wrote:

> > More specifically what it does is make the invalidation of the register
> > cache unconditional.  It doesn't really matter if the invalidation is
> > done on suspend or resume, so long as it happens before we attempt to
> > resync - this could also be done by deleting the first_hw_init check.

> Mark, that's exactly my point: if the amp rejoins the bus, we will
> *always* mark the cache as dirty, before the resync is done in the
> resume sequence.

Ah, yes - I see.

> I am really trying to figure out if we have a major flaw in the resume
> sequence and why things are different in the case of the Maxim amp.

> Instead of changing the suspend sequence, can we please try to modify
> the max98373_io_init() routine to unconditionally flag the cache as
> dirty, maybe this points to a problem with the management of the
> max98373->first_hw_init flag.

A quick survey of other drivers suggests that this pattern should be
factored out into some helpers as it looks like there's several ways of
implementing it that look very similar but not quite the same...

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