staging: axis-fifo: remove driver

Signed-off-by Arihan Bhor <[email protected]>

---

On Tue, Jun 02, 2026 at 04:01:53PM +0530, Arihan Bhor wrote:

I don't think we should delete this driver. From reading the git log, Ovidiu Panait was obviously using this code last year. Let's also add Jacob Feder, although he hasn't touched the code in 8 years, he still might know if there are other users.

Also no commit message.

Quoted 7 lines · Dan Carpenter

On Tue, Jun 02, 2026 at 04:01:53PM +0530, Arihan Bhor wrote:

I don't think we should delete this driver. From reading the git log, Ovidiu Panait was obviously using this code last year. Let's also add Jacob Feder, although he hasn't touched the code in 8 years, he still might know if there are other users.

I could not find any user-space applications that depend on this driver.

https://lore.kernel.org/lkml/CAD03fjb=_kW9=q9YV4qnQ5GD=HMB5Bx7pf3+AFcgDR2gVc1V6Q@mail.gmail.com/
I was looking for any users of this driver on the linux-kernel, linux-staging, and linux-arm-kernel mailing lists as well as Jacob Feder, and received no replies since I posted it 1 day ago. If someone is using it or maintaining a proprietary app, they will complain and we can bring the driver back.

Quoted 9 lines · Grewstad

Quoted 7 lines · Dan Carpenter

On Tue, Jun 02, 2026 at 04:01:53PM +0530, Arihan Bhor wrote:

I don't think we should delete this driver. From reading the git log, Ovidiu Panait was obviously using this code last year. Let's also add Jacob Feder, although he hasn't touched the code in 8 years, he still might know if there are other users.

Quoted 7 lines

I could not find any user-space applications that depend on this driver.

https://lore.kernel.org/lkml/CAD03fjb=_kW9=q9YV4qnQ5GD=HMB5Bx7pf3+AFcgDR2gVc1V6Q@mail.gmail.com/
I was looking for any users of this driver on the linux-kernel, linux-staging, and linux-arm-kernel mailing lists as well as Jacob Feder, and received no replies since I posted it 1 day ago. If someone is using it or maintaining a proprietary app, they will complain and we can bring the driver back.

Here are people using it and running into issues in Jan 2025.
https://adaptivesupport.amd.com/s/question/0D54U00008zRBdISAW/vitis-is-not-creating-a-driver-entry-for-axififomm-43?language=zh_CN
Someone provides a work around:
https://adaptivesupport.amd.com/s/question/0D54U00008sLBuMSAW/how-to-use-the-axi-stream-fifo-drivers-xllfifoh-xllfifogc-etc-in-the-project?language=en_US
Then Ovidiu Panait fixed the bug in Sep by adding the correct compatible.

regards,
dan carpenter

I was using this driver to play around with an FPGA board I have (Arty Z7-20), so not for commercial purposes. This IP provides a convenient way to move data to/from a custom IP in the FPGA. I am using it mostly for testing.

I think there are no in-tree users mainly because the IP it talks to lives in the FPGA fabric, and drivers for custom FPGA IP blocks generally don't get upstreamed.

However, there is the problem of what subsystem this belongs to. It was suggested to be turned into a DMA controller to get it moved out of staging:
https://lore.kernel.org/all/20260227-unboxed-customary-7ce6eda1858c@spud/

Here are people using it and running into issues in Jan 2025.
https://adaptivesupport.amd.com/s/question/0D54U00008zRBdISAW/vitis-is-not-creating-a-driver-entry-for-axififomm-43?language=zh_CN
Someone provides a work around:
https://adaptivesupport.amd.com/s/question/0D54U00008sLBuMSAW/how-to-use-the-axi-stream-fifo-drivers-xllfifoh-xllfifogc-etc-in-the-project?language=en_US
Then Ovidiu Panait fixed the bug in Sep by adding the correct compatible.

I ’ve gotten a few emails over the years from people using it, and there is also development happening in parallel on the original github repo:
https://github.com/jacobfeder/axisfifo

But I am not sure that this fits as a DMA controller, as it has no DMA capabilities. The CPU moves every word individually to and from a register.

My understanding is that the real Xilinx dmaengine IP is drivers/dma/xilinx/xilinx_dma.c and this IP is just a simpler, register based alternative to move data between the CPU and the FPGA fabric.

Quoted 4 lines · Ovidiu Panait

I was using this driver to play around with an FPGA board I have (Arty Z7-20), so not for commercial purposes. This IP provides a convenient way to move data to/from a custom IP in the FPGA. I am using it mostly for testing.

Are you still using it?

Quoted 7 lines

I think there are no in-tree users mainly because the IP it talks to lives in the FPGA fabric, and drivers for custom FPGA IP blocks generally don't get upstreamed.

However, there is the problem of what subsystem this belongs to. It was suggested to be turned into a DMA controller to get it moved out of staging:
https://lore.kernel.org/all/20260227-unboxed-customary-7ce6eda1858c@spud/

This is the main reason i suggested its deletion. it is very difficult to group it into any particular subsystem because at a low level it is just a 'dumb buffer'. If we do not know its end users and which software uses it, it will probably be very difficult to move it out of staging.

Quoted 6 lines

Here are people using it and running into issues in Jan 2025.
https://adaptivesupport.amd.com/s/question/0D54U00008zRBdISAW/vitis-is-not-creating-a-driver-entry-for-axififomm-43?language=zh_CN
Someone provides a work around:
https://adaptivesupport.amd.com/s/question/0D54U00008sLBuMSAW/how-to-use-the-axi-stream-fifo-drivers-xllfifoh-xllfifogc-etc-in-the-project?language=en_US
Then Ovidiu Panait fixed the bug in Sep by adding the correct compatible.

There are obviously some users, but in my honest opinion too few, too minor and too unverified to justify its maintenance in the kernel, especially because we have no feedback loop for the development of the driver.

Quoted 2 lines

I ’ve gotten a few emails over the years from people using it, and there is also development happening in parallel on the original github repo:
https://github.com/jacobfeder/axisfifo

This project has basically ground to a halt now, three commits in 2025 and basically dead for a year now.

Thanks,
Arihan Bhor

Quoted 6 lines

But I am not sure that this fits as a DMA controller, as it has no DMA capabilities. The CPU moves every word individually to and from a register.

My understanding is that the real Xilinx dmaengine IP is drivers/dma/xilinx/xilinx_dma.c and this IP is just a simpler, register based alternative to move data between the CPU and the FPGA fabric.

Hi,

On 6/1/26 09:15, Grewstad wrote:

It is clear that driver in current state can't be used with axi ethernet out of box because pretty much it is just about user interface for fifo via char device fops. But we are talking about the same IP used in specific scenario and this driver doesn't implement integration which can be used in ethernet driver.

I don't think you will find out any in-tree user because driver purpose is different. It is about providing a user way via char device to push data to axi streaming interface which can be consumed by user logic. It is generic way how to push data there without writing specialized kernel driver for custom HW. I think this is leaf driver which provide a way to axi fifo streaming interface

where stream is connected to custom HW which consumes it. I can understand that this can be very useful for a lot of people who wants to process data from user space via custom logic with using streaming interface.

And I don't have any issue to agree to move the driver out of staging to common location.

Quoted 9 lines · Grewstad

Quoted 7 lines · Dan Carpenter

On Tue, Jun 02, 2026 at 04:01:53PM +0530, Arihan Bhor wrote:

I don't think we should delete this driver. From reading the git log, Ovidiu Panait was obviously using this code last year. Let's also add Jacob Feder, although he hasn't touched the code in 8 years, he still might know if there are other users.

Quoted 7 lines

I could not find any user-space applications that depend on this driver.

https://lore.kernel.org/lkml/CAD03fjb=_kW9=q9YV4qnQ5GD=HMB5Bx7pf3+AFcgDR2gVc1V6Q@mail.gmail.com/
I was looking for any users of this driver on the linux-kernel, linux-staging, and linux-arm-kernel mailing lists as well as Jacob Feder, and received no replies since I posted it 1 day ago. If someone is using it or maintaining a proprietary app, they will complain and we can bring the driver back.

Here are people using it and running into issues in Jan 2025.
https://adaptivesupport.amd.com/s/question/0D54U00008zRBdISAW/vitis-is-not-creating-a-driver-entry-for-axififomm-43?language=zh_CN
Someone provides a work around:
https://adaptivesupport.amd.com/s/question/0D54U00008sLBuMSAW/how-to-use-the-axi-stream-fifo-drivers-xllfifoh-xllfifogc-etc-in-the-project?language=en_US
Then Ovidiu Panait fixed the bug in Sep by adding the correct compatible.

regards,
dan carpenter

Adding Michal Simek, as he posted some relevant points in another thread.

Quoted 17 lines · Michal Simek

Hi,

On 6/1/26 09:15, Grewstad wrote:

It is clear that driver in current state can't be used with axi ethernet out of box because pretty much it is just about user interface for fifo via char device fops. But we are talking about the same IP used in specific scenario and this driver doesn't implement integration which can be used in ethernet driver.

I don't think you will find out any in-tree user because driver purpose is different. It is about providing a user way via char device to push data to axi streaming interface which can be consumed by user logic. It is generic way how to push data there without writing specialized kernel driver for custom HW. I think this is leaf driver which provide a way to axi fifo streaming interface

Quoted 6 lines

where stream is connected to custom HW which consumes it. I can understand that this can be very useful for a lot of people who wants to process data from user space via custom logic with using streaming interface.

And I don't have any issue to agree to move the driver out of staging to common location.

Thanks for letting me know. When you say common location, can you give your opinion on where it can be moved? We cannot find any user-space applications that use this driver, as you said it is a 'leaf driver'. Because of this, we do not know
how it is used, who the end users are and hence we dont know where it can be moved.