lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0aa32a6f-2ec1-4ba8-ce62-2e998bc8c93a@gpxsee.org>
Date:   Wed, 30 Nov 2022 06:42:06 +0100
From:   Martin Tůma <tumic@...see.org>
To:     Lizhi Hou <lizhi.hou@....com>, vkoul@...nel.org,
        dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     max.zhen@....com, sonal.santan@....com, larry.liu@....com,
        brian.xu@....com
Subject: Re: [RESEND PATCH V10 XDMA 0/2] xilinx XDMA driver

On 22. 11. 22 18:21, Lizhi Hou wrote:
> Hello,
> 
> This V10 of patch series is to provide the platform driver to support the
> Xilinx XDMA subsystem. The XDMA subsystem is used in conjunction with the
> PCI Express IP block to provide high performance data transfer between host
> memory and the card's DMA subsystem. It also provides up to 16 user
> interrupt wires to user logic that generate interrupts to the host.
> 
>              +-------+       +-------+       +-----------+
>     PCIe     |       |       |       |       |           |
>     Tx/Rx    |       |       |       |  AXI  |           |
>   <=======>  | PCIE  | <===> | XDMA  | <====>| User Logic|
>              |       |       |       |       |           |
>              +-------+       +-------+       +-----------+
> 
> The XDMA has been used for Xilinx Alveo PCIe devices.
> And it is also integrated into Versal ACAP DMA and Bridge Subsystem.
>      https://www.xilinx.com/products/boards-and-kits/alveo.html
>      https://docs.xilinx.com/r/en-US/pg344-pcie-dma-versal/Introduction-to-the-DMA-and-Bridge-Subsystems
> 
> The device driver for any FPGA based PCIe device which leverages XDMA can
> call the standard dmaengine APIs to discover and use the XDMA subsystem
> without duplicating the XDMA driver code in its own driver.
> 
> Changes since v9:
> - Cleanup code based on review comments.
> 
> Changes since v8:
> - Fixed test robot failure on s390.
> 
> Changes since v7:
> - Used pci device pointer for dma_pool_create().
> 
> Changes since v6:
> - Fixed descriptor filling bug.
> 
> Changes since v5:
> - Modified user logic interrupt APIs to handle user logic IP which does not
>    have its own register to enable/disable interrupt.
> - Clean up code based on review comments.
> 
> Changes since v4:
> - Modified user logic interrupt APIs.
> 
> Changes since v3:
> - Added one patch to support user logic interrupt.
> 
> Changes since v2:
> - Removed tasklet.
> - Fixed regression bug introduced to V2.
> - Test Robot warning.
> 
> Changes since v1:
> - Moved filling hardware descriptor to xdma_prep_device_sg().
> - Changed hardware descriptor enum to "struct xdma_hw_desc".
> - Minor changes from code review comments.
> 
> Lizhi Hou (2):
>    dmaengine: xilinx: xdma: Add xilinx xdma driver
>    dmaengine: xilinx: xdma: Add user logic interrupt support
> 
>   MAINTAINERS                            |   11 +
>   drivers/dma/Kconfig                    |   14 +
>   drivers/dma/xilinx/Makefile            |    1 +
>   drivers/dma/xilinx/xdma-regs.h         |  173 ++++
>   drivers/dma/xilinx/xdma.c              | 1004 ++++++++++++++++++++++++
>   include/linux/dma/amd_xdma.h           |   16 +
>   include/linux/platform_data/amd_xdma.h |   34 +
>   7 files changed, 1253 insertions(+)
>   create mode 100644 drivers/dma/xilinx/xdma-regs.h
>   create mode 100644 drivers/dma/xilinx/xdma.c
>   create mode 100644 include/linux/dma/amd_xdma.h
>   create mode 100644 include/linux/platform_data/amd_xdma.h
> 

Hi,
I see that there is no response for more than two weeks on this driver, 
is there some problem with it? The XDMA driver is required for our mgb4
v4l2 driver to work:

https://patchwork.kernel.org/project/linux-media/patch/20221123140431.4730-2-tumic@gpxsee.org/

The patches not being included in the kernel block the progress on our 
driver as it naturally fails to compile and as a result the willingness 
to deal with our patch is quiet low among the v4l2 people... Thanks for 
any help.

Martin Tůma

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ