[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFULd4YGFGSVqmHuor89e_hk9wT5pso3jcRiBkHP4ppx+W-D7g@mail.gmail.com>
Date: Mon, 20 Jul 2020 08:13:51 +0200
From: Uros Bizjak <ubizjak@...il.com>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Linux Crypto List <linux-crypto@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"Chang S. Bae" <chang.seok.bae@...el.com>,
Sasha Levin <sashal@...nel.org>
Subject: Re: linux-next: manual merge of the tip tree with the crypto tree
On Mon, Jul 20, 2020 at 6:03 AM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> > Please find attached the incremental patch that puts back integer
> > parts of inst.h. This resolves the conflict with the tip tree.
>
> The tip tree change needs the XMM parts kept as well, sorry.
Strange, because I did test my patch with the tip tree from
'origin/master' at commit a282cddefe90c4b21ef2c22a76a7c3ebd3ec6b86 and
the compilation produced the same lonely rdpid %eax in
.altinstr_replacement section. AFAICS, the header is included only for
RDPID macro, where XMM registers are unused.
> So I ended up just removing the actual now unused crypto instruction
> macros.
To avoid any further troubles, this is also OK with me.
Uros.
Powered by blists - more mailing lists