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

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


  • To: Oleksii <oleksii.kurochko@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 13 Jul 2023 14:25:33 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WGInQ63RH9BoVszkg+YVbqNi9E+CNcqXFnDAW7bqnzc=; b=YO4TSHUSNy/fJiPbiHSbqjmnQDm/4btOsc4p76StyKQB0La445ke2jduliBYMQx1N5pAHtW0KFNa1Ctya3Ow2Kom7sOKbbAIrYgnqD9Q1TubTKD6w3hCjOvMccBwmaxgGhuuV1mHubX8703x7SBYuulotI2RmHsN9AGcCYnJRROms/3iXiQNshMerHzKiwZnRY/JnPmi5Gk27Z3YoU8vtGsjgOv/Psp/85jcLet5Gogp1HSlA7/fXedElsnJlb0Awc/nxM7hKqNoVb4V1KySxcYACHtdOsLALpkIVrjk6Ax1jn9zoDh6ihf729wiUxctVzB1u/KSrDw2pdMf0ijByg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QldQrssk/g1Ii6ynhl8mPfdBXj0z2T6Xa+DXUgbGpB4y4MzZ1zmAI/pywDC5BdEph5YI4iqpD5fxElw3f4mUKPibSm+lopCprQ56Mzcma3juzbaKq7D6BYmBU9WkL0yYSNc41OewCzDR0YwgpUUe6dOa6EVzhWQKfxuKMr0G81h6IWrLY0l4HgiYIO91bl3c5DiueiGbAuTwr6SjNyv+3JZvLQDpGh0gIA0K5MRqEskXzXvsT/cEC3Ogfa3Y/RknmCL47uoVJ7axjLnFStLHmNaHqUIAWrTIwA0FgwlUZuI4w/MWfaq31gGhLngSfP6hqPcqmidZLuFFoqn5vyf0OQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Julien Grall <julien@xxxxxxx>
  • Delivery-date: Thu, 13 Jul 2023 12:25:48 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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



 


Rackspace

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