Michael K. Edwards wrote:
Doubtless this is on purpose, but it's not clear to me why that should
be true for these particular functions/macros. I shouldn't have to
cast away the volatile on a pointer to hardware registers in order to
pass it into writel(), should I? And it shouldn't be
Preface: I am aware that other people here know far more that I do
about the details of C semantics. If the inconsistency is deliberate,
please just point me to the previous LKML thread.
On 2/2/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
H. Peter Anvin wrote:
> Jeff Garzik wrote:
>> Volatile is
H. Peter Anvin wrote:
Jeff Garzik wrote:
Volatile is usually reserved for a specific need on a specific arch.
I doubt it is correct to force it on all arches.
They already are volatile; the issue is adding "const".
All io(read|write)* pointers are volatile, IIRC.
No, none are volatile,
H. Peter Anvin wrote:
Jeff Garzik wrote:
Volatile is usually reserved for a specific need on a specific arch.
I doubt it is correct to force it on all arches.
They already are volatile; the issue is adding const.
All io(read|write)* pointers are volatile, IIRC.
No, none are volatile,
Preface: I am aware that other people here know far more that I do
about the details of C semantics. If the inconsistency is deliberate,
please just point me to the previous LKML thread.
On 2/2/07, Jeff Garzik [EMAIL PROTECTED] wrote:
H. Peter Anvin wrote:
Jeff Garzik wrote:
Volatile is
Michael K. Edwards wrote:
Doubtless this is on purpose, but it's not clear to me why that should
be true for these particular functions/macros. I shouldn't have to
cast away the volatile on a pointer to hardware registers in order to
pass it into writel(), should I? And it shouldn't be
Jeff Garzik wrote:
Volatile is usually reserved for a specific need on a specific arch. I
doubt it is correct to force it on all arches.
They already are volatile; the issue is adding "const".
All io(read|write)* pointers are volatile, IIRC.
-hpa
-
To unsubscribe from this list:
Volatile is usually reserved for a specific need on a specific arch. I
doubt it is correct to force it on all arches.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Michael K. Edwards wrote:
It looks to me, by comparison to memcpy_(from|to)io, as if the
volatiles ought to be there. It also looks to me like the void *
parameters should be u(8|16|32) * instead, so the compiler knows what
alignment to expect (the implementations would generally fail or suck
Sorry, I wrote this:
(This is not an ARM-specific question, although the example is on ARM.)
and then sent it to linux-arm-kernel anyway. :-P
I'm writing an ALSA driver for an ARM SoC whose PCM audio interface is
MMIO. ALSA provides copy_from_user_toio and copy_to_user_fromio
routines for
Sorry, I wrote this:
(This is not an ARM-specific question, although the example is on ARM.)
and then sent it to linux-arm-kernel anyway. :-P
I'm writing an ALSA driver for an ARM SoC whose PCM audio interface is
MMIO. ALSA provides copy_from_user_toio and copy_to_user_fromio
routines for
Michael K. Edwards wrote:
It looks to me, by comparison to memcpy_(from|to)io, as if the
volatiles ought to be there. It also looks to me like the void *
parameters should be u(8|16|32) * instead, so the compiler knows what
alignment to expect (the implementations would generally fail or suck
Volatile is usually reserved for a specific need on a specific arch. I
doubt it is correct to force it on all arches.
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Jeff Garzik wrote:
Volatile is usually reserved for a specific need on a specific arch. I
doubt it is correct to force it on all arches.
They already are volatile; the issue is adding const.
All io(read|write)* pointers are volatile, IIRC.
-hpa
-
To unsubscribe from this list: send
14 matches
Mail list logo
