[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200720162927.4aedff0f@canb.auug.org.au>
Date: Mon, 20 Jul 2020 16:29:27 +1000
From: Stephen Rothwell <sfr@...b.auug.org.au>
To: Uros Bizjak <ubizjak@...il.com>
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
Hi Uros,
On Mon, 20 Jul 2020 08:13:51 +0200 Uros Bizjak <ubizjak@...il.com> wrote:
>
> 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.
Sorry, I see what happened now. Since your patch was not in the crypto
tree yet, I did a fixup to the tip tree merge based on your patch, but
did it by hand and didn't remove the XMM bits from the REG_TYPE
macro ...
So your original patch is probably all good (especially since you
actually tested it :-))
--
Cheers,
Stephen Rothwell
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists