linux-kernel - Re: [PATCH v11 2/3] ASoC: qcom: dt-bindings: Add sc7180 machine bindings

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: <7bdc0d63-27b1-f99e-c5f8-65f880733d16@linaro.org>
Date:   Tue, 13 Oct 2020 11:36:33 +0100
From:   Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:     Cheng-Yi Chiang <cychiang@...omium.org>,
        linux-kernel@...r.kernel.org
Cc:     Mark Brown <broonie@...nel.org>, Taniya Das <tdas@...eaurora.org>,
        Rohit kumar <rohitkr@...eaurora.org>,
        Banajit Goswami <bgoswami@...eaurora.org>,
        Patrick Lai <plai@...eaurora.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Stephan Gerhold <stephan@...hold.net>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Heiko Stuebner <heiko@...ech.de>,
        Srinivasa Rao <srivasam@...eaurora.org>, dianders@...omium.org,
        dgreid@...omium.org, tzungbi@...omium.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        alsa-devel@...a-project.org, linux-mediatek@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH v11 2/3] ASoC: qcom: dt-bindings: Add sc7180 machine
 bindings

Hi Cheng,

Sorry for such late review w.r.t compatibles,

On 14/09/2020 09:06, Cheng-Yi Chiang wrote:
> +---
> +$id:http://devicetree.org/schemas/sound/qcom,sc7180.yaml#
> +$schema:http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Technologies Inc. SC7180 ASoC sound card driver
> +
> +maintainers:
> +  - Rohit kumar<rohitkr@...eaurora.org>
> +  - Cheng-Yi Chiang<cychiang@...omium.org>
> +
> +description:
> +  This binding describes the SC7180 sound card which uses LPASS for audio.
> +
> +properties:
> +  compatible:
> +    const: qcom,sc7180-sndcard-rt5682-m98357-1mic

This information can come from the dai link description itself, why 
should compatible string have this information?

Can't we have better compatible string with actual board name or use the 
same compatible name as used by other boards?

Can you give us some details on the advantages of doing this way?

Or am I missing something?

AFAIU, you should add proper board name / model name to the compatible 
string rather than describe how its connected. Connection is already 
part of dai link definition.

On the other hand model property can include variant information.
This can also be used to set card long name which will help in UCM2.

The reason I had to bring this up is because the use-space (ucm in this 
case) will not be in a position to differentiate between different board 
variants to select correct mixer controls, so its going to be a pain!

Thanks,
srini