Re: Dovetail on risc-v: Testing strategy, managing efforts for forward porting

On Fri, 2026-05-29 at 12:43 +0200, Philippe Gerum wrote:
> Jan Kiszka <[email protected]> writes:
> 
> > On 29.05.26 12:08, Philippe Gerum wrote:
> > > 
> > > Florian Bezdeka <[email protected]> writes:
> > > 
> > > > Hi Philippe,
> > > > 
> > > > I'm currently waiting for a v8 of Tobias' risc-v implementation. A
> > > > couple of minor things still need fixing, but overall I would say that
> > > > we are looking good - ready for merging - assuming that currently
> > > > running tests are successful.
> > > > 
> > > 
> > > Really nice stuff, thanks to anyone involved.
> > > 
> > > > From my point of view there is one issue left, that needs a discussion:
> > > > Testing and forward porting in the future.
> > > > 
> > > > Up to now I was able to test all architectures using cobalt / x3. That
> > > > will change now, as we don't have risc-v support in x3.
> > > > 
> > > > I see the following options:
> > > > 
> > > > 1: Additionally forward port linux-evl in the future, so that we can run
> > > > tests against risc-v using x4. Additional effort for me, especially
> > > > because we don't have an in-house user for that. Can you estimate how
> > > > much time it takes you to forward port linux-evl in comparison to linux-
> > > > dovetail?
> > > > 
> > > 
> > > Porting evl to a new arch kernel-wise is fundamentally trivial, the real
> > > work is done by Dovetail. For every currently supported arch, the amount
> > > of arch-specific evl code is 60 lines of C, merely wrappers in headers
> > > (arch/*/include/asm/evl/*.h). Tobias already contributed the few bits
> > > libevl needs to support risc-v.
> > > 
> > > > 2: Add risc-v support to x3 as well. To my understanding there were no
> > > > plans yet, but it might be worth it to limit forward porting efforts. I
> > > > could focus on x3 for testing. This might also help to compare risc-v
> > > > against the other architectures.
> > > > 
> > > 
> > > Although this may require a little more effort compared to x4, such port
> > > would still be tractable since Dovetail does most of the work here as
> > > well. Adding risc-v support to x3 is Jan's call.
> > > 
> > > > 3: Ignore risc-v during forward porting. Yes, this option exists, but I
> > > > don't consider it as a real / valid option.
> > > > 
> > > 
> > > Neither do I. Merged implies maintained.
> > > 
> > > > 4: Merge the risc-v support into linux-evl. That would make risc-v
> > > > support exclusive to evl, where we could already test it. Would that be
> > > > an valid option for the evl side?
> > > > 
> > > 
> > > No, I believe that we can deal with one arch more such as risc-v in the
> > > Dovetail maintenance process. Besides, we really want the generic
> > > Dovetail code to be shared by all architectures, otherwise this would
> > > become a maintenance nightmare for the risc-v port.
> > > 
> > > > Any additional option available, that I missed?
> > > > 
> > > 
> > > I'd say, the simpler the better. Today, enabling risc-v for x4 would be
> > > straightforward while keeping the current maintenance model for Dovetail
> > > mostly unaffected.  Granted, forward porting to the latest kernel
> > > release may require a bit more work in order to maintain the risc-v part
> > > too, but my understanding is that Tobias is willing to help with this in
> > > the long term. AFAICS, the arch-specific part in risc-v for Dovetail is
> > > fairly reasonable in size as well.
> > > 
> > > So, first step would be to merge the Dovetail risc-v support into
> > > linux-dovetail like other supported archs, enabling it for x4/evl in the
> > > same move. It could be enabled for x3 next, when time allows on your end
> > > if desired.
> > > 
> > 
> > To my understanding, Florian's concerns are not about the first-time
> > enabling or risc-v but its future testing when going to a new kernel
> > version. While arch-wise, most work is done in dovetail, testing would
> > only be possible once linux-evl is ported to a new kernel as well. And
> > that porting is widely arch-agnostic but for other reasons (drivers
> > e.g.) quite some generic effort.
> 
> This proved to be a limited effort over time. Porting issues in generic
> driver code for linux-evl can only affect the GPIO core, all the rest is
> on the Dovetail side (NIC drivers, SPI and DMA cores), so already ported
> actually.
> 
> Those issues did happen but rarely, and the complexity to address them
> always were an order of magnitude smaller than it has been for Dovetail
> over time. Most importantly, those merge conflicts were all due to
> changes in symbol names and routines moving around due to upstream
> refactoring/cleaning up the code, still keeping the original logic
> untouched though. I'd say such porting work still qualifies as simple.

With that: Let me try it. Which branch should be the "source" for v7.1-
evl-rebase? next/v7.0-evl-rebase or v7.0-evl-rebase? (with or without
next/)

I would do it the same way as for Dovetail: I would push to something
like wip/<release>-rebase and ask you to take over / release. Right?

Florian