Re: [PATCHv2 00/11]Get rid of all the old macro DMA_nBIT_MASK and use DMA_BIT_MASK(n) instead

* Andrew Morton [off-list ref] wrote:

On Thu, 19 Feb 2009 16:08:51 +0100
Ingo Molnar [off-list ref] wrote:

quoted

* Stefan Richter [off-list ref] wrote:

quoted

Yang Hongyang wrote:

quoted

v1->v2:fix s/micro/macro typo and keep the old defines
            of DMA_nBIT_MASK
----------------------
Replace all DMA_nBIT_MASK macro with the new DMA_BIT_MASK(n) macro

01:Replace all DMA_64BIT_MASK macro with DMA_BIT_MASK(64)
02:Replace all DMA_48BIT_MASK macro with DMA_BIT_MASK(48)
03:Replace all DMA_40BIT_MASK macro with DMA_BIT_MASK(40)
04:Replace all DMA_39BIT_MASK macro with DMA_BIT_MASK(39)
05:Replace all DMA_35BIT_MASK macro with DMA_BIT_MASK(35)
06:Replace all DMA_32BIT_MASK macro with DMA_BIT_MASK(32)
07:Replace all DMA_31BIT_MASK macro with DMA_BIT_MASK(31)
08:Replace all DMA_30BIT_MASK macro with DMA_BIT_MASK(30)
09:Replace all DMA_28BIT_MASK macro with DMA_BIT_MASK(28)
10:Replace all DMA_24BIT_MASK macro with DMA_BIT_MASK(24)
11:Update the old macro DMA_nBIT_MASK related documentations

Shouldn't you organize the patch series per subsystem, not per old
macro?  And then Cc the respective maintainers?

As it stands, the patches cannot be routed through the normal channels;
yet there is no fundamental reason to handle these patches differently
from normal patches.

Traditionally such trivially correct convert-it-all patches 
lived in -mm and were merged upstream in one go, near the end of 
the merge window.

Sprinkling it into dozens of subsystem channels (some of which 
are very unreliable) is neither good nor an economic use of our 
resources.

Patches that can potentially cause trouble should go via the 
usual channels.

yes, fun.

I hit several rejects merging these, easily fixed.  After this 
lot is merged there will probably be a few unconverted sites 
which will need a second pass.  After that we can think about 
removing the old #defines.

Yeah. I wanted to suggest for you to _drop_ all conflicts - 
because the old defines still live.

That makes it the easiest for you to keep it all merged up in 
the future too with minimum fuss, and we need a second pass 
anyway so dropping a few hunks is no big issue.

[ But since you merged it up that's fine too - it's just that 
  code that got changed recently and created conflicts has a 
  higher chance of being changed in the near future too - and 
  causing you ongoing conflicts in that area, in the next ~1.5 
  months until the next merge window closes. ]

	Ingo