Dear Mike Frysinger,
In message 20111003.15436.vap...@gentoo.org you wrote:
I'm OK with expanding the name[] field, but as Thomas pointed out,
providing convenient u32 / u16 variables for the MAC address is
actually a faux ami that misleads people into using these variables
without
Hello Mike,
+ union {
+ u32 enetaddr32;
+ u16 enetaddr16[3];
+ unsigned char enetaddr[6];
+ };
This will work only as long the endianess is matching.
Picking single chars from enetaddr[] and combine them to a u32 register
will be more independent
Dear Mike Frysinger,
In message 1320970267-22297-2-git-send-email-vap...@gentoo.org you wrote:
The current eth_device leaves a 2 byte hole after enetaddr and before
iobase. Since the enetaddr member has to be 6 bytes, we might as well
fill that 2 byte hole with something useful.
Further,
On Friday 11 November 2011 06:55:45 Wolfgang Denk wrote:
Mike Frysinger wrote:
The current eth_device leaves a 2 byte hole after enetaddr and before
iobase. Since the enetaddr member has to be 6 bytes, we might as well
fill that 2 byte hole with something useful.
Further, most device
On Fri, Nov 11, 2011 at 9:03 AM, Mike Frysinger vap...@gentoo.org wrote:
On Friday 11 November 2011 06:55:45 Wolfgang Denk wrote:
Mike Frysinger wrote:
The current eth_device leaves a 2 byte hole after enetaddr and before
iobase. Since the enetaddr member has to be 6 bytes, we might as well
On Friday 11 November 2011 10:44:45 Andy Fleming wrote:
On Fri, Nov 11, 2011 at 9:03 AM, Mike Frysinger vap...@gentoo.org wrote:
On Friday 11 November 2011 06:55:45 Wolfgang Denk wrote:
Mike Frysinger wrote:
The current eth_device leaves a 2 byte hole after enetaddr and
before iobase.
The current eth_device leaves a 2 byte hole after enetaddr and before
iobase. Since the enetaddr member has to be 6 bytes, we might as well
fill that 2 byte hole with something useful.
Further, most device drivers want to load enetaddr from memory into the
hardware as 1 32bit value and 1 16bit
7 matches
Mail list logo
