[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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.