linux-kernel - Re: [PATCH] arm64: dts: meson: add SM1 soundcard name to VIM3L

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

Message-ID: <7hy2kol9s4.fsf@baylibre.com>
Date:   Fri, 02 Oct 2020 12:15:07 -0700
From:   Kevin Hilman <khilman@...libre.com>
To:     Jerome Brunet <jbrunet@...libre.com>,
        Christian Hewitt <christianshewitt@...il.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-amlogic@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: dts: meson: add SM1 soundcard name to VIM3L

Jerome Brunet <jbrunet@...libre.com> writes:

> On Fri 02 Oct 2020 at 20:45, Kevin Hilman <khilman@...libre.com> wrote:
>
>> Christian Hewitt <christianshewitt@...il.com> writes:
>>
>>>> On 2 Oct 2020, at 6:44 pm, Jerome Brunet <jbrunet@...libre.com> wrote:
>>>> 
>>>> On Fri 02 Oct 2020 at 16:16, Christian Hewitt <christianshewitt@...il.com> wrote:
>>>> 
>>>>> VIM3L now inherits the sound node from the VIM3 common dtsi but is
>>>>> an SM1 device, so label it as such, and stop users blaming future
>>>>> support issues on the distro/app "wrongly detecting" their device.
>>>>> 
>>>>> Signed-off-by: Christian Hewitt <christianshewitt@...il.com>
>>>>> ---
>>>>> arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts | 4 ++++
>>>>> 1 file changed, 4 insertions(+)
>>>>> 
>>>>> diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
>>>>> index 4b517ca72059..f46f0ecc37ec 100644
>>>>> --- a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
>>>>> +++ b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
>>>>> @@ -32,6 +32,10 @@
>>>>> 		regulator-boot-on;
>>>>> 		regulator-always-on;
>>>>> 	};
>>>>> +
>>>>> +	sound {
>>>>> +		model = "SM1-KHADAS-VIM3L";
>>>>> +	};
>>>> 
>>>> The sound card is the same so I don't see why the sm1 board should have
>>>> a different name. If you are not happy with the name, please update it
>>>> in the common file.
>>>
>>> It’s a nice-to-have not a must-have, but the current LE images that are
>>> in circulation use 5.7 with the previous board-correct name so I was
>>> looking for continuity. We do see user forum reports (infrequent but
>>> recurring) of wrongly detected hardware with other SoC platforms where
>>> similar name inheritance surfaces the ‘wrong’ device name in GUIs, and
>>> I like anything that avoids support work.
>>>
>>> I’d suggest KHADAS-VIM3-VIM3L as a common name, but then it’s the only
>>> device in the current device-tree set that is not prefixed with the SoC
>>> identifier, which (OCD) feels wrong.
>>
>> True, but turns out there's nothing SoC specific about this sound block
>> since it's identical across SoCs, so specifying the SoC is being too
>> specific. 
>>
>> OTOH, while I agree it looks "wrong", it's pretty common in Linux DT to
>> have the SoC prefix to mean only that it's "compatible" with that SoC,
>> not that it *is* that SoC.
>>
>> However, I agree that that can lead to confusion with end users, so
>> since this change has not functional change, and only a UX issue in
>> userspace, I'm fine to apply it.
>
> It is not UX only. This string is used by alsa-utils to match the
> card. For example, the string will be matched to restore the controls
> settings with alsactl on boot. VIM3 and VIM3L are the same sound card
> AFAICT, so it should be the same string.

Ah, OK, thanks for clarifying.   Then I would say if it gets changed, it
gets changed in the common file.

Kevin