On Tue, 2009-05-26 at 09:37 -0700, Grant Grundler wrote:
> On Sat, May 23, 2009 at 2:11 PM, Michael Chan <mchan@xxxxxxxxxxxx> wrote:
> > New iSCSI driver for Broadcom BNX2 devices.
> ...
> > +/*
> > + * iSCSI Async CQE
> > + */
> > +struct bnx2i_async_msg {
> ...
> > +#if defined(__BIG_ENDIAN)
> > + u8 async_event;
> > + u8 async_vcode;
> > + u16 param1;
> > +#elif defined(__LITTLE_ENDIAN)
> > + u16 param1;
> > + u8 async_vcode;
> > + u8 async_event;
> > +#endif
> ...
>
> Michael,
> I'm feeling a bit dense and am not seeing why byte data
> would have to worry about the 32-bit word endianess of the CPU.
> Can you give an example of why defined(__BIG_ENDIAN) is needed?
>
> Normally the _*ENDIAN defines are used for bit fields, not byte fields.
>
> Byte data addressable by the CPU (e.g. host memory) is at the same offset
> regardless of endianness of the CPU. I feel like I'm missing
> something that should be obvious.
Hi Grant, these are what we call "DMA control structures" as opposed to
DMA packet data. Our chips are configured to do an additional 32-bit
endian swap on all DMA control structures. This way, all 32-bit control
fields (such as length, status, etc) will come out right when the driver
reads these fields.
If everything was defined as u32 in all these control structures, we
wouldn't have to add the #ifdef. u8 and u16 fields have to be defined
this way or else big endian CPUs would read the wrong offset.
If you look at some of the control structures in tg3.h, you'll see the
same thing.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
