All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sekhar Nori <nsekhar@ti.com>
To: Nishanth Menon <nm@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>,
	Device Tree Mailing List <devicetree@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>, Tero Kristo <t-kristo@ti.com>,
	Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, Faiz Abbas <faiz_abbas@ti.com>,
	Lokesh Vutla <lokeshvutla@ti.com>,
	Andre Przywara <andre.przywara@arm.com>
Subject: Re: [PATCH v2 2/4] arm64: dts: ti: k3: squelch warnings regarding no #address-cells for interrupt-controller
Date: Tue, 24 Nov 2020 09:46:53 +0530	[thread overview]
Message-ID: <8885dd79-061b-82e3-1aeb-a318f7d8256d@ti.com> (raw)
In-Reply-To: <20201124012100.fq7w7bjxvewuhbt2@shirt>

On 24/11/20 6:51 AM, Nishanth Menon wrote:
> On 09:45-20201123, Sekhar Nori wrote:
>>>> The main reason I commented - is hope to get some clarification from DT maintainers.
>>>> 90% of interrupt-controller nodes do not have #address-cells and I never seen in in GPIO nodes
>>>> (most often is present in PCI and GIC nodes).
>>>> and nobody seems fixing it. So, if we are going to move this direction it's reasonable to get clarification to be sure.
>>>>
>>>> And there is no "never" here - #address-cells always can be added if really required.
>>>
>>>
>>> OK - as a GPIO node, but as an interrupt-controller node, I was
>>> looking at [1] and wondering if that was the precedence.
>>>
>>> Yes, will be good to get direction from the DT maintainers on this
>>> topic.
>>
>> Shall I respin this series with 2/4 dropped while we wait for decision
>> on this?
>>
>> #address-cells warnings on interrupt controller can perhaps be handled
>> all at once (there are many of those in existing DT anyway).
>>
>> GPIO is basic support and holds up many other modules (like MMC/SD).
> 
> 
> There are'nt too many new patches in my queue that depends on GPIO, I'd
> rather not introduce new warnings unless we are completely at a
> stalemate. I'd rather use this opportunity to understand where what we
> need to be doing.
GPIO was originally submitted as part of 8  patch series titled "[PATCH
0/8] Add support for UHS modes in TI's J721e and J7200 boards"

Rest of those patches need to be resubmitted after GPIO is accepted.

Can you apply patch 1/4 at least. Its fairly non-controversial. It will
help reduce patch backlog and fix some warnings too.

Thanks,
Sekhar

WARNING: multiple messages have this Message-ID (diff)
From: Sekhar Nori <nsekhar@ti.com>
To: Nishanth Menon <nm@ti.com>
Cc: Device Tree Mailing List <devicetree@vger.kernel.org>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Lokesh Vutla <lokeshvutla@ti.com>,
	Andre Przywara <andre.przywara@arm.com>,
	linux-kernel@vger.kernel.org, Faiz Abbas <faiz_abbas@ti.com>,
	Tero Kristo <t-kristo@ti.com>, Rob Herring <robh+dt@kernel.org>,
	Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 2/4] arm64: dts: ti: k3: squelch warnings regarding no #address-cells for interrupt-controller
Date: Tue, 24 Nov 2020 09:46:53 +0530	[thread overview]
Message-ID: <8885dd79-061b-82e3-1aeb-a318f7d8256d@ti.com> (raw)
In-Reply-To: <20201124012100.fq7w7bjxvewuhbt2@shirt>

On 24/11/20 6:51 AM, Nishanth Menon wrote:
> On 09:45-20201123, Sekhar Nori wrote:
>>>> The main reason I commented - is hope to get some clarification from DT maintainers.
>>>> 90% of interrupt-controller nodes do not have #address-cells and I never seen in in GPIO nodes
>>>> (most often is present in PCI and GIC nodes).
>>>> and nobody seems fixing it. So, if we are going to move this direction it's reasonable to get clarification to be sure.
>>>>
>>>> And there is no "never" here - #address-cells always can be added if really required.
>>>
>>>
>>> OK - as a GPIO node, but as an interrupt-controller node, I was
>>> looking at [1] and wondering if that was the precedence.
>>>
>>> Yes, will be good to get direction from the DT maintainers on this
>>> topic.
>>
>> Shall I respin this series with 2/4 dropped while we wait for decision
>> on this?
>>
>> #address-cells warnings on interrupt controller can perhaps be handled
>> all at once (there are many of those in existing DT anyway).
>>
>> GPIO is basic support and holds up many other modules (like MMC/SD).
> 
> 
> There are'nt too many new patches in my queue that depends on GPIO, I'd
> rather not introduce new warnings unless we are completely at a
> stalemate. I'd rather use this opportunity to understand where what we
> need to be doing.
GPIO was originally submitted as part of 8  patch series titled "[PATCH
0/8] Add support for UHS modes in TI's J721e and J7200 boards"

Rest of those patches need to be resubmitted after GPIO is accepted.

Can you apply patch 1/4 at least. Its fairly non-controversial. It will
help reduce patch backlog and fix some warnings too.

Thanks,
Sekhar

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-11-24  4:17 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-17 16:19 [PATCH v2 0/4] arm64: dts: ti: J7200 GPIO support and warning fixes Sekhar Nori
2020-11-17 16:19 ` Sekhar Nori
2020-11-17 16:19 ` [PATCH v2 1/4] arm64: dts: ti: k3: squelch warning about lack of #interrupt-cells Sekhar Nori
2020-11-17 16:19   ` Sekhar Nori
2020-11-17 16:19 ` [PATCH v2 2/4] arm64: dts: ti: k3: squelch warnings regarding no #address-cells for interrupt-controller Sekhar Nori
2020-11-17 16:19   ` Sekhar Nori
2020-11-18 11:38   ` Grygorii Strashko
2020-11-18 11:38     ` Grygorii Strashko
2020-11-18 15:12     ` Nishanth Menon
2020-11-18 15:12       ` Nishanth Menon
2020-11-19 11:17       ` Grygorii Strashko
2020-11-19 11:17         ` Grygorii Strashko
2020-11-19 13:28         ` Nishanth Menon
2020-11-19 13:28           ` Nishanth Menon
2020-11-23  4:15           ` Sekhar Nori
2020-11-23  4:15             ` Sekhar Nori
2020-11-24  1:21             ` Nishanth Menon
2020-11-24  1:21               ` Nishanth Menon
2020-11-24  4:16               ` Sekhar Nori [this message]
2020-11-24  4:16                 ` Sekhar Nori
2020-11-27 14:23                 ` Nishanth Menon
2020-11-27 14:23                   ` Nishanth Menon
2021-01-08 14:05                   ` Lokesh Vutla
2021-01-08 14:05                     ` Lokesh Vutla
2021-01-26  0:01         ` Rob Herring
2021-01-26  0:01           ` Rob Herring
2021-01-26 16:38           ` Andre Przywara
2021-01-26 16:38             ` Andre Przywara
2021-03-11 22:01             ` Nishanth Menon
2021-03-11 22:01               ` Nishanth Menon
2020-11-17 16:19 ` [PATCH v2 3/4] arm64: dts: ti: k3-j7200: Add gpio nodes Sekhar Nori
2020-11-17 16:19   ` Sekhar Nori
2020-11-17 16:19 ` [PATCH v2 4/4] arm64: dts: ti: k3-j7200-common-proc-board: Disable unused gpio modules Sekhar Nori
2020-11-17 16:19   ` Sekhar Nori
2020-11-19 11:20 ` [PATCH v2 0/4] arm64: dts: ti: J7200 GPIO support and warning fixes Grygorii Strashko
2020-11-19 11:20   ` Grygorii Strashko

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=8885dd79-061b-82e3-1aeb-a318f7d8256d@ti.com \
    --to=nsekhar@ti.com \
    --cc=andre.przywara@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=faiz_abbas@ti.com \
    --cc=grygorii.strashko@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lokeshvutla@ti.com \
    --cc=nm@ti.com \
    --cc=robh+dt@kernel.org \
    --cc=t-kristo@ti.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.