linux-next.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: Re: linux-next: manual merge of the tip tree with the crypto tree
Date: Tue, 4 Aug 2020 08:14:02 +1000	[thread overview]
Message-ID: <20200804081402.70e81d3b@canb.auug.org.au> (raw)
In-Reply-To: <20200721142845.76ebea00@canb.auug.org.au>

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

Hi all,

On Tue, 21 Jul 2020 14:28:45 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> 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

This is now a conflict between the tip tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

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

  reply	other threads:[~2020-08-03 22:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-21  4:28 linux-next: manual merge of the tip tree with the crypto tree Stephen Rothwell
2020-08-03 22:14 ` Stephen Rothwell [this message]
  -- 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=20200804081402.70e81d3b@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).