On Thu, Jan 6, 2022 at 5:29 PM Niklas Söderlund <niklas.soderlund@xxxxxxxxxxxx> wrote: > On 2022-01-05 19:25:25 +0000, Lad, Prabhakar wrote: > > On Wed, Jan 5, 2022 at 7:13 PM Niklas Söderlund > > <niklas.soderlund@xxxxxxxxxxxx> wrote: > > > On 2022-01-04 14:52:11 +0000, Lad Prabhakar wrote: ... > > > > + if (!irq || irq == -ENXIO) > > > > + break; > > > > > > This do not look correct and differs form v1. > > > > > > In the old code if we can't get an IRQ the loop is continued. This is > > > used to detect if interrupts are supported or not on the platform. This > > > change will fail on all systems that don't describes interrupts in DT > > > while the driver can function without interrupts. > > > > > There are no non-DT users for this driver. Do you see this driver > > being used in a non-DT environment in near future? > > No, maybe I was unclear sorry about that. What I intended to say was > that this change will break platforms that that make use of this driver > but do not describe interrupts in its DT description. As with this > change not describing interrupts is consider an error. > > For example checkout thermal@ffc48000 in arch/arm/boot/dts/r8a7779.dtsi. > > > Is there a reason you wish to do this change in addition to the switch > > > to platform_get_irq_optional()? If so I think that should be done in a > > > separate patch. > > > > > No other reason, It was suggested by Gerrt too to use a break instead > > of continue in v1. > > I think we need to keep the original behavior. I don't see how this can break those. Or are you stating that some of them are using board files with 0 as a valid (v)IRQ? -- With Best Regards, Andy Shevchenko
