On Wed, 2018-08-08 at 06:28 +0000, Bharat Bhushan wrote:

quoted

-----Original Message-----
From: Scott Wood [mailto:oss@buserror.net]
Sent: Wednesday, August 8, 2018 11:26 AM
To: Bharat Bhushan <redacted>;
benh@kernel.crashing.org; paulus@samba.org; mpe@ellerman.id.au;
galak@kernel.crashing.org; mark.rutland@arm.com;
kstewart@linuxfoundation.org; gregkh@linuxfoundation.org;
devicetree@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
kernel@vger.kernel.org
Cc: robh@kernel.org; keescook@chromium.org; tyreld@linux.vnet.ibm.com;
joe@perches.com
Subject: Re: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

On Wed, 2018-08-08 at 03:44 +0000, Bharat Bhushan wrote:

quoted

quoted

-----Original Message-----
From: Scott Wood [mailto:oss@buserror.net]
Sent: Wednesday, August 8, 2018 2:44 AM
To: Bharat Bhushan <redacted>;
benh@kernel.crashing.org; paulus@samba.org; mpe@ellerman.id.au;
galak@kernel.crashing.org; mark.rutland@arm.com;
kstewart@linuxfoundation.org; gregkh@linuxfoundation.org;
devicetree@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
kernel@vger.kernel.org
Cc: robh@kernel.org; keescook@chromium.org;
tyreld@linux.vnet.ibm.com; joe@perches.com
Subject: Re: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for
P2020

On Fri, 2018-07-27 at 15:18 +0530, Bharat Bhushan wrote:

quoted

MPIC on NXP (Freescale) P2020 supports following irq
ranges:
  > 0 - 11      (External interrupt)
  > 16 - 79     (Internal interrupt)
  > 176 - 183   (Messaging interrupt)
  > 224 - 231   (Shared message signaled interrupt)

Why don't you convert to the 4-cell interrupt specifiers that make
dealing with these ranges less error-prone?

Ok , will do if we agree to have this series as per comment on other
patch.

If you're concerned with errors, this would be a good things to do
regardless.
 Actually, it seems that p2020si-post.dtsi already uses 4-cell interrupts.

What is motivating this patchset?  Is there something wrong in the
existing
dts files?

There is no error in device tree. Main motivation is to improve code for
following reasons: 
  - While code study it was found that if a reserved irq-number used then
there are no check in driver. irq will be configured as correct and
interrupt will never fire.

Again, a wrong interrupt number won't fire, whether an interrupt by that
number exists or not.  I wouldn't mind a sanity check in the driver if the
programming model made it properly discoverable, but I don't think it's worth
messing with device trees just for this (and even less so given that there
don't seem to be new chips coming out that this would be relevant for).

quoted

quoted

One other confusing observation I have is that "irq_count" from
platform code is given precedence over "last-interrupt-source" in
device-

tree.

quoted

Should not device-tree should have precedence otherwise there is no
point using " last-interrupt-source" if platform code passes
"irq_count" in mpic_alloc().

Maybe, though I don't think it matters much given that last-interrupt-
source
was only added to avoid having to pass irq_count in platform code.

Thanks for clarifying;

My understanding was that "last-interrupt-source" added to ensure that we
can over-ride value passed from platform code. In that case we do not need
to change code and can control from device tree.

The changelog says, "To avoid needing to write custom board-specific code to
detect that scenario, allow it to be easily overridden in the device-tree,"
where "it" means the value provided by hardware.  The goal was to pass in 256
without board code in the kernel, not to override the 256.

-Scott