Merging plan for SBIv3-dependent patches

Merging plan for SBIv3-dependent patches

[Palmer Dabbelt]

We've talked about this a few times in the patchwork meeting, but I 
figured I'd write up an email as this is a bit of a wacky process.  

There's a bunch of patch sets blocked on the SBIv3 freeze.  That's been 
coming soon for a while now, but it seems like now it's actually really 
coming soon.  So I'm going to start staging those onto a "sbiv3" branch, 
as there's some cross-set dependencies and probably some merge conflicts 
that will need to get sorted out.

I'm going to plan on doing a staging merge of that branch onto the tip  
of for-next, so it can get some time on the testers.  That'll be a 
little different than how we usually handle for-next, but I think it's 
the best way to go as it'll make dropping the patches easy in case the 
specs don't get frozen in time.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: Merging plan for SBIv3-dependent patches

[Atish Patra]

On 5/8/25 10:25 AM, Palmer Dabbelt wrote:
> We've talked about this a few times in the patchwork meeting, but I 
> figured I'd write up an email as this is a bit of a wacky process.
> There's a bunch of patch sets blocked on the SBIv3 freeze.  That's been 
> coming soon for a while now, but it seems like now it's actually really 
> coming soon.  So I'm going to start staging those onto a "sbiv3" branch,

Yes. The SBI v3.0 is officially frozen now. here is the announcement and 
along with the document status.

https://lore.kernel.org/linux-riscv/CAOnJCUJz6p6b0WK_7=qowe8_pCHnv5WJXNYMa-uzFy0PHc7Dvg@mail.gmail.com/


> as there's some cross-set dependencies and probably some merge conflicts 
> that will need to get sorted out.
> 
> I'm going to plan on doing a staging merge of that branch onto the tip 
> of for-next, so it can get some time on the testers.  That'll be a 
> little different than how we usually handle for-next, but I think it's 
> the best way to go as it'll make dropping the patches easy in case the 
> specs don't get frozen in time.
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv