[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] ns1650: refactor interrupt handling in ns16550_uart_dt_init()
On 13.07.2023 13:55, Oleksii wrote: > On Thu, 2023-07-13 at 11:13 +0100, Julien Grall wrote: >> Hi Jan, >> >> On 13/07/2023 11:08, Jan Beulich wrote: >>> On 13.07.2023 11:30, Oleksii Kurochko wrote: >>>> --- a/xen/drivers/char/ns16550.c >>>> +++ b/xen/drivers/char/ns16550.c >>>> @@ -1791,8 +1791,16 @@ static int __init >>>> ns16550_uart_dt_init(struct dt_device_node *dev, >>>> } >>>> >>>> res = platform_get_irq(dev, 0); >>>> - if ( ! res ) >>>> - return -EINVAL; >>>> + if ( res == -1 ) >>>> + { >>>> + printk("ns1650: polling will be used\n"); >>> >>> Nit: Please don't omit one of the two 5-s here. >>> >>>> + /* >>>> + * There is the check 'if ( uart->irq > 0 )' in >>>> ns16550_init_postirq(). >>>> + * If the check is true then interrupt mode will be used >>>> otherwise >>>> + * ( when irq = 0 )polling. >>>> + */ >>> >>> I wonder in how far that's actually correct outside of x86. On x86 >>> IRQ0 is >>> always the timer interrupt, but I'm not convinced something similar >>> can be >>> used as kind of a heuristic on Arm, RISC-V, or basically any other >>> architecture. >> >> I wondered the same. On Arm we are fine because the UART will be an >> SPI >> which starts at 32. >> >> That's part why I was suggesting to use a define. Because we don't >> have >> to hardcode the poll value everywhere. > Probably then it would be better to introduce 'bool is_polling_mode' > inside struct ns16550? Perhaps. If I was to make such a change, I'd probably convert intr_works to a tristate. But a boolean will be okay; if I may ask, name it just "polling" though. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |