Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3548160pxb; Sun, 7 Feb 2021 13:34:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJzf92qHRInZcn05eVZKqp1s1q2+ZCrkDlgPS35sAPb3CitZMoAEAxk/Z8xYfr0DDisYdZy+ X-Received: by 2002:a05:6402:1153:: with SMTP id g19mr9644494edw.292.1612733689614; Sun, 07 Feb 2021 13:34:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612733689; cv=none; d=google.com; s=arc-20160816; b=MLj+BAMb+5xqNrNCpECpueimZehNrFgI4G6vE/5hyfnssc+S0yMLln2Jix0AM7JdZl qpWdfk5yqxsmJZmMiKCUK5B9VEoOlrwOtnqYszwDuagdPwq1Lb9gMMZ5hnFr3f7aHNSZ 6afz/ysAEwOHpIupDgsUt+GmQEBktL606WxXmL0Hx2uFfUx99UoJQ+C6j/+Gib+m8AP3 jTI0d1TX5vUrkCSbF4yaP7SDu+/sjPrHcbIT1E1Eqr+HZMLrZwGWuAMjEEASk8h7yKxu TNZQY7pZf6DD7J4SxEv46efDpM+nTfjszIzGxoTQ+vRA+1eipacMB+J2M22wgJDzdnnD TM+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=VjR1kMTzRAE+Y1hkSFU+Pm1Z5fg9MkPoQKgcuRGBhrQ=; b=Y+JHA6pWgWlLGZ9ECENA3j/LaaE5KhLN9QHUGaL9KfVWAphTAcAkN6RiPCsdB7Uq5v ndWiMAiIez/QtBd8J5hWGTOeUFDNi7ZFd8WpY4AMRF0v6NMUAsZhowCspc2MELt8j1XL OllAqKUpCXqB5hSMPV5MVlce+GP4uanhNmV5SDKLbrpcK/UvB612xNJhauYyME3my8Sw jpzmv4E8lni/WrqZ8LP3NNbWQ6VumnZS5M0euocI+ixVm7gkGVoOCTXNgkPTIzHaOUFE H7aYM6gfhEQhCyPO7/6CWRkv7Vhzp7okPbo98U2rzvs2p362pJqAODcs1aJ7mTwCHzGB 2RWA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y10si7614218edv.110.2021.02.07.13.34.26; Sun, 07 Feb 2021 13:34:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229692AbhBGVc2 (ORCPT + 99 others); Sun, 7 Feb 2021 16:32:28 -0500 Received: from angie.orcam.me.uk ([157.25.102.26]:47232 "EHLO angie.orcam.me.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229506AbhBGVcX (ORCPT ); Sun, 7 Feb 2021 16:32:23 -0500 Received: by angie.orcam.me.uk (Postfix, from userid 500) id A46C39200B4; Sun, 7 Feb 2021 22:31:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 9D2109200B3; Sun, 7 Feb 2021 22:31:38 +0100 (CET) Date: Sun, 7 Feb 2021 22:31:38 +0100 (CET) From: "Maciej W. Rozycki" To: Jinyang He , Thomas Bogendoerfer cc: Jiaxun Yang , linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, Paul Burton , Jun-Ru Chang Subject: Re: [PATCH v2 2/4] MIPS: microMIPS: Fix the judgment of mm_jr16_op and mm_jalr_op In-Reply-To: <1611207098-11381-3-git-send-email-hejinyang@loongson.cn> Message-ID: References: <1611207098-11381-1-git-send-email-hejinyang@loongson.cn> <1611207098-11381-3-git-send-email-hejinyang@loongson.cn> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 21 Jan 2021, Jinyang He wrote: > mm16_r5_format.rt is 5 bits, so directly judge the value if equal or not. > mm_jalr_op requires 7th to 16th bits. These 10 which bits generated by The minor opcode extension field is comprised of bits 15:6, not 16:7 as your description suggests. Please be accurate with statements. > shifting u_format.uimmediate by 6 may be affected by sign extension. Why? The `uimmediate' bit-field member is unsigned for a reason. No sign-extension is made on unsigned data with the right-shift operation. > Thus, take out the 10 bits for comparison. > > Without this patch, errors may occur, such as these bits are all ones. How did you come to this conclusion? > diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c > index d737234..74d7fd8 100644 > --- a/arch/mips/kernel/process.c > +++ b/arch/mips/kernel/process.c > @@ -292,8 +292,8 @@ static inline int is_jump_ins(union mips_instruction *ip) > * microMIPS is kind of more fun... > */ > if (mm_insn_16bit(ip->word >> 16)) { > - if ((ip->mm16_r5_format.opcode == mm_pool16c_op && > - (ip->mm16_r5_format.rt & mm_jr16_op) == mm_jr16_op)) > + if (ip->mm16_r5_format.opcode == mm_pool16c_op && > + ip->mm16_r5_format.rt == mm_jr16_op) > return 1; > return 0; > } Code style changes should be submitted on their own as separate patches. > @@ -305,7 +305,7 @@ static inline int is_jump_ins(union mips_instruction *ip) > if (ip->r_format.opcode != mm_pool32a_op || > ip->r_format.func != mm_pool32axf_op) > return 0; > - return ((ip->u_format.uimmediate >> 6) & mm_jalr_op) == mm_jalr_op; > + return ((ip->u_format.uimmediate >> 6) & GENMASK(9, 0)) == mm_jalr_op; You've now excluded JALR.HB, JALRS, and JALRS.HB instructions. The mask was there for a reason. If you can't be bothered to verify microMIPS changes say with QEMU, then at the very least please check documentation. The intent of this code is clear and these instructions are even spelled out explicitly in the comment at the top. Thomas, please revert this change as I can see you've already taken it. It's plain wrong. Maciej