[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v4 1/1] ns16550: add support for polling mode when device tree is used
On Mon, 2023-07-31 at 15:24 +0200, Jan Beulich wrote: > On 27.07.2023 18:45, Oleksii Kurochko wrote: > > @@ -654,6 +674,9 @@ static void ns16550_init_common(struct ns16550 > > *uart) > > > > /* Default lsr_mask = UART_LSR_THRE */ > > uart->lsr_mask = UART_LSR_THRE; > > + > > + if ( strstr(opt_com1, "poll") || strstr(opt_com2, "poll") ) > > + uart->intr_works = polling; > > } > > A non-__init function may not reference __initdata objects. But > strstr() > is too lax anyway, and you also shouldn't check the wrong port's > options. > You want to recognize "poll" _only_ where all other command line > options > are processed. Just to confirm, do you mean that I should use parse_positional() ( or something similar ) for the device-tree method of initializing ns16550? I checked the polling behavior as described above because parse_positional() is utilized solely for X86. It appears that command line options are parsed only in the case of x86. > > Also may I remind you that extending command line options requires > their > doc to also be updated? Thank you for the reminder. It seems I misunderstood which doc I need to update. I believed you were referring to the comment above the declaration of opt_com1[]. I think you meant xen-command-line.pandoc. > > > @@ -1333,9 +1356,13 @@ pci_uart_config(struct ns16550 *uart, bool_t > > skip_amt, unsigned int idx) > > uart->irq = 0; > > #endif > > if ( !uart->irq ) > > + { > > + uart->intr_works = polling; > > + > > printk(XENLOG_INFO > > "ns16550: %pp: no legacy IRQ, using > > poll mode\n", > > &PCI_SBDF(0, b, d, f)); > > + } > > I'm okay to leave it at this for now, since this way at least nothing > regresses that was working before. I'm not convinced this is all > correct, but that's a largely separate (and pre-existing) issue then. > > > @@ -1791,8 +1808,11 @@ static int __init > > ns16550_uart_dt_init(struct dt_device_node *dev, > > } > > > > res = platform_get_irq(dev, 0); > > - if ( ! res ) > > - return -EINVAL; > > + if ( res < 0 ) > > + { > > + printk("there is no interrupt property, polling will be > > used\n"); > > + uart->intr_works = polling; > > + } > > uart->irq = res; > > Shouldn't you avoid writing uart->irq when res is negative? I think you are right, and I missed that. I'll update it in a new patch version. ~ Oleksii
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |