[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181204000623.6tmqntmxi2dydrlz@pburton-laptop>
Date: Tue, 4 Dec 2018 00:06:24 +0000
From: Paul Burton <paul.burton@...s.com>
To: Jakub Kicinski <jakub.kicinski@...ronome.com>
CC: "daniel@...earbox.net" <daniel@...earbox.net>,
"ast@...nel.org" <ast@...nel.org>,
Jiong Wang <jiong.wang@...ronome.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"oss-drivers@...ronome.com" <oss-drivers@...ronome.com>,
Markos Chandras <markos.chandras@...tec.com>,
Paul Burton <pburton@...ecomp.com>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>
Subject: Re: [PATCH v2 bpf] mips: bpf: fix encoding bug for mm_srlv32_op
Hi Jakub,
On Mon, Dec 03, 2018 at 03:55:45PM -0800, Jakub Kicinski wrote:
> On Mon, 3 Dec 2018 22:42:04 +0000, Paul Burton wrote:
> > Jiong Wang wrote:
> > > For micro-mips, srlv inside POOL32A encoding space should use 0x50
> > > sub-opcode, NOT 0x90.
> > >
> > > Some early version ISA doc describes the encoding as 0x90 for both srlv and
> > > srav, this looks to me was a typo. I checked Binutils libopcode
> > > implementation which is using 0x50 for srlv and 0x90 for srav.
> > >
> > > v1->v2:
> > > - Keep mm_srlv32_op sorted by value.
> > >
> > > Fixes: f31318fdf324 ("MIPS: uasm: Add srlv uasm instruction")
> > > Cc: Markos Chandras <markos.chandras@...tec.com>
> > > Cc: Paul Burton <paul.burton@...s.com>
> > > Cc: linux-mips@...r.kernel.org
> > > Acked-by: Jakub Kicinski <jakub.kicinski@...ronome.com>
> > > Acked-by: Song Liu <songliubraving@...com>
> > > Signed-off-by: Jiong Wang <jiong.wang@...ronome.com>
> >
> > Applied to mips-fixes.
>
> Newbie process related question - are the arch JIT patches routed via
> arch trees or bpf-next? Jiong has more (slightly conflicting) JIT
> patches to send - I wonder how they'll get applied and whether to wait
> for the mips -> Linus -> net -> bpf merge chain.
I'd expect that to be a case-by-case "what makes most sense this time?"
sort of question.
In this particular patch the code you're changing isn't specifically
BPF-related code, it's part of the MIPS uasm assembler which MIPS BPF
happens to use behind the scenes, so since it seemed like a pretty
standalone patch taking it through the MIPS tree made sense to me.
If you have related patches the best thing to do would be to submit them
together as a series. Then after the maintainers involved can see the
patches we can figure out the best way to apply them.
Thanks,
Paul
Powered by blists - more mailing lists