Re: [RFC PATCH 1/2] riscv: vendors: andes: Add support to configure the PMA regions

[Conor.Dooley]

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.