On Tue, Mar 23, 2021 at 05:15:30PM +0530, Vinod Koul wrote: > Hi Dave, > > On 22-03-21, 16:31, Dave Jiang wrote: > > v7: > > - Fix up the 'struct device' setup in char device code (Jason) > > - Split out the char dev fixes (Jason) > > - Split out the DMA dev fixes (Dan) > > - Split out the each of the conf_dev fixes > > - Split out removal of the pcim_* calls > > - Split out removal of the devm_* calls > > - Split out the fixes for interrupt config calls > > - Reviewed by Dan. > > > > v6: > > - Fix char dev initialization issues (Jason) > > - Fix other 'struct device' initialization issues. > > > > v5: > > - Rebased against 5.12-rc dmaengine/fixes > > v4: > > - fix up the life time of cdev creation/destruction (Jason) > > - Tested with KASAN and other memory allocation leak detections. (Jason) > > > > v3: > > - Remove devm_* for irq request and cleanup related bits (Jason) > > v2: > > - Remove all devm_* alloc for idxd_device (Jason) > > - Add kref dep for dma_dev (Jason) > > > > 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. Jason