Messages in this thread | | | From | Bharat Bhushan <> | Subject | RE: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020 | Date | Thu, 9 Aug 2018 03:28:07 +0000 |
| |
> -----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
| |