From: Melody Olvera <quic_molvera@quicinc.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Georgi Djakov <djakov@kernel.org>, Andy Gross <agross@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Odelu Kukatla <quic_okukatla@quicinc.com>,
<linux-arm-msm@vger.kernel.org>, <linux-pm@vger.kernel.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 1/3] dt-bindings: interconnect: Remove required reg field
Date: Mon, 7 Nov 2022 14:46:36 -0800 [thread overview]
Message-ID: <aa22ab8e-903d-07bb-f390-9ca32752af71@quicinc.com> (raw)
In-Reply-To: <225f3ff2-62cb-7f11-3eb1-f677360b4359@linaro.org>
On 11/7/2022 10:28 AM, Krzysztof Kozlowski wrote:
> On 07/11/2022 15:36, Georgi Djakov wrote:
>> Hi,
>>
>> On 2.11.22 23:11, Krzysztof Kozlowski wrote:
>>> On 31/10/2022 19:29, Melody Olvera wrote:
>>>>
>>>> On 10/27/2022 8:29 AM, Krzysztof Kozlowski wrote:
>>>>> On 26/10/2022 15:05, Melody Olvera wrote:
>>>>>> Many of the *-virt compatible devices do not have a reg field
>>>>>> so remove it as required from the bindings.
>>>>> and some virt have it... This should be probably separate binding or if
>>>>> the list is small - allOf:if:then.
>>>> I attempted this; however I'm still seeing failures in dtb_check. I've added this
>>>> to the binding; does this look correct?
>>>> allOf:
>>>> - $ref: qcom,rpmh-common.yaml#
>>>> + - if:
>>>> + properties:
>>>> + compatible:
>>>> + contains:
>>>> + enum:
>>>> + - qcom,qdu1000-clk-virt
>>>> + - qcom,qdu1000-mc-virt
>>>> +
>>>> + then:
>>>> + required:
>>>> + - compatible
>>> No, because we talk about reg, not compatible. You should not require
>>> reg instead for some compatibles... but then the schema is getting
>>> complicated.
>>>
>>> It's difficult to give you recommendation because I do not know what are
>>> all these "virt" interconnects. Why some have unit address, why some do not?
>> My understanding is that the "reg" property is required for the NoCs that have
>> registers for controlling the QoS settings for the ports from Linux side.
>> Other NoCs might be controlled by some remote processor and direct access from
>> Linux may not be possible, so they do not have unit address and are outside of
>> the soc DT node.
>> Do we need to strictly define when exactly the "reg" property is required,
>> can't we just mark it as optional?
> It's preferred to make it strictly required or not allowed, so the
> bindings are specific. This also allows to validate for mistakes. It
> would be a bit different case if such test for req would make the
> bindings complicated. I think it's not the case because we could just
> split the bindings into two files:
> 1. One for controlled by AP, with reg.
> 2. One for controller by remote processors, without reg.
>
Sounds good. Will drop this change and add a new binding document.
Thanks,
Melody
next prev parent reply other threads:[~2022-11-07 22:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-26 19:05 [PATCH v3 0/3] Add interconnect support for QDU1000/QRU1000 SoCs Melody Olvera
2022-10-26 19:05 ` [PATCH v3 1/3] dt-bindings: interconnect: Remove required reg field Melody Olvera
2022-10-27 15:29 ` Krzysztof Kozlowski
2022-10-31 23:29 ` Melody Olvera
2022-11-02 21:11 ` Krzysztof Kozlowski
2022-11-07 14:36 ` Georgi Djakov
2022-11-07 18:28 ` Krzysztof Kozlowski
2022-11-07 22:46 ` Melody Olvera [this message]
2022-10-26 19:05 ` [PATCH v3 2/3] dt-bindings: interconnect: Add QDU1000/QRU1000 dt bindings Melody Olvera
2022-10-27 15:29 ` Krzysztof Kozlowski
2022-10-26 19:05 ` [PATCH v3 3/3] interconnect: qcom: Add QDU1000/QRU1000 interconnect driver Melody Olvera
2022-10-27 15:31 ` Krzysztof Kozlowski
2022-11-07 22:45 ` Melody Olvera
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aa22ab8e-903d-07bb-f390-9ca32752af71@quicinc.com \
--to=quic_molvera@quicinc.com \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=djakov@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=quic_okukatla@quicinc.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).