linux-kernel - Re: [PATCH v4 06/10] dt-bindings: riscv: Add bouffalolab bl808 board compatibles

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c6e44e14-35b2-da09-5e8c-4d47e7a7a055@sholland.org>
Date:   Thu, 18 May 2023 22:31:35 -0500
From:   Samuel Holland <samuel@...lland.org>
To:     Jisheng Zhang <jszhang@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
        devicetree@...r.kernel.org, linux-serial@...r.kernel.org,
        Palmer Dabbelt <palmer@...osinc.com>,
        Conor Dooley <conor.dooley@...rochip.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>
Subject: Re: [PATCH v4 06/10] dt-bindings: riscv: Add bouffalolab bl808 board
 compatibles

Hi Jisheng, DT maintainers,

On 5/18/23 10:22, Jisheng Zhang wrote:
> Several SoMs and boards are available that feature the Bouffalolab
> bl808 SoC. Document the compatible strings.
> 
> Signed-off-by: Jisheng Zhang <jszhang@...nel.org>
> Acked-by: Palmer Dabbelt <palmer@...osinc.com>
> Reviewed-by: Conor Dooley <conor.dooley@...rochip.com>
> ---
>  .../bindings/riscv/bouffalolab.yaml           | 29 +++++++++++++++++++
>  1 file changed, 29 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml
> 
> diff --git a/Documentation/devicetree/bindings/riscv/bouffalolab.yaml b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml
> new file mode 100644
> index 000000000000..3b25d1a5d04a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml
> @@ -0,0 +1,29 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Bouffalo Lab Technology SoC-based boards
> +
> +maintainers:
> +  - Jisheng Zhang <jszhang@...nel.org>
> +
> +description:
> +  Bouffalo Lab Technology SoC-based boards
> +
> +properties:
> +  $nodename:
> +    const: '/'
> +  compatible:
> +    oneOf:
> +      - description: Carrier boards for the Sipeed M1s SoM
> +        items:
> +          - enum:
> +              - sipeed,m1s-dock
> +          - const: sipeed,m1s
> +          - const: bouffalolab,bl808

As mentioned in the message for patch 5, "The Bouffalolab bl808 SoC
contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V
GC compatible, so can run linux."

I have also been running U-Boot and NOMMU Linux on the less powerful,
but still quite fast, "M0" core. However, this core needs a different
DTB because:
 1) The CPU is different (T-HEAD E907 instead of C906).
 2) The interrupt routing is completely different.
    a. The M0 core contains a CLIC instead of a PLIC.
    b. The peripherals in the SoC are split between two buses. Those
       on one bus have their IRQs directly connected to M0, and share
       a multiplexed IRQ connection to D0; and vice versa for the
       other bus. So each bus's interrupt-parent needs to be swapped.

Using some preprocessor magic like we did for Allwinner and Renesas, I
was able to share most of the SoC and board DTs between the cores[1].
However, this still ends up with two DTs for each board. So here are my
questions:
 - Is this acceptable?
 - Is there precedent for how we should name the two board DTs?
 - How does this affect the board and SoC compatible strings?
   - Should there be a separate "bouffalolab,bl808-d0" in addition to
     "bouffalolab,bl808"?
   - Is it acceptable to use the same board compatible string for both,
     since the _board_ part of the DT does not change, only things
     inside the SoC?

It would be possible to avoid having two DTs per board by guarding all
of the differences behind "#ifdef CONFIG_64BIT", but that seems wrong
because you would end up with two totally incompatible DTBs named the
same thing, depending on how the DTB was built.

Thoughts?

Regards,
Samuel

[1]: https://github.com/openbouffalo/u-boot/commit/3ca800850f30