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]
Date:   Tue, 6 Sep 2022 10:39:03 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <prabhakar.mahadev-lad.rj@...renesas.com>,
        <paul.walmsley@...ive.com>, <palmer@...belt.com>,
        <aou@...s.berkeley.edu>
CC:     <atishp@...osinc.com>, <apatel@...tanamicro.com>,
        <geert+renesas@...der.be>, <linux-riscv@...ts.infradead.org>,
        <linux-renesas-soc@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <prabhakar.csengg@...il.com>,
        <biju.das.jz@...renesas.com>
Subject: Re: [RFC PATCH 1/2] riscv: vendors: andes: Add support to configure
 the PMA regions

On 06/09/2022 11:21, Lad Prabhakar wrote:

> diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> index 2a0ef738695e..10a7c855d125 100644
> --- a/arch/riscv/include/asm/sbi.h
> +++ b/arch/riscv/include/asm/sbi.h
> @@ -37,6 +37,7 @@ enum sbi_ext_id {
> 
>          /* Vendor extensions must lie within this range */
>          SBI_EXT_VENDOR_START = 0x09000000,
> +       SBI_EXT_ANDES = 0x0900031E,
>          SBI_EXT_VENDOR_END = 0x09FFFFFF,
>   };

Everything else aside, I am very interested in what's happening
here. I'll take a proper look through things later, but for now:

For PolarFire SoC we have an InterHart Communication SBI EXT that
would would like to upstream support for. We are not aiming to put
the driver itself in arch/riscv - it's just a mailbox driver, but
I would like to use sbi.h for defining the vendor id etc.

I am not sure how this all aligns with:
> We’ll only accept patches for new modules or extensions if the
> specifications for those modules or extensions are listed as being
> “Frozen” or “Ratified” by the RISC-V Foundation. (Developers may, of
> course, maintain their own Linux kernel trees that contain code for
> any draft extensions that they wish.)
> 
> Additionally, the RISC-V specification allows implementors to create
> their own custom extensions. These custom extensions aren’t required
> to go through any review or ratification process by the RISC-V
> Foundation. To avoid the maintenance complexity and potential
> performance impact of adding kernel code for implementor-specific
> RISC-V extensions, we’ll only to accept patches for extensions that
> have been officially frozen or ratified by the RISC-V Foundation.
> (Implementors, may, of course, maintain their own Linux kernel trees
> containing code for any custom extensions that they wish.)

Which is in: https://docs.kernel.org/riscv/patch-acceptance.html

It is unclear to me whether that is just for ISA extensions or if that
covers SBI extensions too. At least for us, since we don't touch arch
code there is relatively little friction & there's no concerns about
reducing the portability of a kernel since it is just a regular old
driver.

I was planning on cornering some people *cough* Palmer *cough* at
LPC and asking him what his thoughts were there.

FWIW this is what we have been doing:
https://github.com/linux4microchip/linux/blob/linux-5.15-mchp/drivers/mailbox/mailbox-miv-ihc.c#L27

The IP itself has not stabilised yet, so we have not sent any patches
yet, but we do intend doing so...

But yea, I'll take a properly look at what you're doing here soonTM,
although at this point it may be the other side of LPC.

btw, where can I get my hands on your hardware?

Thanks,
Conor.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ