[xdma] alonbl's stable patchset

[alonbl]

Xilinx developers do not maintain the xdma driver and does not cooperate on github as well, I collected stable fixes of the xdma driver for people use and review.

WARNING: The xdma driver is far from being production grade, it crashes the kernel when aio is used, crashes when readv/writev is used, it have fundamental issues that are solved in this series, it loses sync at random time splitting buffers into parts, it also does not respect small buffer boundary.

XDMA DMA engine was merged into mainline since linux-6.3, staging is at https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git/tree/drivers/dma/xilinx/xdma.c a user bridge is missing so we can switch.

The following patchset at least provides some sanity for EOP and stream based synchronous continues allocation operations.

Thanks for all contributors.

Notice

The name of the module is renamed from xdma.ko to xdma-chr.ko due to a conflict with latest merge of xdma.ko dmaengine into upstream.

Patchset includes

Reference	Description
	xdma: rename module to xdma-chr
	xdma: build improvements
#218	xdma: correct typos in xdma_mod.c
#226	xdma: cdev_ctrl: use resource_size_t for pci_resource_start()
	xdma: libxdma: fix resource free on open
#158	xmda: set module parameter timeouts as milliseconds
#92	xdma: simplify next_adj setting
#190	xdma: fixed PCIe domain and bus values in info ioctl
#161	xdma: fix decs_cmpl and flush when eop received
#144	xdma: explicitly stop engine on transfer completion
#252,#259	xdma: add linux 6.5 support

[hmaarrfk]

I remember when I was looking at options for XDMA, I ran into https://gitlab.com/WZab/Artix-DMA1

We have been maintaining a significant set of patches for QDMA (not XDMA), at the time required to avoid crashes, and kernel panics.

Over the many years, Xilinx did address some of the crashes, we still avoid things like aoi, and maybe preadv.

Xilinx also tended to break compatibility by changing the order inside enums. This has caused us great headaches with backward compatibility. Ultimately, we have decided to simply undo their ordering changing, for our own compatibility purposes.

We periodically rebase with Xilinx's patches, but their refusal to acknowledge anything posted here has been very frustrating.

[alonbl]

Thank you @hmaarrfk, Thank you for your insights, yes, Xilinx is doing a very bad job in supporting their own product, I am unsure what they gain provided it simply does not work. Alon

[hmaarrfk]

Working in a small company, and I presume the team in charge of support is quite small, I believe there is a directive to simply ignore whatever is posted here.

They do however, monitor their forum. That isn't to say it is particularly amazing advice they gave, mostly due to the fact that sharing code, designs, and environment is inherently hard with hardware, but I have been able to get replies from people that were knowledgeable about the problems by posting there.

Its juts a shame that they won't take a look here when specific resolutions, less than 10 lines long each, would fix real problems in the code.

[eniv]

Hi Alon, Thanks a lot for maintaining your fork! Can I suggest that you avoid using forced-push and simply commit in a conventional way? When you force push the commit hashes change. This make it harder for someone who wants to keep up with the new changes and just cherry pick them.

[alonbl]

@eniv this is a downstream patchset, it is not a development, the patchset is a set of patches each is performing a specific change on top of upstream, it will always be rebased (forced push) and ordered by the most trivial to the most intrusive to ease upstream merge. this behavior is same as any downstream distribution/subsystem/maintainer.