linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Suman Anna <s-anna@ti.com>
To: Rob Herring <robh@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>, Nishanth Menon <nm@ti.com>,
	Lokesh Vutla <lokeshvutla@ti.com>, Sekhar Nori <nsekhar@ti.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	David Lechner <david@lechnology.com>,
	<devicetree@vger.kernel.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Subject: Re: [PATCH] dt-bindings: irqchip: Add #address-cells to PRUSS INTC
Date: Tue, 26 Jan 2021 09:54:46 -0600	[thread overview]
Message-ID: <23225695-57ea-f255-798b-17cf6962e543@ti.com> (raw)
In-Reply-To: <CAL_JsqLYfGvJ=zYbdJp4pUjmmJ_ROu1u_0dVwTj06Cw5+23fGw@mail.gmail.com>

Hi Rob,

On 1/25/21 8:47 PM, Rob Herring wrote:
> On Mon, Jan 25, 2021 at 6:16 PM Suman Anna <s-anna@ti.com> wrote:
>>
>> Hi Rob,
>>
>> On 1/25/21 6:04 PM, Rob Herring wrote:
>>> On Fri, Jan 15, 2021 at 02:58:19PM -0600, Suman Anna wrote:
>>>> The '#address-cells' property looks to be a required property for
>>>> interrupt controller nodes as indicated by a warning message seen
>>>> when building dtbs with W=2. Adding the property to the PRUSS INTC
>>>> dts nodes though fails the dtbs_check. Add this property to the
>>>> PRUSS INTC binding to make it compliant with both dtbs_check and
>>>> building dtbs.
>>>>
>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>> ---
>>>> Hi Rob,
>>>>
>>>> This patch is also part of our effort to get rid of the warnings seen
>>>> around interrupt providers on TI K3 dtbs [1]. I needed this in the PRUSS
>>>> INTC bindings to not get a warning with dtbs_check while also ensuring
>>>> no warnings while building dtbs with W=2.
>>>>
>>>> I would have expected the '#address-cells' requirement to be inherited
>>>> automatically. And looking through the schema files, I actually do not
>>>> see the interrupt-controller.yaml included automatically anywhere. You
>>>> had asked us to drop the inclusion in this binding in our first version
>>>> with YAML [3]. Am I missing something, and how do we ensure that this
>>>> is enforced automatically for everyone?
>>>
>>> interrupt-controller.yaml is applied to any node named
>>> 'interrupt-controller'. More generally, if 'compatible' is not present,
>>> then we look at $nodename for the default 'select'. In your case, you
>>> didn't name the node appropriately.
>>
>> Thanks for the clarification. Yeah, I didn't add anything specifically, since
>> the expectation is interrupt-controller. Should I be adding that to this binding?
> 
> No, either interrupt-controller.yaml needs to learn a new node name or
> your node names need to be fixed. I prefer the latter, but if you have
> more than 1 and don't have a unit-address (and in turn a 'reg' prop)
> we'd have to do the former. How are the interrupts controllers
> accessed if there's no way to address them?

The PRUSS INTC will always have a unit-address, so we won't have the issues with
having to maintain unique names. All my examples already have the nodes in the
form 'interrupt-controller@<addr>'. Anyway, I will drop this patch, and post a
new patch adding the $nodename to the binding.

> 
>>
>>>
>>> We can't check this in interrupt-controller.yaml because #address-cells
>>> is not always 0. GICv3 is one notable exception.
>>>
>>>>
>>>> regards
>>>> Suman
>>>>
>>>> [1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210115083003.27387-1-lokeshvutla@ti.com/
>>>
>>> I've commented on this thread now in regards to #address-cells.
>>
>> I suppose I still need this patch to be defined to unblock the ICSSG nodes
>> getting accepted by our dts maintainer. Care to give your Reviewed-by for the
>> change? Or I can spin a v2 with $nodename added as well if that's needed too.
> 
> No, I don't think you have to add #address-cells. We need to fix the
> warning in dtc.

Thank you for clarifying this.

regards
Suman

      reply	other threads:[~2021-01-26 15:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-15 20:58 [PATCH] dt-bindings: irqchip: Add #address-cells to PRUSS INTC Suman Anna
2021-01-26  0:04 ` Rob Herring
2021-01-26  0:16   ` Suman Anna
2021-01-26  0:16     ` Suman Anna
2021-01-26  2:47     ` Rob Herring
2021-01-26 15:54       ` Suman Anna [this message]

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=23225695-57ea-f255-798b-17cf6962e543@ti.com \
    --to=s-anna@ti.com \
    --cc=david@lechnology.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grzegorz.jaszczyk@linaro.org \
    --cc=jan.kiszka@siemens.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=lokeshvutla@ti.com \
    --cc=maz@kernel.org \
    --cc=nm@ti.com \
    --cc=nsekhar@ti.com \
    --cc=robh@kernel.org \
    --cc=tglx@linutronix.de \
    /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).