linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).