[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] ns1650: refactor interrupt handling in ns16550_uart_dt_init()



Hi Julien,

On Thu, 2023-07-13 at 10:43 +0100, Julien Grall wrote:
> Hi Oleksii,
> 
> Title: IMO, Your patch doesn't do any refactor. Instead, it add
> support 
> for polling when using the DT.
Agree. It would be better to rephrase the title.

> 
> On 13/07/2023 10:30, Oleksii Kurochko wrote:
> > In ns16550_init_postirq() there is the following check:
> >      if ( uart->irq > 0 )
> >      {
> >          uart->irqaction.handler = ns16550_interrupt;
> >          uart->irqaction.name    = "ns16550";
> >          uart->irqaction.dev_id  = port;
> >          if ( (rc = setup_irq(uart->irq, 0, &uart->irqaction)) != 0
> > )
> >              printk("ERROR: Failed to allocate ns16550 IRQ %d\n",
> > uart->irq);
> >      }
> > 
> > Thereby to have ns16550 work in polling mode uart->irq, should be
> > equal to 0.
> > 
> > So it is needed to relax the following check in
> > ns16550_uart_dt_init():
> >      res = platform_get_irq(dev, 0);
> >      if ( ! res )
> >          return -EINVAL;
> >      uart->irq = res;
> > If 'res' equals to -1 then polling mode should be used instead of
> > return
> > -EINVAL.
> 
> This commit message has a bit too much code in it for me taste. I
> don't 
> think it is necessary to quote the code. Instead, you can explain the
> following:
> 
>   * Why you want to support polling
>   * Why this is valid to have a node without interrupts (add a
> reference 
> to the bindings)
>   * That polling is indicated by using 'irq = 0'. I would consider to
> provide a define (e.g NO_IRQ_POLL) to make it more clearer.
Thanks. I'll update the commit message.

> 
> > 
> > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
> > ---
> >   xen/drivers/char/ns16550.c | 12 ++++++++++--
> >   1 file changed, 10 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/drivers/char/ns16550.c
> > b/xen/drivers/char/ns16550.c
> > index 2aed6ec707..f30f10d175 100644
> > --- 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 )
> 
> Why do you check explicitely for -1 instead of < 0? Also, the
> behavior 
> is somewhat change now.
I checked it for -1 as I missed that platform_get_irq() returns 'int'
and uart->irq is also 'int'. 'irq' variable inside plaform_get_irq is
declared as 'unsigned int', so I thought that in case of 'interrupt'
property is processed successfully we will have some positive value
otherwise platform_get_irq() returns -1 ( in current implementation ).
So it would be better to check for " res < 0 ".

>  Before, we would return -EINVAL when res equals 
> 0. Can you explain in the commit message why this is done?
This is not clear for me.
It was done during replacing of dt_device_get_irq by platform_get_irq
( 
https://gitlab.com/xen-project/xen/-/commit/554cbe32381fa4482e1a47cd31afb054e97d986d
) and for other similar cases it was changed to "res < 0" except
ns16550 driver.

> 
> > +    {
> > +        printk("ns1650: polling will be used\n");
> > +        /*
> > +         * 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.
> > +         */
> 
> Similar remark to the commit message. You could write:
> 
> "If the node doesn't have any interrupt, then it means the driver
> will 
> want to using polling."
Thanks. I'll take into account.
> 
> > +        res = 0;
> > +    }
> >       uart->irq = res;
> >   
> >       uart->dw_usr_bsy = dt_device_is_compatible(dev, "snps,dw-apb-
> > uart");
> 
> Cheers,
> 

~ Oleksii




 


Rackspace

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