* [PATCH 5/6] rt2x00 update: Apply correct endian annotation for structures that are DMA'ed to device.
From: Ivo van Doorn @ 2006-04-28 14:52 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
[-- Attachment #1: Type: text/plain, Size: 8749 bytes --]
From: Ivo van Doorn <IvDoorn@gmail.com>
Use __le32 annotations for all fields in the descriptor,
since these should always be treated as little endian.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.h wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.h 2006-04-28 15:09:48.000000000 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.h 2006-04-28 15:59:24.000000000 +0200
@@ -739,7 +739,7 @@
* TX descriptor format for TX, PRIO, ATIM and Beacon Ring.
*/
struct txd{
- u32 word0;
+ __le32 word0;
#define TXD_W0_OWNER_NIC FIELD32(0x00000001)
#define TXD_W0_VALID FIELD32(0x00000002)
#define TXD_W0_RESULT FIELD32(0x0000001c)
@@ -753,32 +753,32 @@ struct txd{
#define TXD_W0_AGC FIELD32(0x00ff0000)
#define TXD_W0_R2 FIELD32(0xff000000)
- u32 word1;
+ __le32 word1;
#define TXD_W1_BUFFER_ADDRESS FIELD32(0xffffffff)
- u32 word2;
+ __le32 word2;
#define TXD_W2_BUFFER_LENGTH FIELD32(0x0000ffff)
#define TXD_W2_DATABYTE_COUNT FIELD32(0xffff0000)
- u32 word3;
+ __le32 word3;
#define TXD_W3_PLCP_SIGNAL FIELD32(0x0000ffff)
#define TXD_W3_PLCP_SERVICE FIELD32(0xffff0000)
- u32 word4;
+ __le32 word4;
#define TXD_W4_PLCP_LENGTH_LOW FIELD32(0x0000ffff)
#define TXD_W4_PLCP_LENGTH_HIGH FIELD32(0xffff0000)
- u32 word5;
+ __le32 word5;
#define TXD_W5_BBCR4 FIELD32(0x0000ffff)
#define TXD_W5_AGC_REG FIELD32(0x007f0000)
#define TXD_W5_AGC_REG_VALID FIELD32(0x00800000)
#define TXD_W5_XXX_REG FIELD32(0x7f000000)
#define TXD_W5_XXX_REG_VALID FIELD32(0x80000000)
- u32 word6;
+ __le32 word6;
#define TXD_W6_SK_BUFF FIELD32(0xffffffff)
- u32 word7;
+ __le32 word7;
#define TXD_W7_RESERVED FIELD32(0xffffffff)
} __attribute__ ((packed));
@@ -786,7 +786,7 @@ struct txd{
* RX descriptor format for RX Ring.
*/
struct rxd{
- u32 word0;
+ __le32 word0;
#define RXD_W0_OWNER_NIC FIELD32(0x00000001)
#define RXD_W0_UNICAST_TO_ME FIELD32(0x00000002)
#define RXD_W0_MULTICAST FIELD32(0x00000004)
@@ -796,30 +796,30 @@ struct rxd{
#define RXD_W0_PHYSICAL_ERROR FIELD32(0x00000080)
#define RXD_W0_DATABYTE_COUNT FIELD32(0xffff0000)
- u32 word1;
+ __le32 word1;
#define RXD_W1_BUFFER_ADDRESS FIELD32(0xffffffff)
- u32 word2;
+ __le32 word2;
#define RXD_W2_BUFFER_LENGTH FIELD32(0x0000ffff)
#define RXD_W2_BBR0 FIELD32(0x00ff0000)
#define RXD_W2_RSSI FIELD32(0xff000000)
- u32 word3;
+ __le32 word3;
#define RXD_W3_BBR2 FIELD32(0x000000ff)
#define RXD_W3_BBR3 FIELD32(0x0000ff00)
#define RXD_W3_BBR4 FIELD32(0x00ff0000)
#define RXD_W3_BBR5 FIELD32(0xff000000)
- u32 word4;
+ __le32 word4;
#define RXD_W4_RX_END_TIME FIELD32(0xffffffff)
- u32 word5;
+ __le32 word5;
#define RXD_W5_RESERVED FIELD32(0xffffffff)
- u32 word6;
+ __le32 word6;
#define RXD_W6_RESERVED FIELD32(0xffffffff)
- u32 word7;
+ __le32 word7;
#define RXD_W7_RESERVED FIELD32(0xffffffff)
} __attribute__ ((packed));
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.h wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.h 2006-04-28 15:09:48.000000000 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.h 2006-04-28 15:58:29.000000000 +0200
@@ -987,7 +987,7 @@
* TX descriptor format for TX, PRIO, ATIM and Beacon Ring.
*/
struct txd{
- u32 word0;
+ __le32 word0;
#define TXD_W0_OWNER_NIC FIELD32(0x00000001)
#define TXD_W0_VALID FIELD32(0x00000002)
#define TXD_W0_RESULT FIELD32(0x0000001c)
@@ -1002,40 +1002,40 @@ struct txd{
#define TXD_W0_DATABYTE_COUNT FIELD32(0x0fff0000)
#define TXD_W0_CIPHER_ALG FIELD32(0xe0000000)
- u32 word1;
+ __le32 word1;
#define TXD_W1_BUFFER_ADDRESS FIELD32(0xffffffff)
- u32 word2;
+ u32 word2;
#define TXD_W2_IV_OFFSET FIELD32(0x0000003f)
#define TXD_W2_AIFS FIELD32(0x000000c0)
#define TXD_W2_CWMIN FIELD32(0x00000f00)
#define TXD_W2_CWMAX FIELD32(0x0000f000)
- u32 word3;
+ __le32 word3;
#define TXD_W3_PLCP_SIGNAL FIELD32(0x000000ff)
#define TXD_W3_PLCP_SERVICE FIELD32(0x0000ff00)
#define TXD_W3_PLCP_LENGTH_LOW FIELD32(0x00ff0000)
#define TXD_W3_PLCP_LENGTH_HIGH FIELD32(0xff000000)
- u32 word4;
+ __le32 word4;
#define TXD_W4_IV FIELD32(0xffffffff)
- u32 word5;
+ __le32 word5;
#define TXD_W5_EIV FIELD32(0xffffffff)
- u32 word6;
+ __le32 word6;
#define TXD_W6_KEY FIELD32(0xffffffff)
- u32 word7;
+ __le32 word7;
#define TXD_W7_KEY FIELD32(0xffffffff)
- u32 word8;
+ __le32 word8;
#define TXD_W8_KEY FIELD32(0xffffffff)
- u32 word9;
+ __le32 word9;
#define TXD_W9_KEY FIELD32(0xffffffff)
- u32 word10;
+ __le32 word10;
#define TXD_W10_RTS FIELD32(0x00000001)
#define TXD_W10_TX_RATE FIELD32(0x000000fe)
} __attribute__ ((packed));
@@ -1044,7 +1044,7 @@ struct txd{
* RX descriptor format for RX Ring.
*/
struct rxd{
- u32 word0;
+ __le32 word0;
#define RXD_W0_OWNER_NIC FIELD32(0x00000001)
#define RXD_W0_UNICAST_TO_ME FIELD32(0x00000002)
#define RXD_W0_MULTICAST FIELD32(0x00000004)
@@ -1059,36 +1059,36 @@ struct rxd{
#define RXD_W0_DATABYTE_COUNT FIELD32(0x0fff0000)
#define RXD_W0_CIPHER_ALG FIELD32(0xe0000000)
- u32 word1;
+ __le32 word1;
#define RXD_W1_BUFFER_ADDRESS FIELD32(0xffffffff)
- u32 word2;
+ __le32 word2;
#define RXD_W2_BBR0 FIELD32(0x000000ff)
#define RXD_W2_RSSI FIELD32(0x0000ff00)
#define RXD_W2_TA FIELD32(0xffff0000)
- u32 word3;
+ __le32 word3;
#define RXD_W3_TA FIELD32(0xffffffff)
- u32 word4;
+ __le32 word4;
#define RXD_W4_IV FIELD32(0xffffffff)
- u32 word5;
+ __le32 word5;
#define RXD_W5_EIV FIELD32(0xffffffff)
- u32 word6;
+ __le32 word6;
#define RXD_W6_KEY FIELD32(0xffffffff)
- u32 word7;
+ __le32 word7;
#define RXD_W7_KEY FIELD32(0xffffffff)
- u32 word8;
+ __le32 word8;
#define RXD_W8_KEY FIELD32(0xffffffff)
- u32 word9;
+ __le32 word9;
#define RXD_W9_KEY FIELD32(0xffffffff)
- u32 word10;
+ __le32 word10;
#define RXD_W10_DROP FIELD32(0x00000001)
} __attribute__ ((packed));
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.h wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500usb.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.h 2006-04-28 15:09:48.000000000 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500usb.h 2006-04-28 15:58:57.000000000 +0200
@@ -553,7 +553,7 @@
* TX descriptor format for TX, PRIO, ATIM and Beacon Ring.
*/
struct txd{
- u32 word0;
+ __le32 word0;
#define TXD_W0_PACKET_ID FIELD32(0x0000000f)
#define TXD_W0_RETRY_LIMIT FIELD32(0x000000f0)
#define TXD_W0_MORE_FRAG FIELD32(0x00000100)
@@ -566,22 +566,22 @@ struct txd{
#define TXD_W0_CIPHER FIELD32(0x20000000)
#define TXD_W0_KEY_ID FIELD32(0xc0000000)
- u32 word1;
+ __le32 word1;
#define TXD_W1_IV_OFFSET FIELD32(0x0000003f)
#define TXD_W1_AIFS FIELD32(0x000000c0)
#define TXD_W1_CWMIN FIELD32(0x00000f00)
#define TXD_W1_CWMAX FIELD32(0x0000f000)
- u32 word2;
+ __le32 word2;
#define TXD_W2_PLCP_SIGNAL FIELD32(0x000000ff)
#define TXD_W2_PLCP_SERVICE FIELD32(0x0000ff00)
#define TXD_W2_PLCP_LENGTH_LOW FIELD32(0x00ff0000)
#define TXD_W2_PLCP_LENGTH_HIGH FIELD32(0xff000000)
- u32 word3;
+ __le32 word3;
#define TXD_W3_IV FIELD32(0xffffffff)
- u32 word4;
+ __le32 word4;
#define TXD_W4_EIV FIELD32(0xffffffff)
} __attribute__ ((packed));
@@ -589,7 +589,7 @@ struct txd{
* RX descriptor format for RX Ring.
*/
struct rxd{
- u32 word0;
+ __le32 word0;
#define RXD_W0_UNICAST_TO_ME FIELD32(0x00000002)
#define RXD_W0_MULTICAST FIELD32(0x00000004)
#define RXD_W0_BROADCAST FIELD32(0x00000008)
@@ -601,14 +601,14 @@ struct rxd{
#define RXD_W0_CI_ERROR FIELD32(0x00000200)
#define RXD_W0_DATABYTE_COUNT FIELD32(0x0fff0000)
- u32 word1;
+ __le32 word1;
#define RXD_W1_SIGNAL FIELD32(0x000000ff)
#define RXD_W1_RSSI FIELD32(0x0000ff00)
- u32 word2;
+ __le32 word2;
#define RXD_W2_IV FIELD32(0xffffffff)
- u32 word3;
+ __le32 word3;
#define RXD_W3_EIV FIELD32(0xffffffff)
} __attribute__ ((packed));
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 4/6] rt2x00 update: Remove packed attributes for structures that don't need it
From: Ivo van Doorn @ 2006-04-28 14:52 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
[-- Attachment #1: Type: text/plain, Size: 3264 bytes --]
From: Ivo van Doorn <IvDoorn@gmail.com>
Remove __attribute__ ((packed)) for structures that
are not being send to the device.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2x00.h wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2x00.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2x00.h 2006-04-28 15:09:53.000000000 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2x00.h 2006-04-28 15:50:06.000000000 +0200
@@ -324,12 +324,12 @@ extern int error_bitrange_bad;
struct rt2x00_field16{
u16 bit_offset;
u16 bit_mask;
-} __attribute__ ((packed));
+};
struct rt2x00_field32{
u32 bit_offset;
u32 bit_mask;
-} __attribute__ ((packed));
+};
/*
* Before intitializing the rt2x00_field# structures,
@@ -430,7 +430,7 @@ rt2x00_get_field16_nb(const u16 reg, con
struct _rt2x00_chip{
u16 rt;
u16 rf;
-} __attribute__ ((packed));
+};
/*
* Set chipset data.
@@ -511,7 +511,7 @@ struct data_ring{
*/
u16 data_size;
u16 desc_size;
-} __attribute__ ((packed));
+};
/*
* Handlers to determine the address of the current device specific
@@ -612,7 +612,7 @@ struct scanning{
short status;
#define SCANNING_READY 0x0001
#define SCANNING_CANCELLED 0x0002
-} __attribute__ ((packed));
+};
/*
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2x00pci.h wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2x00pci.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2x00pci.h 2006-04-28 15:09:45.000000000 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2x00pci.h 2006-04-28 15:49:18.000000000 +0200
@@ -72,7 +72,7 @@ struct rt2x00_button{
short button_status:1;
short active_poll:1;
short __pad:14;
-} __attribute__ ((packed));
+};
#endif /* CONFIG_RT2X00_BUTTON */
/*
@@ -106,7 +106,7 @@ struct data_entry{
*/
void *data_addr;
dma_addr_t data_dma;
-} __attribute__ ((packed));
+};
/*
* Device specific structure.
@@ -231,7 +231,7 @@ struct rt2x00_pci{
* after that the beacon and RX ring follow.
*/
struct data_ring *ring;
-} __attribute__ ((packed));
+};
static inline struct data_ring*
rt2x00pci_get_ring(struct rt2x00_pci *rt2x00pci, const int ring)
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2x00usb.h wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2x00usb.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2x00usb.h 2006-04-28 15:09:44.000000000 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2x00usb.h 2006-04-28 15:49:31.000000000 +0200
@@ -85,7 +85,7 @@ struct data_entry{
*/
void *data_addr;
dma_addr_t data_dma;
-} __attribute__ ((packed));
+};
/*
* The location of the descriptor is variating and depends
@@ -215,7 +215,7 @@ struct rt2x00_usb{
* after that the beacon and RX ring follow.
*/
struct data_ring *ring;
-} __attribute__ ((packed));
+};
static inline struct data_ring*
rt2x00usb_get_ring(struct rt2x00_usb *rt2x00usb, const int ring)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 6/6] rt2x00 update: Apply correct error handling to dscape stack
From: Ivo van Doorn @ 2006-04-28 14:52 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
[-- Attachment #1: Type: text/plain, Size: 4507 bytes --]
From: Ivo van Doorn <IvDoorn@gmail.com>
Return correct error code at failure, and
request debug report when the function _tx()
has received an invalid queue.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c 2006-04-28 15:32:12.000000000 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2400pci.c 2006-04-28 16:34:55.000000000 +0200
@@ -1538,20 +1538,21 @@ rt2400pci_tx(struct net_device *net_dev,
*/
ring = rt2x00pci_get_ring(rt2x00pci, control->queue);
if (unlikely(!ring)) {
- ERROR("Attempt to send packet over invalid queue %d.\n",
- control->queue);
- return NET_RX_DROP;
+ ERROR("Attempt to send packet over invalid queue %d.\n"
+ "Please file bug report to %s.\n",
+ control->queue, DRV_PROJECT);
+ return NET_XMIT_DROP;
}
if (rt2x00_ring_full(ring))
- return NET_RX_DROP;
+ return NET_XMIT_DROP;
entry = rt2x00_get_data_entry(ring);
txd = entry->desc_addr;
if (rt2x00_get_field32(txd->word0, TXD_W0_OWNER_NIC)
|| rt2x00_get_field32(txd->word0, TXD_W0_VALID))
- return NET_RX_DROP;
+ return NET_XMIT_DROP;
memcpy(entry->data_addr, skb->data, skb->len);
rt2400pci_write_tx_desc(rt2x00pci, txd, skb, control);
@@ -2032,7 +2033,7 @@ rt2400pci_conf_tx(struct net_device *net
*/
if (queue != IEEE80211_TX_QUEUE_DATA0) {
NOTICE("Ignoring configuration for queue %d.\n", queue);
- return 0;
+ return -EINVAL;
}
memcpy(&ring->tx_params, params, sizeof(*params));
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c 2006-04-28 15:32:31.000000000 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500pci.c 2006-04-28 16:34:54.000000000 +0200
@@ -1661,20 +1661,21 @@ rt2500pci_tx(struct net_device *net_dev,
*/
ring = rt2x00pci_get_ring(rt2x00pci, control->queue);
if (unlikely(!ring)) {
- ERROR("Attempt to send packet over invalid queue %d.\n",
- control->queue);
- return NET_RX_DROP;
+ ERROR("Attempt to send packet over invalid queue %d.\n"
+ "Please file bug report to %s.\n",
+ control->queue, DRV_PROJECT);
+ return NET_XMIT_DROP;
}
if (rt2x00_ring_full(ring))
- return NET_RX_DROP;
+ return NET_XMIT_DROP;
entry = rt2x00_get_data_entry(ring);
txd = entry->desc_addr;
if (rt2x00_get_field32(txd->word0, TXD_W0_OWNER_NIC)
|| rt2x00_get_field32(txd->word0, TXD_W0_VALID))
- return NET_RX_DROP;
+ return NET_XMIT_DROP;
memcpy(entry->data_addr, skb->data, skb->len);
rt2500pci_write_tx_desc(rt2x00pci, txd, skb, control);
@@ -2147,7 +2148,7 @@ rt2500pci_conf_tx(struct net_device *net
ring = rt2x00pci_get_ring(rt2x00pci, queue);
if (unlikely(!ring)) {
NOTICE("Ignoring configuration for queue %d.\n", queue);
- return 0;
+ return -EINVAL;
}
memcpy(&ring->tx_params, params, sizeof(*params));
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c 2006-04-28 15:32:06.000000000 +0200
+++ wireless-dev-rt2x00-patch/drivers/net/wireless/d80211/rt2x00/rt2500usb.c 2006-04-28 16:34:56.000000000 +0200
@@ -1373,13 +1373,14 @@ rt2500usb_tx(struct net_device *net_dev,
*/
ring = rt2x00usb_get_ring(rt2x00usb, control->queue);
if (unlikely(!ring)) {
- ERROR("Attempt to send packet over invalid queue %d.\n",
- control->queue);
- return NET_RX_DROP;
+ ERROR("Attempt to send packet over invalid queue %d.\n"
+ "Please file bug report to %s.\n",
+ control->queue, DRV_PROJECT);
+ return NET_XMIT_DROP;
}
if (rt2x00_ring_full(ring))
- return NET_RX_DROP;
+ return NET_XMIT_DROP;
entry = rt2x00_get_data_entry(ring);
txd = rt2x00usb_txdesc_addr(entry);
@@ -1797,7 +1798,7 @@ rt2500usb_conf_tx(struct net_device *net
ring = rt2x00usb_get_ring(rt2x00usb, queue);
if (unlikely(!ring)) {
NOTICE("Ignoring configuration for queue %d.\n", queue);
- return 0;
+ return -EINVAL;
}
memcpy(&ring->tx_params, params, sizeof(*params));
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 0/6] rt2x00 update
From: Ivo van Doorn @ 2006-04-28 14:52 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]
Hi,
Here is a small update for the rt2x00 drivers in the wireless-dev tree.
They all contain fixes and requests from the feedback from the last series.
And they should be applied after the last series.
A short summary of all patches the are following:
[PATCH 1/6] rt2x00 update: Remove casts from void* pointers
[PATCH 2/6] rt2x00 update: Deactivate monitor_during_oper for now
[PATCH 3/6] rt2x00 update: Use static const for the vals arrays
[PATCH 4/6] rt2x00 update: Remove packed attributes for structures that don't need it
[PATCH 5/6] rt2x00 update: Apply correct endian annotation for structures that are DMA'ed to device.
[PATCH 6/6] rt2x00 update: Apply correct error handling to dscape stack
Altough all patches are small and are inlined, I have added
them to the same location of the previous patch series.
http://mendiosus.nl/rt2x00/rt2x00-33-void-casts.diff
http://mendiosus.nl/rt2x00/rt2x00-34-monitor-operation.diff
http://mendiosus.nl/rt2x00/rt2x00-35-static-const.diff
http://mendiosus.nl/rt2x00/rt2x00-36-packed.diff
http://mendiosus.nl/rt2x00/rt2x00-37-endian-annotation.diff
http://mendiosus.nl/rt2x00/rt2x00-38-error-handling.diff
IvD
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 20/32] rt2x00: byte ordering correctness
From: Ivo van Doorn @ 2006-04-28 15:01 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Michael Buesch, netdev, rt2x00-devel
In-Reply-To: <20060428134632.GA4526@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]
On Friday 28 April 2006 15:46, Christoph Hellwig wrote:
> On Fri, Apr 28, 2006 at 03:42:29PM +0200, Michael Buesch wrote:
> > I guess you are confusing something here:
> > MMIO access versus values in structs (for example) that
> > are accessed through DMA (for example).
>
> so there's two general problems:
>
> mmio/pio - linux expects the device to be le there by defalt and
> {read,write}{b,s,l} do the switch automatically
> dmaed data - you always need to switch data yourself, data is commonly
> either be or le
>
> now there's devices that are always be for mmio or can be switched to it
> during initialization. For Linux you'd traditionally have to switch before
> calling {read,write}{b,s,l} or use the __raw_ version that have other issues.
> The ioread*/iowrite* APIs now have a BE version, too.
Unless I am mistaken, or the ralink design sheets are outdated on that issue,
I do recall that there was a big endian switch in one of the registers.
I think I need to definately investigate that to see if it would be usefull. :)
Thanks,
Ivo
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] bcm43xx_d80211: fix bug in open
From: Jiri Benc @ 2006-04-28 15:45 UTC (permalink / raw)
To: John W. Linville; +Cc: Michael Buesch, netdev
In-Reply-To: <20060426193907.GB7922@tuxdriver.com>
On Wed, 26 Apr 2006 15:39:12 -0400, John W. Linville wrote:
> Hacky or not, I'm applying this patch to keep the bcm43xx driver
> from breaking. I don't suppose you have a patch for the rt2x00 driver?
The patch for bcm43xx was really just quick fix, only partially
tested...
Signed-off-by: Jiri Benc <jbenc@suse.cz>
---
drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- dscape.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
+++ dscape/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
@@ -4172,7 +4172,7 @@ static int bcm43xx_net_open(struct net_d
int res;
res = bcm43xx_init_board(bcm);
- if (!res)
+ if (res)
return res;
bcm43xx_set_iwmode(bcm, bcm->iw_mode);
return 0;
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* RE: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Caitlin Bestler @ 2006-04-28 15:59 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: David S. Miller, kelly, rusty, netdev
Evgeniy Polyakov wrote:
> On Thu, Apr 27, 2006 at 02:12:09PM -0700, Caitlin Bestler
> (caitlinb@broadcom.com) wrote:
>> So the real issue is when there is an intelligent device that uses
>> hardware packet classification to place the packet in the correct
>> ring. We don't want to bypass packet filtering, but it would be
>> terribly wasteful to reclassify the packet.
>> Intelligent NICs will have packet classification capabilities to
>> support RDMA and iSCSI. Those capabilities should be available to
>> benefit SOCK_STREAM and SOCK_DGRAM users as well without it being a
>> choice of either turning all stack control over to the NIC or
>> ignorign all NIC capabilities beyound pretending to be a dumb
>> Ethernet NIC.
>
> Btw, how is it supposed to work without header split capabale
> hardware?
Hardware that can classify packets is obviously capable of doing
header data separation, but that does not mean that it has to do so.
If the host wants header data separation it's real value is that when
packets arrive in order that fewer distinct copies are required to
move the data to the user buffer (because separated data can
be placed back-to-back in a data-only ring). But that's an optimization,
it's not needed to make the idea worth doing, or even necessarily
in the first implementation.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov @ 2006-04-28 16:12 UTC (permalink / raw)
To: Caitlin Bestler; +Cc: David S. Miller, kelly, rusty, netdev
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F143B0E2@NT-SJCA-0751.brcm.ad.broadcom.com>
On Fri, Apr 28, 2006 at 08:59:19AM -0700, Caitlin Bestler (caitlinb@broadcom.com) wrote:
> > Btw, how is it supposed to work without header split capabale
> > hardware?
>
> Hardware that can classify packets is obviously capable of doing
> header data separation, but that does not mean that it has to do so.
>
> If the host wants header data separation it's real value is that when
> packets arrive in order that fewer distinct copies are required to
> move the data to the user buffer (because separated data can
> be placed back-to-back in a data-only ring). But that's an optimization,
> it's not needed to make the idea worth doing, or even necessarily
> in the first implementation.
If there is dataflow, not flow of packets or flow of data with holes,
it could be possible to modify recv() to just return the right pointer,
so in theory userspace modifications would be minimal.
With copy in place it completely does not differ from current design
with copy_to_user() being used since memcpy() is just slightly faster
than copy*user().
--
Evgeniy Polyakov
^ permalink raw reply
* RE: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Caitlin Bestler @ 2006-04-28 17:02 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: David S. Miller, kelly, rusty, netdev
Evgeniy Polyakov wrote:
> On Fri, Apr 28, 2006 at 08:59:19AM -0700, Caitlin Bestler
> (caitlinb@broadcom.com) wrote:
>>> Btw, how is it supposed to work without header split capabale
>>> hardware?
>>
>> Hardware that can classify packets is obviously capable of doing
>> header data separation, but that does not mean that it has to do so.
>>
>> If the host wants header data separation it's real value is that when
>> packets arrive in order that fewer distinct copies are required to
>> move the data to the user buffer (because separated data can be
>> placed back-to-back in a data-only ring). But that's an
>> optimization, it's not needed to make the idea worth doing, or even
>> necessarily in the first implementation.
>
> If there is dataflow, not flow of packets or flow of data
> with holes, it could be possible to modify recv() to just
> return the right pointer, so in theory userspace
> modifications would be minimal.
> With copy in place it completely does not differ from current
> design with copy_to_user() being used since memcpy() is just
> slightly faster than copy*user().
If the app is really ready to use a modified interface we might as well
just give them a QP/CQ interface. But I suppose "receive by pointer"
interfaces don't really stretch the sockets interface all that badly.
The key is that you have to decide how the buffer is released,
is it the next call? Or a separate call? Does releasing buffer
N+2 release buffers N and N+1? What you want to avoid
is having to keep a scoreboard of which buffers have been
released.
But in context, header/data separation would allow in order
packets to have the data be placed back to back, which
could allow a single recv to report the payload of multiple
successive TCP segments. So the benefit of header/data
separation remains the same, and I still say it's a optimization
that should not be made a requirement. The benefits of vj_channels
exist even without them. When the packet classifier runs on the
host, header/data separation would not be free. I want to enable
hardware offloads, not make the kernel bend over backwards
to emulate how hardware would work. I'm just hoping that we
can agree to let hardware do its work without being forced to
work the same way the kernel does (i.e., running down a long
list of arbitrary packet filter rules on a per packet basis).
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Stephen Hemminger @ 2006-04-28 17:18 UTC (permalink / raw)
To: Caitlin Bestler; +Cc: Evgeniy Polyakov, David S. Miller, kelly, rusty, netdev
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F143B0F3@NT-SJCA-0751.brcm.ad.broadcom.com>
On Fri, 28 Apr 2006 10:02:10 -0700
"Caitlin Bestler" <caitlinb@broadcom.com> wrote:
> Evgeniy Polyakov wrote:
> > On Fri, Apr 28, 2006 at 08:59:19AM -0700, Caitlin Bestler
> > (caitlinb@broadcom.com) wrote:
> >>> Btw, how is it supposed to work without header split capabale
> >>> hardware?
> >>
> >> Hardware that can classify packets is obviously capable of doing
> >> header data separation, but that does not mean that it has to do so.
> >>
> >> If the host wants header data separation it's real value is that when
> >> packets arrive in order that fewer distinct copies are required to
> >> move the data to the user buffer (because separated data can be
> >> placed back-to-back in a data-only ring). But that's an
> >> optimization, it's not needed to make the idea worth doing, or even
> >> necessarily in the first implementation.
> >
> > If there is dataflow, not flow of packets or flow of data
> > with holes, it could be possible to modify recv() to just
> > return the right pointer, so in theory userspace
> > modifications would be minimal.
> > With copy in place it completely does not differ from current
> > design with copy_to_user() being used since memcpy() is just
> > slightly faster than copy*user().
>
> If the app is really ready to use a modified interface we might as well
> just give them a QP/CQ interface. But I suppose "receive by pointer"
> interfaces don't really stretch the sockets interface all that badly.
> The key is that you have to decide how the buffer is released,
> is it the next call? Or a separate call? Does releasing buffer
> N+2 release buffers N and N+1? What you want to avoid
> is having to keep a scoreboard of which buffers have been
> released.
>
Please just use existing AIO interface. We don't need another
interface. The number of interfaces increases the exposed bug
surface geometrically. Which means for each new interface, it
means testing and fixing bugs in every possible usage.
> But in context, header/data separation would allow in order
> packets to have the data be placed back to back, which
> could allow a single recv to report the payload of multiple
> successive TCP segments. So the benefit of header/data
> separation remains the same, and I still say it's a optimization
> that should not be made a requirement. The benefits of vj_channels
> exist even without them. When the packet classifier runs on the
> host, header/data separation would not be free. I want to enable
> hardware offloads, not make the kernel bend over backwards
> to emulate how hardware would work. I'm just hoping that we
> can agree to let hardware do its work without being forced to
> work the same way the kernel does (i.e., running down a long
> list of arbitrary packet filter rules on a per packet basis).
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] netem: fix loss
From: Stephen Hemminger @ 2006-04-28 17:22 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, George Nychis, netem
The following one line fix is needed to make loss function of
netem work right when doing loss on the local host.
Otherwise, higher layers just recover.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
--- linux-2.6.orig/net/sched/sch_netem.c
+++ linux-2.6/net/sched/sch_netem.c
@@ -167,7 +167,7 @@ static int netem_enqueue(struct sk_buff
if (count == 0) {
sch->qstats.drops++;
kfree_skb(skb);
- return NET_XMIT_DROP;
+ return NET_XMIT_BYPASS;
}
/*
^ permalink raw reply
* Re: [LARTC] how to change classful netem loss probability?
From: Stephen Hemminger @ 2006-04-28 17:24 UTC (permalink / raw)
To: George P Nychis; +Cc: George Nychis, lartc, netdev
In-Reply-To: <32923.128.2.140.234.1146187103.squirrel@128.2.140.234>
Loss was broken, patch sent.
The following works now:
# tc qdisc add dev eth1 root handle 1:0 netem loss 20%
# tc qdisc add dev eth1 parent 1:1 handle 10: tbf \
rate 256kbit buffer 1600 limit 3000
# ping -f -c 1000 shell
1000 packets transmitted, 781 received, 21% packet loss, time 3214ms
rtt min/avg/max/mdev = 0.187/0.398/3.763/0.730 ms, ipg/ewma 3.217/0.538 ms
# tc qdisc chang dev eth1 handle 1: netem loss 1%
# ping -f -c 1000 shell
1000 packets transmitted, 990 received, 1% packet loss, time 2922ms
rtt min/avg/max/mdev = 0.187/2.739/3.298/0.789 ms, ipg/ewma 2.924/2.084 ms
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov @ 2006-04-28 17:25 UTC (permalink / raw)
To: Caitlin Bestler; +Cc: David S. Miller, kelly, rusty, netdev
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F143B0F3@NT-SJCA-0751.brcm.ad.broadcom.com>
On Fri, Apr 28, 2006 at 10:02:10AM -0700, Caitlin Bestler (caitlinb@broadcom.com) wrote:
> If the app is really ready to use a modified interface we might as well
> just give them a QP/CQ interface. But I suppose "receive by pointer"
> interfaces don't really stretch the sockets interface all that badly.
> The key is that you have to decide how the buffer is released,
> is it the next call? Or a separate call? Does releasing buffer
> N+2 release buffers N and N+1? What you want to avoid
> is having to keep a scoreboard of which buffers have been
> released.
>
> But in context, header/data separation would allow in order
> packets to have the data be placed back to back, which
> could allow a single recv to report the payload of multiple
> successive TCP segments. So the benefit of header/data
> separation remains the same, and I still say it's a optimization
> that should not be made a requirement. The benefits of vj_channels
> exist even without them. When the packet classifier runs on the
> host, header/data separation would not be free. I want to enable
> hardware offloads, not make the kernel bend over backwards
> to emulate how hardware would work. I'm just hoping that we
> can agree to let hardware do its work without being forced to
> work the same way the kernel does (i.e., running down a long
> list of arbitrary packet filter rules on a per packet basis).
I see your point, and respectfully disagree.
The more complex userspace interface we create the less users it will
have. It is completely unconvenient to read 100 bytes and receive only
80, since 20 were eaten by header. And what if we need only 20, but
packet contains 100, introduce per packet head pointer?
For purpose of benchmarking it works perfectly -
read the whole packet, one can event touch that data to emulate real
work, but for the real world it becomes practically unusabl.
But what we are talking about right now is a research project, not
production system, so we can create any interface we like since the main
goal, IMHO, is searching for the bottlenecks in the current stack and
ways of it's removal even by introducing new complex interface.
I would definitely like to see how your approach works for some
kind of real workloads and does it allow to
create faster and generally better systems.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov @ 2006-04-28 17:29 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Caitlin Bestler, David S. Miller, kelly, rusty, netdev
In-Reply-To: <20060428101833.2f0d6ae8@localhost.localdomain>
On Fri, Apr 28, 2006 at 10:18:33AM -0700, Stephen Hemminger (shemminger@osdl.org) wrote:
> Please just use existing AIO interface. We don't need another
> interface. The number of interfaces increases the exposed bug
> surface geometrically. Which means for each new interface, it
> means testing and fixing bugs in every possible usage.
Networking AIO? Like [1] :)
That would be really good.
1. http://tservice.net.ru/~s0mbre/old/?section=projects&item=naio
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Stephen Hemminger @ 2006-04-28 17:41 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: Caitlin Bestler, David S. Miller, kelly, rusty, netdev
In-Reply-To: <20060428172932.GB16916@2ka.mipt.ru>
On Fri, 28 Apr 2006 21:29:32 +0400
Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> On Fri, Apr 28, 2006 at 10:18:33AM -0700, Stephen Hemminger (shemminger@osdl.org) wrote:
> > Please just use existing AIO interface. We don't need another
> > interface. The number of interfaces increases the exposed bug
> > surface geometrically. Which means for each new interface, it
> > means testing and fixing bugs in every possible usage.
>
> Networking AIO? Like [1] :)
> That would be really good.
>
> 1. http://tservice.net.ru/~s0mbre/old/?section=projects&item=naio
>
The existing infrastructure is there in the syscall layer, it just
isn't really AIO for sockets. That naio project has two problems, first
they require driver changes, and he is doing it on the stupidest
of hardware, optimizing a 8139too is foolish. Second, introducing
kevents, seems unnecessary and hasn't been accepted in the mainline.
The existing linux AIO model seems sufficient:
http://lse.sourceforge.net/io/aio.html
There is work to put true Posix AIO on top of this.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov @ 2006-04-28 17:55 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Caitlin Bestler, David S. Miller, kelly, rusty, netdev
In-Reply-To: <20060428104118.6a056a59@localhost.localdomain>
On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger (shemminger@osdl.org) wrote:
> On Fri, 28 Apr 2006 21:29:32 +0400
> Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
>
> > On Fri, Apr 28, 2006 at 10:18:33AM -0700, Stephen Hemminger (shemminger@osdl.org) wrote:
> > > Please just use existing AIO interface. We don't need another
> > > interface. The number of interfaces increases the exposed bug
> > > surface geometrically. Which means for each new interface, it
> > > means testing and fixing bugs in every possible usage.
> >
> > Networking AIO? Like [1] :)
> > That would be really good.
> >
> > 1. http://tservice.net.ru/~s0mbre/old/?section=projects&item=naio
> >
>
> The existing infrastructure is there in the syscall layer, it just
> isn't really AIO for sockets. That naio project has two problems, first
> they require driver changes, and he is doing it on the stupidest
> of hardware, optimizing a 8139too is foolish.
No, it does not. You confuse it with receiving zero-copy support which
allows to DMA data directly into VFS cache [1].
NAIO works for any kind of hardware and was tested with e1000 and showed
noticeble win in both CPU usage and network performance.
> Second, introducing
> kevents, seems unnecessary and hasn't been accepted in the mainline.
kevent was never sent to lkml@ although it showed over 40% win over epoll for
test web server. Sending it to lkml@ is just jumping into ... not into
technical world, so I posted it first here, but without much attention
though.
> The existing linux AIO model seems sufficient:
> http://lse.sourceforge.net/io/aio.html
>
> There is work to put true Posix AIO on top of this.
There are a lot of discussions about combining AIO with epoll and
combine them into something similar to kevent which allows to monitor
level and edge triggered events, to create proper state machine for AIO
compeltions. kevent [2] does exactly that. AIO works not as state
machine, but it's repeated-check design is more like postponing work
from one context to special thread.
1. receiving zero-copy support
http://tservice.net.ru/~s0mbre/old/?section=projects&item=recv_zero_copy
2. kevent system
http://tservice.net.ru/~s0mbre/old/?section=projects&item=kevent
--
Evgeniy Polyakov
^ permalink raw reply
* RE: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Caitlin Bestler @ 2006-04-28 17:55 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: David S. Miller, kelly, rusty, netdev
Evgeniy Polyakov wrote:
>
> I see your point, and respectfully disagree.
> The more complex userspace interface we create the less users
> it will have. It is completely unconvenient to read 100 bytes
> and receive only 80, since 20 were eaten by header. And what
> if we need only 20, but packet contains 100, introduce per packet
> head pointer? For purpose of benchmarking it works perfectly - read
> the whole packet, one can event touch that data to emulate real
> work, but for the real world it becomes practically unusabl.
>
In a straight-forward user-mode library using existing interfaces the
message would be interleaved with the headers in the inbound ring.
While the inbound ring is part of user memory, it is not what the
user would process from, that would be the buffer they supplied
in a call to read() or recvmsg(), that buffer would have to make
no allowances for interleaved headers.
Enabling zero-copy when a buffer is pre-posted is possible, but
modestly complex. Research on MPI and SDP have generally
shown that the unless the pinning overhead is eliminated somehow
that the buffers have to be quite large before zero-copy reception
becomes a benefit. vj_netchannels represent a strategy of minimizing
registration/pinning costs even if it means paying for an extra copy.
Because the extra copy is closely tied to the activation of the data
sink consumer the cost of that extra copy is greatly reduced because
it places the data in the cache immediately before the application
will in fact use the received data.
Also keep in mind that once the issues are resolved to allow the
netchannel rings to be directly visible to a user-mode client that
enhanced/specialized interfaces can easily be added in user-mode
libraries. So focusing on supporting existing conventional interfaces
is probably the best approach for the initial efforts.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 18:20 UTC (permalink / raw)
To: johnpol; +Cc: caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428073216.GB3378@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Fri, 28 Apr 2006 11:32:16 +0400
> Definitely, userspace application must be very smart to deal with
> ip/tcp/option headers...
That is why we will put an "offset+len" in the ring so they need not
parse the packet headers.
^ permalink raw reply
* [PATCH] rt2x00: Compile fix and kernel version cleanup
From: Ivo van Doorn @ 2006-04-28 18:52 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
[-- Attachment #1: Type: text/plain, Size: 5789 bytes --]
From: Ivo van Doorn <IvDoorn@gmail.com>
During CVS merge I noticed several compilation errors have sneaked
into the git version of rt2x00.
- PRIO_ENTRIES define has been removed, TX_ENTRIES should be used
- poll_delay module argument is of the type short
- Remove LINUX_VERSION_CODE checks.
- Fix missing byteordering type
- Fix typo in usb_device
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c 2006-04-28 20:49:32.000000000 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2400pci.c 2006-04-28 20:50:40.000000000 +0200
@@ -1239,7 +1239,7 @@ rt2400pci_allocate_rings(struct rt2x00_p
ATIM_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2400pci_alloc_ring(
rt2x00pci, &rt2x00pci->ring[RING_PRIO], rt2400pci_txdone,
- PRIO_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
+ TX_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2400pci_alloc_ring(
rt2x00pci, &rt2x00pci->ring[RING_BEACON], rt2400pci_beacondone,
BEACON_ENTRIES, MGMT_FRAME_SIZE, sizeof(struct txd))) {
@@ -2729,14 +2729,12 @@ MODULE_PARM_DESC(debug, "Set this parame
#endif /* CONFIG_RT2400PCI_DEBUG */
#ifdef CONFIG_RT2400PCI_BUTTON
-module_param_named(poll_delay, rt2x00_poll_delay, int, S_IRUGO);
+module_param_named(poll_delay, rt2x00_poll_delay, short, S_IRUGO);
MODULE_PARM_DESC(debug, "Delay between WiFi button pollings (in 100ms).");
#endif /* CONFIG_RT2400PCI_BUTTON */
static struct pci_driver rt2400pci_driver = {
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 14)
.owner = THIS_MODULE,
-#endif /* LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 14) */
.name = DRV_NAME,
.id_table = rt2400pci_device_table,
.probe = rt2400pci_probe,
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c 2006-04-28 20:49:45.000000000 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.c 2006-04-28 20:50:39.000000000 +0200
@@ -1328,7 +1328,7 @@ rt2500pci_allocate_rings(struct rt2x00_p
ATIM_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2500pci_alloc_ring(
rt2x00pci, &rt2x00pci->ring[RING_PRIO], rt2500pci_txdone,
- PRIO_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
+ TX_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2500pci_alloc_ring(
rt2x00pci, &rt2x00pci->ring[RING_BEACON], rt2500pci_beacondone,
BEACON_ENTRIES, MGMT_FRAME_SIZE, sizeof(struct txd))) {
@@ -3032,14 +3032,12 @@ MODULE_PARM_DESC(debug, "Set this parame
#endif /* CONFIG_RT2500PCI_DEBUG */
#ifdef CONFIG_RT2500PCI_BUTTON
-module_param_named(poll_delay, rt2x00_poll_delay, int, S_IRUGO);
+module_param_named(poll_delay, rt2x00_poll_delay, short, S_IRUGO);
MODULE_PARM_DESC(debug, "Delay between WiFi button pollings (in 100ms).");
#endif /* CONFIG_RT2500PCI_BUTTON */
static struct pci_driver rt2500pci_driver = {
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 14)
.owner = THIS_MODULE,
-#endif /* LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 14) */
.name = DRV_NAME,
.id_table = rt2500pci_device_table,
.probe = rt2500pci_probe,
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.h wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.h 2006-04-28 15:58:29.000000000 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.h 2006-04-28 20:28:58.000000000 +0200
@@ -1005,7 +1005,7 @@ struct txd{
__le32 word1;
#define TXD_W1_BUFFER_ADDRESS FIELD32(0xffffffff)
- u32 word2;
+ __le32 word2;
#define TXD_W2_IV_OFFSET FIELD32(0x0000003f)
#define TXD_W2_AIFS FIELD32(0x000000c0)
#define TXD_W2_CWMIN FIELD32(0x00000f00)
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c 2006-04-28 20:49:59.000000000 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500usb.c 2006-04-28 20:50:39.000000000 +0200
@@ -1362,7 +1362,7 @@ rt2500usb_tx(struct net_device *net_dev,
struct sk_buff *skb, struct ieee80211_tx_control *control)
{
struct rt2x00_usb *rt2x00usb = ieee80211_dev_hw_data(net_dev);
- struct usb_devive *usb_dev =
+ struct usb_device *usb_dev =
interface_to_usbdev(rt2x00usb->usb_intf);
struct data_ring *ring;
struct data_entry *entry;
@@ -1844,7 +1844,7 @@ rt2500usb_beacon_update(struct net_devic
struct sk_buff *skb, struct ieee80211_tx_control *control)
{
struct rt2x00_usb *rt2x00usb = ieee80211_dev_hw_data(net_dev);
- struct usb_devive *usb_dev =
+ struct usb_device *usb_dev =
interface_to_usbdev(rt2x00usb->usb_intf);
struct data_entry *entry;
@@ -2074,7 +2074,7 @@ rt2500usb_init_hw_channels(struct rt2x00
channels[counter].val = vals[counter];
}
- /*
+ /*
* Set TX power, each EEPROM TXpower entry
* contains the TXpower value for 2 channels.
*/
@@ -2628,9 +2628,7 @@ MODULE_PARM_DESC(debug, "Set this parame
#endif /* CONFIG_RT2500USB_DEBUG */
static struct usb_driver rt2500usb_driver = {
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 15)
.owner = THIS_MODULE,
-#endif /* LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 15) */
.name = DRV_NAME,
.id_table = rt2500usb_device_table,
.probe = rt2500usb_probe,
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1]x25: fix for spinlock recurse and spinlock lockup with timer handler in x25
From: David S. Miller @ 2006-04-28 19:00 UTC (permalink / raw)
To: spereira; +Cc: akpm, netdev, eis, linux-x25, linux-kernel
In-Reply-To: <1145509403.16180.10.camel@spereira05.tusc.com.au>
From: Shaun Pereira <spereira@tusc.com.au>
Date: Thu, 20 Apr 2006 15:03:23 +1000
> From: spereira@tusc.com.au
>
> When the sk_timer function x25_heartbeat_expiry() is called by the kernel
> in a running/terminating process, spinlock-recursion and spinlock-lockup
> locks up the kernel.
> This has happened with testing on some distro's and the patch below fixed it.
>
> Signed-off-by:Shaun Pereira <spereira@tusc.com.au>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 19:09 UTC (permalink / raw)
To: johnpol; +Cc: caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428161221.GA12357@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Fri, 28 Apr 2006 20:12:21 +0400
> If there is dataflow, not flow of packets or flow of data with holes,
> it could be possible to modify recv() to just return the right pointer,
> so in theory userspace modifications would be minimal.
> With copy in place it completely does not differ from current design
> with copy_to_user() being used since memcpy() is just slightly faster
> than copy*user().
I very much feel that avoiding userland API changes is
a complete mistake.
We need new interfaces to do this right.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 19:10 UTC (permalink / raw)
To: shemminger; +Cc: caitlinb, johnpol, kelly, rusty, netdev
In-Reply-To: <20060428101833.2f0d6ae8@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Fri, 28 Apr 2006 10:18:33 -0700
> Please just use existing AIO interface.
I totally disagree, the existing AIO interface is garbage.
We need new APIs to do this right, to get the ring buffer
and the zero-copy'ness correct.
^ permalink raw reply
* Re: [PATCH] netem: fix loss
From: David S. Miller @ 2006-04-28 19:12 UTC (permalink / raw)
To: shemminger; +Cc: netdev, gnychis, netem
In-Reply-To: <20060428102240.59ba2a7a@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Fri, 28 Apr 2006 10:22:40 -0700
> The following one line fix is needed to make loss function of
> netem work right when doing loss on the local host.
> Otherwise, higher layers just recover.
>
> Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 19:14 UTC (permalink / raw)
To: johnpol; +Cc: caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428172536.GA16916@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Fri, 28 Apr 2006 21:25:36 +0400
> The more complex userspace interface we create the less users it will
> have. It is completely unconvenient to read 100 bytes and receive only
> 80, since 20 were eaten by header.
These bytes are charged to socket anyways, and allowing the
headers to be there is the only clean way to finesse the whole
zero-copy problem.
User can manage his data any way he likes. He can decide to take
advantage of the zero-copy layout we've provided, or he can copy
to put things into a format he is more happy with at the cost
of the copy.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 19:16 UTC (permalink / raw)
To: johnpol; +Cc: shemminger, caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428175538.GA13898@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Fri, 28 Apr 2006 21:55:39 +0400
> On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger (shemminger@osdl.org) wrote:
> > Second, introducing
> > kevents, seems unnecessary and hasn't been accepted in the mainline.
>
> kevent was never sent to lkml@ although it showed over 40% win over epoll for
> test web server. Sending it to lkml@ is just jumping into ... not into
> technical world, so I posted it first here, but without much attention
> though.
Frankly I found kevents to be a very strong idea.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox