linux-next: x86/cpufreq merge conflict

linux-next: x86/cpufreq merge conflict

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

Hi Dave, Ingo,

Today's linux-next cpufreq merge got a conflict in
drivers/cpufreq/cpufreq.c between commit
fdbf6c63c1bd250d45a59a6392fa18ccb360837b ("x86: Use performance variant
for_each_cpu_mask_nr") from the x86 tree and commit
ae47c109341198f814767d2f06a1c1e4c7910fb9 ("[CPUFREQ] change cpu freq
arrays to per_cpu variables") from the cpufreq tree.  The conflict is
just contextual with the former changing for_each_cpu_mask to
for_each_cpu_mask_nr in a couple of places right next to the latter
changing "cpufreq_cpu_data[j]" to "per_cpu(cpufreq_cpu_data, j)".

I did the obvious fixups but maybe worth a look.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: linux-next: x86/cpufreq merge conflict

[Dave Jones]

On Mon, May 19, 2008 at 02:39:27PM +1000, Stephen Rothwell wrote:
 > Hi Dave, Ingo,
 > 
 > Today's linux-next cpufreq merge got a conflict in
 > drivers/cpufreq/cpufreq.c between commit
 > fdbf6c63c1bd250d45a59a6392fa18ccb360837b ("x86: Use performance variant
 > for_each_cpu_mask_nr") from the x86 tree and commit
 > ae47c109341198f814767d2f06a1c1e4c7910fb9 ("[CPUFREQ] change cpu freq
 > arrays to per_cpu variables") from the cpufreq tree.  The conflict is
 > just contextual with the former changing for_each_cpu_mask to
 > for_each_cpu_mask_nr in a couple of places right next to the latter
 > changing "cpufreq_cpu_data[j]" to "per_cpu(cpufreq_cpu_data, j)".

ok, so how do we deal with this? Either Ingo or myself will have
to fix it up depending on whoever merges into .27 first I guess,
but in the interim, you'll have to carry that diff ?
Or should one of us drop a diff, and merge both through the other tree?

 > I did the obvious fixups but maybe worth a look.

btw, I've just slightly changed my workflow for the cpufreq.git tree.
>From now on, pull from the 'next' branch.   master will be untouched,
and 'fixes' will be stuff that will go to linus v. soon in the current cycle.

	Dave

-- 
http://www.codemonkey.org.uk

Re: linux-next: x86/cpufreq merge conflict

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

Hi Dave,

On Mon, 19 May 2008 18:26:04 -0400 Dave Jones <davej@redhat.com> wrote:
>
> On Mon, May 19, 2008 at 02:39:27PM +1000, Stephen Rothwell wrote:
>  > Hi Dave, Ingo,
>  > 
>  > Today's linux-next cpufreq merge got a conflict in
>  > drivers/cpufreq/cpufreq.c between commit
>  > fdbf6c63c1bd250d45a59a6392fa18ccb360837b ("x86: Use performance variant
>  > for_each_cpu_mask_nr") from the x86 tree and commit
>  > ae47c109341198f814767d2f06a1c1e4c7910fb9 ("[CPUFREQ] change cpu freq
>  > arrays to per_cpu variables") from the cpufreq tree.  The conflict is
>  > just contextual with the former changing for_each_cpu_mask to
>  > for_each_cpu_mask_nr in a couple of places right next to the latter
>  > changing "cpufreq_cpu_data[j]" to "per_cpu(cpufreq_cpu_data, j)".
> 
> ok, so how do we deal with this? Either Ingo or myself will have
> to fix it up depending on whoever merges into .27 first I guess,
> but in the interim, you'll have to carry that diff ?
> Or should one of us drop a diff, and merge both through the other tree?

This conflict appears to have vanished today.  So something changed in
your tree or Ingo's tree.

Normally trivial conflicts like this I can just carry. If they occur
for Linus (when your code goes upstream) he can just fix them up as well.
Also "git rerere" remembers the conflict fix for me and just applies it
again if the conflict reappears.

> btw, I've just slightly changed my workflow for the cpufreq.git tree.
> >From now on, pull from the 'next' branch.   master will be untouched,
> and 'fixes' will be stuff that will go to linus v. soon in the current cycle.

I have updated for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]