On Fri, Nov 26, 2021 at 2:58 AM Geert Uytterhoeven [off-list ref] wrote:

Hi Jessica,

On Thu, Nov 25, 2021 at 5:08 PM Jessica Clarke [off-list ref] wrote:

quoted

On 25 Nov 2021, at 15:22, Geert Uytterhoeven [off-list ref] wrote:

quoted

To improve human readability and enable automatic validation, the tuples
in "interrupts-extended" properties should be grouped using angle
brackets.  As the DT bindings lack an upper bound on the number of
interrupts, thus assuming one, proper grouping is currently flagged as
an error.

Rob: Is this a bug in the tooling that should be fixed?

The grouping or upper bound? The tools default to minItems ==
maxItems, so you be getting 'maxItems: 1' here.

For grouping, I plan to make this not matter for validation. I'm
working on making the validation operate on dtbs and we lose any
source grouping with that. I'll probably switch the kernel to use dtbs
as well because I don't want to maintain both. Still, I think the
grouping is good from a source consistency POV.

Regardless, specifying a real upper limit is always a good idea.

Yes. A 'should be enough for now' limit is better than none IMO, too.

quoted

quoted

Fix this by adding the missing "maxItems", limiting it to 9 interrupts
(one interrupt for a system management core, and two interrupts per core
for other cores), which should be sufficient for now.

This is SiFive’s IP, so is this actually true? I would imagine it’s
just parameterised and could be generated with as many targets as fit
in the MMIO space, and that this is thus inaccurate. Besides, such a

Yes, this is implementation-defined.  I just used the maximum value
currently in use.

drivers/irqchip/irq-sifive-plic.c has #define MAX_CONTEXTS 15872,
which matches the value of CONTEXT_PER_HART and the available address
space in the driver and in [1].
Would you be more comfortable with "maxItems: 15872"?

Always good to have a real value rather than an unknown implementation limit.

Rob