> -----Original Message----- > From: Scott Wood [mailto:oss@xxxxxxxxxxxx] > Sent: Wednesday, August 8, 2018 11:27 PM > To: Bharat Bhushan <bharat.bhushan@xxxxxxx>; > benh@xxxxxxxxxxxxxxxxxxx; paulus@xxxxxxxxx; mpe@xxxxxxxxxxxxxx; > galak@xxxxxxxxxxxxxxxxxxx; mark.rutland@xxxxxxx; > kstewart@xxxxxxxxxxxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; > devicetree@xxxxxxxxxxxxxxx; linuxppc-dev@xxxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx > Cc: robh@xxxxxxxxxx; keescook@xxxxxxxxxxxx; tyreld@xxxxxxxxxxxxxxxxxx; > joe@xxxxxxxxxxx > 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@xxxxxxxxxxxx] > > > Sent: Wednesday, August 8, 2018 11:26 AM > > > To: Bharat Bhushan <bharat.bhushan@xxxxxxx>; > > > benh@xxxxxxxxxxxxxxxxxxx; paulus@xxxxxxxxx; mpe@xxxxxxxxxxxxxx; > > > galak@xxxxxxxxxxxxxxxxxxx; mark.rutland@xxxxxxx; > > > kstewart@xxxxxxxxxxxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; > > > devicetree@xxxxxxxxxxxxxxx; linuxppc-dev@xxxxxxxxxxxxxxxx; linux- > > > kernel@xxxxxxxxxxxxxxx > > > Cc: robh@xxxxxxxxxx; keescook@xxxxxxxxxxxx; > > > tyreld@xxxxxxxxxxxxxxxxxx; joe@xxxxxxxxxxx > > > 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@xxxxxxxxxxxx] > > > > > Sent: Wednesday, August 8, 2018 2:44 AM > > > > > To: Bharat Bhushan <bharat.bhushan@xxxxxxx>; > > > > > benh@xxxxxxxxxxxxxxxxxxx; paulus@xxxxxxxxx; mpe@xxxxxxxxxxxxxx; > > > > > galak@xxxxxxxxxxxxxxxxxxx; mark.rutland@xxxxxxx; > > > > > kstewart@xxxxxxxxxxxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; > > > > > devicetree@xxxxxxxxxxxxxxx; linuxppc-dev@xxxxxxxxxxxxxxxx; > > > > > linux- kernel@xxxxxxxxxxxxxxx > > > > > Cc: robh@xxxxxxxxxx; keescook@xxxxxxxxxxxx; > > > > > tyreld@xxxxxxxxxxxxxxxxxx; joe@xxxxxxxxxxx > > > > > 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 ��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
