> > +#define rom_out_be16(addr,w)
> > \
> > + ({u16 __w, __v;
> > \
> > + __v = (w) >> 8; \
> > + __w = ((*(__force volatile u16 *) ((addr) + 0x10000 + (__v<<1)))); \
> ^^^
> Shouldn't this and __w be u8? I though the hardware only did 8-bit
> accesses?
The 8 bit is the effective data path but the data written are read back on
the high byte of a 16 bit word. Not sure we really do need the dummy read
at all - in that case, it probably wouldn't matter.
>
> > + __v = (w) & 0x0f; \
> ^^
> ff?
Right you are :-( Didn't do hex calculation in a long while ...
> > + __w = ((*(__force volatile u16 *) ((addr) + 0x10000 + (__v<<1)))); })
>
> Woops, multiple use of `addr' and `w' in a macro can have nasty side-effects
> (think e.g. `outw(addr++, value)'.
Oops - that I need to fix for sure.
> Wouldn't it be better to implement rom_out_be16() to use rom_out_8(),
> for easier understanding of the code?
I was worried about even more side effects there...
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
