Re: [CFT] dmfe.c network driver update for 2.4
[Jeff Garzik] > Pretty much all ISA and PCI drivers need to be portable and SMP > safe... if not so, it's a bug. That said, there is certainly more > motivation to make a popular PCI driver is SMP safe than an older ISA > driver. Usually, but you never know... "o SMP optimised 3c501" -- 2.1.132ac2 changelog (: Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
[Jeff Garzik] Pretty much all ISA and PCI drivers need to be portable and SMP safe... if not so, it's a bug. That said, there is certainly more motivation to make a popular PCI driver is SMP safe than an older ISA driver. Usually, but you never know... "o SMP optimised 3c501" -- 2.1.132ac2 changelog (: Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
Tobias Ringstrom wrote: > > On Fri, 17 Nov 2000, Frank Davis wrote: > > > > I would rather fix those non-SMP compliant drivers to be SMP compliant, > > then keeping them 'broken'. Adding the print statements would only be a > > temporary solution. > > Of course. This list of priorites is very natural, I think: > > 1. Working SMP driver > 2. Broken SMP driver with a warning. > 3. Broken SMP driver without a warning. (Even if "everyone" knows it >is broken) > > It takes less than a minute to add such a warning, but it can take days > or weeks to find someone to really fix the driver. That was my point. Marking them with a #warning is fine with me. -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
On Fri, 17 Nov 2000, Frank Davis wrote: > > I would rather fix those non-SMP compliant drivers to be SMP compliant, > then keeping them 'broken'. Adding the print statements would only be a > temporary solution. Of course. This list of priorites is very natural, I think: 1. Working SMP driver 2. Broken SMP driver with a warning. 3. Broken SMP driver without a warning. (Even if "everyone" knows it is broken) It takes less than a minute to add such a warning, but it can take days or weeks to find someone to really fix the driver. That was my point. /Tobias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
On Fri, 17 Nov 2000, Frank Davis wrote: I would rather fix those non-SMP compliant drivers to be SMP compliant, then keeping them 'broken'. Adding the print statements would only be a temporary solution. Of course. This list of priorites is very natural, I think: 1. Working SMP driver 2. Broken SMP driver with a warning. 3. Broken SMP driver without a warning. (Even if "everyone" knows it is broken) It takes less than a minute to add such a warning, but it can take days or weeks to find someone to really fix the driver. That was my point. /Tobias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
Tobias Ringstrom wrote: On Fri, 17 Nov 2000, Frank Davis wrote: I would rather fix those non-SMP compliant drivers to be SMP compliant, then keeping them 'broken'. Adding the print statements would only be a temporary solution. Of course. This list of priorites is very natural, I think: 1. Working SMP driver 2. Broken SMP driver with a warning. 3. Broken SMP driver without a warning. (Even if "everyone" knows it is broken) It takes less than a minute to add such a warning, but it can take days or weeks to find someone to really fix the driver. That was my point. Marking them with a #warning is fine with me. -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
> --On Friday, November 17, 2000 10:20 AM +0100 Tobias Ringstrom > > How about adding an ifdef CONFIG_SMP then print ugly warning to all known > > SMP unsafe drivers? A message could be printed booth at compile and load > > time. Frank Davis wrote: > I would rather fix those non-SMP compliant drivers to be SMP compliant, > then keeping them 'broken'. Adding the print statements would only be a > temporary solution. Agreed. If people have SMP safety patches for net drivers, let me know... Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
I would rather fix those non-SMP compliant drivers to be SMP compliant, then keeping them 'broken'. Adding the print statements would only be a temporary solution. Regards, Frank --On Friday, November 17, 2000 10:20 AM +0100 Tobias Ringstrom > How about adding an ifdef CONFIG_SMP then print ugly warning to all known > SMP unsafe drivers? A message could be printed booth at compile and load > time. > > /Tobias > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
On Thu, 16 Nov 2000, Jeff Garzik wrote: > The kernel driver APIs are designed so that SMP and UP cases are equally > high-performance, and portable beyond the x86 platform. > > Pretty much all ISA and PCI drivers need to be portable and SMP safe... > if not so, it's a bug. That said, there is certainly more motivation to > make a popular PCI driver is SMP safe than an older ISA driver. And > portability is [IMHO] less of a priority than SMP safety, though it > depends on the hardware being supported. How about adding an ifdef CONFIG_SMP then print ugly warning to all known SMP unsafe drivers? A message could be printed booth at compile and load time. /Tobias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
On Thu, 16 Nov 2000, Jeff Garzik wrote: The kernel driver APIs are designed so that SMP and UP cases are equally high-performance, and portable beyond the x86 platform. Pretty much all ISA and PCI drivers need to be portable and SMP safe... if not so, it's a bug. That said, there is certainly more motivation to make a popular PCI driver is SMP safe than an older ISA driver. And portability is [IMHO] less of a priority than SMP safety, though it depends on the hardware being supported. How about adding an ifdef CONFIG_SMP then print ugly warning to all known SMP unsafe drivers? A message could be printed booth at compile and load time. /Tobias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
I would rather fix those non-SMP compliant drivers to be SMP compliant, then keeping them 'broken'. Adding the print statements would only be a temporary solution. Regards, Frank --On Friday, November 17, 2000 10:20 AM +0100 Tobias Ringstrom How about adding an ifdef CONFIG_SMP then print ugly warning to all known SMP unsafe drivers? A message could be printed booth at compile and load time. /Tobias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
--On Friday, November 17, 2000 10:20 AM +0100 Tobias Ringstrom How about adding an ifdef CONFIG_SMP then print ugly warning to all known SMP unsafe drivers? A message could be printed booth at compile and load time. Frank Davis wrote: I would rather fix those non-SMP compliant drivers to be SMP compliant, then keeping them 'broken'. Adding the print statements would only be a temporary solution. Agreed. If people have SMP safety patches for net drivers, let me know... Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
Tobias Ringstrom wrote: > On Wed, 15 Nov 2000, Jeff Garzik wrote: > > Tobias Ringstrom wrote: > > > I have updated the dmfe.c network driver for 2.4.0-test by adding proper > > > locking (I hope), and also made transmission much efficient. > > Would you mind creating a separate patch that -just- correcting the SMP > > safety? That makes it much easier to review and apply, and then we can > > consider the other changes... > Such a patch will appear shortly. I and Frank Davis are currently merging > our patches for dmfe.c. Thanks a bunch. > [Actually, I just added reasonable locks while my main goal was to improve > performance. I did not realize that there was such a strong need for SMP > safety (since it has been broken in that regard for a long time, without > anyone fixing it).] The kernel driver APIs are designed so that SMP and UP cases are equally high-performance, and portable beyond the x86 platform. Pretty much all ISA and PCI drivers need to be portable and SMP safe... if not so, it's a bug. That said, there is certainly more motivation to make a popular PCI driver is SMP safe than an older ISA driver. And portability is [IMHO] less of a priority than SMP safety, though it depends on the hardware being supported. Regards, Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
On Wed, 15 Nov 2000, Jeff Garzik wrote: > Tobias Ringstrom wrote: > > > > I have updated the dmfe.c network driver for 2.4.0-test by adding proper > > locking (I hope), and also made transmission much efficient. > > > > I would appreciate any feedback from people using this driver, to confirm > > that I did not break it. > > > > It would also be great if someone could take a look at the lock handling, > > to confirm that is is correct and sufficient. > > Would you mind creating a separate patch that -just- correcting the SMP > safety? That makes it much easier to review and apply, and then we can > consider the other changes... Such a patch will appear shortly. I and Frank Davis are currently merging our patches for dmfe.c. [Actually, I just added reasonable locks while my main goal was to improve performance. I did not realize that there was such a strong need for SMP safety (since it has been broken in that regard for a long time, without anyone fixing it).] /Tobias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
Tobias Ringstrom wrote: On Wed, 15 Nov 2000, Jeff Garzik wrote: Tobias Ringstrom wrote: I have updated the dmfe.c network driver for 2.4.0-test by adding proper locking (I hope), and also made transmission much efficient. Would you mind creating a separate patch that -just- correcting the SMP safety? That makes it much easier to review and apply, and then we can consider the other changes... Such a patch will appear shortly. I and Frank Davis are currently merging our patches for dmfe.c. Thanks a bunch. [Actually, I just added reasonable locks while my main goal was to improve performance. I did not realize that there was such a strong need for SMP safety (since it has been broken in that regard for a long time, without anyone fixing it).] The kernel driver APIs are designed so that SMP and UP cases are equally high-performance, and portable beyond the x86 platform. Pretty much all ISA and PCI drivers need to be portable and SMP safe... if not so, it's a bug. That said, there is certainly more motivation to make a popular PCI driver is SMP safe than an older ISA driver. And portability is [IMHO] less of a priority than SMP safety, though it depends on the hardware being supported. Regards, Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
Tobias Ringstrom wrote: > > I have updated the dmfe.c network driver for 2.4.0-test by adding proper > locking (I hope), and also made transmission much efficient. > > I would appreciate any feedback from people using this driver, to confirm > that I did not break it. > > It would also be great if someone could take a look at the lock handling, > to confirm that is is correct and sufficient. Would you mind creating a separate patch that -just- correcting the SMP safety? That makes it much easier to review and apply, and then we can consider the other changes... Thanks, Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
Hello,
I'll double check the locking later today, but not sure about the
transmission changes.
Regards,
Frank
([EMAIL PROTECTED])
--On Wednesday, November 15, 2000 9:34 PM +0100 Tobias Ringstrom
<[EMAIL PROTECTED]> wrote:
> I have updated the dmfe.c network driver for 2.4.0-test by adding proper
> locking (I hope), and also made transmission much efficient.
>
> I would appreciate any feedback from people using this driver, to confirm
> that I did not break it.
>
> It would also be great if someone could take a look at the lock handling,
> to confirm that is is correct and sufficient.
>
> /Tobias
>
>
> --- dmfe.c.orig Wed Nov 15 19:53:48 2000
> +++ dmfe.cWed Nov 15 21:35:24 2000
> @@ -57,6 +57,11 @@
> Resource usage cleanups.
> Report driver version to user.
>
> + Tobias Ringström <[EMAIL PROTECTED]> :
> + Added proper locking.
> + Rewrote the transmit code to actually use the ring buffer,
> + and to generate a lot fewer interrupts.
> +
> TODO
>
> Implement pci_driver::suspend() and pci_driver::resume()
> @@ -108,6 +113,7 @@
> #define TX_MAX_SEND_CNT 0x1 /* Maximum tx packet per time */
> #define TX_DESC_CNT 0x10 /* Allocated Tx descriptors */
> #define RX_DESC_CNT 0x10 /* Allocated Rx descriptors */
> +#define TX_IRQ_THR 12
> #define DESC_ALL_CNTTX_DESC_CNT+RX_DESC_CNT
> #define TX_BUF_ALLOC0x600
> #define RX_ALLOC_SIZE 0x620
> @@ -188,6 +194,8 @@
>u32 cr7_data;
>u32 cr15_data;
>
> + spinlock_t lock;
> +
>/* descriptor pointer */
>unsigned char *buf_pool_ptr; /* Tx buffer pool memory */
>unsigned char *buf_pool_start; /* Tx buffer pool align dword */
> @@ -198,8 +206,7 @@
>struct rx_desc *first_rx_desc;
>struct rx_desc *rx_insert_ptr;
>struct rx_desc *rx_ready_ptr; /* packet come pointer */
> - u32 tx_packet_cnt; /* transmitted packet count */
> - u32 tx_queue_cnt; /* wait to send packet count */
> + u32 tx_live_cnt;/* number of used/live tx slots */
>u32 rx_avail_cnt; /* available rx descriptor count */
>u32 interval_rx_cnt; /* rx packet count a callback time */
>
> @@ -490,8 +497,6 @@
>
>/* system variable init */
>db->cr6_data = CR6_DEFAULT | dmfe_cr6_user_set;
> - db->tx_packet_cnt = 0;
> - db->tx_queue_cnt = 0;
>db->rx_avail_cnt = 0;
>db->link_failed = 0;
>db->wait_reset = 0;
> @@ -595,46 +600,42 @@
> {
>struct dmfe_board_info *db = dev->priv;
>struct tx_desc *txptr;
> + static unsigned pkt_num = TX_IRQ_THR;
>
>DMFE_DBUG(0, "dmfe_start_xmit", 0);
> -
> - netif_stop_queue(dev);
> -
> - /* Too large packet check */
> - if (skb->len > MAX_PACKET_SIZE) {
> - printk(KERN_ERR "%s: oversized frame (%d bytes) for transmit.\n",
> dev->name, (u16) skb->len); - dev_kfree_skb(skb);
> - return 0;
> - }
> - /* No Tx resource check, it never happen nromally */
> - if (db->tx_packet_cnt >= TX_FREE_DESC_CNT) {
> - return 1;
> - }
> +
> + spin_lock_irq(>lock);
>
>/* transmit this packet */
>txptr = db->tx_insert_ptr;
>memcpy((char *) txptr->tx_buf_ptr, (char *) skb->data, skb->len);
> - txptr->tdes1 = 0xe100 | skb->len;
> + if (--pkt_num == 0)
> + {
> + txptr->tdes1 = 0xe100 | skb->len;
> + pkt_num = TX_IRQ_THR;
> + }
> + else
> + txptr->tdes1 = 0x6100 | skb->len;
> +
> + /* Transmit Packet Process */
> + txptr->tdes0 = 0x8000; /* set owner bit to DM910X */
> + outl(0x1, dev->base_addr + DCR1); /* Issue Tx polling comand */
> + dev->trans_start = jiffies; /* saved the time stamp */
>
>/* Point to next transmit free descriptor */
> - db->tx_insert_ptr = (struct tx_desc *) txptr->next_tx_desc;
> + txptr = (struct tx_desc *)txptr->next_tx_desc;
>
> - /* Transmit Packet Process */
> - if (db->tx_packet_cnt < TX_MAX_SEND_CNT) {
> - txptr->tdes0 = 0x8000; /* set owner bit to DM910X */
> - db->tx_packet_cnt++;/* Ready to send count */
> - outl(0x1, dev->base_addr + DCR1); /* Issue Tx polling comand */
> - } else {
> - db->tx_queue_cnt++; /* queue the tx packet */
> - outl(0x1, dev->base_addr + DCR1); /* Issue Tx polling comand */
> - }
> + if (txptr->tdes0 & 0x8000)
> + netif_stop_queue(dev);
>
> - /* Tx resource check */
> - if (db->tx_packet_cnt < TX_FREE_DESC_CNT)
> - netif_wake_queue(dev);
> + db->tx_insert_ptr = txptr;
> + db->tx_live_cnt++;
> +
> + spin_unlock_irq(>lock);
>
>/* free this SKB */
>dev_kfree_skb(skb);
> +
>return 0;
> }
>
> @@ -713,12 +714,14 @@
>outl(0, ioaddr + DCR7);/* disable all interrupt */
>
Re: [CFT] dmfe.c network driver update for 2.4
Hello,
I'll double check the locking later today, but not sure about the
transmission changes.
Regards,
Frank
([EMAIL PROTECTED])
--On Wednesday, November 15, 2000 9:34 PM +0100 Tobias Ringstrom
[EMAIL PROTECTED] wrote:
I have updated the dmfe.c network driver for 2.4.0-test by adding proper
locking (I hope), and also made transmission much efficient.
I would appreciate any feedback from people using this driver, to confirm
that I did not break it.
It would also be great if someone could take a look at the lock handling,
to confirm that is is correct and sufficient.
/Tobias
--- dmfe.c.orig Wed Nov 15 19:53:48 2000
+++ dmfe.cWed Nov 15 21:35:24 2000
@@ -57,6 +57,11 @@
Resource usage cleanups.
Report driver version to user.
+ Tobias Ringström [EMAIL PROTECTED] :
+ Added proper locking.
+ Rewrote the transmit code to actually use the ring buffer,
+ and to generate a lot fewer interrupts.
+
TODO
Implement pci_driver::suspend() and pci_driver::resume()
@@ -108,6 +113,7 @@
#define TX_MAX_SEND_CNT 0x1 /* Maximum tx packet per time */
#define TX_DESC_CNT 0x10 /* Allocated Tx descriptors */
#define RX_DESC_CNT 0x10 /* Allocated Rx descriptors */
+#define TX_IRQ_THR 12
#define DESC_ALL_CNTTX_DESC_CNT+RX_DESC_CNT
#define TX_BUF_ALLOC0x600
#define RX_ALLOC_SIZE 0x620
@@ -188,6 +194,8 @@
u32 cr7_data;
u32 cr15_data;
+ spinlock_t lock;
+
/* descriptor pointer */
unsigned char *buf_pool_ptr; /* Tx buffer pool memory */
unsigned char *buf_pool_start; /* Tx buffer pool align dword */
@@ -198,8 +206,7 @@
struct rx_desc *first_rx_desc;
struct rx_desc *rx_insert_ptr;
struct rx_desc *rx_ready_ptr; /* packet come pointer */
- u32 tx_packet_cnt; /* transmitted packet count */
- u32 tx_queue_cnt; /* wait to send packet count */
+ u32 tx_live_cnt;/* number of used/live tx slots */
u32 rx_avail_cnt; /* available rx descriptor count */
u32 interval_rx_cnt; /* rx packet count a callback time */
@@ -490,8 +497,6 @@
/* system variable init */
db-cr6_data = CR6_DEFAULT | dmfe_cr6_user_set;
- db-tx_packet_cnt = 0;
- db-tx_queue_cnt = 0;
db-rx_avail_cnt = 0;
db-link_failed = 0;
db-wait_reset = 0;
@@ -595,46 +600,42 @@
{
struct dmfe_board_info *db = dev-priv;
struct tx_desc *txptr;
+ static unsigned pkt_num = TX_IRQ_THR;
DMFE_DBUG(0, "dmfe_start_xmit", 0);
-
- netif_stop_queue(dev);
-
- /* Too large packet check */
- if (skb-len MAX_PACKET_SIZE) {
- printk(KERN_ERR "%s: oversized frame (%d bytes) for transmit.\n",
dev-name, (u16) skb-len); - dev_kfree_skb(skb);
- return 0;
- }
- /* No Tx resource check, it never happen nromally */
- if (db-tx_packet_cnt = TX_FREE_DESC_CNT) {
- return 1;
- }
+
+ spin_lock_irq(db-lock);
/* transmit this packet */
txptr = db-tx_insert_ptr;
memcpy((char *) txptr-tx_buf_ptr, (char *) skb-data, skb-len);
- txptr-tdes1 = 0xe100 | skb-len;
+ if (--pkt_num == 0)
+ {
+ txptr-tdes1 = 0xe100 | skb-len;
+ pkt_num = TX_IRQ_THR;
+ }
+ else
+ txptr-tdes1 = 0x6100 | skb-len;
+
+ /* Transmit Packet Process */
+ txptr-tdes0 = 0x8000; /* set owner bit to DM910X */
+ outl(0x1, dev-base_addr + DCR1); /* Issue Tx polling comand */
+ dev-trans_start = jiffies; /* saved the time stamp */
/* Point to next transmit free descriptor */
- db-tx_insert_ptr = (struct tx_desc *) txptr-next_tx_desc;
+ txptr = (struct tx_desc *)txptr-next_tx_desc;
- /* Transmit Packet Process */
- if (db-tx_packet_cnt TX_MAX_SEND_CNT) {
- txptr-tdes0 = 0x8000; /* set owner bit to DM910X */
- db-tx_packet_cnt++;/* Ready to send count */
- outl(0x1, dev-base_addr + DCR1); /* Issue Tx polling comand */
- } else {
- db-tx_queue_cnt++; /* queue the tx packet */
- outl(0x1, dev-base_addr + DCR1); /* Issue Tx polling comand */
- }
+ if (txptr-tdes0 0x8000)
+ netif_stop_queue(dev);
- /* Tx resource check */
- if (db-tx_packet_cnt TX_FREE_DESC_CNT)
- netif_wake_queue(dev);
+ db-tx_insert_ptr = txptr;
+ db-tx_live_cnt++;
+
+ spin_unlock_irq(tp-lock);
/* free this SKB */
dev_kfree_skb(skb);
+
return 0;
}
@@ -713,12 +714,14 @@
outl(0, ioaddr + DCR7);/* disable all interrupt */
return;
}
+
+ spin_lock(db-lock);
+
/* Free the transmitted descriptor */
txptr = db-tx_remove_ptr;
- while (db-tx_packet_cnt) {
Re: [CFT] dmfe.c network driver update for 2.4
Tobias Ringstrom wrote: I have updated the dmfe.c network driver for 2.4.0-test by adding proper locking (I hope), and also made transmission much efficient. I would appreciate any feedback from people using this driver, to confirm that I did not break it. It would also be great if someone could take a look at the lock handling, to confirm that is is correct and sufficient. Would you mind creating a separate patch that -just- correcting the SMP safety? That makes it much easier to review and apply, and then we can consider the other changes... Thanks, Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
