linux-kernel - Re: [PATCH v3 2/3] dt-bindings: rockchip: rk809: Document audio codec properties

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: <0b0a4c9f-0549-4566-a900-b1d7de5838d5@linaro.org>
Date: Tue, 23 Jan 2024 08:37:54 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Tim Lunn <tim@...thertop.org>, linux-rockchip@...ts.infradead.org,
 conor.dooley@...rochip.com, robh+dt@...nel.org, devicetree@...r.kernel.org
Cc: linux-arm-kernel@...ts.infradead.org, Chris Zhong <zyw@...k-chips.com>,
 Conor Dooley <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Lee Jones <lee@...nel.org>, Zhang Qing <zhangqing@...k-chips.com>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/3] dt-bindings: rockchip: rk809: Document audio codec
 properties

On 23/01/2024 05:10, Tim Lunn wrote:
> 
> On 1/22/24 19:14, Krzysztof Kozlowski wrote:
>> On 20/01/2024 14:55, Tim Lunn wrote:
>>> Rockchip RK809 shares the same audio codec block as the rk817 mfd, and
>>> is compatible with the existing rk817_codec driver.
>> Please use subject prefixes matching the subsystem. You can get them for
>> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
>> your patch is touching.
> Ok I will check this.
>>
>>> This patch introduces to the binding the standard property #sound-dai-cells
>>> and also an optional codec child node to hold codec specific properties.
>>> Currently there is only one property in this node however the downstream
>>> driver shows a number of other properties that are supported by the codec
>>> hardware, that could be implemented in the future. This maintains the
>>> existing driver ABI and keeps consistency with the rk817 bindings.
>> So you are adding a new node? Just for one property? No, just put it
>> into parent node.
> The existing upstream codec driver parses the property from the "codec" 
> sub-node, if I
> move it to the parent node here, I will need to patch the codec driver 
> to search in both locations,
> so as to not break the rk817 bindings.  If that is preferred, I can do 
> it that way.

Your long commit msg has just very short mention about existing driver
and the rest is not helpful. Please rephrase to explain why and what you
are doing it.

>>
>> Downstream driver does not matter at all in that aspect.
>>
> The codec hardware supports additional properties but they are not 
> implemented currently in
> upstream driver.


Again: it does not matter. Bindings are not about drivers.

Best regards,
Krzysztof