linux-kernel - Re: [PATCH 1/2] ASoC: dt-bindings: Add adi,ssm3515 amp schema

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: <ZFr9CP3Dfmb/3LzP@finisterre.sirena.org.uk>
Date:   Wed, 10 May 2023 11:10:16 +0900
From:   Mark Brown <broonie@...nel.org>
To:     Martin Povišer <povik+lin@...ebit.org>
Cc:     Conor Dooley <conor@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Nuno Sá <nuno.sa@...log.com>,
        asahi@...ts.linux.dev, alsa-devel@...a-project.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] ASoC: dt-bindings: Add adi,ssm3515 amp schema

On Tue, May 09, 2023 at 09:38:46PM +0200, Martin Povišer wrote:
> > On 9. 5. 2023, at 20:25, Conor Dooley <conor@...nel.org> wrote:

> >> +        00: 8.4 V Full-Scale Gain Mapping
> >> +        01: 12.6 V Full-Scale Gain Mapping
> >> +        10: 14 V Full-Scale Gain Mapping
> >> +        11: 15 V Full-Scale Gain Mapping

> > Putting register values into the DT does not seem correct, although
> > I know nothing about sound and will have to defer to Krzysztof & Co. on
> > that front.

> I thought this should be here, and not with the other gain controls to be
> exported to userspace, since it relates to the supply voltage. You probably
> can’t select a gain value close or over the amp’s supply and expect proper
> functioning, so the value here should be the system’s integrator choice.

> On second thought there doesn’t seem to be any risk of damage to the amp
> itself, so the knowledge of what’s the optimal value could be left up to
> ALSA use-case configuration, and there’s no real downside in treating it
> like other gain controls.

Alternatively why not just query the supply voltage via the regulator
API?  Those are kind of weird numbers (eg, 12.6V rather than 12V)
though, it looks like they're not expected to be the actual maximum
supply values but rather something slightly less.

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