linux-kernel - Re: [PATCH 2/2] ASoC: dt-bindings: add bindings for TI TAS5805M.

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: <20220111184700.GA10070@nyquist.nev>
Date:   Wed, 12 Jan 2022 07:47:00 +1300
From:   Daniel Beer <daniel.beer@...rinstitute.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     alsa-devel@...a-project.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Andy Liu <andy-liu@...com>,
        Derek Simkowiak <derek.simkowiak@...rinstitute.com>,
        Rob Herring <robh+dt@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>
Subject: Re: [PATCH 2/2] ASoC: dt-bindings: add bindings for TI TAS5805M.

On Tue, Jan 11, 2022 at 05:26:14PM +0000, Mark Brown wrote:
> On Tue, Jan 11, 2022 at 01:00:09PM +1300, Daniel Beer wrote:
> 
> > +  ti,dsp-config: |
> > +    description: |
> > +      A byte sequence giving DSP configuration. Each pair of bytes, in
> > +      sequence, gives a register address and a value to write. If you
> > +      are taking this data from TI's PPC3 tool, this should contain only
> > +      the register writes following the 5ms delay.
> 
> This doesn't look appropriate for DT, it looks more like it should be
> loaded as firmware since systems might want to support multiple
> configurations at runtime based on use casea.  It would also be good to
> have code to validate that any supplied coefficeints/firmware don't
> overwrite registers managed by the driver, just in case.

Hi Mark,

That was my initial thought, but the problem is that different instances
may have different configurations.

We don't really have a way of validating the configuration here, since
it's typically generated by TI's PPC3 tool.

If you think it's still inappropriate to supply the configuration in the
device-tree, do you have any suggestions?

Cheers,
Daniel

-- 
Daniel Beer
Firmware Engineer at Igor Institute
daniel.beer@...rinstitute.com or +64-27-420-8101
Offices in Seattle, San Francisco, and Vancouver BC or (206) 494-3312