[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] ns1650: refactor interrupt handling in ns16550_uart_dt_init()
On Thu, 2023-07-13 at 16:26 +0200, Jan Beulich wrote: > On 13.07.2023 15:36, Oleksii wrote: > > On Thu, 2023-07-13 at 15:27 +0200, Jan Beulich wrote: > > > I don't understand. My earlier comment was affecting all checks > > > of > > > uart->irq alike, as I'm unconvinced IRQ0 may not possibly be > > > usable > > > on some architecture / platform. IOW I don't see why the check in > > > ns16550_init_postirq() would allow us any leeway. > > It looks like I misunderstood you. > > > > Do you mean that on some architecture IRQ0 may be used for ns16550? > > Yes, I don't see why this shouldn't be possible in principle. As > Julien > said it can't happen on Arm, so if it also can't happen on RISC-V and > PPC, we could elect to continue to ignore that aspect. > Then for RISC-V ( at least, for PLIC interrupt controller ) it is reserved: https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc#interrupt-identifiers-ids What about to have 'define NO_IRQ_POLL 0' ( mentioned by Julien )+ assert(irq_from_device_tree != NO_IRQ_POLL) ? ~ Oleksii
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |