linux-kernel - Re: [PATCH v2 19/22] ASoC: dt-bindings: mt8192: Document audio-routing and dai-link subnode

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]

Date: Fri, 8 Mar 2024 09:35:05 +0100
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Rob Herring <robh@...nel.org>
Cc: broonie@...nel.org, wenst@...omium.org, lgirdwood@...il.com,
 krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
 matthias.bgg@...il.com, perex@...ex.cz, tiwai@...e.com,
 trevor.wu@...iatek.com, maso.huang@...iatek.com,
 xiazhengqiao@...qin.corp-partner.google.com, arnd@...db.de,
 kuninori.morimoto.gx@...esas.com, shraash@...gle.com, amergnat@...libre.com,
 nicolas.ferre@...rochip.com, u.kleine-koenig@...gutronix.de,
 dianders@...omium.org, frank.li@...o.com, allen-kh.cheng@...iatek.com,
 eugen.hristev@...labora.com, claudiu.beznea@...on.dev,
 jarkko.nikula@...mer.com, jiaxin.yu@...iatek.com, alpernebiyasak@...il.com,
 ckeepax@...nsource.cirrus.com, zhourui@...qin.corp-partner.google.com,
 nfraprado@...labora.com, alsa-devel@...a-project.org,
 shane.chien@...iatek.com, linux-sound@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-mediatek@...ts.infradead.org,
 kernel@...labora.com
Subject: Re: [PATCH v2 19/22] ASoC: dt-bindings: mt8192: Document
 audio-routing and dai-link subnode

Il 07/03/24 15:12, Rob Herring ha scritto:
> On Thu, Mar 07, 2024 at 12:44:42PM +0100, AngeloGioacchino Del Regno wrote:
>> Document the dai-link subnodes and the audio-routing property, allowing
>> to describe machine specific audio hardware and links in device tree.
>>
>> While at it, also deprecate the old properties which were previously
>> used with the driver's partially hardcoded configuration.
>>
> 
> I replied on v1, but one more thing here.
> 
>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
>> ---
>>   .../sound/mt8192-mt6359-rt1015-rt5682.yaml    | 124 ++++++++++++++++--
>>   1 file changed, 115 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml b/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml
>> index 7e50f5d65c8f..449454c50dcc 100644
>> --- a/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml
>> +++ b/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml
>> @@ -13,6 +13,9 @@ maintainers:
>>   description:
>>     This binding describes the MT8192 sound card.
>>   
>> +allOf:
>> +  - $ref: sound-card-common.yaml#
>> +
>>   properties:
>>     compatible:
>>       enum:
>> @@ -20,6 +23,14 @@ properties:
>>         - mediatek,mt8192_mt6359_rt1015p_rt5682
>>         - mediatek,mt8192_mt6359_rt1015p_rt5682s
>>   
>> +  audio-routing:
>> +    description:
>> +      A list of the connections between audio components. Each entry is a
>> +      pair of strings, the first being the connection's sink, the second
>> +      being the connection's source.
>> +      Valid names could be the input or output widgets of audio components,
>> +      power supplies, MicBias of codec and the software switch.
>> +
>>     mediatek,platform:
>>       $ref: /schemas/types.yaml#/definitions/phandle
>>       description: The phandle of MT8192 ASoC platform.
>> @@ -27,10 +38,12 @@ properties:
>>     mediatek,hdmi-codec:
>>       $ref: /schemas/types.yaml#/definitions/phandle
>>       description: The phandle of HDMI codec.
>> +    deprecated: true
> 
> The deprecated keyword doesn't do anything at the moment, but my plan
> there is to add a mode to the tools which disables all deprecated
> properties. That will give you want you want in terms of disallowing
> these properties.

That would definitely be awesome - looking forward to it!

> 
> That would require dropping them from "required" which I'm fine with you
> doing. (Though technically that's still an ABI change)
> 

Then instead of waiting for you to add that mode and then remove stuff later,
I'll just omit the `else: required:` block on v3, so that we avoid commit
noise and all the warnings when the deprecated check gets released.

I guess that's fine, right?

Cheers,
Angelo