linux-kernel - Re: [RFC PATCH 0/5] Apple Macs machine-level ASoC driver

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, 22 Apr 2022 12:43:30 +0200
From:   Martin Povišer <povik@...ebit.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Martin Povišer <povik+lin@...ebit.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Mark Kettenis <kettenis@...nbsd.org>,
        Hector Martin <marcan@...can.st>,
        Sven Peter <sven@...npeter.dev>
Subject: Re: [RFC PATCH 0/5] Apple Macs machine-level ASoC driver

> On 31. 3. 2022, at 17:36, Mark Brown <broonie@...nel.org> wrote:
> 
> On Thu, Mar 31, 2022 at 05:04:32PM +0200, Martin Povišer wrote:
>>> On 31. 3. 2022, at 16:18, Mark Brown <broonie@...nel.org> wrote:
> 
>>> Yes, having two devices driving the bus at the same time wouldn't be
>>> great.  How is the TDM slot selection for the signals done in the
>>> hardware, I'm not seeing anything immediately obvious in the driver?
>>> I'd have thought that things would be implemented such that you could
>>> implement speaker protection on all speakers simultaneously but perhaps
>>> not.
> 
>> I don’t know. I would have to go study the details of this. Should I see
>> if I can find a combination of ‘ASI1 Sel’ ‘VSENSE’ ‘ISENSE’ settings
>> that would lead to driver conflict on one of the models, or is there
>> a chance we could hide those controls just on the basis of ‘it doesn’t
>> do anything usable and is possibly dangerous’?
> 
> If ISENSE and VSENSE output are controlled by the same mux as routing
> then we should lock one of the controls out for at least stereo devices
> (it might be a good idea to check if the output is actually high Z when
> ISENSE and VSENSE are off rather than just driving zeros, if not it
> definitely has to be the routing control).  My instinct is that it's
> better to preserve the ability to implement speaker protection in future
> since that is something that'd be broadly useful, especially if someone
> comes up with a generic speaker protection implementation in which case
> there should be an awful lot of systems out there which could benefit. 

Sorry for having put this on hold for a while.

I looked in the TAS2770 and TAS2764 drivers/datasheets, and to answer
the questions we had:

 * VSENSE/ISENSE output slots are configured independently of audio samples
   routing. Kernel drivers configure the slots based on the 'ti,imon-slot-no'
   and 'ti,vmon-slot-no' properties of devicetree.

 * By default codecs transmit Hi-Z for duration of unused slots.

So once we supply the devicetree props it should be electrically sound
under any configuration of userspace knobs.

One final thought on the playback routing controls: On systems with >2
speakers, the codecs need to be assigned slots through set_tdm_slot.
The macaudio driver RFCed here assigns a single slot to each speaker,
making the effect of each speaker's routing control this:

  'I2C offset' -- uses a random slot

  'Left' 'Right' 'LeftRight' -- uses the single slot we configured

I suppose I better assign two slots to speakers in each left-right pair
of the same kind (e.g. woofer 1, woofer 2, tweeter). This way the
routing control will mimic its behavior from simple stereo systems but
replicated within each left-right pair.  (I would prefer to hide the
controls altogether, but as I learned that hiding things unless proven
dangerous is an ASoC non-goal, this way I can make the controls do
something interesting.)

Martin