All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Anup Patel <anup@brainfault.org>
Cc: Anup Patel <anup.patel@wdc.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Palmer Dabbelt <palmerdabbelt@google.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marc Zyngier <maz@kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Atish Patra <atish.patra@wdc.com>,
	Alistair Francis <Alistair.Francis@wdc.com>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	"linux-kernel@vger.kernel.org List"
	<linux-kernel@vger.kernel.org>, DTML <devicetree@vger.kernel.org>,
	Bin Meng <bmeng.cn@gmail.com>
Subject: Re: [RFC PATCH v3 05/11] dt-bindings: interrupt-controller: Add ACLINT MSWI and SSWI bindings
Date: Tue, 7 Sep 2021 08:48:04 -0500	[thread overview]
Message-ID: <CAL_JsqLXnYAGY5yqVkazeVdUgOtbbOZ2DMCU0_O892suYA4d-w@mail.gmail.com> (raw)
In-Reply-To: <CAAhSdy1NBNTQ5F=4MjjwLb4k_kGgB9j5iFxJ6qoGSCuGkn=66g@mail.gmail.com>

On Fri, Sep 3, 2021 at 5:40 AM Anup Patel <anup@brainfault.org> wrote:
>
> On Thu, Sep 2, 2021 at 6:04 AM Rob Herring <robh@kernel.org> wrote:
> >
> > On Wed, Sep 1, 2021 at 6:56 AM Anup Patel <anup@brainfault.org> wrote:
> > >
> > > On Wed, Sep 1, 2021 at 6:54 AM Rob Herring <robh@kernel.org> wrote:
> > > >
> > > > On Mon, Aug 30, 2021 at 09:47:23AM +0530, Anup Patel wrote:
> > > > > We add DT bindings documentation for the ACLINT MSWI and SSWI
> > > > > devices found on RISC-V SOCs.
> > > > >
> > > > > Signed-off-by: Anup Patel <anup.patel@wdc.com>
> > > > > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> > > > > ---
> > > > >  .../riscv,aclint-swi.yaml                     | 95 +++++++++++++++++++
> > > > >  1 file changed, 95 insertions(+)
> > > > >  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/riscv,aclint-swi.yaml
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,aclint-swi.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,aclint-swi.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..68563259ae24
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,aclint-swi.yaml
> > > > > @@ -0,0 +1,95 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/interrupt-controller/riscv,aclint-swi.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: RISC-V ACLINT Software Interrupt Devices
> > > > > +
> > > > > +maintainers:
> > > > > +  - Anup Patel <anup.patel@wdc.com>
> > > > > +
> > > > > +description:
> > > > > +  RISC-V SOCs include an implementation of the M-level software interrupt
> > > > > +  (MSWI) device and the S-level software interrupt (SSWI) device defined
> > > > > +  in the RISC-V Advanced Core Local Interruptor (ACLINT) specification.
> > > > > +
> > > > > +  The ACLINT MSWI and SSWI devices are documented in the RISC-V ACLINT
> > > > > +  specification located at
> > > > > +  https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc.
> > > > > +
> > > > > +  The ACLINT MSWI and SSWI devices directly connect to the M-level and
> > > > > +  S-level software interrupt lines of various HARTs (or CPUs) respectively
> > > > > +  so the RISC-V per-HART (or per-CPU) local interrupt controller is the
> > > > > +  parent interrupt controller for the ACLINT MSWI and SSWI devices.
> > > > > +
> > > > > +allOf:
> > > > > +  - $ref: /schemas/interrupt-controller.yaml#
> > > > > +
> > > > > +properties:
> > > > > +  compatible:
> > > > > +    oneOf:
> > > > > +      - items:
> > > > > +        - enum:
> > > > > +          - riscv,aclint-mswi
> > > > > +
> > > > > +      - items:
> > > > > +        - enum:
> > > > > +          - riscv,aclint-sswi
> > > >
> > > > All this can be just:
> > > >
> > > > enum:
> > > >   - riscv,aclint-mswi
> > > >   - riscv,aclint-sswi
> > > >
> > > > However...
> > > >
> > > > > +
> > > > > +    description:
> > > > > +      For ACLINT MSWI devices, it should be "riscv,aclint-mswi" OR
> > > > > +      "<vendor>,<chip>-aclint-mswi".
> > > > > +      For ACLINT SSWI devices, it should be "riscv,aclint-sswi" OR
> > > > > +      "<vendor>,<chip>-aclint-sswi".
> > > >
> > > > s/OR/AND/
> > > >
> > > > There must be a compatible for the implementation. Unless RiscV
> > > > implementations of specs are complete describing all clocks, power
> > > > domains, resets, etc. and are quirk free.
> > > >
> > > > But don't write free form constraints...
> > >
> > > It is possible that quite a few implementations (QEMU, FPGAs, and
> > > other simulators) will not require implementation specific compatible
> > > strings. Should we still mandate implementation specific compatible
> > > strings in DTS for such cases?
> >
> > No, but the schema says you only have those cases. Are there not any
> > actual implementations?
>
> All existing RISC-V boards have SiFive CLINT and ACLINT is backward
> compatible with SiFive CLINT so we do have actual implementations.

So there's a SiFive compatible you can add here?

> None of the existing RISC-V boards have special clocks, power domain,
> resets etc for these devices.
>
> >
> > Minimally make "<vendor>,<chip>-aclint-mswi" into a schema pattern for
> > the first entry and perhaps a note to replace with actual strings when
> > there are some. It's ultimately up to the RiscV maintainers to require
> > SoC specific compatibles here. Allowing a generic one alone makes that
> > harder because the schema can't enforce it.
>
> Can we have a common compatible string for QEMU, FPGAs, etc ?
>
> For example,
> compatible = "riscv,generic-aclint-mswi", "riscv,aclint-mswi";

This is not any better than just allowing "riscv,aclint-mswi" by
itself as someone could just use the above strings on their new
implementation to avoid warnings.

You could just not worry about the QEMU and FPGA cases. FPGAs are
probably not upstream and if they are, don't they need specific
compatibles tied to versions of FPGA images? QEMU generating its own
DT doesn't run schema validation though that could change. I'm looking
at enabling schema validation at runtime for purposes of firmware
testing and with that QEMU generated DT may be something we test.

Rob

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Anup Patel <anup@brainfault.org>
Cc: Anup Patel <anup.patel@wdc.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	 Palmer Dabbelt <palmerdabbelt@google.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	 Thomas Gleixner <tglx@linutronix.de>,
	Marc Zyngier <maz@kernel.org>,
	 Daniel Lezcano <daniel.lezcano@linaro.org>,
	Atish Patra <atish.patra@wdc.com>,
	 Alistair Francis <Alistair.Francis@wdc.com>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	 "linux-kernel@vger.kernel.org List"
	<linux-kernel@vger.kernel.org>, DTML <devicetree@vger.kernel.org>,
	Bin Meng <bmeng.cn@gmail.com>
Subject: Re: [RFC PATCH v3 05/11] dt-bindings: interrupt-controller: Add ACLINT MSWI and SSWI bindings
Date: Tue, 7 Sep 2021 08:48:04 -0500	[thread overview]
Message-ID: <CAL_JsqLXnYAGY5yqVkazeVdUgOtbbOZ2DMCU0_O892suYA4d-w@mail.gmail.com> (raw)
In-Reply-To: <CAAhSdy1NBNTQ5F=4MjjwLb4k_kGgB9j5iFxJ6qoGSCuGkn=66g@mail.gmail.com>

On Fri, Sep 3, 2021 at 5:40 AM Anup Patel <anup@brainfault.org> wrote:
>
> On Thu, Sep 2, 2021 at 6:04 AM Rob Herring <robh@kernel.org> wrote:
> >
> > On Wed, Sep 1, 2021 at 6:56 AM Anup Patel <anup@brainfault.org> wrote:
> > >
> > > On Wed, Sep 1, 2021 at 6:54 AM Rob Herring <robh@kernel.org> wrote:
> > > >
> > > > On Mon, Aug 30, 2021 at 09:47:23AM +0530, Anup Patel wrote:
> > > > > We add DT bindings documentation for the ACLINT MSWI and SSWI
> > > > > devices found on RISC-V SOCs.
> > > > >
> > > > > Signed-off-by: Anup Patel <anup.patel@wdc.com>
> > > > > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> > > > > ---
> > > > >  .../riscv,aclint-swi.yaml                     | 95 +++++++++++++++++++
> > > > >  1 file changed, 95 insertions(+)
> > > > >  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/riscv,aclint-swi.yaml
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,aclint-swi.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,aclint-swi.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..68563259ae24
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,aclint-swi.yaml
> > > > > @@ -0,0 +1,95 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/interrupt-controller/riscv,aclint-swi.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: RISC-V ACLINT Software Interrupt Devices
> > > > > +
> > > > > +maintainers:
> > > > > +  - Anup Patel <anup.patel@wdc.com>
> > > > > +
> > > > > +description:
> > > > > +  RISC-V SOCs include an implementation of the M-level software interrupt
> > > > > +  (MSWI) device and the S-level software interrupt (SSWI) device defined
> > > > > +  in the RISC-V Advanced Core Local Interruptor (ACLINT) specification.
> > > > > +
> > > > > +  The ACLINT MSWI and SSWI devices are documented in the RISC-V ACLINT
> > > > > +  specification located at
> > > > > +  https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc.
> > > > > +
> > > > > +  The ACLINT MSWI and SSWI devices directly connect to the M-level and
> > > > > +  S-level software interrupt lines of various HARTs (or CPUs) respectively
> > > > > +  so the RISC-V per-HART (or per-CPU) local interrupt controller is the
> > > > > +  parent interrupt controller for the ACLINT MSWI and SSWI devices.
> > > > > +
> > > > > +allOf:
> > > > > +  - $ref: /schemas/interrupt-controller.yaml#
> > > > > +
> > > > > +properties:
> > > > > +  compatible:
> > > > > +    oneOf:
> > > > > +      - items:
> > > > > +        - enum:
> > > > > +          - riscv,aclint-mswi
> > > > > +
> > > > > +      - items:
> > > > > +        - enum:
> > > > > +          - riscv,aclint-sswi
> > > >
> > > > All this can be just:
> > > >
> > > > enum:
> > > >   - riscv,aclint-mswi
> > > >   - riscv,aclint-sswi
> > > >
> > > > However...
> > > >
> > > > > +
> > > > > +    description:
> > > > > +      For ACLINT MSWI devices, it should be "riscv,aclint-mswi" OR
> > > > > +      "<vendor>,<chip>-aclint-mswi".
> > > > > +      For ACLINT SSWI devices, it should be "riscv,aclint-sswi" OR
> > > > > +      "<vendor>,<chip>-aclint-sswi".
> > > >
> > > > s/OR/AND/
> > > >
> > > > There must be a compatible for the implementation. Unless RiscV
> > > > implementations of specs are complete describing all clocks, power
> > > > domains, resets, etc. and are quirk free.
> > > >
> > > > But don't write free form constraints...
> > >
> > > It is possible that quite a few implementations (QEMU, FPGAs, and
> > > other simulators) will not require implementation specific compatible
> > > strings. Should we still mandate implementation specific compatible
> > > strings in DTS for such cases?
> >
> > No, but the schema says you only have those cases. Are there not any
> > actual implementations?
>
> All existing RISC-V boards have SiFive CLINT and ACLINT is backward
> compatible with SiFive CLINT so we do have actual implementations.

So there's a SiFive compatible you can add here?

> None of the existing RISC-V boards have special clocks, power domain,
> resets etc for these devices.
>
> >
> > Minimally make "<vendor>,<chip>-aclint-mswi" into a schema pattern for
> > the first entry and perhaps a note to replace with actual strings when
> > there are some. It's ultimately up to the RiscV maintainers to require
> > SoC specific compatibles here. Allowing a generic one alone makes that
> > harder because the schema can't enforce it.
>
> Can we have a common compatible string for QEMU, FPGAs, etc ?
>
> For example,
> compatible = "riscv,generic-aclint-mswi", "riscv,aclint-mswi";

This is not any better than just allowing "riscv,aclint-mswi" by
itself as someone could just use the above strings on their new
implementation to avoid warnings.

You could just not worry about the QEMU and FPGA cases. FPGAs are
probably not upstream and if they are, don't they need specific
compatibles tied to versions of FPGA images? QEMU generating its own
DT doesn't run schema validation though that could change. I'm looking
at enabling schema validation at runtime for purposes of firmware
testing and with that QEMU generated DT may be something we test.

Rob

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2021-09-07 13:48 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-30  4:17 [RFC PATCH v3 00/11] Linux RISC-V ACLINT Support Anup Patel
2021-08-30  4:17 ` Anup Patel
2021-08-30  4:17 ` [RFC PATCH v3 01/11] RISC-V: Clear SIP bit only when using SBI IPI operations Anup Patel
2021-08-30  4:17   ` Anup Patel
2021-08-30  4:17 ` [RFC PATCH v3 02/11] RISC-V: Treat IPIs as normal Linux IRQs Anup Patel
2021-08-30  4:17   ` Anup Patel
2021-08-30  4:17 ` [RFC PATCH v3 03/11] RISC-V: Allow marking IPIs as suitable for remote FENCEs Anup Patel
2021-08-30  4:17   ` Anup Patel
2021-08-30  4:17 ` [RFC PATCH v3 04/11] RISC-V: Use IPIs for remote TLB flush when possible Anup Patel
2021-08-30  4:17   ` Anup Patel
2021-08-30  4:17 ` [RFC PATCH v3 05/11] dt-bindings: interrupt-controller: Add ACLINT MSWI and SSWI bindings Anup Patel
2021-08-30  4:17   ` Anup Patel
2021-09-01  1:24   ` Rob Herring
2021-09-01  1:24     ` Rob Herring
2021-09-01 11:56     ` Anup Patel
2021-09-01 11:56       ` Anup Patel
2021-09-02  0:33       ` Rob Herring
2021-09-02  0:33         ` Rob Herring
2021-09-03 10:40         ` Anup Patel
2021-09-03 10:40           ` Anup Patel
2021-09-07 13:48           ` Rob Herring [this message]
2021-09-07 13:48             ` Rob Herring
2021-08-30  4:17 ` [RFC PATCH v3 06/11] dt-bindings: timer: Update SiFive CLINT bindings for IPI support Anup Patel
2021-08-30  4:17   ` Anup Patel
2021-09-01  1:29   ` Rob Herring
2021-09-01  1:29     ` Rob Herring
2021-09-01 12:00     ` Anup Patel
2021-09-01 12:00       ` Anup Patel
2021-09-02  0:18       ` Rob Herring
2021-09-02  0:18         ` Rob Herring
2021-09-02  5:37         ` Anup Patel
2021-09-02  5:37           ` Anup Patel
2021-08-30  4:17 ` [RFC PATCH v3 07/11] irqchip: Add ACLINT software interrupt driver Anup Patel
2021-08-30  4:17   ` Anup Patel
2021-08-30  4:17 ` [RFC PATCH v3 08/11] RISC-V: Select ACLINT SWI driver for virt machine Anup Patel
2021-08-30  4:17   ` Anup Patel
2021-08-30  4:17 ` [RFC PATCH v3 09/11] dt-bindings: timer: Add ACLINT MTIMER bindings Anup Patel
2021-08-30  4:17   ` Anup Patel
2021-09-01  1:31   ` Rob Herring
2021-09-01  1:31     ` Rob Herring
2021-08-30  4:17 ` [RFC PATCH v3 10/11] clocksource: clint: Add support for ACLINT MTIMER device Anup Patel
2021-08-30  4:17   ` Anup Patel
2021-08-30  4:17 ` [RFC PATCH v3 11/11] MAINTAINERS: Add entry for RISC-V ACLINT drivers Anup Patel
2021-08-30  4:17   ` Anup Patel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAL_JsqLXnYAGY5yqVkazeVdUgOtbbOZ2DMCU0_O892suYA4d-w@mail.gmail.com \
    --to=robh@kernel.org \
    --cc=Alistair.Francis@wdc.com \
    --cc=anup.patel@wdc.com \
    --cc=anup@brainfault.org \
    --cc=atish.patra@wdc.com \
    --cc=bmeng.cn@gmail.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=palmerdabbelt@google.com \
    --cc=paul.walmsley@sifive.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.