On Sat, Jul 18, 2015 at 05:42:42AM +0200, Ingo Molnar wrote: > > * Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote: > > > On Thu, Jul 09, 2015 at 06:34:22PM -0700, Luis R. Rodriguez wrote: > > > From: "Luis R. Rodriguez" <mcgrof@xxxxxxxx> > > > > > > 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@xxxxxxxxx > > > [1] http://lkml.kernel.org/r/1434483609-25498-1-git-send-email-mcgrof@xxxxxxxxxxxxxxxx > > > > > > 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. Sure, I'll be re-spinning now. Luis -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html