Re: [PATCH V2 1/2] tty: serial: qcom_geni_serial: IRQ cleanup

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

 



Quoting Akash Asthana (2019-10-11 00:39:06)
> 
> On 10/10/2019 7:49 PM, Stephen Boyd wrote:
> > Quoting Akash Asthana (2019-10-10 02:46:03)
> >> diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c
> >> index 14c6306..5180cd8 100644
> >> --- a/drivers/tty/serial/qcom_geni_serial.c
> >> +++ b/drivers/tty/serial/qcom_geni_serial.c
> >> @@ -1297,11 +1291,21 @@ static int qcom_geni_serial_probe(struct platform_device *pdev)
> >>          port->rx_fifo_depth = DEF_FIFO_DEPTH_WORDS;
> >>          port->tx_fifo_width = DEF_FIFO_WIDTH_BITS;
> >>   
> >> +       scnprintf(port->name, sizeof(port->name), "qcom_geni_serial_%s%d",
> >> +               (uart_console(uport) ? "console" : "uart"), uport->line);
> > Drop useless parenthesis. Also, it might make more sense to make this a
> > devm_kasprintf() call now.
> 
> OK
> 
> >>          irq = platform_get_irq(pdev, 0);
> >>          if (irq < 0)
> >>                  return irq;
> >>          uport->irq = irq;
> >>   
> >> +       irq_set_status_flags(uport->irq, IRQ_NOAUTOEN);
> > Is there a reason why we can't always leave the irq enabled and request
> > it later once the uart structure has been fully initialized?
> 
> According to current design we are requesting IRQ handler in probe, and 
> we enable and disable it from the startup(port open) and shutdown(port 
> close) function respectively.
> 
> We need to call for disable_irq in shutdown function because client has 
> closed the port and we don't expect any transfer requests after it.
> 
> >>request it later once the uart structure has been fully initialized?
> 
>      Is the ask is to move request irq later in probe after the uport is 
> fully initialized?

Yes I'm wondering if we can get rid of the IRQ_NOAUTOEN and
irq_enable/disable bits in here and leave the interrupt enabled all the
time.





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux