Re: [RFC PATCH] fpga: region: Add support for FPGA region variants

[Marco Pagani <marco.pagani@linux.dev>]

On 23/09/2026 18:57, Rob Herring wrote:
> On Wed, Sep 23, 2026 at 11:43 AM Marco Pagani <marco.pagani@linux.dev> wrote:
>>
>>
>>
>> On 23/09/2026 17:09, Krzysztof Kozlowski wrote:
>>> On 23/09/2026 16:30, Marco Pagani wrote:
>>>>
>>>>
>>>> On 18/09/2026 19:36, Xu Yilun wrote:
>>>>> On Fri, Sep 18, 2026 at 05:07:07PM +0200, Marco Pagani wrote:
>>>>>>
>>>>>> Hi Yilun,
>>>>>>
>>>>>> Is it okay with you if I CC the DT people to ask for an opinion?
>>>>>
>>>>> Of course. It's good to know in which case could a DTO be applied.
>>>>>
>>>>> But to be clear, I think that only affects how we accept and apply the
>>>>> image-DTO pair. For now, I basically don't want a varient selection
>>>>> interface.
>>>>
>>>>
>>>> Hello Rob, Saravana, Krzysztof, Conor,
>>>>
>>>> I'm CC-ing you on this thread as OF/DT maintainers to kindly ask
>>>> for your input on this debate we are having about how to implement
>>>> userspace FPGA reconfiguration, an important feature currently
>>>> lacking in mainline kernel.
>>>>
>>>> https://lore.kernel.org/all/20260608164247.1998417-1-marco.pagani@linux.dev
>>>>
>>>> To recap: modern FPGAs allow portions of the fabric to be reconfigured
>>>> at runtime to dynamically swap soft IPs. Usually, these IPs are
>>>> connected through a non-discoverable on-chip bus like AMBA AXI.
>>>> From a kernel perspective, this means the FPGA device configuration
>>>> image (bitstream) must be paired with a DT fragment that describes
>>>> the new topology.
>>>>
>>>> In this thread, we are essentially debating between two approaches for
>>>> implementing FPGA userspace reconfiguration at runtime:
>>>>
>>>> - Statically defined Variants (this RFC): Userspace can change FPGA
>>>>   configuration by selecting from a pre-validated set of variants
>>>>   (DT fragments) baked into the base DT.
>>>
>>> I don't know what DT fragments are, maybe you meant overlays? But they
>>> are not baked into the base DT.
>>>
>>> There are no bindings here and no DT maintainers were CCed on this RFC,
>>> so I really do not get how this patch can enable something like that.
>>>
>>> Linked URL shows some undocumented ABI, so obviously this would be a no
>>> go. And RFC prefix does not justify undocumented ABI. At least one
>>> without clear explanation in the cover letter, why is this RFC and why
>>> it cannot be merged/reviewed.
>>
>> Sorry, I couldn't have imagined that missing ABI documentation in a
>> "proof of concept" RFC would be so detrimental while asking for a
>> high-level opinion.
> 
> I think the point is the RFC needs to say why it can't be merged.
> Otherwise we have to guess no documentation is because you don't know
> that's a requirement or because it is an RFC.

Fair point. I mistakenly assumed that the content of the message and the
RFC being framed as a "proof of concept" would have made it clear that I
was just asking for a high-level opinion.

During the discussion with Yilun, we also touched on other important
topics, like how to safely pair the DT "descriptions" with the
images/bitstreams to avoid TOCTOU races.

My intent was to collect some constructive feedback on these topics and
extend the discussion to other developers and maintainers before investing
further effort into this.


>>>> - Runtime DTOs (Nava's RFC): Userspace can change FPGA configuration
>>>>   by loading DTOs that are validated at runtime.
>>>
>>> If runtime overlays were working, this looks suitable to the problem of
>>> runtime change of the hardware. This also fits hot-pluggable hardware
>>> problem, which Bootlin is working on.
> 
> Overlays were the plan when FPGA regions were added to the kernel. Not
> sure why that never happened. I would suggest you go read any
> discussions from that.

I spent a considerable amount of time reading related discussions
on the mailing list, before and after sending the RFC, as it can be
seen in the discussion.

https://lore.kernel.org/linux-fpga/97739313-fc97-4b11-b2e2-d680621a7fe1@linux.dev/
https://lore.kernel.org/linux-fpga/db7cfe9e-b2ba-4323-bff9-44598e1f70bb@linux.dev/

The historical pushback against userspace overlay interfaces motivated
by security, resource management, and kernel stability concerns
is exactly what led me to experiment with the statically pre-validated
region "variants" in the first place.

> From: Rob Herring @ 2017-10-18 15:44 UTC:
> [...]
> The issue remains that the kernel is not really setup to deal with any
> random property or node to be changed at any point in run-time. I
> think there needs to be some restrictions around what the overlays can
> touch. We can't have it be wide open and then lock things down later
> and break users. One example of what you could do is you can only add
> sub-trees to whitelisted nodes.

> From: Frank Rowand @ 2017-10-19 21:46 UTC
> [...]
> I would state that somewhat differently.  :-)  There is very little
> code that is aware of overlays, and most code assumes the device tree
> does not change after early boot.

https://lore.kernel.org/all/CAL_JsqKR3Jg+tgZr4xGPtcWnZW7ng741YjuyUFaS2SXKXbxGtg@mail.gmail.com/

The FPGA "variants" proposed in this RFC are essentially statically-defined
whitelisted nodes.

I see that "DT addon" mentioned by Krzysztof is the preferred solution,
but I still think a static approach is preferable for FPGA since the set
of bitstreams for an FPGA region is finite and statically defined at
design time. I think there is a fundamental asymmetry between the
marginal convenience of not having to rebuild the base DTB and the
burden of securing a DTO interface.


>> Glad to know the problem is already being solved.
> 
> Not sure I'd go that far. There are plenty of areas that need
> help/attention. And I don't like merging new things with only one user

I completely understand. However, the general idea behind variant regions
was to introduce a common way to handle partial reconfiguration from
userspace. In the proof-of-concept RFC, I extended of-fpga-region to
implement variants in a statically-defined way because it was a relevant
case, but the mechanism was designed to be eventually implemented also for
other FPGA regions.


> because every time I do that, someone comes along right after wanting
> something a bit different...
> 
> Rob


Thanks,
Marco