linux-kernel - Re: [PATCH] staging: bcm2835-audio: bcm2835.h: fix various coding style issues

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 17 Feb 2017 11:52:09 -0800
From:   Joe Perches <joe@...ches.com>
To:     Nathan Howard <adanhawthorn@...il.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Ray Jui <rjui@...adcom.com>,
        Scott Branden <sbranden@...adcom.com>,
        bcm-kernel-feedback-list@...adcom.com,
        Stephen Warren <swarren@...dotorg.org>,
        Lee Jones <lee@...nel.org>, Eric Anholt <eric@...olt.net>,
        Michael Zoran <mzoran@...wfest.net>,
        devel@...verdev.osuosl.org, linux-rpi-kernel@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: bcm2835-audio: bcm2835.h: fix various coding
 style issues

On Fri, 2017-02-17 at 13:39 -0500, Nathan Howard wrote:
> The following coding style issues (as per checkpatch.pl) were resolved.

What Greg said is true, and the volatile conversion
especially needs to be verified.

> diff --git a/drivers/staging/bcm2835-audio/bcm2835.h b/drivers/staging/bcm2835-audio/bcm2835.h
[]
> @@ -27,8 +27,8 @@
>  #include <linux/workqueue.h>
>  
>  /*
> -#define AUDIO_DEBUG_ENABLE
> -#define AUDIO_VERBOSE_DEBUG_ENABLE
> + * #define AUDIO_DEBUG_ENABLE
> + * #define AUDIO_VERBOSE_DEBUG_ENABLE
>   */

Using #define DEBUG would be more common.
 
>  /* Debug macros */
> @@ -37,10 +37,10 @@
>  #ifdef AUDIO_VERBOSE_DEBUG_ENABLE
>  
>  #define audio_debug(fmt, arg...) \
> -	printk(KERN_INFO"%s:%d " fmt, __func__, __LINE__, ##arg)
> +	pr_info("%s:%d " fmt, __func__, __LINE__, ##arg)
>  
>  #define audio_info(fmt, arg...) \
> -	printk(KERN_INFO"%s:%d " fmt, __func__, __LINE__, ##arg)
> +	pr_info("%s:%d " fmt, __func__, __LINE__, ##arg)
>  
>  #else
>  
> @@ -59,13 +59,13 @@
>  #endif /* AUDIO_DEBUG_ENABLE */
>  
>  #define audio_error(fmt, arg...) \
> -	printk(KERN_ERR"%s:%d " fmt, __func__, __LINE__, ##arg)
> +	pr_err("%s:%d " fmt, __func__, __LINE__, ##arg)
>  
>  #define audio_warning(fmt, arg...) \
> -	printk(KERN_WARNING"%s:%d " fmt, __func__, __LINE__, ##arg)
> +	pr_warn("%s:%d " fmt, __func__, __LINE__, ##arg)
>  
>  #define audio_alert(fmt, arg...) \
> -	printk(KERN_ALERT"%s:%d " fmt, __func__, __LINE__, ##arg)
> +	pr_alert("%s:%d " fmt, __func__, __LINE__, ##arg)

These might as well be removed and converted to
the direct pr_<level> equivalents and have

#define pr_fmt(fmt) "%s:%d: " fmt, __func__, __LINE__

added before any include, but honestly the
__func__ and __LINE__ aren't particularly useful.

> @@ -122,8 +125,8 @@ struct bcm2835_alsa_stream {
>  	struct semaphore buffers_update_sem;
>  	struct semaphore control_sem;
>  	spinlock_t lock;
> -	volatile unsigned int control;
> -	volatile unsigned int status;
> +	unsigned int control;
> +	unsigned int status;

Unless you can absolutely verify that that
doesn't change hardware access, you should
leave this alone.
'