linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Linux Crypto List <linux-crypto@vger.kernel.org>
Cc: Linux Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Chang S. Bae" <chang.seok.bae@intel.com>,
	Sasha Levin <sashal@kernel.org>, Uros Bizjak <ubizjak@gmail.com>
Subject: linux-next: manual merge of the tip tree with the crypto tree
Date: Tue, 21 Jul 2020 14:28:45 +1000	[thread overview]
Message-ID: <20200721142845.76ebea00@canb.auug.org.au> (raw)

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/include/asm/inst.h

between commit:

  d7866e503bdc ("crypto: x86 - Remove include/asm/inst.h")
(also "crypto: x86 - Put back integer parts of include/asm/inst.h"
which I have added to the crypto tree merge today)

from the crypto tree and commit:

  eaad981291ee ("x86/entry/64: Introduce the FIND_PERCPU_BASE macro")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/include/asm/inst.h
index 438ccd4f3cc4,d063841a17e3..000000000000
--- a/arch/x86/include/asm/inst.h
+++ b/arch/x86/include/asm/inst.h
@@@ -143,6 -203,124 +143,21 @@@
  	.macro MODRM mod opd1 opd2
  	.byte \mod | (\opd1 & 7) | ((\opd2 & 7) << 3)
  	.endm
+ 
 -	.macro PSHUFB_XMM xmm1 xmm2
 -	XMM_NUM pshufb_opd1 \xmm1
 -	XMM_NUM pshufb_opd2 \xmm2
 -	PFX_OPD_SIZE
 -	PFX_REX pshufb_opd1 pshufb_opd2
 -	.byte 0x0f, 0x38, 0x00
 -	MODRM 0xc0 pshufb_opd1 pshufb_opd2
 -	.endm
 -
 -	.macro PCLMULQDQ imm8 xmm1 xmm2
 -	XMM_NUM clmul_opd1 \xmm1
 -	XMM_NUM clmul_opd2 \xmm2
 -	PFX_OPD_SIZE
 -	PFX_REX clmul_opd1 clmul_opd2
 -	.byte 0x0f, 0x3a, 0x44
 -	MODRM 0xc0 clmul_opd1 clmul_opd2
 -	.byte \imm8
 -	.endm
 -
 -	.macro PEXTRD imm8 xmm gpr
 -	R32_NUM extrd_opd1 \gpr
 -	XMM_NUM extrd_opd2 \xmm
 -	PFX_OPD_SIZE
 -	PFX_REX extrd_opd1 extrd_opd2
 -	.byte 0x0f, 0x3a, 0x16
 -	MODRM 0xc0 extrd_opd1 extrd_opd2
 -	.byte \imm8
 -	.endm
 -
 -	.macro AESKEYGENASSIST rcon xmm1 xmm2
 -	XMM_NUM aeskeygen_opd1 \xmm1
 -	XMM_NUM aeskeygen_opd2 \xmm2
 -	PFX_OPD_SIZE
 -	PFX_REX aeskeygen_opd1 aeskeygen_opd2
 -	.byte 0x0f, 0x3a, 0xdf
 -	MODRM 0xc0 aeskeygen_opd1 aeskeygen_opd2
 -	.byte \rcon
 -	.endm
 -
 -	.macro AESIMC xmm1 xmm2
 -	XMM_NUM aesimc_opd1 \xmm1
 -	XMM_NUM aesimc_opd2 \xmm2
 -	PFX_OPD_SIZE
 -	PFX_REX aesimc_opd1 aesimc_opd2
 -	.byte 0x0f, 0x38, 0xdb
 -	MODRM 0xc0 aesimc_opd1 aesimc_opd2
 -	.endm
 -
 -	.macro AESENC xmm1 xmm2
 -	XMM_NUM aesenc_opd1 \xmm1
 -	XMM_NUM aesenc_opd2 \xmm2
 -	PFX_OPD_SIZE
 -	PFX_REX aesenc_opd1 aesenc_opd2
 -	.byte 0x0f, 0x38, 0xdc
 -	MODRM 0xc0 aesenc_opd1 aesenc_opd2
 -	.endm
 -
 -	.macro AESENCLAST xmm1 xmm2
 -	XMM_NUM aesenclast_opd1 \xmm1
 -	XMM_NUM aesenclast_opd2 \xmm2
 -	PFX_OPD_SIZE
 -	PFX_REX aesenclast_opd1 aesenclast_opd2
 -	.byte 0x0f, 0x38, 0xdd
 -	MODRM 0xc0 aesenclast_opd1 aesenclast_opd2
 -	.endm
 -
 -	.macro AESDEC xmm1 xmm2
 -	XMM_NUM aesdec_opd1 \xmm1
 -	XMM_NUM aesdec_opd2 \xmm2
 -	PFX_OPD_SIZE
 -	PFX_REX aesdec_opd1 aesdec_opd2
 -	.byte 0x0f, 0x38, 0xde
 -	MODRM 0xc0 aesdec_opd1 aesdec_opd2
 -	.endm
 -
 -	.macro AESDECLAST xmm1 xmm2
 -	XMM_NUM aesdeclast_opd1 \xmm1
 -	XMM_NUM aesdeclast_opd2 \xmm2
 -	PFX_OPD_SIZE
 -	PFX_REX aesdeclast_opd1 aesdeclast_opd2
 -	.byte 0x0f, 0x38, 0xdf
 -	MODRM 0xc0 aesdeclast_opd1 aesdeclast_opd2
 -	.endm
 -
 -	.macro MOVQ_R64_XMM opd1 opd2
 -	REG_TYPE movq_r64_xmm_opd1_type \opd1
 -	.if movq_r64_xmm_opd1_type == REG_TYPE_XMM
 -	XMM_NUM movq_r64_xmm_opd1 \opd1
 -	R64_NUM movq_r64_xmm_opd2 \opd2
 -	.else
 -	R64_NUM movq_r64_xmm_opd1 \opd1
 -	XMM_NUM movq_r64_xmm_opd2 \opd2
 -	.endif
 -	PFX_OPD_SIZE
 -	PFX_REX movq_r64_xmm_opd1 movq_r64_xmm_opd2 1
 -	.if movq_r64_xmm_opd1_type == REG_TYPE_XMM
 -	.byte 0x0f, 0x7e
 -	.else
 -	.byte 0x0f, 0x6e
 -	.endif
 -	MODRM 0xc0 movq_r64_xmm_opd1 movq_r64_xmm_opd2
 -	.endm
 -
+ .macro RDPID opd
+ 	REG_TYPE rdpid_opd_type \opd
+ 	.if rdpid_opd_type == REG_TYPE_R64
+ 	R64_NUM rdpid_opd \opd
+ 	.else
+ 	R32_NUM rdpid_opd \opd
+ 	.endif
+ 	.byte 0xf3
+ 	.if rdpid_opd > 7
+ 	PFX_REX rdpid_opd 0
+ 	.endif
+ 	.byte 0x0f, 0xc7
+ 	MODRM 0xc0 rdpid_opd 0x7
+ .endm
  #endif
  
  #endif

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

             reply	other threads:[~2020-07-21  4:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-21  4:28 Stephen Rothwell [this message]
2020-08-03 22:14 ` linux-next: manual merge of the tip tree with the crypto tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2022-11-28  1:29 Stephen Rothwell
2020-07-17  4:46 Stephen Rothwell
2020-07-17  6:27 ` Uros Bizjak
2020-07-17  6:44   ` Herbert Xu
2020-07-17  6:56     ` Stephen Rothwell
2020-07-17  7:31     ` Uros Bizjak
2020-07-20  4:03       ` Stephen Rothwell
2020-07-20  6:13         ` Uros Bizjak
2020-07-20  6:29           ` Stephen Rothwell
2020-07-20 11:59       ` Herbert Xu
2017-11-08  2:21 Stephen Rothwell
2015-10-12  3:24 Stephen Rothwell
2015-10-12  6:18 ` Herbert Xu
2015-06-17  3:21 Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200721142845.76ebea00@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=chang.seok.bae@intel.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=sashal@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=ubizjak@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).