> On Wed, Jun 16, 2021 at 01:05:36AM +0000, Wu, Hao wrote: > > > On 6/15/21 1:08 AM, Wu, Hao wrote: > > > >> Subject: [PATCH v4 1/4] fpga: dfl: reorganize to subdir layout > > > >> > > > >> From: Tom Rix <trix@xxxxxxxxxx> > > > >> > > > >> Follow drivers/net/ethernet/ which has control configs > > > >> NET_VENDOR_BLA that map to drivers/net/ethernet/bla > > > >> Since fpgas do not have many vendors, drop the 'VENDOR' and use > > > >> FPGA_BLA. > > > > Hi Tom, > > > > > > > > Thanks for this patch. : ) > > > > > > > > DFL is not a vendor, but something can be shared/reused. It's possible that > > > > other vendors reuse the same concepts and the drivers of DFL. If vendor > > > > drivers need to be moved inside sub folders, then maybe it's better to > > > > leave DFL in the parent folder? > > > > > > xrt is also not a vendor, more a subdevice framework like dfl. > > > > > > I am not sure what you mean by other dfl vendors can you give an example ? > > > > It's fine, but the description here is a little confusing on vendor/framework > > handling. No other vendor so far, but it's possible, DFL can be used in > > non-intel device, and related drivers can be reused as well. Then a fpga > > mgr driver depends on DFL, should be put inside dfl folder or new > > vendor's subfolder? > > > > Hao > > > > I'm somewhat neutral on this. If someone non-intel starts using DFL we could > also > move the common parts back ... That's fine. > > That being said, I'm not super convinced we have to move stuff in the > first place. I remember that the first submission of our code is having everything inside a sub folder, but was suggested that to have everything moved out, this is why we have dfl files here now. To be honest, I have the similar feeling as you, I didn't see any strong reason to make this something we must do, but both solutions should be fine. : ) Thanks Hao > > - Moritz
