public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [patch] synclink.c compiler optimiation fix
@ 2005-09-07 17:02 Paul Fulghum
  2005-09-08 13:52 ` Christoph Hellwig
  0 siblings, 1 reply; 3+ messages in thread
From: Paul Fulghum @ 2005-09-07 17:02 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

[patch] synclink.c compiler optimization fix

From: Paul Fulghum <paulkf@microgate.com>

Make some fields of DMA descriptor volatile to
prevent compiler optimizations.

Signed-off-by: Paul Fulghum <paulkf@microgate.com>

--- linux-2.6.13/drivers/char/synclink.c	2005-09-07 11:43:56.000000000 -0500
+++ linux-2.6.13-mg/drivers/char/synclink.c	2005-09-07 11:52:08.000000000 -0500
@@ -1,7 +1,7 @@
 /*
  * linux/drivers/char/synclink.c
  *
- * $Id: synclink.c,v 4.28 2004/08/11 19:30:01 paulkf Exp $
+ * $Id: synclink.c,v 4.37 2005/09/07 13:13:19 paulkf Exp $
  *
  * Device driver for Microgate SyncLink ISA and PCI
  * high speed multiprotocol serial adapters.
@@ -141,9 +141,9 @@ static MGSL_PARAMS default_params = {
 typedef struct _DMABUFFERENTRY
 {
 	u32 phys_addr;	/* 32-bit flat physical address of data buffer */
-	u16 count;	/* buffer size/data count */
-	u16 status;	/* Control/status field */
-	u16 rcc;	/* character count field */
+	volatile u16 count;	/* buffer size/data count */
+	volatile u16 status;	/* Control/status field */
+	volatile u16 rcc;	/* character count field */
 	u16 reserved;	/* padding required by 16C32 */
 	u32 link;	/* 32-bit flat link to next buffer entry */
 	char *virt_addr;	/* virtual address of data buffer */
@@ -896,7 +896,7 @@ module_param_array(txdmabufs, int, NULL,
 module_param_array(txholdbufs, int, NULL, 0);
 
 static char *driver_name = "SyncLink serial driver";
-static char *driver_version = "$Revision: 4.28 $";
+static char *driver_version = "$Revision: 4.37 $";
 
 static int synclink_init_one (struct pci_dev *dev,
 				     const struct pci_device_id *ent);



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [patch] synclink.c compiler optimiation fix
  2005-09-07 17:02 [patch] synclink.c compiler optimiation fix Paul Fulghum
@ 2005-09-08 13:52 ` Christoph Hellwig
  2005-09-08 15:32   ` Paul Fulghum
  0 siblings, 1 reply; 3+ messages in thread
From: Christoph Hellwig @ 2005-09-08 13:52 UTC (permalink / raw)
  To: Paul Fulghum; +Cc: Andrew Morton, linux-kernel

On Wed, Sep 07, 2005 at 12:02:23PM -0500, Paul Fulghum wrote:
> -	u16 count;	/* buffer size/data count */
> -	u16 status;	/* Control/status field */
> -	u16 rcc;	/* character count field */
> +	volatile u16 count;	/* buffer size/data count */
> +	volatile u16 status;	/* Control/status field */
> +	volatile u16 rcc;	/* character count field */

this is wrong.  The structure is in ioremaped memory so you must
use reads/writes to access them instead.  volatile usage in drivers
is never okay - if you are accessing I/O memory you need to use
proper acessors, if it is normal memory and you want atomic sematics
you need to use the atomic_t type and the operators defined on it.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [patch] synclink.c compiler optimiation fix
  2005-09-08 13:52 ` Christoph Hellwig
@ 2005-09-08 15:32   ` Paul Fulghum
  0 siblings, 0 replies; 3+ messages in thread
From: Paul Fulghum @ 2005-09-08 15:32 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Andrew Morton, linux-kernel

Christoph Hellwig wrote:
> The structure is in ioremaped memory so you must
> use reads/writes to access them instead.

Yes, using read/write eliminates the compiler optimization
and makes the driver portable to other architectures.
That change is much more extensive, and it may be
a while before I can do a major rewrite of the driver.
The volatile change allows the existing driver to work.

 > volatile usage in drivers
> is never okay - if you are accessing I/O memory you need to use
> proper acessors, if it is normal memory and you want atomic sematics
> you need to use the atomic_t type and the operators defined on it.

This is not a matter of atomicity.
It is a matter of hardware DMA causing the
value to change without the compiler's knowledge.

If I have a DMA descriptor in normal memory (not the
case in the above driver, but it is the case in
another driver I maintain) that has fields that
do not conform to atomic_t, using volatile seems
a valid way of preventing the compiler from
optimizing access to the field out of a loop.

-- 
Paul Fulghum
Microgate Systems, Ltd.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-09-08 15:33 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-09-07 17:02 [patch] synclink.c compiler optimiation fix Paul Fulghum
2005-09-08 13:52 ` Christoph Hellwig
2005-09-08 15:32   ` Paul Fulghum

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox