[PATCH] drivers/perf: hisi: Fix DEVICE_ATTR style tests warning for later PMU driver

Will Deacon will at kernel.org
Tue Sep 15 06:30:45 EDT 2020


On Tue, Sep 15, 2020 at 10:39:28AM +0800, Shaokun Zhang wrote:
> 在 2020/9/14 20:29, Will Deacon 写道:
> > On Sat, Sep 12, 2020 at 05:03:06PM +0800, Shaokun Zhang wrote:
> >> Since commit 001804689b0d ("checkpatch: add a few DEVICE_ATTR style
> >> tests") has checked DEVICE_ATTR style, let's cleanup the sysfs interface
> >> to get rid of the warning for later HiSilicon uncore PMU drivers.
> >> Otherwise the warning is throwed by checkpatch.pl for new drivers as
> >> follow:
> >> WARNING: Consider renaming function(s) 'hisi_cpumask_sysfs_show' to
> >> 'cpumask_show'
> > 
> > [...]
> > 
> >> diff --git a/drivers/perf/hisilicon/hisi_uncore_pmu.c b/drivers/perf/hisilicon/hisi_uncore_pmu.c
> >> index 97aff877a4e7..e2612a73edf6 100644
> >> --- a/drivers/perf/hisilicon/hisi_uncore_pmu.c
> >> +++ b/drivers/perf/hisilicon/hisi_uncore_pmu.c
> >> @@ -54,14 +54,14 @@ EXPORT_SYMBOL_GPL(hisi_event_sysfs_show);
> >>  /*
> >>   * sysfs cpumask attributes. For uncore PMU, we only have a single CPU to show
> >>   */
> >> -ssize_t hisi_cpumask_sysfs_show(struct device *dev,
> >> -				struct device_attribute *attr, char *buf)
> >> +ssize_t cpumask_show(struct device *dev, struct device_attribute *attr,
> >> +		     char *buf)
> >>  {
> >>  	struct hisi_pmu *hisi_pmu = to_hisi_pmu(dev_get_drvdata(dev));
> >>  
> >>  	return sprintf(buf, "%d\n", hisi_pmu->on_cpu);
> >>  }
> >> -EXPORT_SYMBOL_GPL(hisi_cpumask_sysfs_show);
> >> +EXPORT_SYMBOL_GPL(cpumask_show);
> > 
> > This seems like a colossally bad idea to me.
> 
> Apologies. We are developing new uncore PMU module drivers which will be sent to commuinity
> later and do checkpatch.pl that introduces this warning. Since the interface is not new
> developed, so you suggest to keep it the same, right?

I don't think checkpatch warnings hold much value, but in this case having a
global (exported!) 'cpumask_show' symbol sounds like it is going to conflict
with anybody else trying to fix similar warnings. By all means cleanup the
static symbols, but I don't think it's a good idea to go beyond that.

Will



More information about the linux-arm-kernel mailing list