# Re: \[PATCH v4 10/11\] dma: rename dma\_\*\_writecombine() to dma\_\*\_wc()

- From: Andrew Morton \<akpm@linux-foundation.org\>
- Date: 2015-08-25 23:25:44 
- List: linux-fbdev
- Page: https://ratatoskr.run/linux-fbdev/2015/08/4564110
- Thread: https://ratatoskr.run/linux-fbdev/2015/08/4563068/t.md

```text
On Wed, 26 Aug 2015 01:19:13 +0200 "Luis R. Rodriguez" [ref] wrote:

> On Tue, Aug 25, 2015 at 01:43:58PM -0700, Andrew Morton wrote:
> > On Tue, 25 Aug 2015 17:48:37 +0200 "Luis R. Rodriguez" [ref] wrote:
> > 
> > > On Tue, Aug 25, 2015 at 09:53:18AM +0200, Ingo Molnar wrote:
> > > > Which kernel is this against? It has conflicts in 3 files with Linus's latest: 
> > > > v4.2-rc8.
> > > 
> > > Sorry I based it on linux-next, will respin the rename patch onto tip/auto-latest
> > > 
> > 
> > Doing that will make the patch kinda useless, because then the patch
> > will trash more mature work which is pending in linux-next, one week
> > before the merge window opens.
> > 
> > A better plan would be to base the patches on linux-next then wait for
> > 4.3-rc1.
> 
> There's a catch-22 issue here either way, for instance this rename
> patch has been being baked for probably 2 releases already but the
> difficulty has been trying to find the appropriate time to merge it
> without conflict.
> 
> If you do it in the beginning of the merge window, you have to ask
> yourself in what tree it will be done. Since subsystems are topic
> specific that means that subsystem will end up having a conflict
> at the end of the merge window.

Yes it's a special case.  I think the best way of handling such things
is to get them in to Linus either right at the end of the merge window
or the day after he releases -rc1.  This is when most people's trees
are mostly empty.


```