linux-next: manual merge of the crypto tree

linux-next: manual merge of the crypto tree

[Stephen Rothwell]

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

Hi Herbert,

Today's linux-next merge of the crypto tree got a conflict in
include/asm-x86/cpufeature.h between commit
32e1d0a0651004f5fe47f85a2a5c725ad579a90c ("x64, x2apic/intr-remap: cpuid
bits for x2apic feature") from the x86 tree and commit
1f4f8a5d7935c81b5b3c7601ec9ac021db30ba4f ("crypto: crc32c - Use Intel
CRC32 instruction") from the crypto tree.

Just simple overlapping additions.  I added both of them and can carry
the fixup.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the crypto tree

[Herbert Xu]

On Thu, Aug 07, 2008 at 01:35:25PM +1000, Stephen Rothwell wrote:
> 
> Today's linux-next merge of the crypto tree got a conflict in
> include/asm-x86/cpufeature.h between commit
> 32e1d0a0651004f5fe47f85a2a5c725ad579a90c ("x64, x2apic/intr-remap: cpuid
> bits for x2apic feature") from the x86 tree and commit
> 1f4f8a5d7935c81b5b3c7601ec9ac021db30ba4f ("crypto: crc32c - Use Intel
> CRC32 instruction") from the crypto tree.
> 
> Just simple overlapping additions.  I added both of them and can carry
> the fixup.

Thanks Stephen!
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: linux-next: manual merge of the crypto tree

[Stephen Rothwell]

Hi Herbert,

On Thu, 7 Aug 2008 13:35:25 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the crypto tree got a conflict in
> include/asm-x86/cpufeature.h between commit
> 32e1d0a0651004f5fe47f85a2a5c725ad579a90c ("x64, x2apic/intr-remap: cpuid
> bits for x2apic feature") from the x86 tree and commit
> 1f4f8a5d7935c81b5b3c7601ec9ac021db30ba4f ("crypto: crc32c - Use Intel
> CRC32 instruction") from the crypto tree.
> 
> Just simple overlapping additions.  I added both of them and can carry
> the fixup.

This now also conflicts with commit
a648bf4632628c787abb0514277f2a231fca39ca ("x86, xsave: xsave cpuid
feature bits") from the x86 tree.

The fixup looks like below.  Maybe the X86_FEATURE_XMM4_2 bits could also
be added in the x86 tree.

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

diff --cc include/asm-x86/cpufeature.h
index 5ffd493,762f6a6..0000000
--- a/include/asm-x86/cpufeature.h
+++ b/include/asm-x86/cpufeature.h
@@@ -92,8 -91,7 +92,9 @@@
  #define X86_FEATURE_CX16	(4*32+13) /* CMPXCHG16B */
  #define X86_FEATURE_XTPR	(4*32+14) /* Send Task Priority Messages */
  #define X86_FEATURE_DCA		(4*32+18) /* Direct Cache Access */
+ #define X86_FEATURE_XMM4_2	(4*32+20) /* Streaming SIMD Extensions-4.2 */
 +#define X86_FEATURE_X2APIC	(4*32+21) /* x2APIC */
 +#define X86_FEATURE_XSAVE	(4*32+26) /* XSAVE */
  
  /* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC0000001, word 5 */
  #define X86_FEATURE_XSTORE	(5*32+ 2) /* on-CPU RNG present (xstore insn) */
@@@ -192,8 -190,7 +193,9 @@@ extern const char * const x86_power_fla
  #define cpu_has_gbpages		boot_cpu_has(X86_FEATURE_GBPAGES)
  #define cpu_has_arch_perfmon	boot_cpu_has(X86_FEATURE_ARCH_PERFMON)
  #define cpu_has_pat		boot_cpu_has(X86_FEATURE_PAT)
+ #define cpu_has_xmm4_2		boot_cpu_has(X86_FEATURE_XMM4_2)
 +#define cpu_has_x2apic		boot_cpu_has(X86_FEATURE_X2APIC)
 +#define cpu_has_xsave		boot_cpu_has(X86_FEATURE_XSAVE)
  
  #if defined(CONFIG_X86_INVLPG) || defined(CONFIG_X86_64)
  # define cpu_has_invlpg		1

Re: linux-next: manual merge of the crypto tree

[Stephen Rothwell]

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

On Mon, 25 Aug 2008 16:44:18 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Maybe the X86_FEATURE_XMM4_2 bits could also be added in the x86 tree.

Thinking about this, I am not sure that would achieve anything unless the
other two bit definitions were also added to the crypto tree.  So
probably not worth it (though it wouldn't hurt).

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

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

Re: linux-next: manual merge of the crypto tree

[Herbert Xu]

On Mon, Aug 25, 2008 at 04:44:18PM +1000, Stephen Rothwell wrote:
> 
> On Thu, 7 Aug 2008 13:35:25 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the crypto tree got a conflict in
> > include/asm-x86/cpufeature.h between commit
> > 32e1d0a0651004f5fe47f85a2a5c725ad579a90c ("x64, x2apic/intr-remap: cpuid
> > bits for x2apic feature") from the x86 tree and commit
> > 1f4f8a5d7935c81b5b3c7601ec9ac021db30ba4f ("crypto: crc32c - Use Intel
> > CRC32 instruction") from the crypto tree.
> > 
> > Just simple overlapping additions.  I added both of them and can carry
> > the fixup.
> 
> This now also conflicts with commit
> a648bf4632628c787abb0514277f2a231fca39ca ("x86, xsave: xsave cpuid
> feature bits") from the x86 tree.
> 
> The fixup looks like below.  Maybe the X86_FEATURE_XMM4_2 bits could also

Yep looks good.

> be added in the x86 tree.

Sure that sounds like a good idea.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: linux-next: manual merge of the crypto tree

[Ingo Molnar]

* Herbert Xu <herbert@gondor.apana.org.au> wrote:

> On Mon, Aug 25, 2008 at 04:44:18PM +1000, Stephen Rothwell wrote:
> > 
> > On Thu, 7 Aug 2008 13:35:25 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Today's linux-next merge of the crypto tree got a conflict in
> > > include/asm-x86/cpufeature.h between commit
> > > 32e1d0a0651004f5fe47f85a2a5c725ad579a90c ("x64, x2apic/intr-remap: cpuid
> > > bits for x2apic feature") from the x86 tree and commit
> > > 1f4f8a5d7935c81b5b3c7601ec9ac021db30ba4f ("crypto: crc32c - Use Intel
> > > CRC32 instruction") from the crypto tree.
> > > 
> > > Just simple overlapping additions.  I added both of them and can carry
> > > the fixup.
> > 
> > This now also conflicts with commit
> > a648bf4632628c787abb0514277f2a231fca39ca ("x86, xsave: xsave cpuid
> > feature bits") from the x86 tree.
> > 
> > The fixup looks like below.  Maybe the X86_FEATURE_XMM4_2 bits could also
> 
> Yep looks good.
> 
> > be added in the x86 tree.
> 
> Sure that sounds like a good idea.

new x86 feature bits should definitely show up in the x86 tree too. 
Could you please send a standalone patch that only touches the .h file, 
which could be applied to v2.6.27 as well? Thanks,

	Ingo

RE: linux-next: manual merge of the crypto tree

[Zhang, Austin]

>> new x86 feature bits should definitely show up in the x86 tree too
So can we add sse4.1 into this patch also as: 
#define X86_FEATURE_XMM4_1	(4*32+19)
even though now no obvious user is asking it in kernel. 

-----Original Message-----
From: Ingo Molnar [mailto:mingo@elte.hu] 
Sent: 2008年8月25日 15:39
To: Herbert Xu
Cc: Stephen Rothwell; linux-next@vger.kernel.org; Siddha, Suresh B; Zhang, Austin; Thomas Gleixner; H. Peter Anvin
Subject: Re: linux-next: manual merge of the crypto tree


* Herbert Xu <herbert@gondor.apana.org.au> wrote:

> On Mon, Aug 25, 2008 at 04:44:18PM +1000, Stephen Rothwell wrote:
> > 
> > On Thu, 7 Aug 2008 13:35:25 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Today's linux-next merge of the crypto tree got a conflict in
> > > include/asm-x86/cpufeature.h between commit
> > > 32e1d0a0651004f5fe47f85a2a5c725ad579a90c ("x64, x2apic/intr-remap: cpuid
> > > bits for x2apic feature") from the x86 tree and commit
> > > 1f4f8a5d7935c81b5b3c7601ec9ac021db30ba4f ("crypto: crc32c - Use Intel
> > > CRC32 instruction") from the crypto tree.
> > > 
> > > Just simple overlapping additions.  I added both of them and can carry
> > > the fixup.
> > 
> > This now also conflicts with commit
> > a648bf4632628c787abb0514277f2a231fca39ca ("x86, xsave: xsave cpuid
> > feature bits") from the x86 tree.
> > 
> > The fixup looks like below.  Maybe the X86_FEATURE_XMM4_2 bits could also
> 
> Yep looks good.
> 
> > be added in the x86 tree.
> 
> Sure that sounds like a good idea.

new x86 feature bits should definitely show up in the x86 tree too. 
Could you please send a standalone patch that only touches the .h file, 
which could be applied to v2.6.27 as well? Thanks,

	Ingo

Re: linux-next: manual merge of the crypto tree

[H. Peter Anvin]

Zhang, Austin wrote:
>>> new x86 feature bits should definitely show up in the x86 tree too
> So can we add sse4.1 into this patch also as: 
> #define X86_FEATURE_XMM4_1	(4*32+19)
> even though now no obvious user is asking it in kernel. 

The best would be to:

1. rename all the feature bits which have inconsistent names in their
    #defines and in /proc/cpuinfo;
2. generate the /proc/cpuinfo table
    (arch/x86/kernel/cpu/feature_names.c) automatically from
    cpufeature.h.

2. is quite trivial, and 1. can be done largely automatically.  I will 
experiment with this.

	-hpa

Re: linux-next: manual merge of the crypto tree

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

> Zhang, Austin wrote:
>>>> new x86 feature bits should definitely show up in the x86 tree too
>> So can we add sse4.1 into this patch also as: #define 
>> X86_FEATURE_XMM4_1	(4*32+19)
>> even though now no obvious user is asking it in kernel. 
>
> The best would be to:
>
> 1. rename all the feature bits which have inconsistent names in their
>    #defines and in /proc/cpuinfo;
> 2. generate the /proc/cpuinfo table
>    (arch/x86/kernel/cpu/feature_names.c) automatically from
>    cpufeature.h.
>
> 2. is quite trivial, and 1. can be done largely automatically.  I will  
> experiment with this.

i see you committed that into tip/x86/cpu - i just integrated that into 
tip/master and pushed out the result. This way starting at v2.6.28 we'll 
have only a single, non-redundant definition for CPU feature 
information, from which we auto-generate the rest.

	Ingo

Re: linux-next: manual merge of the crypto tree

[Ingo Molnar]

* Herbert Xu <herbert@gondor.apana.org.au> wrote:

> > The fixup looks like below.  Maybe the X86_FEATURE_XMM4_2 bits could 
> > also
> 
> Yep looks good.
> 
> > be added in the x86 tree.
> 
> Sure that sounds like a good idea.

they are upstream now:

| commit 2a61812af2e564cba2c8170cf96e1c823210f619
| Author: Austin Zhang <austin_zhang@linux.intel.com>
| Date:   Mon Aug 25 11:14:51 2008 -0400
|
|     x86: add X86_FEATURE_XMM4_2 definitions

so you should be able to pick this up once you merge linus-latest to the 
crypto tree.

	Ingo

Re: linux-next: manual merge of the crypto tree

[Herbert Xu]

On Thu, Aug 28, 2008 at 09:28:58AM +0200, Ingo Molnar wrote:
>
> | commit 2a61812af2e564cba2c8170cf96e1c823210f619
> | Author: Austin Zhang <austin_zhang@linux.intel.com>
> | Date:   Mon Aug 25 11:14:51 2008 -0400
> |
> |     x86: add X86_FEATURE_XMM4_2 definitions
> 
> so you should be able to pick this up once you merge linus-latest to the 
> crypto tree.

Thanks I'll do a rebase.
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: linux-next: manual merge of the crypto tree

[H. Peter Anvin]

Ingo Molnar wrote:
>>
>> 1. rename all the feature bits which have inconsistent names in their
>>    #defines and in /proc/cpuinfo;
>> 2. generate the /proc/cpuinfo table
>>    (arch/x86/kernel/cpu/feature_names.c) automatically from
>>    cpufeature.h.
>>
>> 2. is quite trivial, and 1. can be done largely automatically.  I will  
>> experiment with this.
> 
> i see you committed that into tip/x86/cpu - i just integrated that into 
> tip/master and pushed out the result. This way starting at v2.6.28 we'll 
> have only a single, non-redundant definition for CPU feature 
> information, from which we auto-generate the rest.
> 

I did #2; I haven't done #1, since that's an all-sourcebase change; it 
would probably make most sense to do at (approximately) the same time we 
do the include/asm-x86 -> arch/x86/include change.

	-hpa