On 19.05.2025 17:19, Oleksii Kurochko wrote: > On 5/15/25 10:42 AM, Jan Beulich wrote: >> On 06.05.2025 18:51, Oleksii Kurochko wrote: >>> --- /dev/null >>> +++ b/xen/arch/riscv/include/asm/imsic.h >>> @@ -0,0 +1,65 @@ >>> +/* SPDX-License-Identifier: MIT */ >>> + >>> +/* >>> + * xen/arch/riscv/imsic.h >>> + * >>> + * RISC-V Incoming MSI Controller support >>> + * >>> + * (c) 2023 Microchip Technology Inc. >>> + */ >>> + >>> +#ifndef ASM__RISCV__IMSIC_H >>> +#define ASM__RISCV__IMSIC_H >>> + >>> +#include <xen/types.h> >>> + >>> +#define IMSIC_MMIO_PAGE_SHIFT 12 >>> +#define IMSIC_MMIO_PAGE_SZ (1UL << IMSIC_MMIO_PAGE_SHIFT) >>> + >>> +#define IMSIC_MIN_ID 63 >> This isn't the "minimum ID", but the "minimum permissible number of IDs" as >> per >> its first use in imsic_parse_node(). Further uses there consider it a mask, >> which makes me wonder whether the imsic_cfg.nr_ids field name is actually >> correct: Isn't this the maximum valid ID rather than their count/number? > > imsic_cfg.nr_ids it is a value of interrupt identities supported by IMSIC > interrupt file according to > DT binding: > riscv,num-ids: > $ref: /schemas/types.yaml#/definitions/uint32 > minimum: 63 > maximum: 2047 > description: > Number of interrupt identities supported by IMSIC interrupt file.
Unless this count accounts for 0 being invalid (and hence isn't counted), I'm still confused: With the maximum value this would mean 2046 is still valid, but 2047 isn't anymore. When normally such a boundary would be at an exact power of 2, i.e. between 2047 and 2048 here. Jan
