linux-kernel - Re: [PATCH 1/2] dt-bindings: sound: qcom,sm8250: add QRB2210 and RB1 soundcards

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: <695ff482-ad53-45fc-9ab0-ad69d8bc89d5@oss.qualcomm.com>
Date: Fri, 17 Oct 2025 12:27:55 +0100
From: Srinivas Kandagatla <srinivas.kandagatla@....qualcomm.com>
To: Alexey Klimov <alexey.klimov@...aro.org>,
        Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>
Cc: Srinivas Kandagatla <srini@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
        Rob Herring <robh@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
        linux-sound@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: sound: qcom,sm8250: add QRB2210 and RB1
 soundcards

On 10/17/25 8:35 AM, Alexey Klimov wrote:
> On Thu Oct 16, 2025 at 8:46 PM BST, Dmitry Baryshkov wrote:
>> On Thu, 16 Oct 2025 at 18:08, Srinivas Kandagatla
>> <srinivas.kandagatla@....qualcomm.com> wrote:
>>>
>>>
>>>
>>> On 10/7/25 2:26 AM, Alexey Klimov wrote:
>>>> Add soundcard compatible for QRB2210 (QCM2290) platforms.
>>>> While at this, also add QRB2210 RB1 entry which is set to be
>>>> compatible with QRB2210 soundcard.
>>>>
>>>> Cc: Srinivas Kandagatla <srini@...nel.org>
>>>> Signed-off-by: Alexey Klimov <alexey.klimov@...aro.org>
>>>> ---
>>>>  Documentation/devicetree/bindings/sound/qcom,sm8250.yaml | 5 +++++
>>>>  1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
>>>> index 8ac91625dce5ccba5c5f31748c36296b12fac1a6..c29e59d0e8043fe2617b969be216525b493458c4 100644
>>>> --- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
>>>> +++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
>>>> @@ -21,6 +21,10 @@ properties:
>>>>                - lenovo,yoga-c630-sndcard
>>>>                - qcom,db845c-sndcard
>>>>            - const: qcom,sdm845-sndcard
>>>> +      - items:
>>>> +          - enum:
>>>> +              - qcom,qrb2210-rb1-sndcard
>>> I don't think you need rb1 specific compatible here, unless there this
>>> is totally different to what the base compatible can provide.
>>
>> Why do we need to deviate from other platforms which declare
>> board-specific compat too?
> 
> There seems to be now a few incompatible suggestions for rb1 sndcard:
> - make it compatible/fallback to qcom,sm8250-sndcard (1);
> - make it compatible/fallback to qcom,qrb4210-rb2-sndcard (2);
> - add separate compatible/enum for rb1 sndcard as qcom,qrb2210-rb1-sndcard (3);
> - add base compatible as qcom,qrb2210-sndcard and fallback
> rb1 sndcard compatible to it.
> 
> The latter one is ruled out because base compatible should be used and
> it is not going to.
> 
> As far as I can see the last addition went simply with (3).
> Which one finally you all want?

Am fine with either "qcom,sm8250-sndcard" or "qcom,qrb4210-rb1-sndcard"
as long as we reflect that correct driver name in machine driver.

traditionally we have SoC level compatible which works fine for 99% of
the boards for that SoC, expectation was that if there is any deviation
or board specific changes required, this can be accommodate using model
information. am fine with board specific compatible too, however am not
okay with both "qcom,sm8250-sndcard" and "qcom,qrb4210-rb1-sndcard"  or
falling back to another board compatible for various reason one being ucm.

So 1 and 2 re *NOK*

I hope this provides some clarity here.

thanks,
Srini>
> Best regards,
> Alexey
>