linux-kernel - Re: [PATCHv3 RESEND 00/10] ASoC: fsl-asoc-card: compatibility integration of a generic codec use case for use with S/PDIF controller

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: <fae1e6f8-f679-4266-95b6-5879c71683a4@linaro.org>
Date: Mon, 18 Dec 2023 13:46:58 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Elinor Montmasson <elinor.montmasson@...oirfairelinux.com>,
 Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
 Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Shengjiu Wang <shengjiu.wang@...il.com>,
 Xiubo Li <Xiubo.Lee@...il.com>, Fabio Estevam <festevam@...il.com>,
 Nicolin Chen <nicoleotsuka@...il.com>, Jaroslav Kysela <perex@...ex.cz>,
 Takashi Iwai <tiwai@...e.com>
Cc: linux-sound@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, alsa-devel@...a-project.org,
 linuxppc-dev@...ts.ozlabs.org,
 Philip-Dylan <philip-dylan.gleonec@...oirfairelinux.com>
Subject: Re: [PATCHv3 RESEND 00/10] ASoC: fsl-asoc-card: compatibility
 integration of a generic codec use case for use with S/PDIF controller

On 18/12/2023 13:40, Elinor Montmasson wrote:
> Hello,
> 
> This is the v3 of the series of patch aiming to make the machine driver
> "fsl-asoc-card" compatible with use cases where there is no real codec
> driver.
> It proposes to use the "spdif_receiver" and "spdif_transmitter"
> drivers instead of the dummy codec.
> This is a first step in using the S/PDIF controller with the ASRC.
> 
> The five first patches add compatibility with the pair of codecs
> "spdif_receiver" and "spdif_transmitter" with a new compatible,
> "fsl,imx-audio-generic".
> Codec parameters are set with default values.
> Consequently, the driver is modified to work with multi-codec use cases.
> It can get 2 codecs phandles from the device tree, and the
> "fsl_asoc_card_priv" struct now has 2 "codec_priv" to store properties
> of both codecs. It is fixed to 2 codecs as only "fsl,imx-audio-generic"
> uses multiple codecs at the moment.
> However, the driver now uses for_each_codecs macros when possible to
> ease future implementations of multi-codec configurations.
> 
> The remaining patches add configuration options for the device tree.
> They configure the CPU DAI when using "fsl,imx-audio-generic".
> These options are usually hard-coded in "fsl-asoc-card.c" for each
> audio codec.
> Because the generic codec could be used with other CPU DAIs than
> the S/PDIF controller, setting these parameters could be required.
> 
> This series of patch was successfully built for arm64 and x86 on top of
> the latest for-next branch of the ASoC git tree on the 14th of December.
> These modifications have also been tested on an i.MX8MN evaluation
> board, with a linux kernel RT v6.1.26-rt8.
> 
> 
> We also have a few questions, following remarks made by
> Krzysztof Kozlowski in a previous email for patch 10/10:
> 
>>>>> The compatible list for this generic sound card currently:
>>>>> @@ -48,6 +51,8 @@ The compatible list for this generic sound card
>>>>> currently:
>>>>>
>>>>> "fsl,imx-audio-nau8822"
>>>>>
>>>>> + "fsl,imx-audio-generic"
>>>>
>>>> Generic does not look like hardware specific.
>>>
>>> Even if our end goal is to use it with the S/PDIF controller, this new
>>> support can be used with different hardware that doesn't
>>> require a codec. Thus, we don't really want to specify "spdif" in it.
>>>
>>> Is this compatible string not suitable ?
>>> Should we rename it to something else, like "fsl,imx-audio-no-codec" ?
>>
>> Maybe Mark or Rob will help here, but for me "imx-audio" is just way too
>> generic.
> 
> * Which generic name should we use ? Or how should we change it?

Compatible should be specific to one SoC, even if there is one driver
for entire family.

>  
>> Also, you add several new properties, so I really expect either
>> converting old binding to DT schema first or adding new device in DT
>> schema format.
> 
> * fsl-asoc-card.txt currently follows the old dt-bindings format.
> Should we update it to DT schema format in this patch series
> before adding my new properties?

You add six new properties, so from my point of view this cannot be in TXT.

Best regards,
Krzysztof