Looks like the risc-v community is learning from history! Hopefully this results in more upstream development efforts: https://riscv.org/blog/2025/07/risc-v-upstreaming/

@gregkh

That post reminds me many moments in Arm architecture history...

Creation of armhf to have all distros target the same armv7.

Creation of Linaro and work done by people there.

SBSA, BSA specifications which tries to define aarch64 hardware and firmware interfaces.

Work done on making enterprise Linux distros running on aarch64 servers.

I hope that RISE will not follow aarch64 mistakes.

@gregkh just not learning from history about AI bullshit, I see

@hrw
Any particular mistakes? I think System Ready for Client PC's could of come sooner and maybe we should have spent less time arguing about Device Tree vs ACPI but in general the standardisation push was the right thing - it's just poorly distributed.
@gregkh

Standards for platform/architecture are good to have.

The question is how well they will be implemented. Arm S*Ready compliance list has systems which misbehave.

And how many drivers will misbehave because of things are done other way than x86-64 or aarch64.

@stsquad @gregkh

@stsquad @hrw Fixing the lack of almost all riscv soc drivers to be upstream so that I can boot a kernel.org release on one of them (i.e. a normal developer can test their changes) would be a good start. Which is one of the things that article says...

@gregkh @stsquad @hrw That's the thing now, is it? SystemReady, DT, ACPI, it's all irrelevant if you don't have any driver. Sure, your kernel would boot. But it would boot to either a panic or a useless brick.

@mripard
Fortunately in the Arm server world most of the SoCs use Arm IP for the additional system peripherals and they are well supported upstream. It gets trickier with the mobile SoCs especially with anything involving wireless. At least vendors like Google and Qualcomm are upstreaming drivers even if they have lived in vendor trees for awhile while products shipped. If RiscV wants to break into the #android space they will need to heed Google's GKI requirements.
@gregkh @hrw

@stsquad @gregkh @hrw I agree, but it's not entirely the point I was trying to make. We've had well supported platforms before DT happened (TI and Atmel now Microchip come to mind), we've had others before SystemReady (Renesas, Rockchip, NXP, Marvell, I'm sure I'm forgetting plenty). Standards are not the issue. It makes it easier for distros, but we've also had distros before they existed, like Yocto. If anything, standards shift the blame to ARM, when the most glaring issue is that some vendors are not doing their homework.