Hi All, Apologies for cross posting multiple lists. Just wanted to reach out to the maximum audience as this is a short notice to set up the first meeting. This is just a quick notice that the first P

Hi All, The doodle poll indicates that the 8AM PDT Wednesday is the most preferred slot. This will probably conflict with hypervisor SIG meetings once in a while. We will reschedule that meeting whene

cross-posting for more visibility. ---------- Forwarded message --------- From: Atish Kumar Patra <atishp@...> Date: Thu, Sep 1, 2022 at 11:55 AM Subject: Call for Chair/Vice-Chair Candidates

Hi All, We are pleased to announce the early formation of Platform Runtime Services(PRS) Task Group with Atish Patra from Rivos as the acting chair and Sunil VL from ventana as the acting vice chair.

As per my understanding, early boot refers to OS world. Introducing UD to the S-mode is not an option in my opinion. We already have all the infrastructure for DT/ACPI in rich OS land. As Phillip poin

Do you mean SBI spec changes are merged in the spec but the SBI spec is not frozen by itself ? Release of the SBI specification - ratified version or frozen is fine ? As long as dependent specs can go

<heinrich.schuchardt@...> wrote: Ahh I see. Sorry I misunderstood your comment. The designated shared memory for debug console is shared across the platforms while STA or PMU use case will h

<heinrich.schuchardt@...> wrote: I would like to understand more about the security concerns you raised. Can you please elaborate on this ? As you pointed out, there are other possible use c

It's also helpful in early board bringup and early debugging as pointed out by Heiko as well. To address some of the concerns raised above, how about putting some restrictions on sbi_debug_console_set

As per my discussions with Philip, there will be a Firmware & Platform Services SIG which will cover all the platform services specs (SBI, UEFI, ACPI). It can spin off separate TGs for SBI/ACPI which

There was no need for any extension specific return value yet. I doubt if we will need one in the future. To reduce ambiguity, how about this change: "Returns 0 if the given SBI extension ID (EID) is

Sounds good to me as well. I will make the change.

That won't be required as the specification clearly states that "SBI extensions as whole are optional but they shall not be partially implemented. If sbi_probe_extension() signals that an extension is

Sure. Here is the proposed diff that removed all the references to RV32 in the specification. Is it a common practice to explicitly specify in the specification that only the RV64 version is ratified

Sounds good. One minor comment: "While there can be a solution using /chosen node in DT based systems to pass this information, a simple and common interface across DT and ACPI platforms is desired on

The description says "Returns 0 if the given SBI extension ID (EID) is not available, or an extension-specific non-zero value if it is available" The specification says it should be non-zero as the va

I just realized that the below email was not delivered to unix platform mailing list and linux-riscv mailing list because of the attachment. Reseeding it again without the attachment. Apologies for th

<abner.chang@...> wrote: I think it would be better to enforce the mandatory requirement explicitly in the UEFI spec. The actual content of the protocol can be hosted under RISC-V.

Send a patch :)

<ksankaran@...> wrote: Not sure why these are not rendered correctly in gmail. The deleted text seems to be garbage as well which indicates a rendering issue in gmail. Please make sure th