From: Krzysztof Kozlowski <krzk@kernel.org>
To: Marco Pagani <marco.pagani@linux.dev>,
Xu Yilun <yilun.xu@linux.intel.com>
Cc: Moritz Fischer <mdf@kernel.org>, Xu Yilun <yilun.xu@intel.com>,
Tom Rix <trix@redhat.com>,
linux-fpga@vger.kernel.org, linux-kernel@vger.kernel.org,
Rob Herring <robh@kernel.org>,
Saravana Kannan <saravanak@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
devicetree@vger.kernel.org
Subject: Re: [RFC PATCH] fpga: region: Add support for FPGA region variants
Date: Wed, 23 Sep 2026 17:09:57 +0200 [thread overview]
Message-ID: <1857df9a-8952-426e-988b-cd05d45a04cc@kernel.org> (raw)
In-Reply-To: <2adefc6f-328c-4683-8cba-091d9f3425ab@linux.dev>
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.
>
> - 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.
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-09-23 15:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 16:42 Marco Pagani
2026-06-08 16:42 ` [RFC PATCH fpga/for-next 1/2] " Marco Pagani
2026-06-08 16:42 ` [RFC PATCH fpga/for-next 2/2] fpga: of-fpga-region: Add support for " Marco Pagani
2026-06-26 12:58 ` [RFC PATCH] fpga: region: Add support for FPGA " Xu Yilun
2026-06-30 9:39 ` Marco Pagani
2026-06-30 14:58 ` Xu Yilun
2026-07-06 10:05 ` Marco Pagani
2026-07-07 8:02 ` Xu Yilun
2026-07-07 21:49 ` Marco Pagani
2026-07-22 11:22 ` Xu Yilun
2026-08-02 21:32 ` Marco Pagani
2026-08-03 9:27 ` Xu Yilun
2026-08-08 19:35 ` Marco Pagani
2026-08-10 7:25 ` Xu Yilun
2026-08-16 13:18 ` Marco Pagani
2026-08-17 3:06 ` Xu Yilun
2026-08-17 16:14 ` Marco Pagani
2026-09-18 15:07 ` Marco Pagani
2026-09-18 17:36 ` Xu Yilun
2026-09-23 14:30 ` Marco Pagani
2026-09-23 15:09 ` Krzysztof Kozlowski [this message]
2026-09-23 16:43 ` Marco Pagani
2026-09-23 16:57 ` Rob Herring
2026-09-24 17:20 ` Marco Pagani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1857df9a-8952-426e-988b-cd05d45a04cc@kernel.org \
--to=krzk@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marco.pagani@linux.dev \
--cc=mdf@kernel.org \
--cc=robh@kernel.org \
--cc=saravanak@kernel.org \
--cc=trix@redhat.com \
--cc=yilun.xu@intel.com \
--cc=yilun.xu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®