linux-kernel - Re: [PATCH] ALSA: hda: Use maple tree register cache

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: <87zg52bn98.wl-tiwai@suse.de>
Date:   Wed, 14 Jun 2023 07:56:19 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Mark Brown <broonie@...nel.org>
Cc:     Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
        alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ALSA: hda: Use maple tree register cache

On Tue, 13 Jun 2023 19:29:19 +0200,
Mark Brown wrote:
> 
> On Tue, Jun 13, 2023 at 07:05:21PM +0200, Takashi Iwai wrote:
> > Mark Brown wrote:
> 
> > > > Oh, I'm afraid that we're seeing different things.  The code there is
> > > > rather to *set* some initial value for each amp register (but only
> > > > once), and it's not about optimization for writing a same value
> > > > again.
> 
> > > > That is, the function helps to set an initial (mute) value on each amp
> > > > when the driver parses the topology and finds an amp.  But if the
> > > > driver already has parsed this amp beforehand by other paths, it skips
> > > > the initialization, as the other path may have already unmuted the
> > > > amp.
> 
> > > So it is possible that we might set two distinct values during setup
> > > then and we're doing this intentionally?  It's not obvious that this
> > > might happen.  A comment wouldn't hurt, and a big part of this is
> > > confusing is that in the non-regmap case all we're doing is suppressing
> > > duplicate writes, in that path it's just checking for changes in the
> > > register value.
> 
> > > None of this is what the non-regmap path does, it just suppresses noop
> > > writes to the hardware.
> 
> > Actually, many of HD-audio codec driver code heavily relies on the
> > regmap, more or less mandatory.  The snd_hda_codec_amp_init() is one
> > of such.  You may write a codec driver without the regmap, but some
> > helpers won't work as expected.
> 
> Sounds like it might be so thinly used it's becoming mandatory to have a
> regmap in order to avoid gotchas like there might be with things getting
> muted?

It's rather historical reasons.  The caching mechanism was already
present and mandatory from the beginning, but it was implemented in a
different way.  Later on, it was translated to the regmap.  Meanwhile,
we generalized the HD-audio codec driver to be on a generic HD-audio
bus, and this allowed the use without regmap.  So some basic helpers
are designed to work without regmap but some are still tightly tied
with regmap.


Takashi