Do ioread32/iowrite32 assume volatile pointer?

[Felnekir]

I'm trying to convert all my driver references from using pointer dereferencing to read/write PCI device memory, to using ioread/iowrite functions as recommended elsewhere.

I have a memory test, which does what memory tests do... the memory pointer in the function is defined as volatile u32*, because otherwise the optimizer just removes all the loops (thinking a write followed by read at same address has an obvious result). However, when I pass the volatile pointer to ioread32/iowrite32, I get compiler warnings because those functions don't take volatile pointers. I could cast away the volatiles, of course, but then I may still have the same problem with the compiler.

So I'm hoping that ioread()/iowrite(), by their nature, assume that they are dealing with external memory which is inherently volatile. Is this a reliable assumption? If not, how do I solve this problem?

[Rubberman]

Making assumptions like this regarding volatility of a variable is not a safe one to make, in my opinion. I checked, and on my CentOS kernel the arguments are not volatile. Since these are I/O addresses, they probably are volatile, and may be changed at any time by the hardware they are mapped to. However, using the volatile keyword in your code is so that the compiler will better guard it from being changed by another thread (not hardware) while you are reading it. Then again, in this case it probably is not an issue as far as you are concerned.

So, why are you worried about this?

[Felnekir]

Well, I'm worried about this because it's a memory test... if the compiler does not realize that a write followed by a read does not produce an obvious result (i.e., the memory is volatile), then I won't get the result that I expect, and I won't detect failed memory... but then I won't know *that* until memory *does* fail in the field, and I don't detect it.

The *real* problem, however, is that I don't know why there's a difference between
*(char *) (xilinx_base + OFFSET) = u8value ;
is different from
iowrite8(u8value, (xilinx_base + OFFSET)) ;
but I've seen that it is, because the former did not work for some of my register writes. So now I'm tediously grinding through 262 xilinx_base references in my 33,000 lines of driver code, trying to carefully convert them over to the new syntax.

And the reason I'm bothering with *that* is because I'm hoping that it's some memory reference BEFORE my DMA test, that is causing the DMA test to fail (as discussed in a separate, earlier message, which is also an unresolved issue).