Message-ID: <f362eaeb-6ccd-4392-a346-55fa5ae25e13@microchip.com>
Date:   Wed, 7 Sep 2022 23:37:43 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <atishp@...shpatra.org>
CC:     <prabhakar.mahadev-lad.rj@...renesas.com>,
        <paul.walmsley@...ive.com>, <palmer@...belt.com>,
        <aou@...s.berkeley.edu>, <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 07/09/2022 22:52, Atish Patra wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> 
> 
> On Tue, Sep 6, 2022 at 3:40 AM <Conor.Dooley@...rochip.com
> <mailto:Conor.Dooley@...rochip.com>> wrote:
> 
> 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
> <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.
> 
> 
> It covers the standard SBI extensions as well. However, I don't think
> this includes a vendor extension as there is no freeze or
> ratification associated with vendor extensions.
> 
> It would be good to discuss the policy around vendor SBI extensions
> during LPC as well. We also need to discuss the ACPI policy as well.
> We most likely need a BoF to discuss these adhoc topics. I will check
> if we can schedule a BoF in advance.

I did briefly mention this to Palmer on IRC last night, just was busy
today & didn't get a chance to reply here. The indication there was
that yes, this paragraph did cover SBI extensions - which would make
vendor extensions not permitted upstream. 

We (microchip) are "only" doing a few ecalls in a driver but this
seems a fair bit more intrusive since it is in arch code. Even if the
answer is a "no" - a no from the horses mouth rather than on IRC &
maybe some rewording of that doc to be clearer would be nice.

I'd be down for a BoF, even if just to get a "no" in person haha

Conor.

> 
> 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
> <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.
> 
> 
> _______________________________________________ linux-riscv mailing
> list linux-riscv@...ts.infradead.org
> <mailto:linux-riscv@...ts.infradead.org> 
> http://lists.infradead.org/mailman/listinfo/linux-riscv
> <http://lists.infradead.org/mailman/listinfo/linux-riscv>
> 
> 
> 
> -- Regards, Atish

Powered by blists - more mailing lists