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] [day] [month] [year] [list]

Message-ID: <a36c434e-0fb6-43f0-b9a7-c59f0c7bc9f9@kernel.org>
Date: Sat, 24 Aug 2024 08:19:12 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Georgi Djakov <djakov@...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 24/08/2024 01:39, Georgi Djakov wrote:
> 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.

Vinod sent his patch more than a year ago, so I think we are indeed
giving up on this :)

Best regards,
Krzysztof