-
Dan Williams authored
I am stepping down as dmaengine maintainer as the bulk of the activity in the subsystem is primarily targeted at the slave-dma case handled by Vinod, and I have recently been unable to give the few patches I do receive timely review. There is still an item in my backlog to eliminate the async_tx api and the constraints it poses on dmaengine drivers, but I need not hold on to the maintainer role in the meantime. I will still be subscribed to dmaengine@vger.kernel.org to answer questions, but all patches should be routed through Vinod unless/until a maintainer for the non-slave-dma use case arrives. It is non-entirely clear at this point that there is enough work going forward for a separate maintainer of the pure-offload case. Ongoing development of the ioatdma driver is handled by Dave. I'm still interested in reviewing ioatdma patches, but he is the primary maintainer/developer going forward. IOP platforms are not generating any traffic in my inbox, but if a patch did arrive I've long since lost access to hardware. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Dave Jiang <dave.jiang@intel.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com>
08223d80