[RFC 0/5] powerpc/mpic: Add non-contiguous interrupt sources

[RFC 0/5] powerpc/mpic: Add non-contiguous interrupt sources

[Bharat Bhushan]

Freescale MPIC h/w may not support all interrupt sources reported
by hardware or "last-interrupt-source" or platform. On these platforms
a misconfigured device tree that assigns one of the reserved
interrupts leaves a non-functioning system without warning.
 
First Patch just moves the last-irq calculation logic to a function,
Second patch reworks same logic, While I feel that device-tree should
 get precedence over platform provided last-irq, but in this series
 I have not changed this logic.
Third and fourth patch add non-contiguous interrupt sources support
Fifth patch enables this for P2020RDB-PC for now.

Bharat Bhushan (5):
  powerpc/mpic: move last irq logic to function
  powerpc/mpic: Rework last source irq calculation logic
  powerpc/mpic: Add support for non-contiguous irq ranges
  powerpc/mpic: Boot print supported interrupt ranges
  powerpc/fsl: Add supported-irq-ranges for P2020

 .../devicetree/bindings/powerpc/fsl/mpic.txt       |   8 +
 arch/powerpc/boot/dts/fsl/p2020si-post.dtsi        |   3 +
 arch/powerpc/include/asm/mpic.h                    |   9 +
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c          |   5 +
 arch/powerpc/sysdev/mpic.c                         | 184 ++++++++++++++++++---
 5 files changed, 182 insertions(+), 27 deletions(-)

-- 
1.9.3

[RFC 1/5] powerpc/mpic: move last irq logic to function

[Bharat Bhushan]

This function just moves the last-irq calculation
logic to a function, while no change in logic.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@nxp.com>
---
 arch/powerpc/sysdev/mpic.c | 52 +++++++++++++++++++++++++++++-----------------
 1 file changed, 33 insertions(+), 19 deletions(-)

diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 353b439..b6803bc 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1210,6 +1210,36 @@ u32 fsl_mpic_primary_get_version(void)
 	return 0;
 }
 
+static int mpic_get_last_irq_source(struct mpic *mpic,
+				    unsigned int irq_count,
+				    unsigned int isu_size)
+{
+	u32 last_irq;
+	u32 greg_feature;
+
+	/*
+	 * Read feature register.  For non-ISU MPICs, num sources as well. On
+	 * ISU MPICs, sources are counted as ISUs are added
+	 */
+	greg_feature = mpic_read(mpic->gregs, MPIC_INFO(GREG_FEATURE_0));
+
+	/*
+	 * By default, the last source number comes from the MPIC, but the
+	 * device-tree and board support code can override it on buggy hw.
+	 * If we get passed an isu_size (multi-isu MPIC) then we use that
+	 * as a default instead of the value read from the HW.
+	 */
+	last_irq = (greg_feature & MPIC_GREG_FEATURE_LAST_SRC_MASK)
+				>> MPIC_GREG_FEATURE_LAST_SRC_SHIFT;
+	if (isu_size)
+		last_irq = isu_size  * MPIC_MAX_ISU - 1;
+	of_property_read_u32(mpic->node, "last-interrupt-source", &last_irq);
+	if (irq_count)
+		last_irq = irq_count - 1;
+
+	return last_irq;
+}
+
 struct mpic * __init mpic_alloc(struct device_node *node,
 				phys_addr_t phys_addr,
 				unsigned int flags,
@@ -1451,25 +1481,7 @@ struct mpic * __init mpic_alloc(struct device_node *node,
 			 0x1000);
 	}
 
-	/*
-	 * Read feature register.  For non-ISU MPICs, num sources as well. On
-	 * ISU MPICs, sources are counted as ISUs are added
-	 */
-	greg_feature = mpic_read(mpic->gregs, MPIC_INFO(GREG_FEATURE_0));
-
-	/*
-	 * By default, the last source number comes from the MPIC, but the
-	 * device-tree and board support code can override it on buggy hw.
-	 * If we get passed an isu_size (multi-isu MPIC) then we use that
-	 * as a default instead of the value read from the HW.
-	 */
-	last_irq = (greg_feature & MPIC_GREG_FEATURE_LAST_SRC_MASK)
-				>> MPIC_GREG_FEATURE_LAST_SRC_SHIFT;
-	if (isu_size)
-		last_irq = isu_size  * MPIC_MAX_ISU - 1;
-	of_property_read_u32(mpic->node, "last-interrupt-source", &last_irq);
-	if (irq_count)
-		last_irq = irq_count - 1;
+	last_irq = mpic_get_last_irq_source(mpic, irq_count, isu_size);
 
 	/* Initialize main ISU if none provided */
 	if (!isu_size) {
@@ -1495,6 +1507,8 @@ struct mpic * __init mpic_alloc(struct device_node *node,
 	if (mpic->irqhost == NULL)
 		return NULL;
 
+	greg_feature = mpic_read(mpic->gregs, MPIC_INFO(GREG_FEATURE_0));
+
 	/* Display version */
 	switch (greg_feature & MPIC_GREG_FEATURE_VERSION_MASK) {
 	case 1:
-- 
1.9.3

[RFC 2/5] powerpc/mpic: Rework last source irq calculation logic

[Bharat Bhushan]

Last irq calculation logic uses below priority order:
  1) irq_count from platform
  2) "last-interrupt-source" from device tree
  3) isu_size from platform
  4) MPIC h/w GREG_FEATURE_0 register

This patch reworks the last irq calculation logic but
functionality and priority order are same as before.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@nxp.com>
---
 arch/powerpc/sysdev/mpic.c | 31 +++++++++++++++++++------------
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index b6803bc..d503887 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1217,25 +1217,32 @@ static int mpic_get_last_irq_source(struct mpic *mpic,
 	u32 last_irq;
 	u32 greg_feature;
 
+	/* Current priority order for getting last irq:
+	 *  1) irq_count from platform
+	 *  2) "last-interrupt-source" from device tree
+	 *  3) isu_size from platform
+	 *  4) MPIC h/w GREG_FEATURE_0 register
+	 */
+
+	if (irq_count)
+		return (irq_count - 1);
+
+	if (!of_property_read_u32(mpic->node, "last-interrupt-source",
+				  &last_irq)) {
+		return last_irq;
+	}
+
+	if (isu_size)
+		return (isu_size  * MPIC_MAX_ISU - 1);
+
 	/*
-	 * Read feature register.  For non-ISU MPICs, num sources as well. On
+	 * Read feature register. For non-ISU MPICs, num sources as well. On
 	 * ISU MPICs, sources are counted as ISUs are added
 	 */
 	greg_feature = mpic_read(mpic->gregs, MPIC_INFO(GREG_FEATURE_0));
 
-	/*
-	 * By default, the last source number comes from the MPIC, but the
-	 * device-tree and board support code can override it on buggy hw.
-	 * If we get passed an isu_size (multi-isu MPIC) then we use that
-	 * as a default instead of the value read from the HW.
-	 */
 	last_irq = (greg_feature & MPIC_GREG_FEATURE_LAST_SRC_MASK)
 				>> MPIC_GREG_FEATURE_LAST_SRC_SHIFT;
-	if (isu_size)
-		last_irq = isu_size  * MPIC_MAX_ISU - 1;
-	of_property_read_u32(mpic->node, "last-interrupt-source", &last_irq);
-	if (irq_count)
-		last_irq = irq_count - 1;
 
 	return last_irq;
 }
-- 
1.9.3

[RFC 3/5] powerpc/mpic: Add support for non-contiguous irq ranges

[Bharat Bhushan]

Freescale MPIC h/w may not support all interrupt sources reported
by hardware, "last-interrupt-source" or platform. On these platforms
a misconfigured device tree that assigns one of the reserved
interrupts leaves a non-functioning system without warning.

This patch adds "supported-irq-ranges" property in device tree to
provide the range of supported source of interrupts. If a reserved
interrupt used then it will not be programming h/w, which it does
currently, and through warning.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@nxp.com>
---
 .../devicetree/bindings/powerpc/fsl/mpic.txt       |   8 ++
 arch/powerpc/include/asm/mpic.h                    |   9 ++
 arch/powerpc/sysdev/mpic.c                         | 113 +++++++++++++++++++--
 3 files changed, 121 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
index dc57446..bd6da54 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
@@ -77,6 +77,14 @@ PROPERTIES
           in the global feature registers.  If specified, this field will
           override the value read from MPIC_GREG_FEATURE_LAST_SRC.
 
+ - supported-irq-ranges
+      Usage: optional
+      Value type: <prop-encoded-array>
+      Definition: This encodes arbitrary number of start-irq and end-irq
+          pairs, both including. Interrupt source supported by an MPIC
+          may not be contigous, in that case this property will be used
+          to pass supported source of interrupt ranges.
+
 INTERRUPT SPECIFIER DEFINITION
 
   Interrupt specifiers consists of 4 cells encoded as
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index fad8ddd..4080c98 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -252,6 +252,11 @@ struct mpic_irq_save {
 #endif
 };
 
+struct mpic_irq_range {
+	u32	start_irq;
+	u32	end_irq;
+};
+
 /* The instance data of a given MPIC */
 struct mpic
 {
@@ -281,6 +286,10 @@ struct mpic
 	/* Number of sources */
 	unsigned int		num_sources;
 
+	/* Supported source ranges */
+	unsigned int num_ranges;
+	struct mpic_irq_range	*irq_ranges;
+
 	/* vector numbers used for internal sources (ipi/timers) */
 	unsigned int		ipi_vecs[4];
 	unsigned int		timer_vecs[8];
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index d503887..cbf3a51 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -155,6 +155,23 @@ struct bus_type mpic_subsys = {
 
 #endif /* CONFIG_MPIC_WEIRD */
 
+static int mpic_irq_source_invalid(struct mpic *mpic, unsigned int irq)
+{
+	int i;
+
+	for (i = 0; i < mpic->num_ranges; i++) {
+		if ((irq >= mpic->irq_ranges[i].start_irq) &&
+			(irq <= mpic->irq_ranges[i].end_irq))
+			return 0;
+	}
+
+	/* if not supported irq-ranges then check for num_sources */
+	if (!mpic->num_ranges && irq < mpic->num_sources)
+		return 0;
+
+	return -EINVAL;
+}
+
 static inline unsigned int mpic_processor_id(struct mpic *mpic)
 {
 	unsigned int cpu = 0;
@@ -873,8 +890,10 @@ int mpic_set_irq_type(struct irq_data *d, unsigned int flow_type)
 	DBG("mpic: set_irq_type(mpic:@%p,virq:%d,src:0x%x,type:0x%x)\n",
 	    mpic, d->irq, src, flow_type);
 
-	if (src >= mpic->num_sources)
+	if (mpic_irq_source_invalid(mpic, src)) {
+		WARN(1, "mpic: Reserved IRQ source %d\n", src);
 		return -EINVAL;
+	}
 
 	vold = mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI));
 
@@ -933,8 +952,10 @@ void mpic_set_vector(unsigned int virq, unsigned int vector)
 	DBG("mpic: set_vector(mpic:@%p,virq:%d,src:%d,vector:0x%x)\n",
 	    mpic, virq, src, vector);
 
-	if (src >= mpic->num_sources)
+	if (mpic_irq_source_invalid(mpic, src)) {
+		WARN(1, "mpic: Reserved IRQ source %d\n", src);
 		return;
+	}
 
 	vecpri = mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI));
 	vecpri = vecpri & ~MPIC_INFO(VECPRI_VECTOR_MASK);
@@ -950,8 +971,10 @@ static void mpic_set_destination(unsigned int virq, unsigned int cpuid)
 	DBG("mpic: set_destination(mpic:@%p,virq:%d,src:%d,cpuid:0x%x)\n",
 	    mpic, virq, src, cpuid);
 
-	if (src >= mpic->num_sources)
+	if (mpic_irq_source_invalid(mpic, src)) {
+		WARN(1, "mpic: Reserved IRQ source %d\n", src);
 		return;
+	}
 
 	mpic_irq_write(src, MPIC_INFO(IRQ_DESTINATION), 1 << cpuid);
 }
@@ -1038,7 +1061,7 @@ static int mpic_host_map(struct irq_domain *h, unsigned int virq,
 	if (mpic_map_error_int(mpic, virq, hw))
 		return 0;
 
-	if (hw >= mpic->num_sources) {
+	if (mpic_irq_source_invalid(mpic, hw)) {
 		pr_warn("mpic: Mapping of source 0x%x failed, source out of range !\n",
 			(unsigned int)hw);
 		return -EINVAL;
@@ -1210,6 +1233,52 @@ u32 fsl_mpic_primary_get_version(void)
 	return 0;
 }
 
+static u32 mpic_last_irq_from_ranges(struct mpic *mpic)
+{
+	int i;
+	u32 last_irq = 0;
+
+	for (i = 0; i < mpic->num_ranges; i++)
+		if (last_irq < mpic->irq_ranges[i].end_irq)
+			last_irq = mpic->irq_ranges[i].end_irq;
+
+	return last_irq;
+}
+
+static int __init mpic_init_irq_ranges(struct mpic *mpic)
+{
+	const u32 *irq_ranges;
+	u32 len, count;
+	int i;
+
+	irq_ranges = of_get_property(mpic->node, "supported-irq-ranges", &len);
+	if (irq_ranges == NULL) {
+		pr_info("%s : supported-irq-ranges not found in mpic(%p)\n",
+			__func__, mpic->node);
+		return -1;
+	}
+
+	if (len % (2 * sizeof(u32)) != 0) {
+		pr_info("%s : incorrect irq ranges in mpic(%p)\n",
+			__func__, mpic->node);
+		return -1;
+	}
+
+	count = len / (2 * sizeof(u32));
+	mpic->irq_ranges = kcalloc(count, sizeof(struct mpic_irq_range),
+				   GFP_KERNEL);
+	if (mpic->irq_ranges == NULL)
+		return -1;
+
+	mpic->num_ranges = count;
+	for (i = 0; i < count; i++) {
+		mpic->irq_ranges[i].start_irq = *irq_ranges++;
+		mpic->irq_ranges[i].end_irq = *irq_ranges++;
+	}
+
+	return 0;
+}
+
 static int mpic_get_last_irq_source(struct mpic *mpic,
 				    unsigned int irq_count,
 				    unsigned int isu_size)
@@ -1219,14 +1288,18 @@ static int mpic_get_last_irq_source(struct mpic *mpic,
 
 	/* Current priority order for getting last irq:
 	 *  1) irq_count from platform
-	 *  2) "last-interrupt-source" from device tree
-	 *  3) isu_size from platform
-	 *  4) MPIC h/w GREG_FEATURE_0 register
+	 *  2) "supported-irq-ranges" from device tree
+	 *  3) "last-interrupt-source" from device tree
+	 *  4) isu_size from platform
+	 *  5) MPIC h/w GREG_FEATURE_0 register
 	 */
 
 	if (irq_count)
 		return (irq_count - 1);
 
+	if (!mpic_init_irq_ranges(mpic))
+		return mpic_last_irq_from_ranges(mpic);
+
 	if (!of_property_read_u32(mpic->node, "last-interrupt-source",
 				  &last_irq)) {
 		return last_irq;
@@ -1632,6 +1705,10 @@ void __init mpic_init(struct mpic *mpic)
 			u32 vecpri = MPIC_VECPRI_MASK | i |
 				(8 << MPIC_VECPRI_PRIORITY_SHIFT);
 
+			/* Skip if source irq not valid */
+			if (mpic_irq_source_invalid(mpic, i))
+				continue;
+
 			/* check if protected */
 			if (mpic->protected && test_bit(i, mpic->protected))
 				continue;
@@ -1732,9 +1809,14 @@ void mpic_setup_this_cpu(void)
 	 * values of irq_desc[].affinity in irq.c.
  	 */
 	if (distribute_irqs && !(mpic->flags & MPIC_SINGLE_DEST_CPU)) {
-	 	for (i = 0; i < mpic->num_sources ; i++)
+		for (i = 0; i < mpic->num_sources ; i++) {
+			/* Skip if irq source is not valid */
+			if (mpic_irq_source_invalid(mpic, i))
+				continue;
+
 			mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION),
 				mpic_irq_read(i, MPIC_INFO(IRQ_DESTINATION)) | msk);
+		}
 	}
 
 	/* Set current processor priority to 0 */
@@ -1772,9 +1854,14 @@ void mpic_teardown_this_cpu(int secondary)
 	raw_spin_lock_irqsave(&mpic_lock, flags);
 
 	/* let the mpic know we don't want intrs.  */
-	for (i = 0; i < mpic->num_sources ; i++)
+	for (i = 0; i < mpic->num_sources ; i++) {
+		/* Skip if irq not valid */
+		if (mpic_irq_source_invalid(mpic, i))
+			continue;
+
 		mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION),
 			mpic_irq_read(i, MPIC_INFO(IRQ_DESTINATION)) & ~msk);
+	}
 
 	/* Set current processor priority to max */
 	mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0xf);
@@ -1958,6 +2045,10 @@ static void mpic_suspend_one(struct mpic *mpic)
 	int i;
 
 	for (i = 0; i < mpic->num_sources; i++) {
+		/* Skip if irq source not valid */
+		if (mpic_irq_source_invalid(mpic, i))
+			continue;
+
 		mpic->save_data[i].vecprio =
 			mpic_irq_read(i, MPIC_INFO(IRQ_VECTOR_PRI));
 		mpic->save_data[i].dest =
@@ -1982,6 +2073,10 @@ static void mpic_resume_one(struct mpic *mpic)
 	int i;
 
 	for (i = 0; i < mpic->num_sources; i++) {
+		/* Skip if irq source not valid */
+		if (mpic_irq_source_invalid(mpic, i))
+			continue;
+
 		mpic_irq_write(i, MPIC_INFO(IRQ_VECTOR_PRI),
 			       mpic->save_data[i].vecprio);
 		mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION),
-- 
1.9.3

Re: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq ranges

[Rob Herring]

On Fri, Jul 27, 2018 at 03:17:59PM +0530, Bharat Bhushan wrote:
> Freescale MPIC h/w may not support all interrupt sources reported
> by hardware, "last-interrupt-source" or platform. On these platforms
> a misconfigured device tree that assigns one of the reserved
> interrupts leaves a non-functioning system without warning.

There are lots of ways to misconfigure DTs. I don't think this is 
special and needs a property. We've had some interrupt mask or valid 
properties in the past, but generally don't accept those.

> 
> This patch adds "supported-irq-ranges" property in device tree to
> provide the range of supported source of interrupts. If a reserved
> interrupt used then it will not be programming h/w, which it does
> currently, and through warning.
> 
> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@nxp.com>
> ---
>  .../devicetree/bindings/powerpc/fsl/mpic.txt       |   8 ++
>  arch/powerpc/include/asm/mpic.h                    |   9 ++
>  arch/powerpc/sysdev/mpic.c                         | 113 +++++++++++++++++++--
>  3 files changed, 121 insertions(+), 9 deletions(-)

Re: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq ranges

[Scott Wood]

On Tue, 2018-08-07 at 12:09 -0600, Rob Herring wrote:
> On Fri, Jul 27, 2018 at 03:17:59PM +0530, Bharat Bhushan wrote:
> > Freescale MPIC h/w may not support all interrupt sources reported
> > by hardware, "last-interrupt-source" or platform. On these platforms
> > a misconfigured device tree that assigns one of the reserved
> > interrupts leaves a non-functioning system without warning.
> 
> There are lots of ways to misconfigure DTs. I don't think this is 
> special and needs a property.

Yeah, the system will be just as non-functioning if you specify a valid-but-
wrong-for-the-device interrupt number.

>  We've had some interrupt mask or valid 
> properties in the past, but generally don't accept those.

FWIW, some of them like protected-sources and mpic-msgr-receive-mask aren't
for detecting errors, but are for partitioning (though the former is obsolete
with pic-no-reset).

-Scott

Re: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq ranges

[Scott Wood]

On Tue, 2018-08-07 at 12:09 -0600, Rob Herring wrote:
> On Fri, Jul 27, 2018 at 03:17:59PM +0530, Bharat Bhushan wrote:
> > Freescale MPIC h/w may not support all interrupt sources reported
> > by hardware, "last-interrupt-source" or platform. On these platforms
> > a misconfigured device tree that assigns one of the reserved
> > interrupts leaves a non-functioning system without warning.
> 
> There are lots of ways to misconfigure DTs. I don't think this is 
> special and needs a property.

Yeah, the system will be just as non-functioning if you specify a valid-but-
wrong-for-the-device interrupt number.

>  We've had some interrupt mask or valid 
> properties in the past, but generally don't accept those.

FWIW, some of them like protected-sources and mpic-msgr-receive-mask aren't
for detecting errors, but are for partitioning (though the former is obsolete
with pic-no-reset).

-Scott

RE: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq ranges

[Bharat Bhushan]

> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Wednesday, August 8, 2018 2:34 AM
> To: Rob Herring <robh@kernel.org>; Bharat Bhushan
> <bharat.bhushan@nxp.com>
> Cc: 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; keescook@chromium.org;
> tyreld@linux.vnet.ibm.com; joe@perches.com
> Subject: Re: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq
> ranges
> 
> On Tue, 2018-08-07 at 12:09 -0600, Rob Herring wrote:
> > On Fri, Jul 27, 2018 at 03:17:59PM +0530, Bharat Bhushan wrote:
> > > Freescale MPIC h/w may not support all interrupt sources reported by
> > > hardware, "last-interrupt-source" or platform. On these platforms a
> > > misconfigured device tree that assigns one of the reserved
> > > interrupts leaves a non-functioning system without warning.
> >
> > There are lots of ways to misconfigure DTs. I don't think this is
> > special and needs a property.
> 
> Yeah, the system will be just as non-functioning if you specify a valid-but-
> wrong-for-the-device interrupt number.

Some is one additional benefits of this changes, MPIC have reserved regions for un-supported interrupts and read/writes to these reserved regions seams have no effect.
MPIC driver reads/writes to the reserved regions during init/uninit and save/restore state.

Let me know if it make sense to have these changes for mentioned reasons.

Thanks
-Bharat

> 
> >  We've had some interrupt mask or valid properties in the past, but
> > generally don't accept those.
> 
> FWIW, some of them like protected-sources and mpic-msgr-receive-mask
> aren't for detecting errors, but are for partitioning (though the former is
> obsolete with pic-no-reset).
> 
> -Scott

RE: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq ranges

[Bharat Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2NvdHQgV29vZCBbbWFp
bHRvOm9zc0BidXNlcnJvci5uZXRdDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDgsIDIwMTgg
MjozNCBBTQ0KPiBUbzogUm9iIEhlcnJpbmcgPHJvYmhAa2VybmVsLm9yZz47IEJoYXJhdCBCaHVz
aGFuDQo+IDxiaGFyYXQuYmh1c2hhbkBueHAuY29tPg0KPiBDYzogYmVuaEBrZXJuZWwuY3Jhc2hp
bmcub3JnOyBwYXVsdXNAc2FtYmEub3JnOyBtcGVAZWxsZXJtYW4uaWQuYXU7DQo+IGdhbGFrQGtl
cm5lbC5jcmFzaGluZy5vcmc7IG1hcmsucnV0bGFuZEBhcm0uY29tOw0KPiBrc3Rld2FydEBsaW51
eGZvdW5kYXRpb24ub3JnOyBncmVna2hAbGludXhmb3VuZGF0aW9uLm9yZzsNCj4gZGV2aWNldHJl
ZUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBsaW51eC0N
Cj4ga2VybmVsQHZnZXIua2VybmVsLm9yZzsga2Vlc2Nvb2tAY2hyb21pdW0ub3JnOw0KPiB0eXJl
bGRAbGludXgudm5ldC5pYm0uY29tOyBqb2VAcGVyY2hlcy5jb20NCj4gU3ViamVjdDogUmU6IFtS
RkMgMy81XSBwb3dlcnBjL21waWM6IEFkZCBzdXBwb3J0IGZvciBub24tY29udGlndW91cyBpcnEN
Cj4gcmFuZ2VzDQo+IA0KPiBPbiBUdWUsIDIwMTgtMDgtMDcgYXQgMTI6MDkgLTA2MDAsIFJvYiBI
ZXJyaW5nIHdyb3RlOg0KPiA+IE9uIEZyaSwgSnVsIDI3LCAyMDE4IGF0IDAzOjE3OjU5UE0gKzA1
MzAsIEJoYXJhdCBCaHVzaGFuIHdyb3RlOg0KPiA+ID4gRnJlZXNjYWxlIE1QSUMgaC93IG1heSBu
b3Qgc3VwcG9ydCBhbGwgaW50ZXJydXB0IHNvdXJjZXMgcmVwb3J0ZWQgYnkNCj4gPiA+IGhhcmR3
YXJlLCAibGFzdC1pbnRlcnJ1cHQtc291cmNlIiBvciBwbGF0Zm9ybS4gT24gdGhlc2UgcGxhdGZv
cm1zIGENCj4gPiA+IG1pc2NvbmZpZ3VyZWQgZGV2aWNlIHRyZWUgdGhhdCBhc3NpZ25zIG9uZSBv
ZiB0aGUgcmVzZXJ2ZWQNCj4gPiA+IGludGVycnVwdHMgbGVhdmVzIGEgbm9uLWZ1bmN0aW9uaW5n
IHN5c3RlbSB3aXRob3V0IHdhcm5pbmcuDQo+ID4NCj4gPiBUaGVyZSBhcmUgbG90cyBvZiB3YXlz
IHRvIG1pc2NvbmZpZ3VyZSBEVHMuIEkgZG9uJ3QgdGhpbmsgdGhpcyBpcw0KPiA+IHNwZWNpYWwg
YW5kIG5lZWRzIGEgcHJvcGVydHkuDQo+IA0KPiBZZWFoLCB0aGUgc3lzdGVtIHdpbGwgYmUganVz
dCBhcyBub24tZnVuY3Rpb25pbmcgaWYgeW91IHNwZWNpZnkgYSB2YWxpZC1idXQtDQo+IHdyb25n
LWZvci10aGUtZGV2aWNlIGludGVycnVwdCBudW1iZXIuDQoNClNvbWUgaXMgb25lIGFkZGl0aW9u
YWwgYmVuZWZpdHMgb2YgdGhpcyBjaGFuZ2VzLCBNUElDIGhhdmUgcmVzZXJ2ZWQgcmVnaW9ucyBm
b3IgdW4tc3VwcG9ydGVkIGludGVycnVwdHMgYW5kIHJlYWQvd3JpdGVzIHRvIHRoZXNlIHJlc2Vy
dmVkIHJlZ2lvbnMgc2VhbXMgaGF2ZSBubyBlZmZlY3QuDQpNUElDIGRyaXZlciByZWFkcy93cml0
ZXMgdG8gdGhlIHJlc2VydmVkIHJlZ2lvbnMgZHVyaW5nIGluaXQvdW5pbml0IGFuZCBzYXZlL3Jl
c3RvcmUgc3RhdGUuDQoNCkxldCBtZSBrbm93IGlmIGl0IG1ha2Ugc2Vuc2UgdG8gaGF2ZSB0aGVz
ZSBjaGFuZ2VzIGZvciBtZW50aW9uZWQgcmVhc29ucy4NCg0KVGhhbmtzDQotQmhhcmF0DQoNCj4g
DQo+ID4gIFdlJ3ZlIGhhZCBzb21lIGludGVycnVwdCBtYXNrIG9yIHZhbGlkIHByb3BlcnRpZXMg
aW4gdGhlIHBhc3QsIGJ1dA0KPiA+IGdlbmVyYWxseSBkb24ndCBhY2NlcHQgdGhvc2UuDQo+IA0K
PiBGV0lXLCBzb21lIG9mIHRoZW0gbGlrZSBwcm90ZWN0ZWQtc291cmNlcyBhbmQgbXBpYy1tc2dy
LXJlY2VpdmUtbWFzaw0KPiBhcmVuJ3QgZm9yIGRldGVjdGluZyBlcnJvcnMsIGJ1dCBhcmUgZm9y
IHBhcnRpdGlvbmluZyAodGhvdWdoIHRoZSBmb3JtZXIgaXMNCj4gb2Jzb2xldGUgd2l0aCBwaWMt
bm8tcmVzZXQpLg0KPiANCj4gLVNjb3R0DQoNCg==

Re: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq ranges

[Scott Wood]

On Wed, 2018-08-08 at 03:37 +0000, Bharat Bhushan wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Wednesday, August 8, 2018 2:34 AM
> > To: Rob Herring <robh@kernel.org>; Bharat Bhushan
> > <bharat.bhushan@nxp.com>
> > Cc: 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; keescook@chromium.org;
> > tyreld@linux.vnet.ibm.com; joe@perches.com
> > Subject: Re: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq
> > ranges
> > 
> > On Tue, 2018-08-07 at 12:09 -0600, Rob Herring wrote:
> > > On Fri, Jul 27, 2018 at 03:17:59PM +0530, Bharat Bhushan wrote:
> > > > Freescale MPIC h/w may not support all interrupt sources reported by
> > > > hardware, "last-interrupt-source" or platform. On these platforms a
> > > > misconfigured device tree that assigns one of the reserved
> > > > interrupts leaves a non-functioning system without warning.
> > > 
> > > There are lots of ways to misconfigure DTs. I don't think this is
> > > special and needs a property.
> > 
> > Yeah, the system will be just as non-functioning if you specify a valid-
> > but-
> > wrong-for-the-device interrupt number.
> 
> Some is one additional benefits of this changes, MPIC have reserved regions
> for un-supported interrupts and read/writes to these reserved regions seams
> have no effect.
> MPIC driver reads/writes to the reserved regions during init/uninit and
> save/restore state.
> 
> Let me know if it make sense to have these changes for mentioned reasons.

The driver has been doing this forever with no ill effect.  What is the
motivation for this change?

-Scott

Re: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq ranges

[Scott Wood]

On Wed, 2018-08-08 at 03:37 +0000, Bharat Bhushan wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Wednesday, August 8, 2018 2:34 AM
> > To: Rob Herring <robh@kernel.org>; Bharat Bhushan
> > <bharat.bhushan@nxp.com>
> > Cc: 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; keescook@chromium.org;
> > tyreld@linux.vnet.ibm.com; joe@perches.com
> > Subject: Re: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq
> > ranges
> > 
> > On Tue, 2018-08-07 at 12:09 -0600, Rob Herring wrote:
> > > On Fri, Jul 27, 2018 at 03:17:59PM +0530, Bharat Bhushan wrote:
> > > > Freescale MPIC h/w may not support all interrupt sources reported by
> > > > hardware, "last-interrupt-source" or platform. On these platforms a
> > > > misconfigured device tree that assigns one of the reserved
> > > > interrupts leaves a non-functioning system without warning.
> > > 
> > > There are lots of ways to misconfigure DTs. I don't think this is
> > > special and needs a property.
> > 
> > Yeah, the system will be just as non-functioning if you specify a valid-
> > but-
> > wrong-for-the-device interrupt number.
> 
> Some is one additional benefits of this changes, MPIC have reserved regions
> for un-supported interrupts and read/writes to these reserved regions seams
> have no effect.
> MPIC driver reads/writes to the reserved regions during init/uninit and
> save/restore state.
> 
> Let me know if it make sense to have these changes for mentioned reasons.

The driver has been doing this forever with no ill effect.  What is the
motivation for this change?

-Scott

RE: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq ranges

[Bharat Bhushan]

> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Wednesday, August 8, 2018 11:21 AM
> To: Bharat Bhushan <bharat.bhushan@nxp.com>; Rob Herring
> <robh@kernel.org>
> Cc: 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; keescook@chromium.org;
> tyreld@linux.vnet.ibm.com; joe@perches.com
> Subject: Re: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq
> ranges
> 
> On Wed, 2018-08-08 at 03:37 +0000, Bharat Bhushan wrote:
> > > -----Original Message-----
> > > From: Scott Wood [mailto:oss@buserror.net]
> > > Sent: Wednesday, August 8, 2018 2:34 AM
> > > To: Rob Herring <robh@kernel.org>; Bharat Bhushan
> > > <bharat.bhushan@nxp.com>
> > > Cc: 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; keescook@chromium.org;
> > > tyreld@linux.vnet.ibm.com; joe@perches.com
> > > Subject: Re: [RFC 3/5] powerpc/mpic: Add support for non-contiguous
> > > irq ranges
> > >
> > > On Tue, 2018-08-07 at 12:09 -0600, Rob Herring wrote:
> > > > On Fri, Jul 27, 2018 at 03:17:59PM +0530, Bharat Bhushan wrote:
> > > > > Freescale MPIC h/w may not support all interrupt sources
> > > > > reported by hardware, "last-interrupt-source" or platform. On
> > > > > these platforms a misconfigured device tree that assigns one of
> > > > > the reserved interrupts leaves a non-functioning system without
> warning.
> > > >
> > > > There are lots of ways to misconfigure DTs. I don't think this is
> > > > special and needs a property.
> > >
> > > Yeah, the system will be just as non-functioning if you specify a
> > > valid-
> > > but-
> > > wrong-for-the-device interrupt number.
> >
> > Some is one additional benefits of this changes, MPIC have reserved
> > regions for un-supported interrupts and read/writes to these reserved
> > regions seams have no effect.
> > MPIC driver reads/writes to the reserved regions during init/uninit
> > and save/restore state.
> >
> > Let me know if it make sense to have these changes for mentioned
> reasons.
> 
> The driver has been doing this forever with no ill effect.

Yes, there are no issue reported

>  What is the  motivation for this change?

On Simulation model I see warning when accessing the reserved region, So this patch is just an effort to improve.

Thanks
-Bharat

> 
> -Scott

RE: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq ranges

[Bharat Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2NvdHQgV29vZCBbbWFp
bHRvOm9zc0BidXNlcnJvci5uZXRdDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDgsIDIwMTgg
MTE6MjEgQU0NCj4gVG86IEJoYXJhdCBCaHVzaGFuIDxiaGFyYXQuYmh1c2hhbkBueHAuY29tPjsg
Um9iIEhlcnJpbmcNCj4gPHJvYmhAa2VybmVsLm9yZz4NCj4gQ2M6IGJlbmhAa2VybmVsLmNyYXNo
aW5nLm9yZzsgcGF1bHVzQHNhbWJhLm9yZzsgbXBlQGVsbGVybWFuLmlkLmF1Ow0KPiBnYWxha0Br
ZXJuZWwuY3Jhc2hpbmcub3JnOyBtYXJrLnJ1dGxhbmRAYXJtLmNvbTsNCj4ga3N0ZXdhcnRAbGlu
dXhmb3VuZGF0aW9uLm9yZzsgZ3JlZ2toQGxpbnV4Zm91bmRhdGlvbi5vcmc7DQo+IGRldmljZXRy
ZWVAdmdlci5rZXJuZWwub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgbGludXgt
DQo+IGtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGtlZXNjb29rQGNocm9taXVtLm9yZzsNCj4gdHly
ZWxkQGxpbnV4LnZuZXQuaWJtLmNvbTsgam9lQHBlcmNoZXMuY29tDQo+IFN1YmplY3Q6IFJlOiBb
UkZDIDMvNV0gcG93ZXJwYy9tcGljOiBBZGQgc3VwcG9ydCBmb3Igbm9uLWNvbnRpZ3VvdXMgaXJx
DQo+IHJhbmdlcw0KPiANCj4gT24gV2VkLCAyMDE4LTA4LTA4IGF0IDAzOjM3ICswMDAwLCBCaGFy
YXQgQmh1c2hhbiB3cm90ZToNCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g
PiBGcm9tOiBTY290dCBXb29kIFttYWlsdG86b3NzQGJ1c2Vycm9yLm5ldF0NCj4gPiA+IFNlbnQ6
IFdlZG5lc2RheSwgQXVndXN0IDgsIDIwMTggMjozNCBBTQ0KPiA+ID4gVG86IFJvYiBIZXJyaW5n
IDxyb2JoQGtlcm5lbC5vcmc+OyBCaGFyYXQgQmh1c2hhbg0KPiA+ID4gPGJoYXJhdC5iaHVzaGFu
QG54cC5jb20+DQo+ID4gPiBDYzogYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOyBwYXVsdXNAc2Ft
YmEub3JnOyBtcGVAZWxsZXJtYW4uaWQuYXU7DQo+ID4gPiBnYWxha0BrZXJuZWwuY3Jhc2hpbmcu
b3JnOyBtYXJrLnJ1dGxhbmRAYXJtLmNvbTsNCj4gPiA+IGtzdGV3YXJ0QGxpbnV4Zm91bmRhdGlv
bi5vcmc7IGdyZWdraEBsaW51eGZvdW5kYXRpb24ub3JnOw0KPiA+ID4gZGV2aWNldHJlZUB2Z2Vy
Lmtlcm5lbC5vcmc7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBsaW51eC0NCj4gPiA+
IGtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGtlZXNjb29rQGNocm9taXVtLm9yZzsNCj4gPiA+IHR5
cmVsZEBsaW51eC52bmV0LmlibS5jb207IGpvZUBwZXJjaGVzLmNvbQ0KPiA+ID4gU3ViamVjdDog
UmU6IFtSRkMgMy81XSBwb3dlcnBjL21waWM6IEFkZCBzdXBwb3J0IGZvciBub24tY29udGlndW91
cw0KPiA+ID4gaXJxIHJhbmdlcw0KPiA+ID4NCj4gPiA+IE9uIFR1ZSwgMjAxOC0wOC0wNyBhdCAx
MjowOSAtMDYwMCwgUm9iIEhlcnJpbmcgd3JvdGU6DQo+ID4gPiA+IE9uIEZyaSwgSnVsIDI3LCAy
MDE4IGF0IDAzOjE3OjU5UE0gKzA1MzAsIEJoYXJhdCBCaHVzaGFuIHdyb3RlOg0KPiA+ID4gPiA+
IEZyZWVzY2FsZSBNUElDIGgvdyBtYXkgbm90IHN1cHBvcnQgYWxsIGludGVycnVwdCBzb3VyY2Vz
DQo+ID4gPiA+ID4gcmVwb3J0ZWQgYnkgaGFyZHdhcmUsICJsYXN0LWludGVycnVwdC1zb3VyY2Ui
IG9yIHBsYXRmb3JtLiBPbg0KPiA+ID4gPiA+IHRoZXNlIHBsYXRmb3JtcyBhIG1pc2NvbmZpZ3Vy
ZWQgZGV2aWNlIHRyZWUgdGhhdCBhc3NpZ25zIG9uZSBvZg0KPiA+ID4gPiA+IHRoZSByZXNlcnZl
ZCBpbnRlcnJ1cHRzIGxlYXZlcyBhIG5vbi1mdW5jdGlvbmluZyBzeXN0ZW0gd2l0aG91dA0KPiB3
YXJuaW5nLg0KPiA+ID4gPg0KPiA+ID4gPiBUaGVyZSBhcmUgbG90cyBvZiB3YXlzIHRvIG1pc2Nv
bmZpZ3VyZSBEVHMuIEkgZG9uJ3QgdGhpbmsgdGhpcyBpcw0KPiA+ID4gPiBzcGVjaWFsIGFuZCBu
ZWVkcyBhIHByb3BlcnR5Lg0KPiA+ID4NCj4gPiA+IFllYWgsIHRoZSBzeXN0ZW0gd2lsbCBiZSBq
dXN0IGFzIG5vbi1mdW5jdGlvbmluZyBpZiB5b3Ugc3BlY2lmeSBhDQo+ID4gPiB2YWxpZC0NCj4g
PiA+IGJ1dC0NCj4gPiA+IHdyb25nLWZvci10aGUtZGV2aWNlIGludGVycnVwdCBudW1iZXIuDQo+
ID4NCj4gPiBTb21lIGlzIG9uZSBhZGRpdGlvbmFsIGJlbmVmaXRzIG9mIHRoaXMgY2hhbmdlcywg
TVBJQyBoYXZlIHJlc2VydmVkDQo+ID4gcmVnaW9ucyBmb3IgdW4tc3VwcG9ydGVkIGludGVycnVw
dHMgYW5kIHJlYWQvd3JpdGVzIHRvIHRoZXNlIHJlc2VydmVkDQo+ID4gcmVnaW9ucyBzZWFtcyBo
YXZlIG5vIGVmZmVjdC4NCj4gPiBNUElDIGRyaXZlciByZWFkcy93cml0ZXMgdG8gdGhlIHJlc2Vy
dmVkIHJlZ2lvbnMgZHVyaW5nIGluaXQvdW5pbml0DQo+ID4gYW5kIHNhdmUvcmVzdG9yZSBzdGF0
ZS4NCj4gPg0KPiA+IExldCBtZSBrbm93IGlmIGl0IG1ha2Ugc2Vuc2UgdG8gaGF2ZSB0aGVzZSBj
aGFuZ2VzIGZvciBtZW50aW9uZWQNCj4gcmVhc29ucy4NCj4gDQo+IFRoZSBkcml2ZXIgaGFzIGJl
ZW4gZG9pbmcgdGhpcyBmb3JldmVyIHdpdGggbm8gaWxsIGVmZmVjdC4NCg0KWWVzLCB0aGVyZSBh
cmUgbm8gaXNzdWUgcmVwb3J0ZWQNCg0KPiAgV2hhdCBpcyB0aGUgIG1vdGl2YXRpb24gZm9yIHRo
aXMgY2hhbmdlPw0KDQpPbiBTaW11bGF0aW9uIG1vZGVsIEkgc2VlIHdhcm5pbmcgd2hlbiBhY2Nl
c3NpbmcgdGhlIHJlc2VydmVkIHJlZ2lvbiwgU28gdGhpcyBwYXRjaCBpcyBqdXN0IGFuIGVmZm9y
dCB0byBpbXByb3ZlLg0KDQpUaGFua3MNCi1CaGFyYXQNCg0KPiANCj4gLVNjb3R0DQoNCg==

[RFC 4/5] powerpc/mpic: Boot print supported interrupt ranges

[Bharat Bhushan]

As mpic can have non-contiguous source of interrupt range,
print same during boot.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@nxp.com>
---
 arch/powerpc/sysdev/mpic.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index cbf3a51..8df248f 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -155,6 +155,21 @@ struct bus_type mpic_subsys = {
 
 #endif /* CONFIG_MPIC_WEIRD */
 
+static void mpic_show_irq_ranges(struct mpic *mpic)
+{
+	int i;
+
+	pr_info("mpic: Initializing for %d sources\n", mpic->num_sources);
+
+	if (mpic->num_ranges) {
+		pr_info(" Supported source of interrupt ranges\n");
+		for (i = 0; i < mpic->num_ranges; i++)
+			pr_info("  > %d - %d\n", mpic->irq_ranges[i].start_irq,
+				mpic->irq_ranges[i].end_irq);
+
+	}
+}
+
 static int mpic_irq_source_invalid(struct mpic *mpic, unsigned int irq)
 {
 	int i;
@@ -1646,8 +1661,7 @@ void __init mpic_init(struct mpic *mpic)
 	int num_timers = 4;
 
 	BUG_ON(mpic->num_sources == 0);
-
-	printk(KERN_INFO "mpic: Initializing for %d sources\n", mpic->num_sources);
+	mpic_show_irq_ranges(mpic);
 
 	/* Set current processor priority to max */
 	mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0xf);
-- 
1.9.3

[RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Bharat Bhushan]

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)

We have to remove "irq_count" from platform code as platform
is given precedence over device-tree, while I think device-tree
should have precedence.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@nxp.com>
---
 arch/powerpc/boot/dts/fsl/p2020si-post.dtsi | 3 +++
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c   | 5 +++++
 2 files changed, 8 insertions(+)

diff --git a/arch/powerpc/boot/dts/fsl/p2020si-post.dtsi b/arch/powerpc/boot/dts/fsl/p2020si-post.dtsi
index 884e01b..08e266b 100644
--- a/arch/powerpc/boot/dts/fsl/p2020si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p2020si-post.dtsi
@@ -192,6 +192,9 @@
 /include/ "pq3-sec3.1-0.dtsi"
 /include/ "pq3-mpic.dtsi"
 /include/ "pq3-mpic-timer-B.dtsi"
+	pic@40000 {
+		supported-irq-ranges = <0 11 16 79 176 183 224 231>;
+	};
 
 	global-utilities@e0000 {
 		compatible = "fsl,p2020-guts";
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 1006950..49ff348 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -57,6 +57,11 @@ void __init mpc85xx_rdb_pic_init(void)
 			MPIC_BIG_ENDIAN |
 			MPIC_SINGLE_DEST_CPU,
 			0, 256, " OpenPIC  ");
+	} else if (of_machine_is_compatible("fsl,P2020RDB-PC")) {
+		mpic = mpic_alloc(NULL, 0,
+		  MPIC_BIG_ENDIAN |
+		  MPIC_SINGLE_DEST_CPU,
+		  0, 0, " OpenPIC  ");
 	} else {
 		mpic = mpic_alloc(NULL, 0,
 		  MPIC_BIG_ENDIAN |
-- 
1.9.3

Re: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Scott Wood]

On Fri, 2018-07-27 at 15:18 +0530, Bharat Bhushan wrote:
> 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?

> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> index 1006950..49ff348 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> @@ -57,6 +57,11 @@ void __init mpc85xx_rdb_pic_init(void)
>  			MPIC_BIG_ENDIAN |
>  			MPIC_SINGLE_DEST_CPU,
>  			0, 256, " OpenPIC  ");
> +	} else if (of_machine_is_compatible("fsl,P2020RDB-PC")) {
> +		mpic = mpic_alloc(NULL, 0,
> +		  MPIC_BIG_ENDIAN |
> +		  MPIC_SINGLE_DEST_CPU,
> +		  0, 0, " OpenPIC  ");
>  	} else {
>  		mpic = mpic_alloc(NULL, 0,
>  		  MPIC_BIG_ENDIAN |

I don't think we want to grow a list of every single revision of every board
in these platform files.

-Scott

Re: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Scott Wood]

On Fri, 2018-07-27 at 15:18 +0530, Bharat Bhushan wrote:
> 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?

> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> index 1006950..49ff348 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> @@ -57,6 +57,11 @@ void __init mpc85xx_rdb_pic_init(void)
>  			MPIC_BIG_ENDIAN |
>  			MPIC_SINGLE_DEST_CPU,
>  			0, 256, " OpenPIC  ");
> +	} else if (of_machine_is_compatible("fsl,P2020RDB-PC")) {
> +		mpic = mpic_alloc(NULL, 0,
> +		  MPIC_BIG_ENDIAN |
> +		  MPIC_SINGLE_DEST_CPU,
> +		  0, 0, " OpenPIC  ");
>  	} else {
>  		mpic = mpic_alloc(NULL, 0,
>  		  MPIC_BIG_ENDIAN |

I don't think we want to grow a list of every single revision of every board
in these platform files.

-Scott

RE: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Bharat Bhushan]

> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Wednesday, August 8, 2018 2:44 AM
> To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> 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:
> > 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.

> 
> > diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > index 1006950..49ff348 100644
> > --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > @@ -57,6 +57,11 @@ void __init mpc85xx_rdb_pic_init(void)
> >  			MPIC_BIG_ENDIAN |
> >  			MPIC_SINGLE_DEST_CPU,
> >  			0, 256, " OpenPIC  ");
> > +	} else if (of_machine_is_compatible("fsl,P2020RDB-PC")) {
> > +		mpic = mpic_alloc(NULL, 0,
> > +		  MPIC_BIG_ENDIAN |
> > +		  MPIC_SINGLE_DEST_CPU,
> > +		  0, 0, " OpenPIC  ");
> >  	} else {
> >  		mpic = mpic_alloc(NULL, 0,
> >  		  MPIC_BIG_ENDIAN |
> 
> I don't think we want to grow a list of every single revision of every board in
> these platform files.

One other confusing observation I have is that "irq_count" from platform code is given precedence over "last-interrupt-source" in device-tree.
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().

Thanks
-Bharat

> 
> -Scott

RE: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Bharat Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2NvdHQgV29vZCBbbWFp
bHRvOm9zc0BidXNlcnJvci5uZXRdDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDgsIDIwMTgg
Mjo0NCBBTQ0KPiBUbzogQmhhcmF0IEJodXNoYW4gPGJoYXJhdC5iaHVzaGFuQG54cC5jb20+Ow0K
PiBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7IHBhdWx1c0BzYW1iYS5vcmc7IG1wZUBlbGxlcm1h
bi5pZC5hdTsNCj4gZ2FsYWtAa2VybmVsLmNyYXNoaW5nLm9yZzsgbWFyay5ydXRsYW5kQGFybS5j
b207DQo+IGtzdGV3YXJ0QGxpbnV4Zm91bmRhdGlvbi5vcmc7IGdyZWdraEBsaW51eGZvdW5kYXRp
b24ub3JnOw0KPiBkZXZpY2V0cmVlQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2QGxpc3Rz
Lm96bGFicy5vcmc7IGxpbnV4LQ0KPiBrZXJuZWxAdmdlci5rZXJuZWwub3JnDQo+IENjOiByb2Jo
QGtlcm5lbC5vcmc7IGtlZXNjb29rQGNocm9taXVtLm9yZzsgdHlyZWxkQGxpbnV4LnZuZXQuaWJt
LmNvbTsNCj4gam9lQHBlcmNoZXMuY29tDQo+IFN1YmplY3Q6IFJlOiBbUkZDIDUvNV0gcG93ZXJw
Yy9mc2w6IEFkZCBzdXBwb3J0ZWQtaXJxLXJhbmdlcyBmb3IgUDIwMjANCj4gDQo+IE9uIEZyaSwg
MjAxOC0wNy0yNyBhdCAxNToxOCArMDUzMCwgQmhhcmF0IEJodXNoYW4gd3JvdGU6DQo+ID4gTVBJ
QyBvbiBOWFAgKEZyZWVzY2FsZSkgUDIwMjAgc3VwcG9ydHMgZm9sbG93aW5nIGlycQ0KPiA+IHJh
bmdlczoNCj4gPiAgID4gMCAtIDExICAgICAgKEV4dGVybmFsIGludGVycnVwdCkNCj4gPiAgID4g
MTYgLSA3OSAgICAgKEludGVybmFsIGludGVycnVwdCkNCj4gPiAgID4gMTc2IC0gMTgzICAgKE1l
c3NhZ2luZyBpbnRlcnJ1cHQpDQo+ID4gICA+IDIyNCAtIDIzMSAgIChTaGFyZWQgbWVzc2FnZSBz
aWduYWxlZCBpbnRlcnJ1cHQpDQo+IA0KPiBXaHkgZG9uJ3QgeW91IGNvbnZlcnQgdG8gdGhlIDQt
Y2VsbCBpbnRlcnJ1cHQgc3BlY2lmaWVycyB0aGF0IG1ha2UgZGVhbGluZw0KPiB3aXRoIHRoZXNl
IHJhbmdlcyBsZXNzIGVycm9yLXByb25lPw0KDQpPayAsIHdpbGwgZG8gaWYgd2UgYWdyZWUgdG8g
aGF2ZSB0aGlzIHNlcmllcyBhcyBwZXIgY29tbWVudCBvbiBvdGhlciBwYXRjaC4NCg0KPiANCj4g
PiBkaWZmIC0tZ2l0IGEvYXJjaC9wb3dlcnBjL3BsYXRmb3Jtcy84NXh4L21wYzg1eHhfcmRiLmMN
Cj4gPiBiL2FyY2gvcG93ZXJwYy9wbGF0Zm9ybXMvODV4eC9tcGM4NXh4X3JkYi5jDQo+ID4gaW5k
ZXggMTAwNjk1MC4uNDlmZjM0OCAxMDA2NDQNCj4gPiAtLS0gYS9hcmNoL3Bvd2VycGMvcGxhdGZv
cm1zLzg1eHgvbXBjODV4eF9yZGIuYw0KPiA+ICsrKyBiL2FyY2gvcG93ZXJwYy9wbGF0Zm9ybXMv
ODV4eC9tcGM4NXh4X3JkYi5jDQo+ID4gQEAgLTU3LDYgKzU3LDExIEBAIHZvaWQgX19pbml0IG1w
Yzg1eHhfcmRiX3BpY19pbml0KHZvaWQpDQo+ID4gIAkJCU1QSUNfQklHX0VORElBTiB8DQo+ID4g
IAkJCU1QSUNfU0lOR0xFX0RFU1RfQ1BVLA0KPiA+ICAJCQkwLCAyNTYsICIgT3BlblBJQyAgIik7
DQo+ID4gKwl9IGVsc2UgaWYgKG9mX21hY2hpbmVfaXNfY29tcGF0aWJsZSgiZnNsLFAyMDIwUkRC
LVBDIikpIHsNCj4gPiArCQltcGljID0gbXBpY19hbGxvYyhOVUxMLCAwLA0KPiA+ICsJCSAgTVBJ
Q19CSUdfRU5ESUFOIHwNCj4gPiArCQkgIE1QSUNfU0lOR0xFX0RFU1RfQ1BVLA0KPiA+ICsJCSAg
MCwgMCwgIiBPcGVuUElDICAiKTsNCj4gPiAgCX0gZWxzZSB7DQo+ID4gIAkJbXBpYyA9IG1waWNf
YWxsb2MoTlVMTCwgMCwNCj4gPiAgCQkgIE1QSUNfQklHX0VORElBTiB8DQo+IA0KPiBJIGRvbid0
IHRoaW5rIHdlIHdhbnQgdG8gZ3JvdyBhIGxpc3Qgb2YgZXZlcnkgc2luZ2xlIHJldmlzaW9uIG9m
IGV2ZXJ5IGJvYXJkIGluDQo+IHRoZXNlIHBsYXRmb3JtIGZpbGVzLg0KDQpPbmUgb3RoZXIgY29u
ZnVzaW5nIG9ic2VydmF0aW9uIEkgaGF2ZSBpcyB0aGF0ICJpcnFfY291bnQiIGZyb20gcGxhdGZv
cm0gY29kZSBpcyBnaXZlbiBwcmVjZWRlbmNlIG92ZXIgImxhc3QtaW50ZXJydXB0LXNvdXJjZSIg
aW4gZGV2aWNlLXRyZWUuDQpTaG91bGQgbm90IGRldmljZS10cmVlIHNob3VsZCBoYXZlIHByZWNl
ZGVuY2Ugb3RoZXJ3aXNlIHRoZXJlIGlzIG5vIHBvaW50IHVzaW5nICIgbGFzdC1pbnRlcnJ1cHQt
c291cmNlIiBpZiBwbGF0Zm9ybSBjb2RlIHBhc3NlcyAiaXJxX2NvdW50IiBpbiBtcGljX2FsbG9j
KCkuDQoNClRoYW5rcw0KLUJoYXJhdA0KDQo+IA0KPiAtU2NvdHQNCg0K

Re: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Scott Wood]

On Wed, 2018-08-08 at 03:44 +0000, Bharat Bhushan wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Wednesday, August 8, 2018 2:44 AM
> > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > 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:
> > > 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?


> 
> > 
> > > diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > > b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > > index 1006950..49ff348 100644
> > > --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > > +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > > @@ -57,6 +57,11 @@ void __init mpc85xx_rdb_pic_init(void)
> > >  			MPIC_BIG_ENDIAN |
> > >  			MPIC_SINGLE_DEST_CPU,
> > >  			0, 256, " OpenPIC  ");
> > > +	} else if (of_machine_is_compatible("fsl,P2020RDB-PC")) {
> > > +		mpic = mpic_alloc(NULL, 0,
> > > +		  MPIC_BIG_ENDIAN |
> > > +		  MPIC_SINGLE_DEST_CPU,
> > > +		  0, 0, " OpenPIC  ");
> > >  	} else {
> > >  		mpic = mpic_alloc(NULL, 0,
> > >  		  MPIC_BIG_ENDIAN |
> > 
> > I don't think we want to grow a list of every single revision of every
> > board in
> > these platform files.
> 
> One other confusing observation I have is that "irq_count" from platform
> code is given precedence over "last-interrupt-source" in device-tree.
> 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.

-Scott

Re: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Scott Wood]

On Wed, 2018-08-08 at 03:44 +0000, Bharat Bhushan wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Wednesday, August 8, 2018 2:44 AM
> > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > 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:
> > > 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?


> 
> > 
> > > diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > > b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > > index 1006950..49ff348 100644
> > > --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > > +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > > @@ -57,6 +57,11 @@ void __init mpc85xx_rdb_pic_init(void)
> > >  			MPIC_BIG_ENDIAN |
> > >  			MPIC_SINGLE_DEST_CPU,
> > >  			0, 256, " OpenPIC  ");
> > > +	} else if (of_machine_is_compatible("fsl,P2020RDB-PC")) {
> > > +		mpic = mpic_alloc(NULL, 0,
> > > +		  MPIC_BIG_ENDIAN |
> > > +		  MPIC_SINGLE_DEST_CPU,
> > > +		  0, 0, " OpenPIC  ");
> > >  	} else {
> > >  		mpic = mpic_alloc(NULL, 0,
> > >  		  MPIC_BIG_ENDIAN |
> > 
> > I don't think we want to grow a list of every single revision of every
> > board in
> > these platform files.
> 
> One other confusing observation I have is that "irq_count" from platform
> code is given precedence over "last-interrupt-source" in device-tree.
> 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.

-Scott

RE: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Bharat Bhushan]

> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Wednesday, August 8, 2018 11:26 AM
> To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> 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:
> > > -----Original Message-----
> > > From: Scott Wood [mailto:oss@buserror.net]
> > > Sent: Wednesday, August 8, 2018 2:44 AM
> > > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > > 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:
> > > > 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.
 - Warnings were observed on development platform (simulator) when read/write to reserved MPIC reason during init.
  
> 
> 
> >
> > >
> > > > diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > > > b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > > > index 1006950..49ff348 100644
> > > > --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > > > +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > > > @@ -57,6 +57,11 @@ void __init mpc85xx_rdb_pic_init(void)
> > > >  			MPIC_BIG_ENDIAN |
> > > >  			MPIC_SINGLE_DEST_CPU,
> > > >  			0, 256, " OpenPIC  ");
> > > > +	} else if (of_machine_is_compatible("fsl,P2020RDB-PC")) {
> > > > +		mpic = mpic_alloc(NULL, 0,
> > > > +		  MPIC_BIG_ENDIAN |
> > > > +		  MPIC_SINGLE_DEST_CPU,
> > > > +		  0, 0, " OpenPIC  ");
> > > >  	} else {
> > > >  		mpic = mpic_alloc(NULL, 0,
> > > >  		  MPIC_BIG_ENDIAN |
> > >
> > > I don't think we want to grow a list of every single revision of
> > > every board in these platform files.
> >
> > One other confusing observation I have is that "irq_count" from
> > platform code is given precedence over "last-interrupt-source" in device-
> tree.
> > 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.

Thanks
-Bharat


> 
> -Scott

RE: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Bharat Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2NvdHQgV29vZCBbbWFp
bHRvOm9zc0BidXNlcnJvci5uZXRdDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDgsIDIwMTgg
MTE6MjYgQU0NCj4gVG86IEJoYXJhdCBCaHVzaGFuIDxiaGFyYXQuYmh1c2hhbkBueHAuY29tPjsN
Cj4gYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOyBwYXVsdXNAc2FtYmEub3JnOyBtcGVAZWxsZXJt
YW4uaWQuYXU7DQo+IGdhbGFrQGtlcm5lbC5jcmFzaGluZy5vcmc7IG1hcmsucnV0bGFuZEBhcm0u
Y29tOw0KPiBrc3Rld2FydEBsaW51eGZvdW5kYXRpb24ub3JnOyBncmVna2hAbGludXhmb3VuZGF0
aW9uLm9yZzsNCj4gZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLWRldkBsaXN0
cy5vemxhYnMub3JnOyBsaW51eC0NCj4ga2VybmVsQHZnZXIua2VybmVsLm9yZw0KPiBDYzogcm9i
aEBrZXJuZWwub3JnOyBrZWVzY29va0BjaHJvbWl1bS5vcmc7IHR5cmVsZEBsaW51eC52bmV0Lmli
bS5jb207DQo+IGpvZUBwZXJjaGVzLmNvbQ0KPiBTdWJqZWN0OiBSZTogW1JGQyA1LzVdIHBvd2Vy
cGMvZnNsOiBBZGQgc3VwcG9ydGVkLWlycS1yYW5nZXMgZm9yIFAyMDIwDQo+IA0KPiBPbiBXZWQs
IDIwMTgtMDgtMDggYXQgMDM6NDQgKzAwMDAsIEJoYXJhdCBCaHVzaGFuIHdyb3RlOg0KPiA+ID4g
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IFNjb3R0IFdvb2QgW21haWx0
bzpvc3NAYnVzZXJyb3IubmV0XQ0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgOCwgMjAx
OCAyOjQ0IEFNDQo+ID4gPiBUbzogQmhhcmF0IEJodXNoYW4gPGJoYXJhdC5iaHVzaGFuQG54cC5j
b20+Ow0KPiA+ID4gYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOyBwYXVsdXNAc2FtYmEub3JnOyBt
cGVAZWxsZXJtYW4uaWQuYXU7DQo+ID4gPiBnYWxha0BrZXJuZWwuY3Jhc2hpbmcub3JnOyBtYXJr
LnJ1dGxhbmRAYXJtLmNvbTsNCj4gPiA+IGtzdGV3YXJ0QGxpbnV4Zm91bmRhdGlvbi5vcmc7IGdy
ZWdraEBsaW51eGZvdW5kYXRpb24ub3JnOw0KPiA+ID4gZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5v
cmc7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBsaW51eC0NCj4gPiA+IGtlcm5lbEB2
Z2VyLmtlcm5lbC5vcmcNCj4gPiA+IENjOiByb2JoQGtlcm5lbC5vcmc7IGtlZXNjb29rQGNocm9t
aXVtLm9yZzsNCj4gPiA+IHR5cmVsZEBsaW51eC52bmV0LmlibS5jb207IGpvZUBwZXJjaGVzLmNv
bQ0KPiA+ID4gU3ViamVjdDogUmU6IFtSRkMgNS81XSBwb3dlcnBjL2ZzbDogQWRkIHN1cHBvcnRl
ZC1pcnEtcmFuZ2VzIGZvcg0KPiA+ID4gUDIwMjANCj4gPiA+DQo+ID4gPiBPbiBGcmksIDIwMTgt
MDctMjcgYXQgMTU6MTggKzA1MzAsIEJoYXJhdCBCaHVzaGFuIHdyb3RlOg0KPiA+ID4gPiBNUElD
IG9uIE5YUCAoRnJlZXNjYWxlKSBQMjAyMCBzdXBwb3J0cyBmb2xsb3dpbmcgaXJxDQo+ID4gPiA+
IHJhbmdlczoNCj4gPiA+ID4gICA+IDAgLSAxMSAgICAgIChFeHRlcm5hbCBpbnRlcnJ1cHQpDQo+
ID4gPiA+ICAgPiAxNiAtIDc5ICAgICAoSW50ZXJuYWwgaW50ZXJydXB0KQ0KPiA+ID4gPiAgID4g
MTc2IC0gMTgzICAgKE1lc3NhZ2luZyBpbnRlcnJ1cHQpDQo+ID4gPiA+ICAgPiAyMjQgLSAyMzEg
ICAoU2hhcmVkIG1lc3NhZ2Ugc2lnbmFsZWQgaW50ZXJydXB0KQ0KPiA+ID4NCj4gPiA+IFdoeSBk
b24ndCB5b3UgY29udmVydCB0byB0aGUgNC1jZWxsIGludGVycnVwdCBzcGVjaWZpZXJzIHRoYXQg
bWFrZQ0KPiA+ID4gZGVhbGluZyB3aXRoIHRoZXNlIHJhbmdlcyBsZXNzIGVycm9yLXByb25lPw0K
PiA+DQo+ID4gT2sgLCB3aWxsIGRvIGlmIHdlIGFncmVlIHRvIGhhdmUgdGhpcyBzZXJpZXMgYXMg
cGVyIGNvbW1lbnQgb24gb3RoZXIgcGF0Y2guDQo+IA0KPiBJZiB5b3UncmUgY29uY2VybmVkIHdp
dGggZXJyb3JzLCB0aGlzIHdvdWxkIGJlIGEgZ29vZCB0aGluZ3MgdG8gZG8gcmVnYXJkbGVzcy4N
Cj4gIEFjdHVhbGx5LCBpdCBzZWVtcyB0aGF0IHAyMDIwc2ktcG9zdC5kdHNpIGFscmVhZHkgdXNl
cyA0LWNlbGwgaW50ZXJydXB0cy4NCj4gDQo+IFdoYXQgaXMgbW90aXZhdGluZyB0aGlzIHBhdGNo
c2V0PyAgSXMgdGhlcmUgc29tZXRoaW5nIHdyb25nIGluIHRoZSBleGlzdGluZw0KPiBkdHMgZmls
ZXM/DQoNClRoZXJlIGlzIG5vIGVycm9yIGluIGRldmljZSB0cmVlLiBNYWluIG1vdGl2YXRpb24g
aXMgdG8gaW1wcm92ZSBjb2RlIGZvciBmb2xsb3dpbmcgcmVhc29uczogDQogIC0gV2hpbGUgY29k
ZSBzdHVkeSBpdCB3YXMgZm91bmQgdGhhdCBpZiBhIHJlc2VydmVkIGlycS1udW1iZXIgdXNlZCB0
aGVuIHRoZXJlIGFyZSBubyBjaGVjayBpbiBkcml2ZXIuIGlycSB3aWxsIGJlIGNvbmZpZ3VyZWQg
YXMgY29ycmVjdCBhbmQgaW50ZXJydXB0IHdpbGwgbmV2ZXIgZmlyZS4NCiAtIFdhcm5pbmdzIHdl
cmUgb2JzZXJ2ZWQgb24gZGV2ZWxvcG1lbnQgcGxhdGZvcm0gKHNpbXVsYXRvcikgd2hlbiByZWFk
L3dyaXRlIHRvIHJlc2VydmVkIE1QSUMgcmVhc29uIGR1cmluZyBpbml0Lg0KICANCj4gDQo+IA0K
PiA+DQo+ID4gPg0KPiA+ID4gPiBkaWZmIC0tZ2l0IGEvYXJjaC9wb3dlcnBjL3BsYXRmb3Jtcy84
NXh4L21wYzg1eHhfcmRiLmMNCj4gPiA+ID4gYi9hcmNoL3Bvd2VycGMvcGxhdGZvcm1zLzg1eHgv
bXBjODV4eF9yZGIuYw0KPiA+ID4gPiBpbmRleCAxMDA2OTUwLi40OWZmMzQ4IDEwMDY0NA0KPiA+
ID4gPiAtLS0gYS9hcmNoL3Bvd2VycGMvcGxhdGZvcm1zLzg1eHgvbXBjODV4eF9yZGIuYw0KPiA+
ID4gPiArKysgYi9hcmNoL3Bvd2VycGMvcGxhdGZvcm1zLzg1eHgvbXBjODV4eF9yZGIuYw0KPiA+
ID4gPiBAQCAtNTcsNiArNTcsMTEgQEAgdm9pZCBfX2luaXQgbXBjODV4eF9yZGJfcGljX2luaXQo
dm9pZCkNCj4gPiA+ID4gIAkJCU1QSUNfQklHX0VORElBTiB8DQo+ID4gPiA+ICAJCQlNUElDX1NJ
TkdMRV9ERVNUX0NQVSwNCj4gPiA+ID4gIAkJCTAsIDI1NiwgIiBPcGVuUElDICAiKTsNCj4gPiA+
ID4gKwl9IGVsc2UgaWYgKG9mX21hY2hpbmVfaXNfY29tcGF0aWJsZSgiZnNsLFAyMDIwUkRCLVBD
IikpIHsNCj4gPiA+ID4gKwkJbXBpYyA9IG1waWNfYWxsb2MoTlVMTCwgMCwNCj4gPiA+ID4gKwkJ
ICBNUElDX0JJR19FTkRJQU4gfA0KPiA+ID4gPiArCQkgIE1QSUNfU0lOR0xFX0RFU1RfQ1BVLA0K
PiA+ID4gPiArCQkgIDAsIDAsICIgT3BlblBJQyAgIik7DQo+ID4gPiA+ICAJfSBlbHNlIHsNCj4g
PiA+ID4gIAkJbXBpYyA9IG1waWNfYWxsb2MoTlVMTCwgMCwNCj4gPiA+ID4gIAkJICBNUElDX0JJ
R19FTkRJQU4gfA0KPiA+ID4NCj4gPiA+IEkgZG9uJ3QgdGhpbmsgd2Ugd2FudCB0byBncm93IGEg
bGlzdCBvZiBldmVyeSBzaW5nbGUgcmV2aXNpb24gb2YNCj4gPiA+IGV2ZXJ5IGJvYXJkIGluIHRo
ZXNlIHBsYXRmb3JtIGZpbGVzLg0KPiA+DQo+ID4gT25lIG90aGVyIGNvbmZ1c2luZyBvYnNlcnZh
dGlvbiBJIGhhdmUgaXMgdGhhdCAiaXJxX2NvdW50IiBmcm9tDQo+ID4gcGxhdGZvcm0gY29kZSBp
cyBnaXZlbiBwcmVjZWRlbmNlIG92ZXIgImxhc3QtaW50ZXJydXB0LXNvdXJjZSIgaW4gZGV2aWNl
LQ0KPiB0cmVlLg0KPiA+IFNob3VsZCBub3QgZGV2aWNlLXRyZWUgc2hvdWxkIGhhdmUgcHJlY2Vk
ZW5jZSBvdGhlcndpc2UgdGhlcmUgaXMgbm8NCj4gPiBwb2ludCB1c2luZyAiIGxhc3QtaW50ZXJy
dXB0LXNvdXJjZSIgaWYgcGxhdGZvcm0gY29kZSBwYXNzZXMNCj4gPiAiaXJxX2NvdW50IiBpbiBt
cGljX2FsbG9jKCkuDQo+IA0KPiBNYXliZSwgdGhvdWdoIEkgZG9uJ3QgdGhpbmsgaXQgbWF0dGVy
cyBtdWNoIGdpdmVuIHRoYXQgbGFzdC1pbnRlcnJ1cHQtc291cmNlDQo+IHdhcyBvbmx5IGFkZGVk
IHRvIGF2b2lkIGhhdmluZyB0byBwYXNzIGlycV9jb3VudCBpbiBwbGF0Zm9ybSBjb2RlLg0KDQpU
aGFua3MgZm9yIGNsYXJpZnlpbmc7DQoNCk15IHVuZGVyc3RhbmRpbmcgd2FzIHRoYXQgImxhc3Qt
aW50ZXJydXB0LXNvdXJjZSIgYWRkZWQgdG8gZW5zdXJlIHRoYXQgd2UgY2FuIG92ZXItcmlkZSB2
YWx1ZSBwYXNzZWQgZnJvbSBwbGF0Zm9ybSBjb2RlLiBJbiB0aGF0IGNhc2Ugd2UgZG8gbm90IG5l
ZWQgdG8gY2hhbmdlIGNvZGUgYW5kIGNhbiBjb250cm9sIGZyb20gZGV2aWNlIHRyZWUuDQoNClRo
YW5rcw0KLUJoYXJhdA0KDQoNCj4gDQo+IC1TY290dA0KDQo=

Re: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Scott Wood]

On Wed, 2018-08-08 at 06:28 +0000, Bharat Bhushan wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Wednesday, August 8, 2018 11:26 AM
> > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > 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:
> > > > -----Original Message-----
> > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > Sent: Wednesday, August 8, 2018 2:44 AM
> > > > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > > > 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:
> > > > > 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).

> > > One other confusing observation I have is that "irq_count" from
> > > platform code is given precedence over "last-interrupt-source" in
> > > device-
> > 
> > tree.
> > > 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

Re: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Scott Wood]

On Wed, 2018-08-08 at 06:28 +0000, Bharat Bhushan wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Wednesday, August 8, 2018 11:26 AM
> > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > 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:
> > > > -----Original Message-----
> > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > Sent: Wednesday, August 8, 2018 2:44 AM
> > > > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > > > 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:
> > > > > 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).

> > > One other confusing observation I have is that "irq_count" from
> > > platform code is given precedence over "last-interrupt-source" in
> > > device-
> > 
> > tree.
> > > 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

RE: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Bharat Bhushan]

> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Wednesday, August 8, 2018 11:27 PM
> To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> 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 06:28 +0000, Bharat Bhushan wrote:
> > > -----Original Message-----
> > > From: Scott Wood [mailto:oss@buserror.net]
> > > Sent: Wednesday, August 8, 2018 11:26 AM
> > > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > > 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:
> > > > > -----Original Message-----
> > > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > > Sent: Wednesday, August 8, 2018 2:44 AM
> > > > > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > > > > 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:
> > > > > > 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).

Fair enough, we can use MPIC version to define supported interrupts ranges. Will that be acceptable.

Thanks
-Bharat

> 
> > > > One other confusing observation I have is that "irq_count" from
> > > > platform code is given precedence over "last-interrupt-source" in
> > > > device-
> > >
> > > tree.
> > > > 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

RE: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Bharat Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2NvdHQgV29vZCBbbWFp
bHRvOm9zc0BidXNlcnJvci5uZXRdDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDgsIDIwMTgg
MTE6MjcgUE0NCj4gVG86IEJoYXJhdCBCaHVzaGFuIDxiaGFyYXQuYmh1c2hhbkBueHAuY29tPjsN
Cj4gYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOyBwYXVsdXNAc2FtYmEub3JnOyBtcGVAZWxsZXJt
YW4uaWQuYXU7DQo+IGdhbGFrQGtlcm5lbC5jcmFzaGluZy5vcmc7IG1hcmsucnV0bGFuZEBhcm0u
Y29tOw0KPiBrc3Rld2FydEBsaW51eGZvdW5kYXRpb24ub3JnOyBncmVna2hAbGludXhmb3VuZGF0
aW9uLm9yZzsNCj4gZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLWRldkBsaXN0
cy5vemxhYnMub3JnOyBsaW51eC0NCj4ga2VybmVsQHZnZXIua2VybmVsLm9yZw0KPiBDYzogcm9i
aEBrZXJuZWwub3JnOyBrZWVzY29va0BjaHJvbWl1bS5vcmc7IHR5cmVsZEBsaW51eC52bmV0Lmli
bS5jb207DQo+IGpvZUBwZXJjaGVzLmNvbQ0KPiBTdWJqZWN0OiBSZTogW1JGQyA1LzVdIHBvd2Vy
cGMvZnNsOiBBZGQgc3VwcG9ydGVkLWlycS1yYW5nZXMgZm9yIFAyMDIwDQo+IA0KPiBPbiBXZWQs
IDIwMTgtMDgtMDggYXQgMDY6MjggKzAwMDAsIEJoYXJhdCBCaHVzaGFuIHdyb3RlOg0KPiA+ID4g
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IFNjb3R0IFdvb2QgW21haWx0
bzpvc3NAYnVzZXJyb3IubmV0XQ0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgOCwgMjAx
OCAxMToyNiBBTQ0KPiA+ID4gVG86IEJoYXJhdCBCaHVzaGFuIDxiaGFyYXQuYmh1c2hhbkBueHAu
Y29tPjsNCj4gPiA+IGJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZzsgcGF1bHVzQHNhbWJhLm9yZzsg
bXBlQGVsbGVybWFuLmlkLmF1Ow0KPiA+ID4gZ2FsYWtAa2VybmVsLmNyYXNoaW5nLm9yZzsgbWFy
ay5ydXRsYW5kQGFybS5jb207DQo+ID4gPiBrc3Rld2FydEBsaW51eGZvdW5kYXRpb24ub3JnOyBn
cmVna2hAbGludXhmb3VuZGF0aW9uLm9yZzsNCj4gPiA+IGRldmljZXRyZWVAdmdlci5rZXJuZWwu
b3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgbGludXgtDQo+ID4gPiBrZXJuZWxA
dmdlci5rZXJuZWwub3JnDQo+ID4gPiBDYzogcm9iaEBrZXJuZWwub3JnOyBrZWVzY29va0BjaHJv
bWl1bS5vcmc7DQo+ID4gPiB0eXJlbGRAbGludXgudm5ldC5pYm0uY29tOyBqb2VAcGVyY2hlcy5j
b20NCj4gPiA+IFN1YmplY3Q6IFJlOiBbUkZDIDUvNV0gcG93ZXJwYy9mc2w6IEFkZCBzdXBwb3J0
ZWQtaXJxLXJhbmdlcyBmb3INCj4gPiA+IFAyMDIwDQo+ID4gPg0KPiA+ID4gT24gV2VkLCAyMDE4
LTA4LTA4IGF0IDAzOjQ0ICswMDAwLCBCaGFyYXQgQmh1c2hhbiB3cm90ZToNCj4gPiA+ID4gPiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+IEZyb206IFNjb3R0IFdvb2QgW21h
aWx0bzpvc3NAYnVzZXJyb3IubmV0XQ0KPiA+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0
IDgsIDIwMTggMjo0NCBBTQ0KPiA+ID4gPiA+IFRvOiBCaGFyYXQgQmh1c2hhbiA8YmhhcmF0LmJo
dXNoYW5AbnhwLmNvbT47DQo+ID4gPiA+ID4gYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOyBwYXVs
dXNAc2FtYmEub3JnOyBtcGVAZWxsZXJtYW4uaWQuYXU7DQo+ID4gPiA+ID4gZ2FsYWtAa2VybmVs
LmNyYXNoaW5nLm9yZzsgbWFyay5ydXRsYW5kQGFybS5jb207DQo+ID4gPiA+ID4ga3N0ZXdhcnRA
bGludXhmb3VuZGF0aW9uLm9yZzsgZ3JlZ2toQGxpbnV4Zm91bmRhdGlvbi5vcmc7DQo+ID4gPiA+
ID4gZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMu
b3JnOw0KPiA+ID4gPiA+IGxpbnV4LSBrZXJuZWxAdmdlci5rZXJuZWwub3JnDQo+ID4gPiA+ID4g
Q2M6IHJvYmhAa2VybmVsLm9yZzsga2Vlc2Nvb2tAY2hyb21pdW0ub3JnOw0KPiA+ID4gPiA+IHR5
cmVsZEBsaW51eC52bmV0LmlibS5jb207IGpvZUBwZXJjaGVzLmNvbQ0KPiA+ID4gPiA+IFN1Ympl
Y3Q6IFJlOiBbUkZDIDUvNV0gcG93ZXJwYy9mc2w6IEFkZCBzdXBwb3J0ZWQtaXJxLXJhbmdlcyBm
b3INCj4gPiA+ID4gPiBQMjAyMA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gT24gRnJpLCAyMDE4LTA3
LTI3IGF0IDE1OjE4ICswNTMwLCBCaGFyYXQgQmh1c2hhbiB3cm90ZToNCj4gPiA+ID4gPiA+IE1Q
SUMgb24gTlhQIChGcmVlc2NhbGUpIFAyMDIwIHN1cHBvcnRzIGZvbGxvd2luZyBpcnENCj4gPiA+
ID4gPiA+IHJhbmdlczoNCj4gPiA+ID4gPiA+ICAgPiAwIC0gMTEgICAgICAoRXh0ZXJuYWwgaW50
ZXJydXB0KQ0KPiA+ID4gPiA+ID4gICA+IDE2IC0gNzkgICAgIChJbnRlcm5hbCBpbnRlcnJ1cHQp
DQo+ID4gPiA+ID4gPiAgID4gMTc2IC0gMTgzICAgKE1lc3NhZ2luZyBpbnRlcnJ1cHQpDQo+ID4g
PiA+ID4gPiAgID4gMjI0IC0gMjMxICAgKFNoYXJlZCBtZXNzYWdlIHNpZ25hbGVkIGludGVycnVw
dCkNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFdoeSBkb24ndCB5b3UgY29udmVydCB0byB0aGUgNC1j
ZWxsIGludGVycnVwdCBzcGVjaWZpZXJzIHRoYXQNCj4gPiA+ID4gPiBtYWtlIGRlYWxpbmcgd2l0
aCB0aGVzZSByYW5nZXMgbGVzcyBlcnJvci1wcm9uZT8NCj4gPiA+ID4NCj4gPiA+ID4gT2sgLCB3
aWxsIGRvIGlmIHdlIGFncmVlIHRvIGhhdmUgdGhpcyBzZXJpZXMgYXMgcGVyIGNvbW1lbnQgb24N
Cj4gPiA+ID4gb3RoZXIgcGF0Y2guDQo+ID4gPg0KPiA+ID4gSWYgeW91J3JlIGNvbmNlcm5lZCB3
aXRoIGVycm9ycywgdGhpcyB3b3VsZCBiZSBhIGdvb2QgdGhpbmdzIHRvIGRvDQo+ID4gPiByZWdh
cmRsZXNzLg0KPiA+ID4gIEFjdHVhbGx5LCBpdCBzZWVtcyB0aGF0IHAyMDIwc2ktcG9zdC5kdHNp
IGFscmVhZHkgdXNlcyA0LWNlbGwgaW50ZXJydXB0cy4NCj4gPiA+DQo+ID4gPiBXaGF0IGlzIG1v
dGl2YXRpbmcgdGhpcyBwYXRjaHNldD8gIElzIHRoZXJlIHNvbWV0aGluZyB3cm9uZyBpbiB0aGUN
Cj4gPiA+IGV4aXN0aW5nIGR0cyBmaWxlcz8NCj4gPg0KPiA+IFRoZXJlIGlzIG5vIGVycm9yIGlu
IGRldmljZSB0cmVlLiBNYWluIG1vdGl2YXRpb24gaXMgdG8gaW1wcm92ZSBjb2RlDQo+ID4gZm9y
IGZvbGxvd2luZyByZWFzb25zOg0KPiA+ICAgLSBXaGlsZSBjb2RlIHN0dWR5IGl0IHdhcyBmb3Vu
ZCB0aGF0IGlmIGEgcmVzZXJ2ZWQgaXJxLW51bWJlciB1c2VkDQo+ID4gdGhlbiB0aGVyZSBhcmUg
bm8gY2hlY2sgaW4gZHJpdmVyLiBpcnEgd2lsbCBiZSBjb25maWd1cmVkIGFzIGNvcnJlY3QNCj4g
PiBhbmQgaW50ZXJydXB0IHdpbGwgbmV2ZXIgZmlyZS4NCj4gDQo+IEFnYWluLCBhIHdyb25nIGlu
dGVycnVwdCBudW1iZXIgd29uJ3QgZmlyZSwgd2hldGhlciBhbiBpbnRlcnJ1cHQgYnkgdGhhdA0K
PiBudW1iZXIgZXhpc3RzIG9yIG5vdC4gIEkgd291bGRuJ3QgbWluZCBhIHNhbml0eSBjaGVjayBp
biB0aGUgZHJpdmVyIGlmIHRoZQ0KPiBwcm9ncmFtbWluZyBtb2RlbCBtYWRlIGl0IHByb3Blcmx5
IGRpc2NvdmVyYWJsZSwgYnV0IEkgZG9uJ3QgdGhpbmsgaXQncw0KPiB3b3J0aCBtZXNzaW5nIHdp
dGggZGV2aWNlIHRyZWVzIGp1c3QgZm9yIHRoaXMgKGFuZCBldmVuIGxlc3Mgc28gZ2l2ZW4gdGhh
dA0KPiB0aGVyZSBkb24ndCBzZWVtIHRvIGJlIG5ldyBjaGlwcyBjb21pbmcgb3V0IHRoYXQgdGhp
cyB3b3VsZCBiZSByZWxldmFudA0KPiBmb3IpLg0KDQpGYWlyIGVub3VnaCwgd2UgY2FuIHVzZSBN
UElDIHZlcnNpb24gdG8gZGVmaW5lIHN1cHBvcnRlZCBpbnRlcnJ1cHRzIHJhbmdlcy4gV2lsbCB0
aGF0IGJlIGFjY2VwdGFibGUuDQoNClRoYW5rcw0KLUJoYXJhdA0KDQo+IA0KPiA+ID4gPiBPbmUg
b3RoZXIgY29uZnVzaW5nIG9ic2VydmF0aW9uIEkgaGF2ZSBpcyB0aGF0ICJpcnFfY291bnQiIGZy
b20NCj4gPiA+ID4gcGxhdGZvcm0gY29kZSBpcyBnaXZlbiBwcmVjZWRlbmNlIG92ZXIgImxhc3Qt
aW50ZXJydXB0LXNvdXJjZSIgaW4NCj4gPiA+ID4gZGV2aWNlLQ0KPiA+ID4NCj4gPiA+IHRyZWUu
DQo+ID4gPiA+IFNob3VsZCBub3QgZGV2aWNlLXRyZWUgc2hvdWxkIGhhdmUgcHJlY2VkZW5jZSBv
dGhlcndpc2UgdGhlcmUgaXMNCj4gPiA+ID4gbm8gcG9pbnQgdXNpbmcgIiBsYXN0LWludGVycnVw
dC1zb3VyY2UiIGlmIHBsYXRmb3JtIGNvZGUgcGFzc2VzDQo+ID4gPiA+ICJpcnFfY291bnQiIGlu
IG1waWNfYWxsb2MoKS4NCj4gPiA+DQo+ID4gPiBNYXliZSwgdGhvdWdoIEkgZG9uJ3QgdGhpbmsg
aXQgbWF0dGVycyBtdWNoIGdpdmVuIHRoYXQNCj4gPiA+IGxhc3QtaW50ZXJydXB0LSBzb3VyY2Ug
d2FzIG9ubHkgYWRkZWQgdG8gYXZvaWQgaGF2aW5nIHRvIHBhc3MNCj4gPiA+IGlycV9jb3VudCBp
biBwbGF0Zm9ybSBjb2RlLg0KPiA+DQo+ID4gVGhhbmtzIGZvciBjbGFyaWZ5aW5nOw0KPiA+DQo+
ID4gTXkgdW5kZXJzdGFuZGluZyB3YXMgdGhhdCAibGFzdC1pbnRlcnJ1cHQtc291cmNlIiBhZGRl
ZCB0byBlbnN1cmUgdGhhdA0KPiA+IHdlIGNhbiBvdmVyLXJpZGUgdmFsdWUgcGFzc2VkIGZyb20g
cGxhdGZvcm0gY29kZS4gSW4gdGhhdCBjYXNlIHdlIGRvDQo+ID4gbm90IG5lZWQgdG8gY2hhbmdl
IGNvZGUgYW5kIGNhbiBjb250cm9sIGZyb20gZGV2aWNlIHRyZWUuDQo+IA0KPiBUaGUgY2hhbmdl
bG9nIHNheXMsICJUbyBhdm9pZCBuZWVkaW5nIHRvIHdyaXRlIGN1c3RvbSBib2FyZC1zcGVjaWZp
YyBjb2RlDQo+IHRvIGRldGVjdCB0aGF0IHNjZW5hcmlvLCBhbGxvdyBpdCB0byBiZSBlYXNpbHkg
b3ZlcnJpZGRlbiBpbiB0aGUgZGV2aWNlLXRyZWUsIg0KPiB3aGVyZSAiaXQiIG1lYW5zIHRoZSB2
YWx1ZSBwcm92aWRlZCBieSBoYXJkd2FyZS4gIFRoZSBnb2FsIHdhcyB0byBwYXNzIGluDQo+IDI1
NiB3aXRob3V0IGJvYXJkIGNvZGUgaW4gdGhlIGtlcm5lbCwgbm90IHRvIG92ZXJyaWRlIHRoZSAy
NTYuDQo+IA0KPiAtU2NvdHQNCg0K

Re: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Scott Wood]

On Thu, 2018-08-09 at 03:28 +0000, Bharat Bhushan wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Wednesday, August 8, 2018 11:27 PM
> > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > 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 06:28 +0000, Bharat Bhushan wrote:
> > > > -----Original Message-----
> > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > Sent: Wednesday, August 8, 2018 11:26 AM
> > > > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > > > 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:
> > > > > > -----Original Message-----
> > > > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > > > Sent: Wednesday, August 8, 2018 2:44 AM
> > > > > > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > > > > > 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:
> > > > > > > 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).
> 
> Fair enough, we can use MPIC version to define supported interrupts ranges.
> Will that be acceptable.

It's better than device tree changes but I'm not convinced it's worthwhile
just to suppress some simulator warnings.  If the warnings really bother you,
you can use pic-no-reset in the device tree (assuming this isn't some new chip
that you want to make sure doesn't fall over when the usual mpic init happens)
and/or convince the hardware people to make the interface properly
discoverable including discontiguous regions (if there *is* some new chip I
haven't heard about).

-Scott

Re: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Scott Wood]

On Thu, 2018-08-09 at 03:28 +0000, Bharat Bhushan wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Wednesday, August 8, 2018 11:27 PM
> > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > 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 06:28 +0000, Bharat Bhushan wrote:
> > > > -----Original Message-----
> > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > Sent: Wednesday, August 8, 2018 11:26 AM
> > > > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > > > 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:
> > > > > > -----Original Message-----
> > > > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > > > Sent: Wednesday, August 8, 2018 2:44 AM
> > > > > > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > > > > > 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:
> > > > > > > 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).
> 
> Fair enough, we can use MPIC version to define supported interrupts ranges.
> Will that be acceptable.

It's better than device tree changes but I'm not convinced it's worthwhile
just to suppress some simulator warnings.  If the warnings really bother you,
you can use pic-no-reset in the device tree (assuming this isn't some new chip
that you want to make sure doesn't fall over when the usual mpic init happens)
and/or convince the hardware people to make the interface properly
discoverable including discontiguous regions (if there *is* some new chip I
haven't heard about).

-Scott

RE: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Bharat Bhushan]

> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Thursday, August 9, 2018 11:42 AM
> To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> 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 Thu, 2018-08-09 at 03:28 +0000, Bharat Bhushan wrote:
> > > -----Original Message-----
> > > From: Scott Wood [mailto:oss@buserror.net]
> > > Sent: Wednesday, August 8, 2018 11:27 PM
> > > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > > 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 06:28 +0000, Bharat Bhushan wrote:
> > > > > -----Original Message-----
> > > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > > Sent: Wednesday, August 8, 2018 11:26 AM
> > > > > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > > > > 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:
> > > > > > > -----Original Message-----
> > > > > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > > > > Sent: Wednesday, August 8, 2018 2:44 AM
> > > > > > > To: Bharat Bhushan <bharat.bhushan@nxp.com>;
> > > > > > > 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:
> > > > > > > > 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).
> >
> > Fair enough, we can use MPIC version to define supported interrupts
> ranges.
> > Will that be acceptable.
> 
> It's better than device tree changes but I'm not convinced it's worthwhile just
> to suppress some simulator warnings.
>  If the warnings really bother you, you
> can use pic-no-reset in the device tree (assuming this isn't some new chip
> that you want to make sure doesn't fall over when the usual mpic init
> happens) and/or convince the hardware people to make the interface
> properly discoverable including discontiguous regions (if there *is* some
> new chip I haven't heard about).

There is new chip under development based on e200, which uses same mpic as in older PowerPC versions.
This patch was not just about suppressing the warning but warning was the observation that reserved region is getting accessed during init/uninit/save/restore. This patch was just an minor improvement to avoid these accesses. We will drop this series if this improvement is not convincing.

Thanks
-Bharat

> 
> -Scott

RE: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Bharat Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2NvdHQgV29vZCBbbWFp
bHRvOm9zc0BidXNlcnJvci5uZXRdDQo+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgOSwgMjAxOCAx
MTo0MiBBTQ0KPiBUbzogQmhhcmF0IEJodXNoYW4gPGJoYXJhdC5iaHVzaGFuQG54cC5jb20+Ow0K
PiBiZW5oQGtlcm5lbC5jcmFzaGluZy5vcmc7IHBhdWx1c0BzYW1iYS5vcmc7IG1wZUBlbGxlcm1h
bi5pZC5hdTsNCj4gZ2FsYWtAa2VybmVsLmNyYXNoaW5nLm9yZzsgbWFyay5ydXRsYW5kQGFybS5j
b207DQo+IGtzdGV3YXJ0QGxpbnV4Zm91bmRhdGlvbi5vcmc7IGdyZWdraEBsaW51eGZvdW5kYXRp
b24ub3JnOw0KPiBkZXZpY2V0cmVlQHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2QGxpc3Rz
Lm96bGFicy5vcmc7IGxpbnV4LQ0KPiBrZXJuZWxAdmdlci5rZXJuZWwub3JnDQo+IENjOiByb2Jo
QGtlcm5lbC5vcmc7IGtlZXNjb29rQGNocm9taXVtLm9yZzsgdHlyZWxkQGxpbnV4LnZuZXQuaWJt
LmNvbTsNCj4gam9lQHBlcmNoZXMuY29tDQo+IFN1YmplY3Q6IFJlOiBbUkZDIDUvNV0gcG93ZXJw
Yy9mc2w6IEFkZCBzdXBwb3J0ZWQtaXJxLXJhbmdlcyBmb3IgUDIwMjANCj4gDQo+IE9uIFRodSwg
MjAxOC0wOC0wOSBhdCAwMzoyOCArMDAwMCwgQmhhcmF0IEJodXNoYW4gd3JvdGU6DQo+ID4gPiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogU2NvdHQgV29vZCBbbWFpbHRv
Om9zc0BidXNlcnJvci5uZXRdDQo+ID4gPiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCA4LCAyMDE4
IDExOjI3IFBNDQo+ID4gPiBUbzogQmhhcmF0IEJodXNoYW4gPGJoYXJhdC5iaHVzaGFuQG54cC5j
b20+Ow0KPiA+ID4gYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOyBwYXVsdXNAc2FtYmEub3JnOyBt
cGVAZWxsZXJtYW4uaWQuYXU7DQo+ID4gPiBnYWxha0BrZXJuZWwuY3Jhc2hpbmcub3JnOyBtYXJr
LnJ1dGxhbmRAYXJtLmNvbTsNCj4gPiA+IGtzdGV3YXJ0QGxpbnV4Zm91bmRhdGlvbi5vcmc7IGdy
ZWdraEBsaW51eGZvdW5kYXRpb24ub3JnOw0KPiA+ID4gZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5v
cmc7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBsaW51eC0NCj4gPiA+IGtlcm5lbEB2
Z2VyLmtlcm5lbC5vcmcNCj4gPiA+IENjOiByb2JoQGtlcm5lbC5vcmc7IGtlZXNjb29rQGNocm9t
aXVtLm9yZzsNCj4gPiA+IHR5cmVsZEBsaW51eC52bmV0LmlibS5jb207IGpvZUBwZXJjaGVzLmNv
bQ0KPiA+ID4gU3ViamVjdDogUmU6IFtSRkMgNS81XSBwb3dlcnBjL2ZzbDogQWRkIHN1cHBvcnRl
ZC1pcnEtcmFuZ2VzIGZvcg0KPiA+ID4gUDIwMjANCj4gPiA+DQo+ID4gPiBPbiBXZWQsIDIwMTgt
MDgtMDggYXQgMDY6MjggKzAwMDAsIEJoYXJhdCBCaHVzaGFuIHdyb3RlOg0KPiA+ID4gPiA+IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gRnJvbTogU2NvdHQgV29vZCBbbWFp
bHRvOm9zc0BidXNlcnJvci5uZXRdDQo+ID4gPiA+ID4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3Qg
OCwgMjAxOCAxMToyNiBBTQ0KPiA+ID4gPiA+IFRvOiBCaGFyYXQgQmh1c2hhbiA8YmhhcmF0LmJo
dXNoYW5AbnhwLmNvbT47DQo+ID4gPiA+ID4gYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOyBwYXVs
dXNAc2FtYmEub3JnOyBtcGVAZWxsZXJtYW4uaWQuYXU7DQo+ID4gPiA+ID4gZ2FsYWtAa2VybmVs
LmNyYXNoaW5nLm9yZzsgbWFyay5ydXRsYW5kQGFybS5jb207DQo+ID4gPiA+ID4ga3N0ZXdhcnRA
bGludXhmb3VuZGF0aW9uLm9yZzsgZ3JlZ2toQGxpbnV4Zm91bmRhdGlvbi5vcmc7DQo+ID4gPiA+
ID4gZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMu
b3JnOw0KPiA+ID4gPiA+IGxpbnV4LSBrZXJuZWxAdmdlci5rZXJuZWwub3JnDQo+ID4gPiA+ID4g
Q2M6IHJvYmhAa2VybmVsLm9yZzsga2Vlc2Nvb2tAY2hyb21pdW0ub3JnOw0KPiA+ID4gPiA+IHR5
cmVsZEBsaW51eC52bmV0LmlibS5jb207IGpvZUBwZXJjaGVzLmNvbQ0KPiA+ID4gPiA+IFN1Ympl
Y3Q6IFJlOiBbUkZDIDUvNV0gcG93ZXJwYy9mc2w6IEFkZCBzdXBwb3J0ZWQtaXJxLXJhbmdlcyBm
b3INCj4gPiA+ID4gPiBQMjAyMA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gT24gV2VkLCAyMDE4LTA4
LTA4IGF0IDAzOjQ0ICswMDAwLCBCaGFyYXQgQmh1c2hhbiB3cm90ZToNCj4gPiA+ID4gPiA+ID4g
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+ID4gRnJvbTogU2NvdHQgV29v
ZCBbbWFpbHRvOm9zc0BidXNlcnJvci5uZXRdDQo+ID4gPiA+ID4gPiA+IFNlbnQ6IFdlZG5lc2Rh
eSwgQXVndXN0IDgsIDIwMTggMjo0NCBBTQ0KPiA+ID4gPiA+ID4gPiBUbzogQmhhcmF0IEJodXNo
YW4gPGJoYXJhdC5iaHVzaGFuQG54cC5jb20+Ow0KPiA+ID4gPiA+ID4gPiBiZW5oQGtlcm5lbC5j
cmFzaGluZy5vcmc7IHBhdWx1c0BzYW1iYS5vcmc7DQo+ID4gPiA+ID4gPiA+IG1wZUBlbGxlcm1h
bi5pZC5hdTsgZ2FsYWtAa2VybmVsLmNyYXNoaW5nLm9yZzsNCj4gPiA+ID4gPiA+ID4gbWFyay5y
dXRsYW5kQGFybS5jb207IGtzdGV3YXJ0QGxpbnV4Zm91bmRhdGlvbi5vcmc7DQo+ID4gPiA+ID4g
PiA+IGdyZWdraEBsaW51eGZvdW5kYXRpb24ub3JnOyBkZXZpY2V0cmVlQHZnZXIua2VybmVsLm9y
ZzsNCj4gPiA+ID4gPiA+ID4gbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7DQo+ID4gPiA+
ID4gPiA+IGxpbnV4LSBrZXJuZWxAdmdlci5rZXJuZWwub3JnDQo+ID4gPiA+ID4gPiA+IENjOiBy
b2JoQGtlcm5lbC5vcmc7IGtlZXNjb29rQGNocm9taXVtLm9yZzsNCj4gPiA+ID4gPiA+ID4gdHly
ZWxkQGxpbnV4LnZuZXQuaWJtLmNvbTsgam9lQHBlcmNoZXMuY29tDQo+ID4gPiA+ID4gPiA+IFN1
YmplY3Q6IFJlOiBbUkZDIDUvNV0gcG93ZXJwYy9mc2w6IEFkZCBzdXBwb3J0ZWQtaXJxLXJhbmdl
cw0KPiA+ID4gPiA+ID4gPiBmb3INCj4gPiA+ID4gPiA+ID4gUDIwMjANCj4gPiA+ID4gPiA+ID4N
Cj4gPiA+ID4gPiA+ID4gT24gRnJpLCAyMDE4LTA3LTI3IGF0IDE1OjE4ICswNTMwLCBCaGFyYXQg
Qmh1c2hhbiB3cm90ZToNCj4gPiA+ID4gPiA+ID4gPiBNUElDIG9uIE5YUCAoRnJlZXNjYWxlKSBQ
MjAyMCBzdXBwb3J0cyBmb2xsb3dpbmcgaXJxDQo+ID4gPiA+ID4gPiA+ID4gcmFuZ2VzOg0KPiA+
ID4gPiA+ID4gPiA+ICAgPiAwIC0gMTEgICAgICAoRXh0ZXJuYWwgaW50ZXJydXB0KQ0KPiA+ID4g
PiA+ID4gPiA+ICAgPiAxNiAtIDc5ICAgICAoSW50ZXJuYWwgaW50ZXJydXB0KQ0KPiA+ID4gPiA+
ID4gPiA+ICAgPiAxNzYgLSAxODMgICAoTWVzc2FnaW5nIGludGVycnVwdCkNCj4gPiA+ID4gPiA+
ID4gPiAgID4gMjI0IC0gMjMxICAgKFNoYXJlZCBtZXNzYWdlIHNpZ25hbGVkIGludGVycnVwdCkN
Cj4gPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ID4gV2h5IGRvbid0IHlvdSBjb252ZXJ0IHRvIHRo
ZSA0LWNlbGwgaW50ZXJydXB0IHNwZWNpZmllcnMNCj4gPiA+ID4gPiA+ID4gdGhhdCBtYWtlIGRl
YWxpbmcgd2l0aCB0aGVzZSByYW5nZXMgbGVzcyBlcnJvci1wcm9uZT8NCj4gPiA+ID4gPiA+DQo+
ID4gPiA+ID4gPiBPayAsIHdpbGwgZG8gaWYgd2UgYWdyZWUgdG8gaGF2ZSB0aGlzIHNlcmllcyBh
cyBwZXIgY29tbWVudCBvbg0KPiA+ID4gPiA+ID4gb3RoZXIgcGF0Y2guDQo+ID4gPiA+ID4NCj4g
PiA+ID4gPiBJZiB5b3UncmUgY29uY2VybmVkIHdpdGggZXJyb3JzLCB0aGlzIHdvdWxkIGJlIGEg
Z29vZCB0aGluZ3MgdG8NCj4gPiA+ID4gPiBkbyByZWdhcmRsZXNzLg0KPiA+ID4gPiA+ICBBY3R1
YWxseSwgaXQgc2VlbXMgdGhhdCBwMjAyMHNpLXBvc3QuZHRzaSBhbHJlYWR5IHVzZXMgNC1jZWxs
DQo+ID4gPiA+ID4gaW50ZXJydXB0cy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFdoYXQgaXMgbW90
aXZhdGluZyB0aGlzIHBhdGNoc2V0PyAgSXMgdGhlcmUgc29tZXRoaW5nIHdyb25nIGluDQo+ID4g
PiA+ID4gdGhlIGV4aXN0aW5nIGR0cyBmaWxlcz8NCj4gPiA+ID4NCj4gPiA+ID4gVGhlcmUgaXMg
bm8gZXJyb3IgaW4gZGV2aWNlIHRyZWUuIE1haW4gbW90aXZhdGlvbiBpcyB0byBpbXByb3ZlDQo+
ID4gPiA+IGNvZGUgZm9yIGZvbGxvd2luZyByZWFzb25zOg0KPiA+ID4gPiAgIC0gV2hpbGUgY29k
ZSBzdHVkeSBpdCB3YXMgZm91bmQgdGhhdCBpZiBhIHJlc2VydmVkIGlycS1udW1iZXINCj4gPiA+
ID4gdXNlZCB0aGVuIHRoZXJlIGFyZSBubyBjaGVjayBpbiBkcml2ZXIuIGlycSB3aWxsIGJlIGNv
bmZpZ3VyZWQgYXMNCj4gPiA+ID4gY29ycmVjdCBhbmQgaW50ZXJydXB0IHdpbGwgbmV2ZXIgZmly
ZS4NCj4gPiA+DQo+ID4gPiBBZ2FpbiwgYSB3cm9uZyBpbnRlcnJ1cHQgbnVtYmVyIHdvbid0IGZp
cmUsIHdoZXRoZXIgYW4gaW50ZXJydXB0IGJ5DQo+ID4gPiB0aGF0IG51bWJlciBleGlzdHMgb3Ig
bm90LiAgSSB3b3VsZG4ndCBtaW5kIGEgc2FuaXR5IGNoZWNrIGluIHRoZQ0KPiA+ID4gZHJpdmVy
IGlmIHRoZSBwcm9ncmFtbWluZyBtb2RlbCBtYWRlIGl0IHByb3Blcmx5IGRpc2NvdmVyYWJsZSwg
YnV0IEkNCj4gPiA+IGRvbid0IHRoaW5rIGl0J3Mgd29ydGggbWVzc2luZyB3aXRoIGRldmljZSB0
cmVlcyBqdXN0IGZvciB0aGlzIChhbmQNCj4gPiA+IGV2ZW4gbGVzcyBzbyBnaXZlbiB0aGF0IHRo
ZXJlIGRvbid0IHNlZW0gdG8gYmUgbmV3IGNoaXBzIGNvbWluZyBvdXQNCj4gPiA+IHRoYXQgdGhp
cyB3b3VsZCBiZSByZWxldmFudCBmb3IpLg0KPiA+DQo+ID4gRmFpciBlbm91Z2gsIHdlIGNhbiB1
c2UgTVBJQyB2ZXJzaW9uIHRvIGRlZmluZSBzdXBwb3J0ZWQgaW50ZXJydXB0cw0KPiByYW5nZXMu
DQo+ID4gV2lsbCB0aGF0IGJlIGFjY2VwdGFibGUuDQo+IA0KPiBJdCdzIGJldHRlciB0aGFuIGRl
dmljZSB0cmVlIGNoYW5nZXMgYnV0IEknbSBub3QgY29udmluY2VkIGl0J3Mgd29ydGh3aGlsZSBq
dXN0DQo+IHRvIHN1cHByZXNzIHNvbWUgc2ltdWxhdG9yIHdhcm5pbmdzLg0KPiAgSWYgdGhlIHdh
cm5pbmdzIHJlYWxseSBib3RoZXIgeW91LCB5b3UNCj4gY2FuIHVzZSBwaWMtbm8tcmVzZXQgaW4g
dGhlIGRldmljZSB0cmVlIChhc3N1bWluZyB0aGlzIGlzbid0IHNvbWUgbmV3IGNoaXANCj4gdGhh
dCB5b3Ugd2FudCB0byBtYWtlIHN1cmUgZG9lc24ndCBmYWxsIG92ZXIgd2hlbiB0aGUgdXN1YWwg
bXBpYyBpbml0DQo+IGhhcHBlbnMpIGFuZC9vciBjb252aW5jZSB0aGUgaGFyZHdhcmUgcGVvcGxl
IHRvIG1ha2UgdGhlIGludGVyZmFjZQ0KPiBwcm9wZXJseSBkaXNjb3ZlcmFibGUgaW5jbHVkaW5n
IGRpc2NvbnRpZ3VvdXMgcmVnaW9ucyAoaWYgdGhlcmUgKmlzKiBzb21lDQo+IG5ldyBjaGlwIEkg
aGF2ZW4ndCBoZWFyZCBhYm91dCkuDQoNClRoZXJlIGlzIG5ldyBjaGlwIHVuZGVyIGRldmVsb3Bt
ZW50IGJhc2VkIG9uIGUyMDAsIHdoaWNoIHVzZXMgc2FtZSBtcGljIGFzIGluIG9sZGVyIFBvd2Vy
UEMgdmVyc2lvbnMuDQpUaGlzIHBhdGNoIHdhcyBub3QganVzdCBhYm91dCBzdXBwcmVzc2luZyB0
aGUgd2FybmluZyBidXQgd2FybmluZyB3YXMgdGhlIG9ic2VydmF0aW9uIHRoYXQgcmVzZXJ2ZWQg
cmVnaW9uIGlzIGdldHRpbmcgYWNjZXNzZWQgZHVyaW5nIGluaXQvdW5pbml0L3NhdmUvcmVzdG9y
ZS4gVGhpcyBwYXRjaCB3YXMganVzdCBhbiBtaW5vciBpbXByb3ZlbWVudCB0byBhdm9pZCB0aGVz
ZSBhY2Nlc3Nlcy4gV2Ugd2lsbCBkcm9wIHRoaXMgc2VyaWVzIGlmIHRoaXMgaW1wcm92ZW1lbnQg
aXMgbm90IGNvbnZpbmNpbmcuDQoNClRoYW5rcw0KLUJoYXJhdA0KDQo+IA0KPiAtU2NvdHQNCg0K