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@xxxxxxxxxxxxx > <mailto:Conor.Dooley@xxxxxxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxx > <mailto:linux-riscv@xxxxxxxxxxxxxxxxxxx> > http://lists.infradead.org/mailman/listinfo/linux-riscv > <http://lists.infradead.org/mailman/listinfo/linux-riscv> > > > > -- Regards, Atish
