Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
References: <20201002141619.14387-1-christianshewitt@gmail.com> <1jzh54it6f.fsf@starbuckisacylon.baylibre.com> <785296E3-FA91-4F5E-A8C0-1FAA8C576A17@gmail.com> <7h7ds8mppz.fsf@baylibre.com>
User-agent: mu4e 1.3.3; emacs 26.3
From:   Jerome Brunet <jbrunet@baylibre.com>
To:     Kevin Hilman <khilman@baylibre.com>,
        Christian Hewitt <christianshewitt@gmail.com>
Cc:     Rob Herring <robh+dt@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: dts: meson: add SM1 soundcard name to VIM3L
In-reply-to: <7h7ds8mppz.fsf@baylibre.com>
Date:   Fri, 02 Oct 2020 20:53:37 +0200
Message-ID: <1jmu14qx1q.fsf@starbuckisacylon.baylibre.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On Fri 02 Oct 2020 at 20:45, Kevin Hilman <khilman@baylibre.com> wrote:

> Christian Hewitt <christianshewitt@gmail.com> writes:
>
>>> On 2 Oct 2020, at 6:44 pm, Jerome Brunet <jbrunet@baylibre.com> wrote:
>>>=20
>>> On Fri 02 Oct 2020 at 16:16, Christian Hewitt <christianshewitt@gmail.c=
om> wrote:
>>>=20
>>>> 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.
>>>>=20
>>>> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
>>>> ---
>>>> arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>>=20
>>>> 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 =3D "SM1-KHADAS-VIM3L";
>>>> +	};
>>>=20
>>> 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=E2=80=99s a nice-to-have not a must-have, but the current LE images t=
hat 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 =E2=80=98wrong=E2=80=99 device nam=
e in GUIs, and
>> I like anything that avoids support work.
>>
>> I=E2=80=99d suggest KHADAS-VIM3-VIM3L as a common name, but then it=E2=
=80=99s 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.=20
>
> 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.

>
> Kevin