Received: by 2002:ac0:a591:0:0:0:0:0 with SMTP id m17-v6csp1407063imm; Thu, 5 Jul 2018 22:46:49 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcg1mxOmcgHcuweCG7eqMI3YzpqC0jmwnFGWE4LyDPAGLj9s0f0UtiKhPWY9ln3D0sUTkah X-Received: by 2002:a17:902:bb8d:: with SMTP id m13-v6mr8849271pls.46.1530856009434; Thu, 05 Jul 2018 22:46:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530856009; cv=none; d=google.com; s=arc-20160816; b=HqNzF5omyW0e0XfJ4/H1wOWC/k5/GbjqylCExTpEg+hztjH0Fa3KSbkPiKGhhUsCJG QqNF9YAm1WP5gBw5iBtEWBW+lS+LYpfD5U3SxpBW3FWV+W+5m0v/0gp5QOswzdZnAnmE SfPMTVQQoB0Oazk3WTdCPQ03SFv6HRJXKR2J7VWx8EP5JrYq5faBduGpozm/dWj++li1 A8BibNqqd/7nx1KinARbd/65lrJ5lX2KGUC8NTnGIstGEVJzAFNVmAKQuzyhVaFk9ItM tVAJ3jpYiO5njBYN4SgQsSBn761aujyrEmoiFJ3amiUjZeqiBt+GJPeRTtlNqsIBzzl8 uk+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=tP1d3rkTKENHoqZxdvMt/zz2I8/pn/11yWQ+JCm354U=; b=C6jZ1DiAOaKQHiQvD81eEwbkXR81AFaVCmvcwpVx0c+5zDsZcXjj6CqWexeoIiR+FN PfO/mUYFZi/panMca8SVG1OZSfUpdhaZEj9xfVw06U4tme7HJ/ZplDo21fCI2V6HgNEo TDdhY6coPkKQ9FTiy9EHpyQYIgioodoy2pmPVT8xTnBUQJriKPDPqxzDfJHRus+VOiga Jbu3rr+OCyhCS10+1ytBp5S9Gcgz5qvVlUh7qFIYaFmMYkzRXgLzGwsNTYt6kxLRGOfS tiWuj+L1/eD6YUkS81KrgvExc2xvY7MtD0exXBAyixgUdREptj/6Uyw92FfwANGR6hzB sOBA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k1-v6si7494919pld.40.2018.07.05.22.46.35; Thu, 05 Jul 2018 22:46:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932725AbeGFFpR (ORCPT + 99 others); Fri, 6 Jul 2018 01:45:17 -0400 Received: from foss.arm.com ([217.140.101.70]:58874 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932498AbeGFFpQ (ORCPT ); Fri, 6 Jul 2018 01:45:16 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D220218A; Thu, 5 Jul 2018 22:45:15 -0700 (PDT) Received: from salmiak (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 16D673F5BA; Thu, 5 Jul 2018 22:45:13 -0700 (PDT) Date: Fri, 6 Jul 2018 06:45:11 +0100 From: Mark Rutland To: Joe Perches Cc: Prakruthi Deepak Heragu , apw@canonical.com, linux-arm-kernel , linux-kernel@vger.kernel.org, ckadabi@codeaurora.org, tsoni@codeaurora.org, bryanh@codeaurora.org Subject: Re: [PATCH] checkpatch: Add exceptions for dsb keyword usage Message-ID: <20180706054510.puli24y6i6ylghxt@salmiak> References: <1530814776-16988-1-git-send-email-pheragu@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 05, 2018 at 02:14:28PM -0700, Joe Perches wrote: > On Thu, 2018-07-05 at 11:19 -0700, Prakruthi Deepak Heragu wrote: > > mb() API can relpace the dsb() API in the kernel code. So, dsb() usage > > is discouraged. However, there are exceptions when dsb is used in a > > variable or a function name. Exceptions are when 'dsb' is prefixed with > > class [-_>*\.] and/or suffixed with class [-_\.;]. This is a really confusing way of describing the match behaviour, and doesn't explain why this is a big problem. In C it's either: dsb() dsb(scope) // e.g. dsb(ish) ... where scope is [a-z]*. ... which can be matched as something like 'dsb([a-z]*)' if necessary. > [] > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl > [] > > @@ -5372,6 +5372,12 @@ sub process { > > "Avoid line continuations in quoted strings\n" . $herecurr); > > } > > > > +# dsb is too ARMish, and should usually be mb. > > + if ($line =~ /[^-_>*\.]\bdsb\b[^-_\.;]/) { > > + WARN("ARM_BARRIER", > > + "Use of dsb is discouranged: prefer mb.\n" . > > + $herecurr); > > + } > > This patch is whitespace damaged with a spelling error. > > Also, if this is reasonable test, and I don't know > that it is, it should be cc'd to the linux-arm list > linux-arm-kernel@lists.infradead.org > > Also, I suggest 2 tests, one for .S files and > another for .[ch] files, and this be made specific > to arch/arm... files > > Something like: > > if ($realfile =~ @^arch/arm@ && > ($realfile =~ /\.S$/ && $line =~ /\bdsb\b/) || > ($realfile =~ /\.[ch]$/ && $line =~ /\bdsb\s*\(/)) { > WARN("ARM_DSB", > "Prefer mb over dsb as an ARM memory barrier\n" . $herecurr); > } > > ARM people, is this reasonable? I don't think this is a big deal today. For code under arch/{arm,arm64}, it's perfectly reasonable to use dsb. For code *ouside* of arch/{arm,arm64}, there are a number of cases where we want to use dsb(), e.g. when dealing with architectural drivers that require special barriers, or for common code shared across arm and arm64. It doesn't look like this is a big problem today, anyhow: [mark@salmiak:~/src/linux]% git grep -w 'dsb(.*)' -- ^arch drivers/irqchip/irq-armada-370-xp.c: dsb(); drivers/irqchip/irq-gic-v3-its.c: dsb(ishst); drivers/irqchip/irq-gic-v3-its.c: dsb(ishst); drivers/irqchip/irq-gic-v3-its.c: dsb(sy); drivers/irqchip/irq-gic-v3-its.c: dsb(sy); drivers/irqchip/irq-gic-v3-its.c: dsb(sy); drivers/mtd/nand/raw/cmx270_nand.c: dsb(); drivers/mtd/nand/raw/cmx270_nand.c: dsb(); drivers/mtd/nand/raw/cmx270_nand.c: dsb(); drivers/mtd/nand/raw/cmx270_nand.c: dsb(); drivers/mtd/nand/raw/cmx270_nand.c: dsb(); drivers/perf/arm_spe_pmu.c: dsb(nsh); drivers/perf/arm_spe_pmu.c: dsb(nsh); drivers/power/reset/arm-versatile-reboot.c: dsb(); drivers/soc/rockchip/pm_domains.c: dsb(sy); drivers/soc/rockchip/pm_domains.c: dsb(sy); drivers/staging/mt7621-mmc/sd.c: //dsb(); /* --- by chhung */ drivers/staging/mt7621-mmc/sd.c: //dsb(); /* --- by chhung */ drivers/staging/vc04_services/interface/vchiq_arm/vchiq.h:#define dsb(a) drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c: dsb(sy); /* data barrier operation */ drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c: dsb(sy); drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h: do { debug_ptr[DEBUG_ ## d] = __LINE__; dsb(sy); } while (0) drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h: do { debug_ptr[DEBUG_ ## d] = (v); dsb(sy); } while (0) drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h: do { debug_ptr[DEBUG_ ## d]++; dsb(sy); } while (0) virt/kvm/arm/hyp/vgic-v3-sr.c: dsb(sy); virt/kvm/arm/hyp/vgic-v3-sr.c: dsb(sy); virt/kvm/arm/hyp/vgic-v3-sr.c: dsb(sy); Thanks, Mark.