On Sun, 31 Oct 2021 15:00:38 +0200 Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > On Sun, Oct 31, 2021 at 11:15 AM Lars-Peter Clausen <lars@xxxxxxxxxx> wrote: > > On 10/31/21 9:54 AM, Andy Shevchenko wrote: > > > On Sunday, October 31, 2021, Lars-Peter Clausen <lars@xxxxxxxxxx > > > <mailto:lars@xxxxxxxxxx>> wrote: > > ... > > > > - if (trig->subirq_base) { > > > + if (trig->subirq_base > 0) { > > > > > > >= ? > > > > I don't know. 0 is not supposed to be a valid irq number. And we > > kzalloc() the struct, so if it hasn't been explicitly initialized we'd > > get 0. > > But it will change the behaviour of the code. > >=0 is the opposite of replacing < 0. > > > > The way the code is at the moment we'd never end up here without calling > > irq_alloc_descs(), so it is either a valid irq or a negative error code > > and I can see why you might want to use >= for consistency and symmetry. > > Right! > > (But on some architectures and cases 0 might be a valid vIRQ) > Given I'm fairly sure this will be after any other irqs we should be fine but I don't think it would be a problem to allow 0. If that's fine with both of you I can just change it to >= 0 whilst applying, or Lars can do a v2 when has time. Thanks, Jonathan
