Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp204854pxb; Wed, 3 Feb 2021 03:33:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJw3tDO4jfRd1ZZUpwRdtROudEfugD1UZ7nCQlzxSZYTAogCGpd8Lqj1EU3kPwgLnsikd8y3 X-Received: by 2002:aa7:d912:: with SMTP id a18mr2483682edr.73.1612352039753; Wed, 03 Feb 2021 03:33:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612352039; cv=none; d=google.com; s=arc-20160816; b=Cw2LCgucz6IzOZJtzl5YovioWQbOt/+OvzIa10GAn8er1JcmujfTqLxdnLENe5R1B5 x4rnb8lQ+Hikgj0fHT5uISujsOzqxTKlkC7Qv+8qkphdXOHVA+FRcNhmf1vbRT3aTA2o ga7/rhabqOIQ1nUrvXLWaGp8aTBPEnMEIpazsyfiwjXT7tOvpyLjIxJV83AnvVieypUw 9trQPg5IhQ1tVMCZu0K7whDvFfYpTKJplJoiI08NYOazjq1sJWv81VCuC2HuDEAqVxNn xlI6zbdX8Hv37mbPPMuUg2VxcziXnf0JMIkmIvYamYAPM9BYxsNioagHsmfqX0XaTXAF yjDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=jTFA1kHDxNsZIAM3IBteg0fnJMGB/tM1Z7g0nhJ3hKI=; b=A23AyEniY3aC9UFX2gDtpcZ9ngeuLiuVldS4hB2m43IP3CTPwagIdmwODiJY4hva6Z mjPaaIaGjjsPYw/NQ8oZqN+yeNgTfHZqlMhrs6mkg46r5IgAhlhva6fgJk5/aeLa6lun 2m2jV8WVNvAZJRHPEKUNZwYVtdrkilAH4N9rKhn478QZxo9obh/ZcbNbHTymUzixQ+kp PBWuayyTkPeIuGNMBvvnQc4zqQrd8PEgRnEX2x+VNTu/3AwHTvMVxMkgx9NGpRfx8TV9 zKNjAnxwfZxAoQ7ZVr9k9I1ac+UrFTy1yq2674S+091nOJhx9NlANSuSAXDxnDnQ1fDN 3z5g== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l3si1261960ejd.83.2021.02.03.03.33.34; Wed, 03 Feb 2021 03:33:59 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234181AbhBCLcp (ORCPT + 99 others); Wed, 3 Feb 2021 06:32:45 -0500 Received: from foss.arm.com ([217.140.110.172]:38270 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234093AbhBCLc3 (ORCPT ); Wed, 3 Feb 2021 06:32:29 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 36EFAD6E; Wed, 3 Feb 2021 03:31:43 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.11.206]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8B60F3F719; Wed, 3 Feb 2021 03:31:41 -0800 (PST) Date: Wed, 3 Feb 2021 11:31:38 +0000 From: Mark Rutland To: Zhiyuan Dai Cc: catalin.marinas@arm.com, will@kernel.org, Dave.Martin@arm.com, broonie@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64/kernel: minor coding style tweaks Message-ID: <20210203113138.GC55896@C02TD0UTHF1T.local> References: <1612329552-17977-1-git-send-email-daizhiyuan@phytium.com.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1612329552-17977-1-git-send-email-daizhiyuan@phytium.com.cn> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 03, 2021 at 01:19:12PM +0800, Zhiyuan Dai wrote: > Fixed two coding style issues in kernel/trap.c > 1. spaces required around that '=' This change makes sense to me as a cleanup. > 2. Missing a blank line after declarations We're inconsistent w.r.t. this across the tree, and applying this everywhere would be very churny, but I think it makes sense to be consistent locally (e.g. within a function). Currently call_undef_hook() is inconsistent in this respect, but I think this patch leaves it inconsistent in a different way. Please see below. > Signed-off-by: Zhiyuan Dai > --- > arch/arm64/kernel/traps.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c > index 6895ce7..4001a39 100644 > --- a/arch/arm64/kernel/traps.c > +++ b/arch/arm64/kernel/traps.c > @@ -45,7 +45,7 @@ > #include > #include > > -static const char *handler[]= { > +static const char *handler[] = { > "Synchronous Abort", > "IRQ", > "FIQ", > @@ -318,6 +318,7 @@ static int call_undef_hook(struct pt_regs *regs) > } else if (compat_thumb_mode(regs)) { > /* 16-bit Thumb instruction */ > __le16 instr_le; > + > if (get_user(instr_le, (__le16 __user *)pc)) > goto exit; > instr = le16_to_cpu(instr_le); Immediately above this we have: | if (!user_mode(regs)) { | __le32 instr_le; | if (get_kernel_nofault(instr_le, (__force __le32 *)pc)) | goto exit; | instr = le32_to_cpu(instr_le); ... which we should either change at the same time, or not bother with this at all. Thanks, Mark. > @@ -332,6 +333,7 @@ static int call_undef_hook(struct pt_regs *regs) > } else { > /* 32-bit ARM instruction */ > __le32 instr_le; > + > if (get_user(instr_le, (__le32 __user *)pc)) > goto exit; > instr = le32_to_cpu(instr_le); > -- > 1.8.3.1 >