Message-ID: <432059A2.4030209@microgate.com>
Date: Thu, 08 Sep 2005 10:32:50 -0500
From: Paul Fulghum <paulkf@microgate.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Christoph Hellwig <hch@infradead.org>
CC: Andrew Morton <akpm@osdl.org>, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [patch] synclink.c compiler optimiation fix
References: <1126112543.3984.17.camel@deimos.microgate.com> <20050908135211.GB8676@infradead.org>
In-Reply-To: <20050908135211.GB8676@infradead.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1334
Lines: 34

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/