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.
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.
Group the tuples in the example.
Signed-off-by: Geert Uytterhoeven <[email protected]>
---
.../interrupt-controller/sifive,plic-1.0.0.yaml | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
index 08d5a57ce00ff446..198b373f984f3438 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
@@ -61,6 +61,7 @@ properties:
interrupts-extended:
minItems: 1
+ maxItems: 9
description:
Specifies which contexts are connected to the PLIC, with "-1" specifying
that a context is not present. Each node pointed to should be a
@@ -89,12 +90,11 @@ examples:
#interrupt-cells = <1>;
compatible = "sifive,fu540-c000-plic", "sifive,plic-1.0.0";
interrupt-controller;
- interrupts-extended = <
- &cpu0_intc 11
- &cpu1_intc 11 &cpu1_intc 9
- &cpu2_intc 11 &cpu2_intc 9
- &cpu3_intc 11 &cpu3_intc 9
- &cpu4_intc 11 &cpu4_intc 9>;
+ interrupts-extended = <&cpu0_intc 11>,
+ <&cpu1_intc 11>, <&cpu1_intc 9>,
+ <&cpu2_intc 11>, <&cpu2_intc 9>,
+ <&cpu3_intc 11>, <&cpu3_intc 9>,
+ <&cpu4_intc 11>, <&cpu4_intc 9>;
reg = <0xc000000 0x4000000>;
riscv,ndev = <10>;
};
--
2.25.1
On 25 Nov 2021, at 15:22, Geert Uytterhoeven <[email protected]> wrote:
>
> 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.
>
> 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
function change should be made separately from the grouping change.
The same goes for your equivalent sifive,clint0 patch.
Jess
> Group the tuples in the example.
>
> Signed-off-by: Geert Uytterhoeven <[email protected]>
> ---
> .../interrupt-controller/sifive,plic-1.0.0.yaml | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> index 08d5a57ce00ff446..198b373f984f3438 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> @@ -61,6 +61,7 @@ properties:
>
> interrupts-extended:
> minItems: 1
> + maxItems: 9
> description:
> Specifies which contexts are connected to the PLIC, with "-1" specifying
> that a context is not present. Each node pointed to should be a
> @@ -89,12 +90,11 @@ examples:
> #interrupt-cells = <1>;
> compatible = "sifive,fu540-c000-plic", "sifive,plic-1.0.0";
> interrupt-controller;
> - interrupts-extended = <
> - &cpu0_intc 11
> - &cpu1_intc 11 &cpu1_intc 9
> - &cpu2_intc 11 &cpu2_intc 9
> - &cpu3_intc 11 &cpu3_intc 9
> - &cpu4_intc 11 &cpu4_intc 9>;
> + interrupts-extended = <&cpu0_intc 11>,
> + <&cpu1_intc 11>, <&cpu1_intc 9>,
> + <&cpu2_intc 11>, <&cpu2_intc 9>,
> + <&cpu3_intc 11>, <&cpu3_intc 9>,
> + <&cpu4_intc 11>, <&cpu4_intc 9>;
> reg = <0xc000000 0x4000000>;
> riscv,ndev = <10>;
> };
> --
> 2.25.1
>
>
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
Hi Jessica,
On Thu, Nov 25, 2021 at 5:08 PM Jessica Clarke <[email protected]> wrote:
> On 25 Nov 2021, at 15:22, Geert Uytterhoeven <[email protected]> wrote:
> > 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?
Regardless, specifying a real upper limit is always a good idea.
> > 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"?
Or do you prefer setting the maximum based on the compatible value
(2 for k210, 9 for fu540, 4 for jh7100[2])?
> function change should be made separately from the grouping change.
OK, will split in v2.
> The same goes for your equivalent sifive,clint0 patch.
OK.
> > Group the tuples in the example.
> >
> > Signed-off-by: Geert Uytterhoeven <[email protected]>
> > ---
> > .../interrupt-controller/sifive,plic-1.0.0.yaml | 12 ++++++------
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> > index 08d5a57ce00ff446..198b373f984f3438 100644
> > --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> > @@ -61,6 +61,7 @@ properties:
> >
> > interrupts-extended:
> > minItems: 1
> > + maxItems: 9
> > description:
> > Specifies which contexts are connected to the PLIC, with "-1" specifying
> > that a context is not present. Each node pointed to should be a
[1] https://static.dev.sifive.com/U54-MC-RVCoreIP.pdf
[2] The PLIC memory map in
https://github.com/starfive-tech/JH7100_Docs/blob/main/vic_u7_manual_with_creativecommons.pdf
indicate other values of ENABLE_PER_HART and CONTEXT_PER_HART?
Is memory the map correct?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, Nov 26, 2021 at 2:28 PM Geert Uytterhoeven <[email protected]> wrote:
>
> Hi Jessica,
>
> On Thu, Nov 25, 2021 at 5:08 PM Jessica Clarke <[email protected]> wrote:
> > On 25 Nov 2021, at 15:22, Geert Uytterhoeven <[email protected]> wrote:
> > > 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?
> Regardless, specifying a real upper limit is always a good idea.
>
> > > 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"?
> Or do you prefer setting the maximum based on the compatible value
> (2 for k210, 9 for fu540, 4 for jh7100[2])?
Yes, 15872 is an appropriate value for "maxItems".
Regards,
Anup
>
> > function change should be made separately from the grouping change.
>
> OK, will split in v2.
>
> > The same goes for your equivalent sifive,clint0 patch.
>
> OK.
>
> > > Group the tuples in the example.
> > >
> > > Signed-off-by: Geert Uytterhoeven <[email protected]>
> > > ---
> > > .../interrupt-controller/sifive,plic-1.0.0.yaml | 12 ++++++------
> > > 1 file changed, 6 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> > > index 08d5a57ce00ff446..198b373f984f3438 100644
> > > --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> > > +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> > > @@ -61,6 +61,7 @@ properties:
> > >
> > > interrupts-extended:
> > > minItems: 1
> > > + maxItems: 9
> > > description:
> > > Specifies which contexts are connected to the PLIC, with "-1" specifying
> > > that a context is not present. Each node pointed to should be a
>
> [1] https://static.dev.sifive.com/U54-MC-RVCoreIP.pdf
> [2] The PLIC memory map in
> https://github.com/starfive-tech/JH7100_Docs/blob/main/vic_u7_manual_with_creativecommons.pdf
> indicate other values of ENABLE_PER_HART and CONTEXT_PER_HART?
> Is memory the map correct?
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
On Fri, Nov 26, 2021 at 2:58 AM Geert Uytterhoeven <[email protected]> wrote:
>
> Hi Jessica,
>
> On Thu, Nov 25, 2021 at 5:08 PM Jessica Clarke <[email protected]> wrote:
> > On 25 Nov 2021, at 15:22, Geert Uytterhoeven <[email protected]> wrote:
> > > 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.
>
> > > 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