On Wed, Aug 9, 2017 at 7:15 PM, Dan Williams <dan.j.willi...@intel.com> wrote: > On Mon, Aug 7, 2017 at 9:39 AM, Dave Jiang <dave.ji...@intel.com> wrote: >> In preparation of adding an API to perform SG to/from buffer for dmaengine, >> we will change DMA_SG to DMA_SG_SG in order to explicitly making clear what >> this op type is for. >> >> Signed-off-by: Dave Jiang <dave.ji...@intel.com> >> --- >> Documentation/dmaengine/provider.txt | 2 +- >> drivers/crypto/ccp/ccp-dmaengine.c | 2 +- >> drivers/dma/at_hdmac.c | 8 ++++---- >> drivers/dma/dmaengine.c | 2 +- >> drivers/dma/dmatest.c | 12 ++++++------ >> drivers/dma/fsldma.c | 2 +- >> drivers/dma/mv_xor.c | 6 +++--- >> drivers/dma/nbpfaxi.c | 2 +- >> drivers/dma/ste_dma40.c | 6 +++--- >> drivers/dma/xgene-dma.c | 4 ++-- >> drivers/dma/xilinx/zynqmp_dma.c | 2 +- >> include/linux/dmaengine.h | 2 +- >> 12 files changed, 25 insertions(+), 25 deletions(-) > > Given the prevalence and age of DMA_SG I think we should call the new > op DMA_SG_SINGLE, or something like that, so that we don't surprise > someone who was expecting the old command type.
Oh wait, you already call the new op DMA_MEMCPY_SG, so why does the old one need to change? ...and thinking about it further why do we need a new op at all? Couldn't we just pass in a single entry scatterlist that was setup on the stack with memcpy target address? _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
