linux-kernel - Re: [RESEND PATCH V12 XDMA 1/2] dmaengine: xilinx: xdma: Add xilinx xdma driver

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]

Date:   Tue, 21 Feb 2023 19:51:56 -0800
From:   Lizhi Hou <lizhi.hou@....com>
To:     Martin Tůma <tumic@...see.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>
CC:     <vkoul@...nel.org>, <dmaengine@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <max.zhen@....com>,
        <sonal.santan@....com>, <larry.liu@....com>, <brian.xu@....com>
Subject: Re: [RESEND PATCH V12 XDMA 1/2] dmaengine: xilinx: xdma: Add xilinx
 xdma driver


On 2/21/23 13:46, Martin Tůma wrote:
> On 21. 02. 23 22:06, Geert Uytterhoeven wrote:
>> Hi Martin,
>>
>> On Tue, Feb 21, 2023 at 9:45 PM Martin Tůma <tumic@...see.org> wrote:
>>> On 21. 02. 23 14:25, Geert Uytterhoeven wrote:
>>>> No platform dependencies at all, while this is a platform driver that
>>>> relies on some other not-yet-existing driver creating an "xdma"
>>>> platform device?
>>>
>>> There is at least one "already-existing" driver based on this driver
>>> that is waiting in the v4l2 queue for xdma - our MGB4 driver:
>>> https://patchwork.kernel.org/project/linux-media/patch/20230207150119.5542-2-tumic@gpxsee.org/ 
>>>
>>
>> Thanks for the link!
>>
>> As VIDEO_MGB4 selects XILINX_XDMA, perhaps XILINX_XDMA
>> can be made invisible, unless compile-testing?
>>
>>      config XILINX_XDMA
>>          tristate "Xilinx DMA/Bridge Subsystem DMA Engine" if 
>> COMPILE_TEST
>>
>> Gr{oetje,eeting}s,
>>
>>                          Geert
>>
>
> Hi,
> I think that the XDMA driver will always be used by a superior PCIe 
> card driver like in our case (mgb4) and using it separately makes no 
> sense/is not possible, so disabling it until some of the superior 
> drivers selects it makes sense for me. But what about out-of-the-tree 
> modules based on xdma? Making the module "invisible" will make compile 
> them much harder I guess? And there will be proprietary drivers based 
> on xdma, see Xilinx XRT: 
> https://github.com/houlz0507/XRT-1/tree/xdma_v4_usage
>
> The xdma authors from Xilinx will definitely give you a more 
> authoritative answer. I'm just a "random" user of the xdma module. 
> Originally our mgb4 driver was based on our own xdma sub-driver (in 
> turn based on some old "test" driver from Xilinx) which I was glad we 
> could abandon when this xdma driver has appeared. I helped the xdma 
> module to become usable for PCIe cards like our v4l2 grabber, but the 
> original intents of the xdma driver are unknown to me. If it is XRT, 
> than Xilinx will probably like the module to stay visible.
>
> M.
>
There are PCIe devices which use the XDMA IP and would use this xdma 
driver. Out of tree drivers for Xilinx/AMD Alveo devices can switch to 
this in kernel xdma driver.


Thanks,

Lizhi