Re: [PATCH V2 1/4] drivers/fpga/amd: Add new driver amd versal-pci

[Yidong Zhang <yidong.zhang@amd.com>]

On 3/1/25 00:20, Xu Yilun wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
>> My last question for this topic:
>> If we decide to upstream both userPF and mgmtPF driver together, could them
>> be both within the drivers/fpga/amd as in-tree driver? This will help user
> 
> I don't look into your full driver stack. Generally, if your drivers are
> all about reprogramming, then yes. If they are also about all kinds of
> accelaration functions you'd better split them out in different domains.
> I may not have enough knowledge to make them correct.
> 

The driver has more features than just re-programing. The re-programing 
is already done in the embedded firmware that's why the mgmtPF driver is 
just a utility driver.

The userPF driver has features such as:
   xdma (already in drivers/xilinx/xdma as platform driver)
   qdma (already in drivers/amd/qdma as platform driver)
   mailbox and more which have not been upstreamed in linux kernel yet.

The driver architecture is:

   userPF driver (as pci_driver)
     qdma (as platform_driver)
     ..
     mailbox (as platform_driver)
        /\
        ||
        \/
     mailbox (as platform_driver)
   mgmtPF driver (as pci_driver)
        /\
        ||
        \/
     Embedded firmware (re-programing done here)

Right now, I am working on upstreaming the mgmtPF driver as pci_driver.
In the future, I think the userPF driver should be fitting into the
"drivers/fpga", given that should manage all these platform_drivers and 
utilize the fpga_region callbacks to online/offline services due to 
hardware changes after re-programing.

Thanks,
David

> Thanks,
> Yilun
> 
>> find source code easily.