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]
Date:   Mon, 14 Nov 2022 13:09:49 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Banajit Goswami <bgoswami@...cinc.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>, alsa-devel@...a-project.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Cc:     Patrick Lai <plai@....qualcomm.com>,
        Srinivasa Rao Mandadapu <srivasam@....qualcomm.com>
Subject: Re: [PATCH 00/10] ASoC: dt-bindings: Rework Qualcomm APR/GPR Sound
 nodes for SM8450

On 14/11/2022 12:50, Srinivas Kandagatla wrote:
> 
> 
> On 14/11/2022 07:48, Krzysztof Kozlowski wrote:
>> On 11/11/2022 17:15, Srinivas Kandagatla wrote:
>>>
>>>
>>> On 11/11/2022 11:35, Krzysztof Kozlowski wrote:
>>>> Adding sound support for Qualcomm SM8450 SoC (and later for SC8280XP) brought
>>>> some changes to APR/GPR services bindings.  These bindings are part of
>>>> qcom,apr.yaml:
>>>>
>>>>     apr-or-gpr-device-node <- qcom,apr.yaml
>>>>       apr-gpr-service@[0-9] <- qcom,apr.yaml
>>>>         service-specific-components <- /schemas/sound/qcom,q6*.yaml
>>>>
>>>> The schema for services (apr-gpr-service@[0-9]) already grows considerably and
>>>> is still quite not specific.  It allows several incorrect combinations, like
>>>> adding a clock-controller to a APM device.  Restricting it would complicate the
>>>> schema even more.  Bringing new support for sound on Qualcomm SM8450 and
>>>> SC8280XP SoC would grow it as well.
>>>
>>> Why would this grow? All the dsp services are static and they will not
>>> change per SoC unless there is a total firmware change in DSP.
>>
>> They grow now with SM8450 which requires changes there. Otherwise DTS
>> does not pass with current bindings. The bindings before my fixing in
>> 2022 were really incomplete. Now they are complete, but:
>> 1. Not for SM8450 - this will bring new things,
>> 2. Very unspecific as they allow multiple invalid configurations.
>>
> Okay, I looked at all the patches, they are fine as it is, the confusion 
> part is the subject and comments which are misleading and trying to say 
> that these are specific to SM8450 or SC8280XP. Infact this is not true, 
> none of these changes are specific to any SoC, they are part of AudioReach.

They are part of bringing audio on SM8450, at the end we all are SoC
centric... we do not bring support for AudioReach just for itself,
right? We bring it because we want to have something working on SM8450
and further...

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ