linux-kernel - Re: [PATCH] dt-bindings: interconnect: qcom: Do not require reg for sc8180x virt NoCs

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: <7c75defd-372b-42cc-897a-eb46e4a8966e@kernel.org>
Date: Sat, 24 Aug 2024 02:39:49 +0300
From: Georgi Djakov <djakov@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
 quic_okukatla@...cinc.com, linux-arm-msm@...r.kernel.org,
 linux-pm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, Vinod Koul <vkoul@...nel.org>
Subject: Re: [PATCH] dt-bindings: interconnect: qcom: Do not require reg for
 sc8180x virt NoCs

On 30.07.24 17:32, Krzysztof Kozlowski wrote:
> On 30/07/2024 16:10, djakov@...nel.org wrote:
>> From: Georgi Djakov <djakov@...nel.org>
>>
>> The virtual interconnect providers do not have their own IO address space,
>> but this is not documented in the DT schema and the following warnings are
>> reported by dtbs_check:
>>
>> sc8180x-lenovo-flex-5g.dtb: interconnect-camnoc-virt: 'reg' is a required property
>> sc8180x-lenovo-flex-5g.dtb: interconnect-mc-virt: 'reg' is a required property
>> sc8180x-lenovo-flex-5g.dtb: interconnect-qup-virt: 'reg' is a required property
>> sc8180x-primus.dtb: interconnect-camnoc-virt: 'reg' is a required property
>> sc8180x-primus.dtb: interconnect-mc-virt: 'reg' is a required property
>> sc8180x-primus.dtb: interconnect-qup-virt: 'reg' is a required property
>>
>> Fix this by adding them to the list of compatibles that do not require
>> the reg property.
> 
> So I guess we are giving up on
> https://lore.kernel.org/all/20230530162454.51708-4-vkoul@kernel.org/
> ?

Thanks for the pointer! That approach is fine too, but i was expecting
a re-send and then later completely forgot about it. I have a slight
preference towards my patch, because it is more compact, but i can also
revive Vinod's patch if you think that it would be a better pattern to
follow in the long term.

BR,
Georgi