summaryrefslogtreecommitdiffstats
path: root/drivers/net/tokenring/olympic.h
diff options
context:
space:
mode:
authorAl Viro <viro@ftp.linux.org.uk>2007-12-16 20:53:36 +0000
committerDavid S. Miller <davem@davemloft.net>2008-01-28 15:07:08 -0800
commitb710b43c306650261c01ad08100791afec78a7db (patch)
tree656c18e9d3736b84b56c1f91303c28207c424951 /drivers/net/tokenring/olympic.h
parentf5a3ea6f966700ae82504202fdd827f2d3c79e66 (diff)
endianness annotations and fixes for olympic
* missing braces in !readl(...) & ... * trivial endianness annotations * in olympic_arb_cmd() the loop collecting fragments of packet is b0rken on big-endian - we have (next_ptr && (buf_ptr=olympic_priv->olympic_lap + ntohs(next_ptr))) as condition and it should have swab16(), not ntohs() - it's host-endian byteswapped, not big-endian. So if we get more than one fragment on big-endian host, we get screwed. This ntohs() got missed back when the rest of those had been switched to swab16() in 2.4.0-test2-pre1 - at a guess, nobody had hit fragmented packets during the testing of PPC fixes. PS: Ken Aaker cc'd on assumption that he is the same guy who'd done the original set of PPC fixes in olympic Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Jeff Garzik <jeff@garzik.org>
Diffstat (limited to 'drivers/net/tokenring/olympic.h')
-rw-r--r--drivers/net/tokenring/olympic.h18
1 files changed, 9 insertions, 9 deletions
diff --git a/drivers/net/tokenring/olympic.h b/drivers/net/tokenring/olympic.h
index 2fc59c99746..c91956310fb 100644
--- a/drivers/net/tokenring/olympic.h
+++ b/drivers/net/tokenring/olympic.h
@@ -216,31 +216,31 @@
/* xxxx These structures are all little endian in hardware. */
struct olympic_tx_desc {
- u32 buffer;
- u32 status_length;
+ __le32 buffer;
+ __le32 status_length;
};
struct olympic_tx_status {
- u32 status;
+ __le32 status;
};
struct olympic_rx_desc {
- u32 buffer;
- u32 res_length;
+ __le32 buffer;
+ __le32 res_length;
};
struct olympic_rx_status {
- u32 fragmentcnt_framelen;
- u32 status_buffercnt;
+ __le32 fragmentcnt_framelen;
+ __le32 status_buffercnt;
};
/* xxxx END These structures are all little endian in hardware. */
/* xxxx There may be more, but I'm pretty sure about these */
struct mac_receive_buffer {
- u16 next ;
+ __le16 next ;
u8 padding ;
u8 frame_status ;
- u16 buffer_length ;
+ __le16 buffer_length ;
u8 frame_data ;
};