linux-kernel - [RFC PATCH] kselftest/alsa: Add configuration for mt8192-asurada-spherion

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>] [day] [month] [year] [list]

Message-ID: <20230921210800.230330-1-nfraprado@collabora.com>
Date:   Thu, 21 Sep 2023 17:07:42 -0400
From:   Nícolas F. R. A. Prado 
        <nfraprado@...labora.com>
To:     Takashi Iwai <tiwai@...e.com>
Cc:     kernel@...labora.com,
        Nícolas F. R. A. Prado 
        <nfraprado@...labora.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Mark Brown <broonie@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Shuah Khan <shuah@...nel.org>, alsa-devel@...a-project.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org, linux-mediatek@...ts.infradead.org
Subject: [RFC PATCH] kselftest/alsa: Add configuration for mt8192-asurada-spherion

Add a configuration file for the mt8192-asurada-spherion platform to
validate that the card and PCMs used for speaker, headphone and
microphones (internal and headset) are correctly exposed to userspace.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@...labora.com>

---
Sending this patch as RFC because I'd like to ask a question. What would
be the most suitable entry to identify the card in a future-proof way?

I have used the card ID here, but given that it is generated at runtime
with the purpose of being unique among the cards present on the system
(and I couldn't find any documentation that states it is stable), I'm
not sure it is supposed to be relied on.

The card ID is derived from the driver name or card longname, which are
themselves stable given userspace (alsa-ucm-conf) relies on them, but
those aren't exposed through sysfs so I can't check for them here.

Another option would be to look for the card number 0. But in the (very
unlikely) case that another soundcard would be connected to the platform
and detected first during boot, it wouldn't work.

Yet another option would be to look at the device's uevent file for
the compatible as defined in the Devicetree, ie

        path "device/uevent"
        regex "OF_COMPATIBLE_.*=mediatek,mt8192_mt6359_rt1015p_rt5682"

Though it is possible (in rare circumstances) for the compatible in the
Devicetree to need to be updated to enable a driver behavior that isn't
backward compatible.

I realize most of these issues are very rare and probably won't ever
occur, but it seems worthwhile to use the most future-proof mechanism
available to identify the card to avoid unnecessary maintenance, even
more so considering the example would be followed by future
configurations.

Thanks,
Nícolas

 .../alsa/conf.d/mt8192-asurada-spherion.conf  | 32 +++++++++++++++++++
 1 file changed, 32 insertions(+)
 create mode 100644 tools/testing/selftests/alsa/conf.d/mt8192-asurada-spherion.conf

diff --git a/tools/testing/selftests/alsa/conf.d/mt8192-asurada-spherion.conf b/tools/testing/selftests/alsa/conf.d/mt8192-asurada-spherion.conf
new file mode 100644
index 000000000000..6a7e15dc17da
--- /dev/null
+++ b/tools/testing/selftests/alsa/conf.d/mt8192-asurada-spherion.conf
@@ -0,0 +1,32 @@
+sysfs [
+	{
+		path "firmware/devicetree/base/compatible"
+		regex "google,spherion"
+	}
+]
+
+card.mt8192 {
+	sysfs [
+		{
+			path "id"
+			regex "mt8192mt6359rt1"
+		}
+	]
+
+	pcm.0.0 {
+		PLAYBACK {
+		}
+	}
+	pcm.3.0 {
+		PLAYBACK {
+		}
+	}
+	pcm.10.0 {
+		CAPTURE {
+		}
+	}
+	pcm.11.0 {
+		CAPTURE {
+		}
+	}
+}
-- 
2.42.0