[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: Fri, 14 Jul 2023 08:56:30 +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=GsOLB+E0eqbsGn9k6wi61DOmyWFBtrf71/o8iat64fA=; b=a8w9PBYT7Whbr/Gl4G/6esthXiudZS1K5KVAXTqT/JQZcEnoSPf5VqB+gkdDu8TxEfbSrsbIB24dWzJQ1nwK+NcPfeNPev5wUE8w4hZDL216vtniqzeO6fZ+lCsVDVMLueqr/ii6ndLXlgagSBhKf8RhZTTsYA7RdokbiFphsvQS+/shmfQQt9P4dHs76frW+buimixEzr4SfrJHTpQ7wqE9/U3P3gxYAUlxbDUYhdlHrnlYl447FM0Pv1pMFv9eXcsr+GT82/OU5pwY3TGTnSeDMk2MloBwx8byFhA/wccdAl+ijmkRvuFbWzUJmPdm4iWrwtcwFIE/RWjKjDrPYQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bn+S4urDe7l3KPug+tDjaXs7CgTvH9v9lZcPyzV9ZsOiXkD42Q8zumCqIxXMD9Up3ZNviIxWxJ7Ezu+iLbga5Hpl7b/jdXnQpNQXX73X0p5HCeEL558E+6D0XdnNnwnmESDtpuEP5oj2sIFm+vQtDl+FHkUGSSrTPNjCac/R85kt7suuZ9QwIWZsF+mvZiNxa5e9XJ7yQiae3VSQc6BDEgWqb4Q4nAIjwzCTn/burH/tG+8VGZU9iiRjc7PB3VBpBZ0NXcQI65xQI4ylInkL2uiYl3j9FjYD07a59OkshIYwgZfmiH1P80SSXaAdfSOnaaneBn9bhvgbpJBC3L+48g==
- 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: Fri, 14 Jul 2023 06:56:40 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 13.07.2023 19:49, Oleksii wrote:
> On Thu, 2023-07-13 at 16:26 +0200, Jan Beulich wrote:
>> On 13.07.2023 15:36, Oleksii wrote:
>>> On Thu, 2023-07-13 at 15:27 +0200, Jan Beulich wrote:
>>>> I don't understand. My earlier comment was affecting all checks
>>>> of
>>>> uart->irq alike, as I'm unconvinced IRQ0 may not possibly be
>>>> usable
>>>> on some architecture / platform. IOW I don't see why the check in
>>>> ns16550_init_postirq() would allow us any leeway.
>>> It looks like I misunderstood you.
>>>
>>> Do you mean that on some architecture IRQ0 may be used for ns16550?
>>
>> Yes, I don't see why this shouldn't be possible in principle. As
>> Julien
>> said it can't happen on Arm, so if it also can't happen on RISC-V and
>> PPC, we could elect to continue to ignore that aspect.
>>
> Then for RISC-V ( at least, for PLIC interrupt controller ) it is
> reserved:
> https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc#interrupt-identifiers-ids
>
> What about to have 'define NO_IRQ_POLL 0' ( mentioned by Julien )+
> assert(irq_from_device_tree != NO_IRQ_POLL) ?
Such a #define may be okay as long as indeed used consistently in all
places where it belongs (which may mean making some code less simple,
which is a downside), but I can't judge at all the validity of the
assertion you propose.
Jan
|
