Johannes Berg <[EMAIL PROTECTED]> :
[...]
> Now, arguably the correct fix would be to make the b44_read_eeprom
> routine read an array of u16 as stored, and then use byte shifting
> everywhere to fix up for the fact that Broadcom stores things into the
Yes.
> high/low byte of a u16 (yes, they always use a u16 layout even if the
> data they want to store is just a u8 or less, then they stuff it into a
> u16 and store it, they don't store byte-wise).
>
> Now, making that fix would result in quite some ugly code along the
> lines of:
> bp->dev->dev_addr[0] = eeprom[39] >> 8;
> bp->dev->dev_addr[1] = eeprom[39] & 0xFF;
> bp->dev->dev_addr[2] = eeprom[40] >> 8;
> bp->dev->dev_addr[3] = eeprom[40] & 0xFF;
> etc.
1 - see drivers/net/tg3.c. The drivers/net code does not swaps register
a lot: one can find some cpu_to_{l/b}e or {l/b}e_to_cpu which go
along read/write but they do not look like the norm.
2 - The code is extracting an u8 from an u16. Nothing shocking (ok, the
capitalized 0xFF _is_ shocking :o) ).
3 - The data in the eeprom contains u16 and it has a known endianness.
It can be annotated as such (__be16 eeprom[]). I do not know how to
do the same with an u8 [].
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
