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

[Akash Asthana <akashast@codeaurora.org>]

On 10/16/2019 1:41 AM, Stephen Boyd wrote:
> 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.

Ideally it should work, I will run few experiments to make sure there 
isn't any spurious interrupts problem after port close is called.

If it works, I will post a separate patch for it.

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na Linux Foundation Collaborative Project