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

[Rob Herring]

On Wed, Sep 23, 2026 at 11:43 AM Marco Pagani <marco.pagani@xxxxxxxxx> 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@xxxxxxxxx
> >>
> >> 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.

> >> - 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.

> 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
because every time I do that, someone comes along right after wanting
something a bit different...

Rob