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]

Message-ID: <YkWfziQzprEsWL72@sirena.org.uk>
Date:   Thu, 31 Mar 2022 13:34:22 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Martin Povišer <povik+lin@...ebit.org>
Cc:     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 Thu, Mar 31, 2022 at 02:04:44AM +0200, Martin Povišer wrote:

> I put together a machine-level ASoC driver for recent Apple Macs (the
> ones with ARM64 SoCs) and want to gauge opinions.

This would be a bit easier to review with a description of the hardware.

> Commit 2 adds a new ASoC card method (filter_controls) to let the card
> prevent some codec kcontrols from being visible to userspace. For example
> the TAS2770 speaker amp driver would be happy to expose TDM slot selection
> and ISENSE/VSENSE enables which is ridiculous. I am all ears on how to
> make the patch acceptable to upstream.

The broad issue here is that what you consider ridiculous someone else
might have some bright ideas for configuring dynamically - if things are
being exposed for dynamic configuration it's probably because someone
wanted them, if the control is genuinely useless then it should just be
removed.  Rather than getting in the way of people's policy arguments
about how to set things we expose them to userspace and let userspace
worry about it, usually with the help of UCM files.  The general
userspace model is that people interact with their sound server more
than the hardware card.  This is also helpful for people developing use
cases, it means they're not having to get the kernel rebuilt to tune
things.

The TDM swap thing you're mentioning looks like it's a left/right
selection which people do use sometimes as a way of doing mono mixes and
reorientation.  The ISENSE/VSENSE is less obvious, though it's possible
there's issues with not having enough slots on a heavily used TDM bus or
sometimes disabling the speaker protection processing for whatever
reason.

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