if_ate handles the bytes of the MAC address in a "wrong" order

[Björn König]

Bernd schrieb:
> On Sat, Jun 09, 2007 at 09:00:40AM +0200, Björn König wrote:
>> [...] I think it's inappropriate and confusing to talk
>> about a most and least significant byte for the purpose of endianess.
>
> You started with it and you were wrong.

Maybe my very first mail was capable of being misunderstood. I just
repeated Atmel's specification and I think I did it correctly. It was
neither my concern to talk about endianess nor to talk about right or
wrong. It does not belong to this issue, because finally it doesn't matter
how Atmel want to read and write the MAC address to the registers since it
is their specification and they are allowed to specify whatever they want
regarding their hardware. They even are allowed to expect that the six
bytes are stored in the order ([6][-][1][4])([3][2][-][5]).

> I also prefer to talk about first, sendond, ... byte, but the order is
> important to understand the datasheet.
> The datasheet is clear that the first 4 bytes belong into the first
> register, but it doesn't tell anything about the order of the bytes
> within the registers.

They do, they give a hint:

"The first bit (i.e., the LSB of the first byte) of the destination
address is the group/individual bit and is set one for multicast addresses
and zero for unicast. This bit corresponds to bit 24 of the first word of
the specific address register. The MSB of the first byte of the
destination address corresponds to bit 31 of the specific
address register."

low register:
[ 31 ][ 30 ][ 29 ][ 28 ][ 27 ][ 26 ][ 25 ][ 24 ]
   8     7     6     5     4     3     2     1

This is what they said (register bit in brackets, below the bit of the MAC
address # 1-48 in transmission order). That consecutively means for the
low register:

[ 23 ][ 22 ][ 21 ][ 20 ][ 19 ][ 18 ][ 17 ][ 16 ]
  16    15    14    13    12    11    10     9

[ 15 ][ 14 ][ 13 ][ 12 ][ 11 ][ 10 ][  9 ][  8 ]
  24    23    22    21    20    19    18    17

[  7 ][  6 ][  5 ][  4 ][  3 ][  2 ][  1 ][  0 ]
  32    31    30    29    28    27    26    25

Consequently you should fill the high register this way:
[ 15 ][ 14 ][ 13 ][ 12 ][ 11 ][ 10 ][  9 ][  8 ]
  40    39    38    37    36    35    34    33

[  7 ][  6 ][  5 ][  4 ][  3 ][  2 ][  1 ][  0 ]
  48    47    46    45    44    43    42    41

Personally I don't want that because it requires changes in *all* Loaders
as well as in FreeBSD and Linux drivers and so on.

> The loader should be fixed and the kernel shouldn't change it, which
> requires the read function to be fixed.

I just want the ate driver's get function to be fixed according to its own
set function. Nothing else. The loader don't need to be changed.

Regards
Björn