Re: [PATCH v2 0/2] dma: rename write-combine APIs with short form

[Ingo Molnar <mingo@kernel.org>]

* Luis R. Rodriguez <mcgrof@suse.com> wrote:

> On Thu, Jul 09, 2015 at 06:34:22PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > 
> > Ingo,
> > 
> > You had asked for this to be kept in my tree until the end of the
> > merge window. I sent it a bit earlier than the end of the merge window,
> > it failed to apply to Boris' tree as my series was based on linux-next
> > and then I went on a small vacation. Boris is now on vacation as well.
> > I've respinned this series today -- and fortunatley both of the patches
> > in this series apply to both Linus' tree and linux-next, I am in hopes
> > it applies to any other tree as well without conflicts. If not it should
> > be easy to respin with the Coccinelle SmPL rule defined.
> > 
> > I'll note that there are a few outstanding series related to MTRR, but
> > those do not have conflicts with these patches at all so feel free
> > to consider these before or after. Also I tried to get an ack for the
> > first patch [1] but that has gone under the radar I believe so
> > merging it now as part of this series and Cc'ing the maintainers.
> > That change is needed in order to make the code match the grammar
> > used by Coccinelle used in the expressed transformation.
> > 
> > [0] http://lkml.kernel.org/r/20150601085332.GA14549@gmail.com
> > [1] http://lkml.kernel.org/r/1434483609-25498-1-git-send-email-mcgrof@do-not-panic.com
> > 
> > Luis R. Rodriguez (2):
> >   drivers/dma/iop-adma: Use dma_alloc_writecombine() kernel-style
> >   dma: rename dma_*_writecombine() to dma_*_wc()
> 
> This series requires some adjustments based on linux-next. Do we accept renames 
> on -rcs? If so should I respin? If its too late for v4.2 I can try to shoot for 
> v4.3 but timing sending this at the right exact time seems a bit hard so any 
> advice for that is highly appreciated.

Could you please also add the old API names as aliases, so that we won't break the 
build if some driver bleeds in the old API use via linux-next? Then we can remove 
the old APIs in a kernel cycle or two.

It doesn't look too bad so I'll apply this (for v4.3) once you've done that and 
will carry it.

Thanks,

	Ingo