On 23-03-21, 08:44, Dave Jiang wrote: > On 3/23/2021 4:56 AM, Jason Gunthorpe wrote: > > On Tue, Mar 23, 2021 at 05:15:30PM +0530, Vinod Koul wrote: > > > > Vinod, > > > > The series fixes the various 'struct device' lifetime handling in the > > > > idxd driver. The devm managed lifetime is incompatible with 'struct device' > > > > objects that resides in the idxd context. Tested with > > > > CONFIG_DEBUG_KOBJECT_RELEASE and address all issues from that. > > > Sorry for not looking into this earlier.. But I would like to check on > > > the direction idxd is taking. Somehow I get the feel the dmaengine is > > > not the right place for this. Considering that now we have auxdev merged > > > in, should the idxd be spilt into smaller function and no dmaengine > > > parts moved away from dmaengine... I think we do lack a subsystem for > > > all things accelerator in kernel atm... > > auxdev shouldn't be over-used IMHO. > > > > If the main purpose of the driver is dma engine then it is OK if the > > "core" part lives there too. > > Hi Vinod, > > So this patch series serves as the basis of getting the idxd dsa_bus_type > related bits fixed up so that auxdev is not necessary. When Jason reviewed > previous iterations of the mdev series, he noted that the mdev driver needs > to go under VFIO. After the auxdev conversion of the mdev series, Jason and > Dan after further review suggested that given there's an internal bus in > idxd driver already (dsa_bus_type), that can be used to load drivers rather > than needing to rely on auxiliary bus. But the implementation of the > dsa_bus_type needs some fixes. After this series, I have another series > that's going through internal review right now that will fixup the driver > setup and initialization of dsa_bus_type and allow us to load external > drivers for the wq. The in kernel use cases for DSA is still valid under > dmaengine so the core parts remains valid for dmaengine. The plan going > forward is after getting all the fixups in we are planning to: > > 1. Introduce UACCE framework support for idxd and have a wq driver resides > under drivers/misc/uacce/idxd to support the char device operations and > deprecate the current custom char dev in idxd. This should remove the burden > on you to deal with the char device. > > 2. Resubmit the mdev driver under drivers/vfio/mdev/idxd after Jason's > latest VFIO refactoring is done. > > 3. Introduce new kernel use cases with dmanegine API support for SVA > operations. > > Let me know if this sounds ok to you. Thanks! Yes that does sound reasonable to me, when should I expect this move to show up on list? -- ~Vinod
