All of lore.kernel.org
 help / color / mirror / Atom feed
From: pheragu@codeaurora.org (pheragu at codeaurora.org)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] checkpatch: Add exceptions for dsb keyword usage
Date: Fri, 06 Jul 2018 10:00:47 -0700	[thread overview]
Message-ID: <048e6ee9521c6b7e2d85ea0cc647e8b2@codeaurora.org> (raw)
In-Reply-To: <ebc3e5cafdf2a11a08940357c91b8ce64e7d3200.camel@perches.com>

On 2018-07-05 22:52, Joe Perches wrote:
> On Fri, 2018-07-06 at 06:45 +0100, Mark Rutland wrote:
>> 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 at 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 at 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.
> 
> So it seems this shouldn't be applied.
Thanks Joe. I appreciate your feedback.

WARNING: multiple messages have this Message-ID (diff)
From: pheragu@codeaurora.org
To: Joe Perches <joe@perches.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	apw@canonical.com,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	linux-kernel@vger.kernel.org, ckadabi@codeaurora.org,
	tsoni@codeaurora.org, bryanh@codeaurora.org
Subject: Re: [PATCH] checkpatch: Add exceptions for dsb keyword usage
Date: Fri, 06 Jul 2018 10:00:47 -0700	[thread overview]
Message-ID: <048e6ee9521c6b7e2d85ea0cc647e8b2@codeaurora.org> (raw)
In-Reply-To: <ebc3e5cafdf2a11a08940357c91b8ce64e7d3200.camel@perches.com>

On 2018-07-05 22:52, Joe Perches wrote:
> On Fri, 2018-07-06 at 06:45 +0100, Mark Rutland wrote:
>> 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.
> 
> So it seems this shouldn't be applied.
Thanks Joe. I appreciate your feedback.

  reply	other threads:[~2018-07-06 17:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-05 18:19 [PATCH] checkpatch: Add exceptions for dsb keyword usage Prakruthi Deepak Heragu
2018-07-05 21:14 ` Joe Perches
2018-07-05 21:14   ` Joe Perches
2018-07-06  5:45   ` Mark Rutland
2018-07-06  5:45     ` Mark Rutland
2018-07-06  5:52     ` Joe Perches
2018-07-06  5:52       ` Joe Perches
2018-07-06 17:00       ` pheragu at codeaurora.org [this message]
2018-07-06 17:00         ` pheragu
2018-07-06 17:02     ` pheragu at codeaurora.org
2018-07-06 17:02       ` pheragu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=048e6ee9521c6b7e2d85ea0cc647e8b2@codeaurora.org \
    --to=pheragu@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.