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.
'
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
