[RFC] drivers/staging/axis-fifo: TODO file and subsystem direction

[RFC] drivers/staging/axis-fifo: TODO file and subsystem direction

[Grewstad]

Dear Maintainers,

I am interested in contributing to the Xilinx AXI-Stream FIFO driver
located in drivers/staging/axis-fifo.

While reviewing the driver, I noticed that it does not currently
contain a TODO file describing the work required for graduation from
staging. I would like to create such a file, but before doing so I
would appreciate guidance on the expected long-term direction for the
driver.

The driver currently exposes a custom userspace ABI through a
miscdevice. While this provides a generic interface to the FIFO, it
does not integrate with existing kernel subsystem tooling. One possible
incremental improvement in this area could be a transition from
miscdevice to a proper character device (cdev) interface, to allow for
a more clearly defined and maintainable userspace ABI.

Some possible directions that came to mind are:

- UIO, if the intent is to provide userspace control over a generic
  AXI-stream FIFO with minimal kernel policy.
- IIO, for data acquisition or SDR-oriented applications that could
  benefit from existing buffer infrastructure and userspace tooling.
- Networking, for packet-oriented AXI-stream use cases.

Before drafting a TODO file and proposing patches, I would like to
understand whether there is a preferred subsystem model for this
hardware, or whether the current architecture is expected to remain in
place.

Any guidance would be greatly appreciated.

Thank you,

Arihan Bhor

Re: [RFC] drivers/staging/axis-fifo: TODO file and subsystem direction

[Greg KH]

On Sun, May 31, 2026 at 08:20:35PM +0530, Grewstad wrote:
> Dear Maintainers,
> 
> I am interested in contributing to the Xilinx AXI-Stream FIFO driver
> located in drivers/staging/axis-fifo.
> 
> While reviewing the driver, I noticed that it does not currently
> contain a TODO file describing the work required for graduation from
> staging. I would like to create such a file, but before doing so I
> would appreciate guidance on the expected long-term direction for the
> driver.
> 
> The driver currently exposes a custom userspace ABI through a
> miscdevice. While this provides a generic interface to the FIFO, it
> does not integrate with existing kernel subsystem tooling. One possible
> incremental improvement in this area could be a transition from
> miscdevice to a proper character device (cdev) interface, to allow for
> a more clearly defined and maintainable userspace ABI.

There really is no difference between a miscdevice and a character
device, the interaction from user/kernel is the same.

> Some possible directions that came to mind are:
> 
> - UIO, if the intent is to provide userspace control over a generic
>   AXI-stream FIFO with minimal kernel policy.

UIO provides a mmap of a device to userspace where it is controlled
directly.  Probably not what you want to do here right?

> - IIO, for data acquisition or SDR-oriented applications that could
>   benefit from existing buffer infrastructure and userspace tooling.

Is that what this device is?

> - Networking, for packet-oriented AXI-stream use cases.

WHat really is this device for?  What is the goal of this hardware and
how is it used today?  Do you have the hardware to test with it?  Who
uses it?

thanks,

greg k-h

Re: [RFC] drivers/staging/axis-fifo: TODO file and subsystem direction

[Andrew Lunn]

On Sun, May 31, 2026 at 08:20:35PM +0530, Grewstad wrote:
> Dear Maintainers,
> 
> I am interested in contributing to the Xilinx AXI-Stream FIFO driver
> located in drivers/staging/axis-fifo.
> 
> While reviewing the driver, I noticed that it does not currently
> contain a TODO file describing the work required for graduation from
> staging. I would like to create such a file, but before doing so I
> would appreciate guidance on the expected long-term direction for the
> driver.
> 
> The driver currently exposes a custom userspace ABI through a
> miscdevice. While this provides a generic interface to the FIFO, it
> does not integrate with existing kernel subsystem tooling. One possible
> incremental improvement in this area could be a transition from
> miscdevice to a proper character device (cdev) interface, to allow for
> a more clearly defined and maintainable userspace ABI.

In addition to what GregKH said, look at the vendor information:

https://docs.amd.com/r/en-US/pg080-axi-fifo-mm-s/Core-Overview

  The AXI4-Stream FIFO core was designed to provide memory-mapped
  access to an AXI4-Stream interface connected to other IP (such as
  the AXI Ethernet core). Systems must be built through the AMD
  Vivado™ Design Suite to attach the AXI4-Stream FIFO core, AXI
  Ethernet core ...

when used for Ethernet, a uAPI is not needed. The FIFO driver would
just expose an kernel internal API the Ethernet driver would use. Are
there any Ethernet devices using it? Is there a driver for the AXI
Ethernet core? Does drivers/net/ethernet/xilinx/* duplicate the same
code? xilinx_axienet_main.c says:

 * TODO:
 *  - Add Axi Fifo support.

which could be this.

As GregKH said, find some hardware using these IP cores, or synthesise
your own, and then work on the driver.

	Andrew

Re: [RFC] drivers/staging/axis-fifo: TODO file and subsystem direction

[Grewstad]

On Sun, May 31, 2026 at 8:56 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> There really is no difference between a miscdevice and a character
> device, the interaction from user/kernel is the same.

> UIO provides a mmap of a device to userspace where it is controlled
> directly.  Probably not what you want to do here right?

Yeah, on second thought, UIO is probably not a great fit here. This device is
expected to handle streaming workloads, so having a kernel driver manage
the data path seems like the better approach. Thanks.

> Is that what this device is?
> WHat really is this device for?  What is the goal of this hardware and
> how is it used today?  Do you have the hardware to test with it?  Who
> uses it?

Well the hardware is programmable and meant for hobbyists and researchers. It
could do anything, but SDR/DAQ and low-end networking are common uses. But since
It is a programmable prototyping board, making it hard to cleanly
categorize it into any
one subsystem.

I don't have the hardware, but I plan on testing it using QEMU.

I was looking for guidance on whether the current miscdevice based ABI
is already the
best fit, or whether it could integrate into an existing subsystem.

Thanks,
Arihan Bhor

Re: [RFC] drivers/staging/axis-fifo: TODO file and subsystem direction

[Greg KH]

On Mon, Jun 01, 2026 at 11:09:36AM +0530, Grewstad wrote:
> I don't have the hardware, but I plan on testing it using QEMU.

I wouldn't recommend this for cleaning up and getting the driver out of
staging, as QEMU might not be working like the real hardware does.

good luck!

greg k-h

Re: [RFC] drivers/staging/axis-fifo: TODO file and subsystem direction

[Grewstad]

On Mon, Jun 1, 2026 at 1:22 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
>
> In addition to what GregKH said, look at the vendor information:
>
> https://docs.amd.com/r/en-US/pg080-axi-fifo-mm-s/Core-Overview
>
>   The AXI4-Stream FIFO core was designed to provide memory-mapped
>   access to an AXI4-Stream interface connected to other IP (such as
>   the AXI Ethernet core). Systems must be built through the AMD
>   Vivado™ Design Suite to attach the AXI4-Stream FIFO core, AXI
>   Ethernet core ...
>
> when used for Ethernet, a uAPI is not needed. The FIFO driver would
> just expose an kernel internal API the Ethernet driver would use. Are
> there any Ethernet devices using it? Is there a driver for the AXI
> Ethernet core?

As I said to Greg K-H, it's 'chameleon' hardware because we don't know
what it'll be used for. It could be SDR or Ethernet or whatever it is
programmed for. The main thing is that it is a streaming interface.
But we cannot assume the use case.

> Does drivers/net/ethernet/xilinx/* duplicate the same
> code? xilinx_axienet_main.c says:
>
>  * TODO:
>  *  - Add Axi Fifo support.
>
> which could be this.
>
> As GregKH said, find some hardware using these IP cores, or synthesise
> your own, and then work on the driver.
>
>         Andrew

Yes, the Axinet driver's TODO suggests adding AXI FIFO support.
Currently, it routes
packets through the AXI DMA engine, but the TODO mentions:

 * TODO:
 *  - Add Axi Fifo support.
 * - Factor out Axi DMA code into a separate driver.

This suggests that the AXI FIFO is merely a different configuration of
the axinet
driver, allowing a Xilinx AXI FIFO device to be used for ethernet.

It does not, however, establish how the AXI Stream FIFO IP is intended to be
used outside of the Ethernet context. Since the AXI Stream FIFO is a
general-purpose IP block used in a variety of FPGA designs, it is not yet
clear whether the Ethernet use case fully defines its role in the kernel, or
whether it should be treated as a more general streaming component with
multiple potential consumers.

Thanks,
Arihan Bhor

Re: [RFC] drivers/staging/axis-fifo: TODO file and subsystem direction

[Andrew Lunn]

On Mon, Jun 01, 2026 at 11:35:14AM +0530, Grewstad wrote:
> On Mon, Jun 1, 2026 at 1:22 AM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> >
> > In addition to what GregKH said, look at the vendor information:
> >
> > https://docs.amd.com/r/en-US/pg080-axi-fifo-mm-s/Core-Overview
> >
> >   The AXI4-Stream FIFO core was designed to provide memory-mapped
> >   access to an AXI4-Stream interface connected to other IP (such as
> >   the AXI Ethernet core). Systems must be built through the AMD
> >   Vivado™ Design Suite to attach the AXI4-Stream FIFO core, AXI
> >   Ethernet core ...
> >
> > when used for Ethernet, a uAPI is not needed. The FIFO driver would
> > just expose an kernel internal API the Ethernet driver would use. Are
> > there any Ethernet devices using it? Is there a driver for the AXI
> > Ethernet core?
> 
> As I said to Greg K-H, it's 'chameleon' hardware because we don't know
> what it'll be used for. It could be SDR or Ethernet or whatever it is
> programmed for. The main thing is that it is a streaming interface.
> But we cannot assume the use case.

Flip that around. What is it actually used for today? Make sure it has
the correct APIs needed for what it does now. New APIs can always be
added latter, especially if they are in-kernel, code to glue it to an
Ethernet driver for example. 

However, a grep for XIL_AXIS_FIFO suggests nothing in-kernel actually
uses it.

Are there any real users from user space? You talk about SDR, does GNU
Radio use it? Using what hardware?

If you have no idea how the code is used, you cannot say what the
correct interface is....

	Andrew

Re: [RFC] drivers/staging/axis-fifo: TODO file and subsystem direction

[Grewstad]

Thanks. My research shows that no user-space application depends on
this driver. As you said, we cannot determine the subsystem without
knowing the actual end users.

Thanks,
Arihan Bhor

On Mon, Jun 1, 2026 at 5:59 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Mon, Jun 01, 2026 at 11:35:14AM +0530, Grewstad wrote:
> > On Mon, Jun 1, 2026 at 1:22 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > >
> > >
> > > In addition to what GregKH said, look at the vendor information:
> > >
> > > https://docs.amd.com/r/en-US/pg080-axi-fifo-mm-s/Core-Overview
> > >
> > >   The AXI4-Stream FIFO core was designed to provide memory-mapped
> > >   access to an AXI4-Stream interface connected to other IP (such as
> > >   the AXI Ethernet core). Systems must be built through the AMD
> > >   Vivado™ Design Suite to attach the AXI4-Stream FIFO core, AXI
> > >   Ethernet core ...
> > >
> > > when used for Ethernet, a uAPI is not needed. The FIFO driver would
> > > just expose an kernel internal API the Ethernet driver would use. Are
> > > there any Ethernet devices using it? Is there a driver for the AXI
> > > Ethernet core?
> >
> > As I said to Greg K-H, it's 'chameleon' hardware because we don't know
> > what it'll be used for. It could be SDR or Ethernet or whatever it is
> > programmed for. The main thing is that it is a streaming interface.
> > But we cannot assume the use case.
>
> Flip that around. What is it actually used for today? Make sure it has
> the correct APIs needed for what it does now. New APIs can always be
> added latter, especially if they are in-kernel, code to glue it to an
> Ethernet driver for example.
>
> However, a grep for XIL_AXIS_FIFO suggests nothing in-kernel actually
> uses it.
>
> Are there any real users from user space? You talk about SDR, does GNU
> Radio use it? Using what hardware?
>
> If you have no idea how the code is used, you cannot say what the
> correct interface is....
>
>         Andrew

Re: [RFC] drivers/staging/axis-fifo: TODO file and subsystem direction

[Greg KH]

On Mon, Jun 01, 2026 at 10:15:49PM +0530, Grewstad wrote:
> Thanks. My research shows that no user-space application depends on
> this driver. As you said, we cannot determine the subsystem without
> knowing the actual end users.

If no one is using it, why don't we just delete it then?  It can come
back if someone shows a real use-case for it.

thanks,

greg k-h

Re: [RFC] drivers/staging/axis-fifo: TODO file and subsystem direction

[Grewstad]

On Tue, Jun 2, 2026 at 11:28 AM Greg KH <gregkh@linuxfoundation.org> wrote:

> If no one is using it, why don't we just delete it then?  It can come
> back if someone shows a real use-case for it.

Yes, this is what i was thinking. These boards are generally used for
development and research teams can probably maintain a patch if
they really want it. As you said, it can always come back if a
user-space application depends on it.

One drawback that comes to mind is a development group may
currently be maintaining a proprietary application that depends on it.

Thanks,
Arihan Bhor

Re: [RFC] drivers/staging/axis-fifo: TODO file and subsystem direction

[Greg KH]

On Tue, Jun 02, 2026 at 12:07:48PM +0530, Grewstad wrote:
> On Tue, Jun 2, 2026 at 11:28 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> 
> > If no one is using it, why don't we just delete it then?  It can come
> > back if someone shows a real use-case for it.
> 
> Yes, this is what i was thinking. These boards are generally used for
> development and research teams can probably maintain a patch if
> they really want it. As you said, it can always come back if a
> user-space application depends on it.
> 
> One drawback that comes to mind is a development group may
> currently be maintaining a proprietary application that depends on it.

Then they will speak up when the driver goes away and we can revert the
removal quite easily.  It's not like code is ever "gone" for forever.

thanks,

greg k-h