So I'm inspecting the read code in my ethernet driver to see if there are
any obvious mistakes. (or even subtle ones ;-) and because I modelled it
after the Rhine driver that is supposed to work already (I'm not saying
that it doesn't, just have to be sure and be explicit in my assumptions)
and the receive code uses the macro _SU32 to access the read descriptor
long words.
The definition is:
#define _SU32( _base_, _offset_) \
*((volatile cyg_uint32 *)((CYG_ADDRWORD)_base_+(_offset_)))
And a read descriptor has four elements, the flags, the received length,
the buffer pointer, and a pointer to the next descriptor.
So would be considered acceptable/portable to code something liked
/* An element in the ring of read descriptors */
struct vt8325_rdd {
cyg_unint32 flags;
cyg_unit32 len;
cyg_uint8 *buf;
struct vt8325_rdd *nxt;
};
And then in the function :
volatile struct vt8325_rdd *rdes;
if (0 == (rdes->flags & VT8325_RDES_OWNED)) {
... not owned ...
}
The question is whether the volatile keyword is transitive to the structure
elements through a pointer, or if only the pointer to the structure is
considered volatile? And if its the latter and I explicity coded it:
/* An element in the ring of read descriptors */
struct vt8325_rdd {
volatile cyg_unint32 flags;
volatile cyg_unit32 len;
volatile cyg_uint8 *buf;
volatile struct vt8325_rdd *nxt;
};
Would that insure that values would not be left in the registers?
And on a more global note, I've already told the HAL to allocate this
memory out of uncached memory space so if I'm not spin looping on these
values do I even need volatile?
--Chuck
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
