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

Message-ID: <kh54xgfvp6rypbvk7eyemg7zsvum2krhsyh6dqa5ck6zf3ph24@szxffcrzngd7>
Date: Fri, 17 Oct 2025 16:50:01 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Srinivas Kandagatla <srinivas.kandagatla@....qualcomm.com>
Cc: Alexey Klimov <alexey.klimov@...aro.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        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 Fri, Oct 17, 2025 at 12:27:55PM +0100, Srinivas Kandagatla wrote:
> 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.

My preference would be to follow the established pattern, unless there
is a good reason to deviate from it. And... it seems we have several
trends there.

- qcom,SoC-sndcard (with possible fallback to earlier SoC). 35 usages
  out of 49, including the recent ones as X1E8, SM[4567]50, SC8280XP,
  QCS8300 and others

- Two users of qcom,SoC-qdsp6-sndcard, let's ignore them.

- 12 users of Board-specific compat string, which includes RB2, RB3,
  RB5, RB3 Gen2, FP4 and FP5 (and several other platforms). Some (3
  SDM845 devices) of these devices use an SoC compat as a fallback
  string, which adds weight to the first bucket.

The "winner" is obvious, but I couldn't help but notice the lack of
generic approach (and yes, before i grepped '-sndcard' I was under
assumption that the board-specific sndcard is a recommended approach,
looking at the boards and phones I cared most).

TL;DR. Alexey, I'm sorry for the possible misguidance earlier. It seems
this device should also use a generic name "qcom,qcm2290-sndcard" (or
"qcom,qrb2210-sndcard").

-- 
With best wishes
Dmitry