[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B713F@saturn3.aculab.com>
Date: Fri, 8 Feb 2013 10:23:08 -0000
From: "David Laight" <David.Laight@...LAB.COM>
To: "Ben Hutchings" <bhutchings@...arflare.com>,
"Freddy Xin" <freddy@...x.com.tw>
Cc: <netdev@...r.kernel.org>, <davem@...emloft.net>,
<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH, resubmit] ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver
> > +struct ax88179_rx_pkt_header {
> > + u8 l4_csum_err:1,
> > + l3_csum_err:1,
> > + l4_type:3,
> > + l3_type:2,
> > + ce:1;
> > +
> > + u8 vlan_ind:3,
> > + rx_ok:1,
> > + pri:3,
> > + bmc:1;
> > +
> > + u16 len:13,
> > + crc:1,
> > + mii:1,
> > + drop:1;
> > +} __packed;
>
> This won't work on both big-endian systems (assuming this works on x86).
> You apparently try to convert the structure in-place in
> ax88179_rx_fixup() by calling le32_to_cpus(); that may work if you
> define all the bitfields to be part of a u32 but it won't work with the
> current definition.
Trying to use bit fields to map hardware registers (etc) isn't a
good idea at all. The C standard says absolutely nothing about
the order in which the bits are allocated to the field names.
(There are at least 4 possible orederings.)
It is much better to define constants for the bit values and
explicitly mask them as required.
David
Powered by blists - more mailing lists