On 2021/05/19 16:16, Anup Patel wrote: > On Wed, May 19, 2021 at 12:24 PM Drew Fustini <drew@xxxxxxxxxxxxxxx> wrote: >> >> On Wed, May 19, 2021 at 08:06:17AM +0200, Christoph Hellwig wrote: >>> On Wed, May 19, 2021 at 02:05:00PM +0800, Guo Ren wrote: >>>> Since the existing RISC-V ISA cannot solve this problem, it is better >>>> to provide some configuration for the SOC vendor to customize. >>> >>> We've been talking about this problem for close to five years. So no, >>> if you don't manage to get the feature into the ISA it can't be >>> supported. >> >> Isn't it a good goal for Linux to support the capabilities present in >> the SoC that a currently being fab'd? >> >> I believe the CMO group only started last year [1] so the RV64GC SoCs >> that are going into mass production this year would not have had the >> opporuntiy of utilizing any RISC-V ISA extension for handling cache >> management. > > The current Linux RISC-V policy is to only accept patches for frozen or > ratified ISA specs. > (Refer, Documentation/riscv/patch-acceptance.rst) > > This means even if emulate CMO instructions in OpenSBI, the Linux > patches won't be taken by Palmer because CMO specification is > still in draft stage. > > Also, we all know how much time it takes for RISCV international > to freeze some spec. Judging by that we are looking at another > 3-4 years at minimum. Which is the root cause of most problems with riscv extension support in Linux. All RISC-V foundation members need to apply pressure on the foundation and these standard groups to deliver frozen specifications with an acceptable schedule. c.f. the H extensions specs which are not yet frozen despite not having been changed for months if not years. -- Damien Le Moal Western Digital Research
