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

On 5/29/26 12:49, Florian Bezdeka wrote:
> 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
> 

I have a working evl rebase based on your wip v7.1-dovetail-rebase that
I used for testing here:
https://github.com/TobiasSchaffner/linux/tree/wip/tobsch/v7.1-evl-rebase
The rebase was streight forward appart from two small issues in drivers/
gpio and kernel/time.

I am willing to support with the forward porting of EVL now as well as
in the future if we decide to go down this route.

Best,
Tobias