linux-kernel - Re: [PATCH 04/38] ASoC: dt-bindings: mt8192-afe-pcm: Fix clocks and clock-names

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]

Message-ID: <fe135942-3040-4858-b2e4-a8e4507b89e9@collabora.com>
Date: Mon, 4 Aug 2025 11:08:11 +0200
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
 linux-mediatek@...ts.infradead.org, robh@...nel.org
Cc: herbert@...dor.apana.org.au, davem@...emloft.net, krzk+dt@...nel.org,
 conor+dt@...nel.org, chunkuang.hu@...nel.org, p.zabel@...gutronix.de,
 airlied@...il.com, simona@...ll.ch, maarten.lankhorst@...ux.intel.com,
 mripard@...nel.org, tzimmermann@...e.de, jassisinghbrar@...il.com,
 mchehab@...nel.org, matthias.bgg@...il.com, chunfeng.yun@...iatek.com,
 vkoul@...nel.org, kishon@...nel.org, sean.wang@...nel.org,
 linus.walleij@...aro.org, lgirdwood@...il.com, broonie@...nel.org,
 andersson@...nel.org, mathieu.poirier@...aro.org, daniel.lezcano@...aro.org,
 tglx@...utronix.de, atenart@...nel.org, jitao.shi@...iatek.com,
 ck.hu@...iatek.com, houlong.wei@...iatek.com,
 kyrie.wu@...iatek.corp-partner.google.com, andy.teng@...iatek.com,
 tinghan.shen@...iatek.com, jiaxin.yu@...iatek.com, shane.chien@...iatek.com,
 olivia.wen@...iatek.com, granquet@...libre.com, eugen.hristev@...aro.org,
 arnd@...db.de, sam.shih@...iatek.com, jieyy.yang@...iatek.com,
 frank-w@...lic-files.de, mwalle@...nel.org, fparent@...libre.com,
 linux-crypto@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 linux-media@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-phy@...ts.infradead.org, linux-gpio@...r.kernel.org,
 linux-remoteproc@...r.kernel.org, linux-sound@...r.kernel.org
Subject: Re: [PATCH 04/38] ASoC: dt-bindings: mt8192-afe-pcm: Fix clocks and
 clock-names

Il 24/07/25 11:12, Krzysztof Kozlowski ha scritto:
> On 24/07/2025 10:38, AngeloGioacchino Del Regno wrote:
>>   
>>     clock-names:
>>       items:
>>         - const: aud_afe_clk
>>         - const: aud_dac_clk
>>         - const: aud_dac_predis_clk
>> +      - const: aud_adc_clk
>> +      - const: aud_adda6_adc_clk
>> +      - const: aud_apll22m_clk
>> +      - const: aud_apll24m_clk
>> +      - const: aud_apll1_tuner_clk
>> +      - const: aud_apll2_tuner_clk
>> +      - const: aud_tdm_clk
>> +      - const: aud_tml_clk
>> +      - const: aud_nle
>> +      - const: aud_dac_hires_clk
>> +      - const: aud_adc_hires_clk
>> +      - const: aud_adc_hires_tml
>> +      - const: aud_adda6_adc_hires_clk
>> +      - const: aud_3rd_dac_clk
>> +      - const: aud_3rd_dac_predis_clk
>> +      - const: aud_3rd_dac_tml
>> +      - const: aud_3rd_dac_hires_clk
>>         - const: aud_infra_clk
>>         - const: aud_infra_26m_clk
> 
> 
> You can only add to the end of lists, not in the middle.
> 

The devicetree follows exactly what I've done here, and if I add to the
end of the list (which was wrong from the beginning), I'd have to reorder
all of the clocks in the devicetree node as well.

I know that I'm not supposed to add those there, but this is not about adding
new clocks, it's about adding ones that were missing in the middle.

> Also, please drop all _clk suffixes and aud/top prefixes. These are
> supposed to be clock inputs, so you name them based on this device. Not
> based on the provider's name.

That breaks everything: the driver uses the _clk suffixes and aud/top prefixes
to get clocks by name - I know that "driver" and "binding" are not two words
that go together in that sense, but *otherwise* we'd need to perform way bigger
changes to get this situation resolved.

Those "way bigger changes" would also add bloat to the kernel as we'd need to
parse clocks with old and new names.

Can we please avoid this on SoCs from years ago, which are only getting maintenance
and no new feat/dev?

Thanks,
Angelo