lkml.org 
[lkml]   [2022]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC PATCH 1/2] riscv: vendors: andes: Add support to configure the PMA regions
    Date
    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@microchip.com
    > <mailto:Conor.Dooley@microchip.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@lists.infradead.org
    > <mailto:linux-riscv@lists.infradead.org>
    > http://lists.infradead.org/mailman/listinfo/linux-riscv
    > <http://lists.infradead.org/mailman/listinfo/linux-riscv>
    >
    >
    >
    > -- Regards, Atish

    \
     
     \ /
      Last update: 2022-09-08 01:39    [W:4.365 / U:0.332 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site