Re: [PATCH 3/3] ipg: plug leaks in the error path of ipg_nic_open

2006-05-01 Thread Pekka J Enberg
On Tue, 2 May 2006, Francois Romieu wrote:
> Added ipg_{rx/tx}_clear() to factor out some code.
> 
> Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>

Applied. Thanks!

Pekka
-
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


Re: [PATCH 2/3] ipg: leaks in ipg_probe

2006-05-01 Thread Pekka J Enberg
On Tue, 2 May 2006, Francois Romieu wrote:
> The error paths are badly broken.
> 
> Bonus:
> - remove duplicate initialization of sp;
> - remove useless NULL initialization of dev;
> - USE_IO_OPS is not used (and the driver does not seem to care about
>   posted writes, rejoice).
> 
> Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>

Applied. Thanks! One comment below.

On Tue, 2 May 2006, Francois Romieu wrote:
> - err = pci_request_regions(pdev, DRV_NAME);
> - if (err)
> - goto out;
> -
> - pio_start = pci_resource_start(pdev, 0) & 0xff80;
> - pio_len = pci_resource_len(pdev, 0);
> - mmio_start = pci_resource_start(pdev, 1) & 0xff80;
> + rc = pci_request_regions(pdev, DRV_NAME);
> + if (rc)
> + goto err_free_dev_1;

Is this tested with hardware? Alignment of the start address looks bogus 
for sure, but any idea why they had it in the first place?

Pekka
-
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


Re: [PATCH 1/3] ipg: removal of unreachable code

2006-05-01 Thread Pekka J Enberg
On Tue, 2 May 2006, Francois Romieu wrote:
> map/unmap is done in ipg_{probe/remove}

Applied. Thanks!

Pekka
-
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


[Patch 4/8] Utilities for genetlink usage

2006-05-01 Thread Balbir Singh

genetlink-utils.patch

Two utilities for simplifying usage of NETLINK_GENERIC
interface.

Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
Signed-off-by: Shailabh Nagar <[EMAIL PROTECTED]>
---

 include/net/genetlink.h |   20 
 1 files changed, 20 insertions(+)

diff -puN include/net/genetlink.h~genetlink-utils include/net/genetlink.h
--- linux-2.6.17-rc3/include/net/genetlink.h~genetlink-utils2006-05-02 
07:35:15.0 +0530
+++ linux-2.6.17-rc3-balbir/include/net/genetlink.h 2006-05-02 
07:35:52.0 +0530
@@ -150,4 +150,24 @@ static inline int genlmsg_unicast(struct
return nlmsg_unicast(genl_sock, skb, pid);
 }
 
+/**
+ * gennlmsg_data - head of message payload
+ * @gnlh: genetlink messsage header
+ */
+static inline void *genlmsg_data(const struct genlmsghdr *gnlh)
+{
+   return ((unsigned char *) gnlh + GENL_HDRLEN);
+}
+
+/**
+ * genlmsg_len - length of message payload
+ * @gnlh: genetlink message header
+ */
+static inline int genlmsg_len(const struct genlmsghdr *gnlh)
+{
+   struct nlmsghdr *nlh = (struct nlmsghdr *)((unsigned char *)gnlh -
+   NLMSG_HDRLEN);
+   return (nlh->nlmsg_len - GENL_HDRLEN - NLMSG_HDRLEN);
+}
+
 #endif /* __NET_GENERIC_NETLINK_H */
_
-
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


Re: IP1000 gigabit nic driver

2006-05-01 Thread David Vrabel

Lennert Buytenhek wrote:

On Mon, May 01, 2006 at 10:38:47PM +0200, Francois Romieu wrote:



-/* Minimum number of miliseconds used to toggle MDC clock during
+/* Minimum number of nanoseconds used to toggle MDC clock during
 * MII/GMII register access.
 */
-#define IPG_PC_PHYCTRLWAIT   0x01
+#defineIPG_PC_PHYCTRLWAIT_NS   200


I would have expected a cycle of 400 ns (p.72/77 of the datasheet)
for a 2.5 MHz clock. Why is it cut by a two factor ?



200 ns high + 200 ns low = 400 ns clock period?


Yes.

David
-
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


Net driver maintenance through May 12

2006-05-01 Thread Jeff Garzik


Stephen Hemminger has agreed to help out with net driver maintenance 
through May 12, when I return from honeymoon.  Thanks, Stephen!


I've got a few patches for 2.6.17-rc that I'll push in the next 24 
hours, then I'm unplugged until May 12.  Already unsubscribed from LKML, 
even .


netdev-2.6.git#upstream is what I have queued for 2.6.18 so far.

Jeff



-
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


[PATCH] vlan: sysfs support

2006-05-01 Thread Stephen Hemminger
Here is a more complete version of vlan sysfs support. Sysfs support is
good because it means scripts don't have to depend on parsing interface
names that may change.

Assuming there is a vlan 5 added to eth0 then the following links are added:

/sys/class/net/eth0/vlan_group/5 -> ../../../../class/net/eth0.5
/sys/class/net/eth0.5/vlan_device -> ../../../class/net/eth0
and one file /sys/class/net/eth0/vlan_id  that contains "5\n"

It handles the reference counts on the vlan_groups properly, but still
has a race between hotplug and creating these sysfs objects because
of the chicken/egg problem with register_netdevice interface.


Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>

--- vlan.orig/net/8021q/Makefile2006-05-01 12:50:58.0 -0700
+++ vlan/net/8021q/Makefile 2006-05-01 15:27:55.0 -0700
@@ -4,9 +4,7 @@
 
 obj-$(CONFIG_VLAN_8021Q) += 8021q.o
 
-8021q-objs := vlan.o vlan_dev.o
-
-ifeq ($(CONFIG_PROC_FS),y)
-8021q-objs += vlanproc.o
-endif
+8021q-y := vlan.o vlan_dev.o
 
+8021q-$(CONFIG_PROC_FS) += vlanproc.o
+8021q-$(CONFIG_SYSFS) += vlan_sysfs.o
--- vlan.orig/net/8021q/vlan.c  2006-05-01 12:50:58.0 -0700
+++ vlan/net/8021q/vlan.c   2006-05-01 16:17:12.0 -0700
@@ -193,9 +193,21 @@
return NULL;
 }
 
+/* Callback after last packet and any open sysfs handles are gone. */
+static void vlan_grp_release(struct kobject *kobj)
+{
+   kfree(container_of(kobj, struct vlan_group, kobj));
+}
+
+static struct kobj_type vlan_grp_ktype = {
+   .release = vlan_grp_release,
+};
+
+/* Callback after last packet in flight has passed. */
 static void vlan_rcu_free(struct rcu_head *rcu)
 {
-   kfree(container_of(rcu, struct vlan_group, rcu));
+   struct vlan_group *grp = container_of(rcu, struct vlan_group, rcu);
+   kobject_put(&grp->kobj);
 }
 
 
@@ -232,6 +244,8 @@
/* Remove proc entry */
vlan_proc_rem_dev(dev);
 
+   vlan_sysfs_remove(dev, real_dev,  grp, vlan_id);
+
/* Take it out of our own structures, but be sure to
 * interlock with HW accelerating devices or SW vlan
 * input packet processing.
@@ -265,6 +279,8 @@
hlist_del_rcu(&grp->hlist);
 
/* Free the group, after all cpu's are done. */
+   kobject_uevent(&grp->kobj, KOBJ_REMOVE);
+   kobject_del(&grp->kobj);
call_rcu(&grp->rcu, vlan_rcu_free);
 
grp = NULL;
@@ -531,13 +547,17 @@
 * so it cannot "appear" on us.
 */
if (!grp) { /* need to add a new group */
-   grp = kmalloc(sizeof(struct vlan_group), GFP_KERNEL);
+   grp = kzalloc(sizeof(struct vlan_group), GFP_KERNEL);
if (!grp)
goto out_free_unregister;

/* printk(KERN_ALERT "VLAN REGISTER:  Allocated new group.\n"); 
*/
-   memset(grp, 0, sizeof(struct vlan_group));
grp->real_dev_ifindex = real_dev->ifindex;
+   kobject_init(&grp->kobj);
+   kobject_set_name(&grp->kobj, "vlan_group");
+   grp->kobj.parent = &real_dev->class_dev.kobj;
+   grp->kobj.ktype = &vlan_grp_ktype;
+   kobject_register(&grp->kobj);
 
hlist_add_head_rcu(&grp->hlist, 
   
&vlan_group_hash[vlan_grp_hashfn(real_dev->ifindex)]);
@@ -557,6 +577,9 @@
 
rtnl_unlock();
 
+   if (vlan_sysfs_add(new_dev, real_dev, grp, VLAN_ID))
+   printk(KERN_WARNING "VLAN: failed to create sysfs entry for 
%s\n",
+  new_dev->name);
 
 #ifdef VLAN_DEBUG
printk(VLAN_DBG "Allocated new device successfully, returning.\n");
--- vlan.orig/net/8021q/vlan.h  2006-05-01 12:50:58.0 -0700
+++ vlan/net/8021q/vlan.h   2006-05-01 16:08:18.0 -0700
@@ -69,4 +69,15 @@
 int vlan_dev_get_vid(const char* dev_name, unsigned short* result);
 void vlan_dev_set_multicast_list(struct net_device *vlan_dev);
 
+#ifdef CONFIG_SYSFS
+int vlan_sysfs_add(struct net_device *dev, struct net_device *real_dev,
+  struct vlan_group *grp, unsigned short tag);
+void vlan_sysfs_remove(struct net_device *dev, struct net_device *real_dev,
+  struct vlan_group *grp, unsigned short tag);
+#else
+#define vlan_sysfs_add(dev, realdev, grp, tag) (0)
+#define vlan_sysfs_remove(dev, realdev, grp, tag)  do { } while (0)
+#endif
+
+
 #endif /* !(__BEN_VLAN_802_1Q_INC__) */
--- /dev/null   1970-01-01 00:00:00.0 +
+++ vlan/net/8021q/vlan_sysfs.c 2006-05-01 16:08:18.0 -0700
@@ -0,0 +1,59 @@
+/*
+ * VLAN sysfs interface.
+ *
+ * Basic access to vlan information via sysfs.
+ * Authors:
+ * Stephen Hemminger   

[PATCH 3/3] ipg: plug leaks in the error path of ipg_nic_open

2006-05-01 Thread Francois Romieu
Added ipg_{rx/tx}_clear() to factor out some code.

Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>

---

 drivers/net/ipg.c |  161 +++--
 1 files changed, 93 insertions(+), 68 deletions(-)

96f29e9d57f503f1275757f4bbec76c0f7f421fc
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index da0fa22..393b617 100644
--- a/drivers/net/ipg.c
+++ b/drivers/net/ipg.c
@@ -16,6 +16,9 @@
  */
 #include 
 
+#define IPG_RX_RING_BYTES  (sizeof(struct RFD) * IPG_RFDLIST_LENGTH)
+#define IPG_TX_RING_BYTES  (sizeof(struct TFD) * IPG_TFDLIST_LENGTH)
+
 #define JUMBO_FRAME_4k_ONLY
 enum {
netdev_io_size = 128
@@ -1485,15 +1488,46 @@ static void ipg_nic_txfree(struct net_de
} while (maxtfdcount != 0);
 }
 
-static int ipg_nic_open(struct net_device *dev)
+static void ipg_rx_clear(struct ipg_nic_private *sp)
 {
-   /* The IPG NIC Ethernet interface is opened when activated
-* by ifconfig.
-*/
+   struct pci_dev *pdev = sp->pdev;
+   unsigned int i;
 
-   int error = 0;
-   void __iomem *ioaddr = ipg_ioaddr(dev);
+   for (i = 0; i < IPG_RFDLIST_LENGTH; i++) {
+   if (sp->RxBuff[i]) {
+   struct ipg_dmabuff *desc = sp->RxBuffDMAhandle + i;
+
+   IPG_DEV_KFREE_SKB(sp->RxBuff[i]);
+   sp->RxBuff[i] = NULL;
+   pci_unmap_single(pdev, desc->dmahandle, desc->len,
+PCI_DMA_FROMDEVICE);
+   }
+   }
+}
+
+static void ipg_tx_clear(struct ipg_nic_private *sp)
+{
+   struct pci_dev *pdev = sp->pdev;
+   unsigned int i;
+
+   for (i = 0; i < IPG_TFDLIST_LENGTH; i++) {
+   if (sp->TxBuff[i]) {
+   struct ipg_dmabuff *desc = sp->TxBuffDMAhandle + i;
+
+   IPG_DEV_KFREE_SKB(sp->TxBuff[i]);
+   sp->TxBuff[i] = NULL;
+   pci_unmap_single(pdev, desc->dmahandle, desc->len,
+PCI_DMA_TODEVICE);
+   }
+   }
+}
+
+static int ipg_nic_open(struct net_device *dev)
+{
struct ipg_nic_private *sp = netdev_priv(dev);
+   void __iomem *ioaddr = ipg_ioaddr(dev);
+   struct pci_dev *pdev = sp->pdev;
+   int rc;
 
IPG_DEBUG_MSG("_nic_open\n");
 
@@ -1508,59 +1542,53 @@ static int ipg_nic_open(struct net_devic
/* Register the interrupt line to be used by the IPG within
 * the Linux system.
 */
-   if ((error = request_irq(sp->pdev->irq,
-&ipg_interrupt_handler,
-SA_SHIRQ, dev->name, dev)) < 0) {
+   rc = request_irq(pdev->irq, &ipg_interrupt_handler, SA_SHIRQ,
+dev->name, dev);
+   if (rc < 0) {
printk(KERN_INFO "%s: Error when requesting interrupt.\n",
   dev->name);
-   return error;
+   goto out;
}
 
-   dev->irq = sp->pdev->irq;
+   dev->irq = pdev->irq;
 
-   sp->RFDList = pci_alloc_consistent(sp->pdev,
-  (sizeof(struct RFD) *
-   IPG_RFDLIST_LENGTH),
+   rc = -ENOMEM;
+
+   sp->RFDList = pci_alloc_consistent(pdev, IPG_RX_RING_BYTES,
   &sp->RFDListDMAhandle);
+   if (!sp->RFDList)
+   goto err_free_irq_0;
 
-   sp->TFDList = pci_alloc_consistent(sp->pdev,
-  (sizeof(struct TFD) *
-   IPG_TFDLIST_LENGTH),
+   sp->TFDList = pci_alloc_consistent(pdev, IPG_TX_RING_BYTES,
   &sp->TFDListDMAhandle);
+   if (!sp->TFDList)
+   goto err_free_rx_1;
 
-   if ((sp->RFDList == NULL) || (sp->TFDList == NULL)) {
-   printk(KERN_INFO
-  "%s: No memory available for IP1000 RFD and/or TFD 
lists.\n",
-  dev->name);
-   return -ENOMEM;
-   }
-
-   error = init_rfdlist(dev);
-   if (error < 0) {
+   rc = init_rfdlist(dev);
+   if (rc < 0) {
printk(KERN_INFO "%s: Error during configuration.\n",
   dev->name);
-   return error;
+   goto err_free_tx_2;
}
 
-   error = init_tfdlist(dev);
-   if (error < 0) {
+   rc = init_tfdlist(dev);
+   if (rc < 0) {
printk(KERN_INFO "%s: Error during configuration.\n",
   dev->name);
-   return error;
+   goto err_release_rfdlist_3;
}
 
-   /* Configure IPG I/O registers. */
-   error = ipg_io_config(dev);
-   if (error < 0) {
+   rc = ipg_io_config(dev);
+   if (rc < 0) {
printk(KERN_INFO "%s: Error during configuration.\n",
  

[PATCH 2/3] ipg: leaks in ipg_probe

2006-05-01 Thread Francois Romieu
The error paths are badly broken.

Bonus:
- remove duplicate initialization of sp;
- remove useless NULL initialization of dev;
- USE_IO_OPS is not used (and the driver does not seem to care about
  posted writes, rejoice).

Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>

---

 drivers/net/ipg.c |   93 -
 1 files changed, 42 insertions(+), 51 deletions(-)

5ea54e95a2319311aaae857ecf2adb7fbe068c92
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index 42396ca..da0fa22 100644
--- a/drivers/net/ipg.c
+++ b/drivers/net/ipg.c
@@ -2914,11 +2914,8 @@ static void ipg_remove(struct pci_dev *p
/* Un-register Ethernet device. */
unregister_netdev(dev);
 
-#ifdef USE_IO_OPS
-   ioport_unmap(ioaddr);
-#else
-   iounmap(sp->ioaddr);
-#endif
+   pci_iounmap(pdev, sp->ioaddr);
+
pci_release_regions(pdev);
 
free_netdev(dev);
@@ -2929,19 +2926,15 @@ #endif
 static int __devinit ipg_probe(struct pci_dev *pdev,
   const struct pci_device_id *id)
 {
-   int err, i;
-   struct net_device *dev = NULL;
+   unsigned int i = id->driver_data;
struct ipg_nic_private *sp;
+   struct net_device *dev;
void __iomem *ioaddr;
-   unsigned long pio_start, pio_len;
-   unsigned long mmio_start;
+   int rc;
 
-   err = pci_enable_device(pdev);
-   if (err)
-   return err;
-
-   /* Get the index for the driver description string. */
-   i = id->driver_data;
+   rc = pci_enable_device(pdev);
+   if (rc < 0)
+   goto out;
 
printk(KERN_INFO "%s found.\n", nics_supported[i].NICname);
printk(KERN_INFO "Bus %x Slot %x\n",
@@ -2949,10 +2942,14 @@ static int __devinit ipg_probe(struct pc
 
pci_set_master(pdev);
 
-   if (!pci_dma_supported(pdev, 0x)) {
-   printk(KERN_INFO "pci_dma_supported out.\n");
-   err = -ENODEV;
-   goto out;
+   rc = pci_set_dma_mask(pdev, DMA_40BIT_MASK);
+   if (rc < 0) {
+   rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK);
+   if (rc < 0) {
+   printk(KERN_ERR "%s: DMA config failed.\n",
+  pci_name(pdev));
+   goto err_disable_0;
+   }
}
 
/*
@@ -2960,9 +2957,9 @@ static int __devinit ipg_probe(struct pc
 */
dev = alloc_etherdev(sizeof(struct ipg_nic_private));
if (!dev) {
-   printk(KERN_ERR "ipg: alloc_etherdev failed\n");
-   err = -ENOMEM;
-   goto out;
+   printk(KERN_ERR "%s: alloc_etherdev failed\n", pci_name(pdev));
+   rc = -ENOMEM;
+   goto err_disable_0;
}
 
sp = netdev_priv(dev);
@@ -2981,50 +2978,44 @@ static int __devinit ipg_probe(struct pc
SET_MODULE_OWNER(dev);
SET_NETDEV_DEV(dev, &pdev->dev);
 
-   err = pci_request_regions(pdev, DRV_NAME);
-   if (err)
-   goto out;
-
-   pio_start = pci_resource_start(pdev, 0) & 0xff80;
-   pio_len = pci_resource_len(pdev, 0);
-   mmio_start = pci_resource_start(pdev, 1) & 0xff80;
+   rc = pci_request_regions(pdev, DRV_NAME);
+   if (rc)
+   goto err_free_dev_1;
 
-#ifdef USE_IO_OPS
-   ioaddr = ioport_map(pio_start, pio_len);
-   if (!ioaddr) {
-   printk(KERN_ERR "%s cannot map PIO\n", pci_name(pdev));
-   err = -EIO;
-   goto out;
-   }
-#else
-   ioaddr = ioremap(mmio_start, netdev_io_size);
+   ioaddr = pci_iomap(pdev, 1, pci_resource_len(pdev, 1));
if (!ioaddr) {
printk(KERN_ERR "%s cannot map MMIO\n", pci_name(pdev));
-   err = -EIO;
-   goto out;
+   rc = -EIO;
+   goto err_release_regions_2;
}
-#endif
-   sp = netdev_priv(dev);
+
/* Save the pointer to the PCI device information. */
sp->ioaddr = ioaddr;
sp->pdev = pdev;
 
pci_set_drvdata(pdev, dev);
 
-   err = ipg_hw_init(dev);
-   if (err)
-   goto out;
+   rc = ipg_hw_init(dev);
+   if (rc < 0)
+   goto err_unmap_3;
 
-   err = register_netdev(dev);
-   if (err)
-   goto out;
+   rc = register_netdev(dev);
+   if (rc < 0)
+   goto err_unmap_3;
 
printk(KERN_INFO "Ethernet device registered as: %s\n", dev->name);
-   return 0;
+out:
+   return rc;
 
-  out:
+err_unmap_3:
+   pci_iounmap(pdev, ioaddr);
+err_release_regions_2:
+   pci_release_regions(pdev);
+err_free_dev_1:
+   free_netdev(dev);
+err_disable_0:
pci_disable_device(pdev);
-   return err;
+   goto out;
 }
 
 static void ipg_set_phy_default_param(unsigned char rev,
-- 
1.3.1

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of

[PATCH 1/3] ipg: removal of unreachable code

2006-05-01 Thread Francois Romieu
map/unmap is done in ipg_{probe/remove}

Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>

---

 drivers/net/ipg.c |   18 --
 1 files changed, 0 insertions(+), 18 deletions(-)

2b14ddef0c29f43c07ffd33c3d1d9e652db3a571
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index 5d4d023..42396ca 100644
--- a/drivers/net/ipg.c
+++ b/drivers/net/ipg.c
@@ -1790,24 +1790,6 @@ static int ipg_nic_stop(struct net_devic
/* Release interrupt line. */
free_irq(dev->irq, dev);
return 0;
-
-#ifdef USE_IO_OPS
-
-   /* Release I/O range reserved for IPG registers. */
-   release_region(dev->base_addr, IPG_IO_REG_RANGE);
-
-#else  /* Not using I/O space. */
-
-   /* Unmap memory used for IPG registers. */
-
-   /* The following line produces strange results unless
-* unregister_netdev precedes it.
-*/
-   iounmap(sp->ioaddr);
-
-#endif
-
-   return 0;
 }
 
 static int ipg_nic_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
-- 
1.3.1

-
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


Re: [PATCH] irda-usb: use NULL instead of 0

2006-05-01 Thread Randy.Dunlap

> I could be mistaken, but wasn't the usb_control_msg timeout type changed in 
> kernel 2.6.12?
> The timeout value is no longer in jiffies but in msecs.

ugh, correct.  Here's a new patch.
Thanks.

---
From: Randy Dunlap <[EMAIL PROTECTED]>

Use NULL instead of 0 for a null pointer value (sparse warning):
drivers/net/irda/irda-usb.c:1781:30: warning: Using plain integer as NULL 
pointer

Correct timeout argument to use milliseconds instead of jiffies.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 drivers/net/irda/irda-usb.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

--- linux-2617-rc3.orig/drivers/net/irda/irda-usb.c
+++ linux-2617-rc3/drivers/net/irda/irda-usb.c
@@ -1778,7 +1778,7 @@ static int irda_usb_probe(struct usb_int
 
if (self->needspatch) {
ret = usb_control_msg (self->usbdev, usb_sndctrlpipe 
(self->usbdev, 0),
-  0x02, 0x40, 0, 0, 0, 0, 
msecs_to_jiffies(500));
+  0x02, 0x40, 0, 0, NULL, 0, 500);
if (ret < 0) {
IRDA_DEBUG (0, "usb_control_msg failed %d\n", ret);
goto err_out_3;
-
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


Re: [RFC] vlan: add sysfs support

2006-05-01 Thread Stephen Hemminger
On Mon, 01 May 2006 15:07:14 -0700
Ben Greear <[EMAIL PROTECTED]> wrote:

> Stephen Hemminger wrote:
> > Add basic sysfs support for vlan device. It creates an entry in the
> > vlan pseudo-device to display tag.  
> > /sys/class/net/eth0.5/vlan_id
> 
> Looks fine to me, though I don't know enough about sysfs to notice
> any bugs with it...
> 
> I do have a question:  Will this work for > 256 vlans?
> 
> /proc had a limit of around 256 directories last I
> checked, so just curious.
> 
> Thanks,
> Ben
> 

There should be no limits caused by sysfs...
-
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


Re: [PATCH] irda-usb: use NULL instead of 0

2006-05-01 Thread Ivo van Doorn
On Tuesday 2 May 2006 00:08, Randy.Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
> 
> Use NULL instead of 0 for a null pointer value (sparse warning):
> drivers/net/irda/irda-usb.c:1781:30: warning: Using plain integer as NULL 
> pointer
> 
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
> ---
>  drivers/net/irda/irda-usb.c |2 +-
>  1 files changed, 1 insertion(+), 1 deletion(-)
> 
> --- linux-2617-rc3.orig/drivers/net/irda/irda-usb.c
> +++ linux-2617-rc3/drivers/net/irda/irda-usb.c
> @@ -1778,7 +1778,7 @@ static int irda_usb_probe(struct usb_int
>  
>   if (self->needspatch) {
>   ret = usb_control_msg (self->usbdev, usb_sndctrlpipe 
> (self->usbdev, 0),
> -0x02, 0x40, 0, 0, 0, 0, 
> msecs_to_jiffies(500));
> +0x02, 0x40, 0, 0, NULL, 0, 
> msecs_to_jiffies(500));

I could be mistaken, but wasn't the usb_control_msg timeout type changed in 
kernel 2.6.12?
The timeout value is no longer in jiffies but in msecs.

>   if (ret < 0) {
>   IRDA_DEBUG (0, "usb_control_msg failed %d\n", ret);
>   goto err_out_3;

IvD


pgpPNmsUAxv8r.pgp
Description: PGP signature


Re: e1000 TX hang problems

2006-05-01 Thread Jesse Brandeburg

On 4/28/06, Gerhard de Jeger <[EMAIL PROTECTED]> wrote:

I'm also experiencing TX hang problems with the e1000 driver.

I was using the 6.0.60-k2 version previously which shipped with the
2.6.14.2 kernel.

I had no problems with this driver, but after my issues with the 7.0.33
driver I tried to go back to the 6.0.60-k driver. Now when I load the
module, there is an error saying that the EEPROM is corrupt - so I
cannot use the old driver which used to work.


so what kernel are you using now?  what kind of hardware do you have?
we need a decent bug report in order to make some progress.


Why is it that I now get the EEPROM error with the older driver?


did you change the kernel?


Any ideas on how to fix the problem (with either the old driver or the
new one)?


it sounds like you may have had a hardware failure?  Or maybe a kernel
problem.  Did you go back to 2.6.14.2 and try it?

It is highly unusual for the driver to be able to change the eeprom
through regular usage.

Please reply with more specifics
-
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


Re: [RFC] vlan: add sysfs support

2006-05-01 Thread Ben Greear

Stephen Hemminger wrote:

Add basic sysfs support for vlan device. It creates an entry in the
vlan pseudo-device to display tag.  
	/sys/class/net/eth0.5/vlan_id


Looks fine to me, though I don't know enough about sysfs to notice
any bugs with it...

I do have a question:  Will this work for > 256 vlans?

/proc had a limit of around 256 directories last I
checked, so just curious.

Thanks,
Ben

--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc  http://www.candelatech.com

-
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


[PATCH] irda-usb: use NULL instead of 0

2006-05-01 Thread Randy.Dunlap
From: Randy Dunlap <[EMAIL PROTECTED]>

Use NULL instead of 0 for a null pointer value (sparse warning):
drivers/net/irda/irda-usb.c:1781:30: warning: Using plain integer as NULL 
pointer

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 drivers/net/irda/irda-usb.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

--- linux-2617-rc3.orig/drivers/net/irda/irda-usb.c
+++ linux-2617-rc3/drivers/net/irda/irda-usb.c
@@ -1778,7 +1778,7 @@ static int irda_usb_probe(struct usb_int
 
if (self->needspatch) {
ret = usb_control_msg (self->usbdev, usb_sndctrlpipe 
(self->usbdev, 0),
-  0x02, 0x40, 0, 0, 0, 0, 
msecs_to_jiffies(500));
+  0x02, 0x40, 0, 0, NULL, 0, 
msecs_to_jiffies(500));
if (ret < 0) {
IRDA_DEBUG (0, "usb_control_msg failed %d\n", ret);
goto err_out_3;


---
-
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


[PATCH resend] softmac: suggest per-frame-type TX rate

2006-05-01 Thread Daniel Drake
This patch is the first step towards rate control inside softmac.

The txrates substructure has been extended to provide different fields for
different types of packets (management/data, unicast/multicast). These fields
are updated on association to values compatible with the access point we are
associating to.

Drivers can then use the new ieee80211softmac_suggest_txrate() function call
when deciding which rate to transmit each frame at. This is immensely useful
for ZD1211, and bcm can use it too.

The user can still specify a rate through iwconfig, which is matched for all
transmissions (assuming the rate they have specified is in the rate set
required by the AP).

At a later date, we can incorporate automatic rate management into the 
ieee80211softmac_recalc_txrates() function.

This patch also removes the mcast_fallback field. Sam Leffler pointed out that
this field is meaningless, because no driver will ever be retransmitting mcast
frames (they are not acked).

Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
Acked-by: Johannes Berg <[EMAIL PROTECTED]>

--

Rediffed against my other recent patches.
Also, even though this patch modifies the softmac API
(ieee80211softmac_txrates), this should not cause any breakage because nobody
uses that yet.

Index: linux-2.6.17-rc3/include/net/ieee80211softmac.h
===
--- linux-2.6.17-rc3.orig/include/net/ieee80211softmac.h
+++ linux-2.6.17-rc3/include/net/ieee80211softmac.h
@@ -86,6 +86,9 @@ struct ieee80211softmac_assoc_info {

/* BSSID we're trying to associate to */
char bssid[ETH_ALEN];
+
+   /* Rates supported by the network */
+   struct ieee80211softmac_ratesinfo supported_rates;

/* some flags.
 * static_essid is valid if the essid is constant,
@@ -132,23 +135,26 @@ enum {
 struct ieee80211softmac_txrates {
/* The Bit-Rate to be used for multicast frames. */
u8 mcast_rate;
-   /* The Bit-Rate to be used for multicast fallback
-* (If the device supports fallback and hardware-retry)
-*/
-   u8 mcast_fallback;
+
+   /* The Bit-Rate to be used for multicast management frames. */
+   u8 mgt_mcast_rate;
+
/* The Bit-Rate to be used for any other (normal) data packet. */
u8 default_rate;
/* The Bit-Rate to be used for default fallback
 * (If the device supports fallback and hardware-retry)
 */
u8 default_fallback;
+
+   /* This is the rate that the user asked for */
+   u8 user_rate;
 };
 
 /* Bits for txrates_change callback. */
 #define IEEE80211SOFTMAC_TXRATECHG_DEFAULT (1 << 0) /* 
default_rate */
 #define IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK   (1 << 1) /* 
default_fallback */
 #define IEEE80211SOFTMAC_TXRATECHG_MCAST   (1 << 2) /* mcast_rate 
*/
-#define IEEE80211SOFTMAC_TXRATECHG_MCAST_FBACK (1 << 3) /* 
mcast_fallback */
+#define IEEE80211SOFTMAC_TXRATECHG_MGT_MCAST   (1 << 3) /* 
mgt_mcast_rate */
 
 struct ieee80211softmac_device {
/* 802.11 structure for data stuff */
@@ -250,6 +256,28 @@ extern void ieee80211softmac_fragment_lo
  * Note that the rates need to be sorted. */
 extern void ieee80211softmac_set_rates(struct net_device *dev, u8 count, u8 
*rates);
 
+/* Helper function which advises you the rate at which a frame should be
+ * transmitted at. */
+static inline u8 ieee80211softmac_suggest_txrate(struct 
ieee80211softmac_device *mac,
+int is_multicast,
+int is_mgt)
+{
+   struct ieee80211softmac_txrates *txrates = &mac->txrates;
+
+   if (!mac->associated)
+   return txrates->mgt_mcast_rate;
+
+   /* We are associated, sending unicast frame */
+   if (!is_multicast)
+   return txrates->default_rate;
+
+   /* We are associated, sending multicast frame */
+   if (is_mgt)
+   return txrates->mgt_mcast_rate;
+   else
+   return txrates->mcast_rate;
+}
+
 /* Start the SoftMAC. Call this after you initialized the device
  * and it is ready to run.
  */
Index: linux-2.6.17-rc3/net/ieee80211/softmac/ieee80211softmac_assoc.c
===
--- linux-2.6.17-rc3.orig/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ linux-2.6.17-rc3/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -96,6 +96,7 @@ ieee80211softmac_disassoc(struct ieee802
mac->associated = 0;
mac->associnfo.bssvalid = 0;
mac->associnfo.associating = 0;
+   ieee80211softmac_init_txrates(mac);
ieee80211softmac_call_events_locked(mac, 
IEEE80211SOFTMAC_EVENT_DISASSOCIATED, NULL);
spin_unlock_irqrestore(&mac->lock, flags);
 }
@@ -118,24 +119,15 @@ ieee80211softmac_send_disassoc_req(struc
 static inline int
 we_support_all_basic_rates(struct ieee80211softmac_d

Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch

2006-05-01 Thread David S. Miller
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 16:44:51 +0400

> Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>

I understand how in some ways this is work in progress,
but direct calls into ext3 from the kevent code?  I'd
like stuff like that cleaned up before reviewing :-)
-
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


Re: [RFC] vlan: add sysfs support

2006-05-01 Thread Sam Ravnborg
On Mon, May 01, 2006 at 02:08:34PM -0700, Stephen Hemminger wrote:
> Add basic sysfs support for vlan device. It creates an entry in the
> vlan pseudo-device to display tag.  
>   /sys/class/net/eth0.5/vlan_id
> 
> It would be nice at some future to have something like:
>   /sys/class/net/eth0/tags/5  -> ../../eth0.5
> as well.
> 
> There is a race with udev though. The sysfs entry can't be created
> until after the the class_device is registered but the registration
> doesn't happen until  rtnl_unlock after register_netdevice. The class_device
> registration causes the hotplug event, so the hotplug user program
> might get there before vlan_id is created.
> 
> 
> --- vlan.orig/net/8021q/Makefile  2006-05-01 12:50:58.0 -0700
> +++ vlan/net/8021q/Makefile   2006-05-01 14:04:56.0 -0700
> @@ -6,7 +6,5 @@
>  
>  8021q-objs := vlan.o vlan_dev.o
Please make this
>  8021q-y := vlan.o vlan_dev.o

To avoid confusion.


>  
> -ifeq ($(CONFIG_PROC_FS),y)
> -8021q-objs += vlanproc.o
> -endif
> -
> +8021q-$(CONFIG_PROC_FS) += vlanproc.o
> +8021q-$(CONFIG_SYSFS) += vlan_sysfs.o

Sam
-
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


[PATCH resend] softmac: deauthentication implies deassociation

2006-05-01 Thread Daniel Drake
The 802.11 specs state that deauthenticating also implies disassociating. This
patch implements that, which improve the behaviour of SIOCSIWMLME.

Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
Acked-by: Johannes Berg <[EMAIL PROTECTED]>

--

Sorry, missed a file (ieee80211softmac_priv.h) in the last attempt.

Index: linux-2.6.17-rc3/net/ieee80211/softmac/ieee80211softmac_assoc.c
===
--- linux-2.6.17-rc3.orig/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ linux-2.6.17-rc3/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -82,28 +82,37 @@ ieee80211softmac_assoc_timeout(void *d)
ieee80211softmac_call_events(mac, 
IEEE80211SOFTMAC_EVENT_ASSOCIATE_TIMEOUT, NULL);
 }
 
-/* Sends out a disassociation request to the desired AP */
 void
-ieee80211softmac_disassoc(struct ieee80211softmac_device *mac, u16 reason)
+ieee80211softmac_disassoc(struct ieee80211softmac_device *mac)
 {
unsigned long flags;
+
+   spin_lock_irqsave(&mac->lock, flags);
+   if (mac->associnfo.associating)
+   cancel_delayed_work(&mac->associnfo.timeout);
+
+   netif_carrier_off(mac->dev);
+
+   mac->associated = 0;
+   mac->associnfo.bssvalid = 0;
+   mac->associnfo.associating = 0;
+   ieee80211softmac_call_events_locked(mac, 
IEEE80211SOFTMAC_EVENT_DISASSOCIATED, NULL);
+   spin_unlock_irqrestore(&mac->lock, flags);
+}
+
+/* Sends out a disassociation request to the desired AP */
+void
+ieee80211softmac_send_disassoc_req(struct ieee80211softmac_device *mac, u16 
reason)
+{
struct ieee80211softmac_network *found;
 
if (mac->associnfo.bssvalid && mac->associated) {
found = ieee80211softmac_get_network_by_bssid(mac, 
mac->associnfo.bssid);
if (found)
ieee80211softmac_send_mgt_frame(mac, found, 
IEEE80211_STYPE_DISASSOC, reason);
-   } else if (mac->associnfo.associating) {
-   cancel_delayed_work(&mac->associnfo.timeout);
}
 
-   /* Change our state */
-   spin_lock_irqsave(&mac->lock, flags);
-   /* Do NOT clear bssvalid as that will break 
ieee80211softmac_assoc_work! */
-   mac->associated = 0;
-   mac->associnfo.associating = 0;
-   ieee80211softmac_call_events_locked(mac, 
IEEE80211SOFTMAC_EVENT_DISASSOCIATED, NULL);
-   spin_unlock_irqrestore(&mac->lock, flags);
+   ieee80211softmac_disassoc(mac);
 }
 
 static inline int
@@ -176,14 +185,18 @@ ieee80211softmac_assoc_work(void *d)
struct ieee80211softmac_device *mac = (struct ieee80211softmac_device 
*)d;
struct ieee80211softmac_network *found = NULL;
struct ieee80211_network *net = NULL, *best = NULL;
+   int bssvalid;
unsigned long flags;
-   
+
+   /* ieee80211_disassoc might clear this */
+   bssvalid = mac->associnfo.bssvalid;
+
/* meh */
if (mac->associated)
-   ieee80211softmac_disassoc(mac, 
WLAN_REASON_DISASSOC_STA_HAS_LEFT);
+   ieee80211softmac_send_disassoc_req(mac, 
WLAN_REASON_DISASSOC_STA_HAS_LEFT);
 
/* try to find the requested network in our list, if we found one 
already */
-   if (mac->associnfo.bssvalid || mac->associnfo.bssfixed)
+   if (bssvalid || mac->associnfo.bssfixed)
found = ieee80211softmac_get_network_by_bssid(mac, 
mac->associnfo.bssid);   

/* Search the ieee80211 networks for this network if we didn't find it 
by bssid,
@@ -380,7 +393,6 @@ ieee80211softmac_handle_disassoc(struct 
 struct ieee80211_disassoc *disassoc)
 {
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
-   unsigned long flags;
 
if (unlikely(!mac->running))
return -ENODEV;
@@ -392,14 +404,11 @@ ieee80211softmac_handle_disassoc(struct 
return 0;
 
dprintk(KERN_INFO PFX "got disassoc frame\n");
-   netif_carrier_off(dev);
-   spin_lock_irqsave(&mac->lock, flags);
-   mac->associnfo.bssvalid = 0;
-   mac->associated = 0;
-   ieee80211softmac_call_events_locked(mac, 
IEEE80211SOFTMAC_EVENT_DISASSOCIATED, NULL);
+   ieee80211softmac_disassoc(mac);
+
+   /* try to reassociate */
schedule_work(&mac->associnfo.work);
-   spin_unlock_irqrestore(&mac->lock, flags);
-   
+
return 0;
 }
 
Index: linux-2.6.17-rc3/net/ieee80211/softmac/ieee80211softmac_auth.c
===
--- linux-2.6.17-rc3.orig/net/ieee80211/softmac/ieee80211softmac_auth.c
+++ linux-2.6.17-rc3/net/ieee80211/softmac/ieee80211softmac_auth.c
@@ -279,6 +279,9 @@ ieee80211softmac_deauth_from_net(struct 
struct list_head *list_ptr;
unsigned long flags;
 
+   /* deauthentication implies disassociation */
+   ieee80211softmac_disassoc(mac);
+
/* Lock and reset status flags */
spin_lock_irqsave(&mac->lock, flag

[RFC] vlan: add sysfs support

2006-05-01 Thread Stephen Hemminger
Add basic sysfs support for vlan device. It creates an entry in the
vlan pseudo-device to display tag.  
/sys/class/net/eth0.5/vlan_id

It would be nice at some future to have something like:
/sys/class/net/eth0/tags/5  -> ../../eth0.5
as well.

There is a race with udev though. The sysfs entry can't be created
until after the the class_device is registered but the registration
doesn't happen until  rtnl_unlock after register_netdevice. The class_device
registration causes the hotplug event, so the hotplug user program
might get there before vlan_id is created.


--- vlan.orig/net/8021q/Makefile2006-05-01 12:50:58.0 -0700
+++ vlan/net/8021q/Makefile 2006-05-01 14:04:56.0 -0700
@@ -6,7 +6,5 @@
 
 8021q-objs := vlan.o vlan_dev.o
 
-ifeq ($(CONFIG_PROC_FS),y)
-8021q-objs += vlanproc.o
-endif
-
+8021q-$(CONFIG_PROC_FS) += vlanproc.o
+8021q-$(CONFIG_SYSFS) += vlan_sysfs.o
--- vlan.orig/net/8021q/vlan.c  2006-05-01 12:50:58.0 -0700
+++ vlan/net/8021q/vlan.c   2006-05-01 13:48:35.0 -0700
@@ -232,6 +232,8 @@
/* Remove proc entry */
vlan_proc_rem_dev(dev);
 
+   vlan_sysfs_remove(dev);
+
/* Take it out of our own structures, but be sure to
 * interlock with HW accelerating devices or SW vlan
 * input packet processing.
@@ -557,6 +559,9 @@
 
rtnl_unlock();
 
+   if (vlan_sysfs_add(new_dev))
+   printk(KERN_WARNING "VLAN: failed to create sysfs entry for 
%s\n",
+  new_dev->name);
 
 #ifdef VLAN_DEBUG
printk(VLAN_DBG "Allocated new device successfully, returning.\n");
--- vlan.orig/net/8021q/vlan.h  2006-05-01 12:50:58.0 -0700
+++ vlan/net/8021q/vlan.h   2006-05-01 13:17:16.0 -0700
@@ -69,4 +69,13 @@
 int vlan_dev_get_vid(const char* dev_name, unsigned short* result);
 void vlan_dev_set_multicast_list(struct net_device *vlan_dev);
 
+#ifdef CONFIG_SYSFS
+int vlan_sysfs_add(struct net_device *dev);
+void vlan_sysfs_remove(struct net_device *dev);
+#else
+#define vlan_sysfs_add(dev)(0)
+#define vlan_sysfs_remove(dev)  do { } while (0)
+#endif
+
+
 #endif /* !(__BEN_VLAN_802_1Q_INC__) */
--- /dev/null   1970-01-01 00:00:00.0 +
+++ vlan/net/8021q/vlan_sysfs.c 2006-05-01 14:04:49.0 -0700
@@ -0,0 +1,38 @@
+/*
+ * VLAN sysfs interface.
+ *
+ * Basic access to vlan information via sysfs.
+ * Authors:
+ * Stephen Hemminger   <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include "vlan.h"
+
+static ssize_t show_vlan_id(struct class_device *cd, char *buf)
+{
+   struct net_device *vlandev = container_of(cd, struct net_device, 
class_dev);
+
+   return sprintf(buf, "%d\n", VLAN_DEV_INFO(vlandev)->vlan_id);
+}
+
+static CLASS_DEVICE_ATTR(vlan_id, S_IRUGO, show_vlan_id, NULL);
+
+int vlan_sysfs_add(struct net_device *dev)
+{
+   return class_device_create_file(&dev->class_dev,
+   &class_device_attr_vlan_id);
+}
+
+void vlan_sysfs_remove(struct net_device *dev)
+{
+   return class_device_remove_file(&dev->class_dev,
+   &class_device_attr_vlan_id);
+
+}
-
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


[PATCH] bcm43xx-d80211: remove sta_up script

2006-05-01 Thread Michael Buesch
Hi John,

This is not really a patch, because it is easier for you
to do it manually. :)

Please remove the file
scripts/bcm43xx-d80211-sta_up.sh
from the wireless-dev tree, as the d80211 user interface has
been fixed and it is not really needed anymore.

While you are at it, please also remove
Documentation/networking/bcm43xx-d80211-HOWTO.txt
Documentation/networking/bcm43xx-d80211.txt
as they are completely outdated and useless these days.

Thanks.

PS: If someone wants to update
Documentation/networking/bcm43xx.txt
please feel free to submit a patch.

-- 
Greetings Michael.
-
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


[PATCH] softmac: deauthentication implies deassociation

2006-05-01 Thread Daniel Drake
The 802.11 specs state that deauthenticating also implies disassociating. This
patch implements that, which improve the behaviour of SIOCSIWMLME.

Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
Acked-by: Johannes Berg <[EMAIL PROTECTED]>

Index: linux-2.6.17-rc3/net/ieee80211/softmac/ieee80211softmac_assoc.c
===
--- linux-2.6.17-rc3.orig/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ linux-2.6.17-rc3/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -82,28 +82,37 @@ ieee80211softmac_assoc_timeout(void *d)
ieee80211softmac_call_events(mac, 
IEEE80211SOFTMAC_EVENT_ASSOCIATE_TIMEOUT, NULL);
 }
 
-/* Sends out a disassociation request to the desired AP */
 void
-ieee80211softmac_disassoc(struct ieee80211softmac_device *mac, u16 reason)
+ieee80211softmac_disassoc(struct ieee80211softmac_device *mac)
 {
unsigned long flags;
+
+   spin_lock_irqsave(&mac->lock, flags);
+   if (mac->associnfo.associating)
+   cancel_delayed_work(&mac->associnfo.timeout);
+
+   netif_carrier_off(mac->dev);
+
+   mac->associated = 0;
+   mac->associnfo.bssvalid = 0;
+   mac->associnfo.associating = 0;
+   ieee80211softmac_call_events_locked(mac, 
IEEE80211SOFTMAC_EVENT_DISASSOCIATED, NULL);
+   spin_unlock_irqrestore(&mac->lock, flags);
+}
+
+/* Sends out a disassociation request to the desired AP */
+void
+ieee80211softmac_send_disassoc_req(struct ieee80211softmac_device *mac, u16 
reason)
+{
struct ieee80211softmac_network *found;
 
if (mac->associnfo.bssvalid && mac->associated) {
found = ieee80211softmac_get_network_by_bssid(mac, 
mac->associnfo.bssid);
if (found)
ieee80211softmac_send_mgt_frame(mac, found, 
IEEE80211_STYPE_DISASSOC, reason);
-   } else if (mac->associnfo.associating) {
-   cancel_delayed_work(&mac->associnfo.timeout);
}
 
-   /* Change our state */
-   spin_lock_irqsave(&mac->lock, flags);
-   /* Do NOT clear bssvalid as that will break 
ieee80211softmac_assoc_work! */
-   mac->associated = 0;
-   mac->associnfo.associating = 0;
-   ieee80211softmac_call_events_locked(mac, 
IEEE80211SOFTMAC_EVENT_DISASSOCIATED, NULL);
-   spin_unlock_irqrestore(&mac->lock, flags);
+   ieee80211softmac_disassoc(mac);
 }
 
 static inline int
@@ -176,14 +185,18 @@ ieee80211softmac_assoc_work(void *d)
struct ieee80211softmac_device *mac = (struct ieee80211softmac_device 
*)d;
struct ieee80211softmac_network *found = NULL;
struct ieee80211_network *net = NULL, *best = NULL;
+   int bssvalid;
unsigned long flags;
-   
+
+   /* ieee80211_disassoc might clear this */
+   bssvalid = mac->associnfo.bssvalid;
+
/* meh */
if (mac->associated)
-   ieee80211softmac_disassoc(mac, 
WLAN_REASON_DISASSOC_STA_HAS_LEFT);
+   ieee80211softmac_send_disassoc_req(mac, 
WLAN_REASON_DISASSOC_STA_HAS_LEFT);
 
/* try to find the requested network in our list, if we found one 
already */
-   if (mac->associnfo.bssvalid || mac->associnfo.bssfixed)
+   if (bssvalid || mac->associnfo.bssfixed)
found = ieee80211softmac_get_network_by_bssid(mac, 
mac->associnfo.bssid);   

/* Search the ieee80211 networks for this network if we didn't find it 
by bssid,
@@ -380,7 +393,6 @@ ieee80211softmac_handle_disassoc(struct 
 struct ieee80211_disassoc *disassoc)
 {
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
-   unsigned long flags;
 
if (unlikely(!mac->running))
return -ENODEV;
@@ -392,14 +404,11 @@ ieee80211softmac_handle_disassoc(struct 
return 0;
 
dprintk(KERN_INFO PFX "got disassoc frame\n");
-   netif_carrier_off(dev);
-   spin_lock_irqsave(&mac->lock, flags);
-   mac->associnfo.bssvalid = 0;
-   mac->associated = 0;
-   ieee80211softmac_call_events_locked(mac, 
IEEE80211SOFTMAC_EVENT_DISASSOCIATED, NULL);
+   ieee80211softmac_disassoc(mac);
+
+   /* try to reassociate */
schedule_work(&mac->associnfo.work);
-   spin_unlock_irqrestore(&mac->lock, flags);
-   
+
return 0;
 }
 
Index: linux-2.6.17-rc3/net/ieee80211/softmac/ieee80211softmac_auth.c
===
--- linux-2.6.17-rc3.orig/net/ieee80211/softmac/ieee80211softmac_auth.c
+++ linux-2.6.17-rc3/net/ieee80211/softmac/ieee80211softmac_auth.c
@@ -279,6 +279,9 @@ ieee80211softmac_deauth_from_net(struct 
struct list_head *list_ptr;
unsigned long flags;
 
+   /* deauthentication implies disassociation */
+   ieee80211softmac_disassoc(mac);
+
/* Lock and reset status flags */
spin_lock_irqsave(&mac->lock, flags);
net->authenticating = 0;
Index: linux-2.6.17-rc3/net/ieee8021

Re: IP1000 gigabit nic driver

2006-05-01 Thread Lennert Buytenhek
On Mon, May 01, 2006 at 10:38:47PM +0200, Francois Romieu wrote:

> > -/* Minimum number of miliseconds used to toggle MDC clock during
> > +/* Minimum number of nanoseconds used to toggle MDC clock during
> >   * MII/GMII register access.
> >   */
> > -#define IPG_PC_PHYCTRLWAIT   0x01
> > +#defineIPG_PC_PHYCTRLWAIT_NS   200
> 
> I would have expected a cycle of 400 ns (p.72/77 of the datasheet)
> for a 2.5 MHz clock. Why is it cut by a two factor ?

200 ns high + 200 ns low = 400 ns clock period?
-
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


Re: IP1000 gigabit nic driver

2006-05-01 Thread Francois Romieu
David Vrabel <[EMAIL PROTECTED]> :
[...]
> It was clocking the MII management interface (MDC) at 500 Hz so each PHY
> register access took some 130 ms, and many registers accesses were being
> done on initialization. According to the datasheet, the maximum
> frequency for MDC is 2.5 MHz.  Delays have been adjusted accordingly.

[...]
> Index: linux-source-2.6.16/drivers/net/ipg.h
> ===
> --- linux-source-2.6.16.orig/drivers/net/ipg.h2006-05-01 
> 12:08:58.343035854 +0100
> +++ linux-source-2.6.16/drivers/net/ipg.h 2006-05-01 12:09:37.282602113 
> +0100
> @@ -672,10 +672,10 @@
>  /* Number of IPG_AC_RESETWAIT timeperiods before declaring timeout. */
>  #define IPG_AC_RESET_TIMEOUT 0x0A
>  
> -/* Minimum number of miliseconds used to toggle MDC clock during
> +/* Minimum number of nanoseconds used to toggle MDC clock during
>   * MII/GMII register access.
>   */
> -#define IPG_PC_PHYCTRLWAIT   0x01
> +#define  IPG_PC_PHYCTRLWAIT_NS   200

I would have expected a cycle of 400 ns (p.72/77 of the datasheet)
for a 2.5 MHz clock. Why is it cut by a two factor ?

-- 
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


[PATCH] bcm43xx: fix iwmode crash when down

2006-05-01 Thread Michael Buesch
(Second attempt, now unmangled and with signed-off-by line, uh...)
This should go into 2.6.17, as it fixes a user exploitable crash.

--

This fixes a crash when
iwconfig ethX mode foo
is done before
ifconfig ethX up
or after
ifconfig ethX down

Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_wx.c2006-04-22 
17:47:03.0 +0200
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_wx.c 2006-05-01 
22:10:18.0 +0200
@@ -182,8 +182,11 @@
mode = BCM43xx_INITIAL_IWMODE;
 
bcm43xx_lock_mmio(bcm, flags);
-   if (bcm->ieee->iw_mode != mode)
-   bcm43xx_set_iwmode(bcm, mode);
+   if (bcm->initialized) {
+   if (bcm->ieee->iw_mode != mode)
+   bcm43xx_set_iwmode(bcm, mode);
+   } else
+   bcm->ieee->iw_mode = mode;
bcm43xx_unlock_mmio(bcm, flags);
 
return 0;


-- 
Greetings Michael.
-
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


[PATCH] bcm43xx: fix iwmode crash when down

2006-05-01 Thread Michael Buesch
This should go into 2.6.17, as it fixes a user exploitable crash.

--

This fixes a crash when
iwconfig ethX mode foo
is done before
ifconfig ethX up
or after
ifconfig ethX down

Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_wx.c2006-04-22 
17:47:03.0 +0200
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_wx.c 2006-05-01 
22:10:18.0 +0200
@@ -182,8 +182,11 @@
mode = BCM43xx_INITIAL_IWMODE;
 
bcm43xx_lock_mmio(bcm, flags);
-   if (bcm->ieee->iw_mode != mode)
-   bcm43xx_set_iwmode(bcm, mode);
+   if (bcm->initialized) {
+   if (bcm->ieee->iw_mode != mode)
+   bcm43xx_set_iwmode(bcm, mode);
+   } else
+   bcm->ieee->iw_mode = mode;
bcm43xx_unlock_mmio(bcm, flags);
 
return 0;


-- 
Greetings Michael.


pgpih87TglngS.pgp
Description: PGP signature


Re: VLAN subinterfaces, bridges and udev

2006-05-01 Thread Marco d'Itri
On May 01, Ben Greear <[EMAIL PROTECTED]> wrote:

> >Can I rely on the presence of the $DEVPATH/driver symlink (e.g.
> >/sys/class/net/eth0/driver) to check if a network interface is a "real"
> >device insteaf of a VLAN or a bridge?
> To distinguish I use a VLAN specific IOCTL (GET_VLAN_REALDEV_NAME_CMD).
> If that IOCTL has no error, then it is a VLAN.
This is not useful for udev, it needs something available in sysfs.

-- 
ciao,
Marco
-
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


Re: IP1000 gigabit nic driver

2006-05-01 Thread David Gómez
Hi Pekka,

On Apr 29 at 11:35:04, Pekka Enberg wrote:
> No, I haven't. I don't have the hardware, so I can't test the driver.
> Furthermore, there's plenty of stuff to fix before it's in any shape for
> submission. If someone wants to give this patch a spin, I would love to
> hear the results.

The latest version of the driver including David's improvements works
here. Nice work ;)

-- 
David Gómez  Jabber ID: [EMAIL PROTECTED]
-
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


[PATCH] bcm43xx-d80211: proper implementation of virtual interface support

2006-05-01 Thread Michael Buesch
Hi,

Jiri, please review this patch for things that might look
strange to you. :)

--

This replaces the bcm43xx-d80211 virtual interfaces hack by
a correct implementation with support for monitor during oper.

Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h 
2006-04-28 16:13:40.0 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h  2006-05-01 
20:25:31.0 +0200
@@ -626,10 +626,34 @@
u8 algorithm;
 };
 
+struct bcm43xx_interface {
+   struct list_head list;
+   /* Interface type (IEEE80211_IF_TYPE_XXX). */
+   int type;
+   /* Opaque ID from the ieee80211 subsystem. Do not modify. */
+   int if_id;
+   /* MAC address for this interface. */
+   u8 *mac_addr;
+   /* BSSID (if any). */
+   u8 *bssid;
+};
+
+struct bcm43xx_interface_list {
+   /* Linked list of active interfaces. */
+   struct list_head list;
+   /* Shortcut pointer to the AP interface (if any). */
+   struct bcm43xx_interface *ap_if;
+
+   /* Usage counters of the internal operation modes. */
+   u16 opmode_ap;
+   u16 opmode_adhoc;
+   u16 opmode_monitor;
+   u16 opmode_promisc;
+};
+
 struct bcm43xx_private {
struct ieee80211_hw *ieee;
struct ieee80211_low_level_stats ieee_stats;
-   int iw_mode;
 
struct net_device *net_dev;
struct pci_dev *pci_dev;
@@ -653,6 +677,11 @@
short_slot:1,   /* TRUE, if short slot timing is 
enabled. */
firmware_norelease:1;   /* Do not release the firmware. Used on 
suspend. */
 
+   /* One physical device can have one or more virtual
+* interfaces. This stores and manages the virtual interfaces.
+*/
+   struct bcm43xx_interface_list interfaces;
+   /* Various statistics about the physical device. */
struct bcm43xx_stats stats;
 
/* Bus type we are connected to.
@@ -716,8 +745,6 @@
 
/* Informational stuff. */
char nick[IW_ESSID_MAX_SIZE + 1];
-   u8 bssid[ETH_ALEN];
-   int interfaces;
 
/* encryption/decryption */
u16 security_offset;
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c
2006-04-28 16:13:40.0 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c 
2006-05-01 18:57:26.0 +0200
@@ -217,7 +217,7 @@
bcm43xx_led_blink_stop(led, 0);
continue;
case BCM43xx_LED_APTRANSFER:
-   if (bcm->iw_mode == IW_MODE_MASTER) {
+   if (bcm->interfaces.opmode_ap) {
if (transferring) {
interval = BCM43xx_LEDBLINK_FAST;
turn_on = 1;
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
2006-04-28 16:13:40.0 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c 
2006-05-01 20:25:24.0 +0200
@@ -378,18 +378,30 @@
 static void bcm43xx_macfilter_clear(struct bcm43xx_private *bcm,
u16 offset)
 {
-   const u8 zero_addr[ETH_ALEN] = { 0 };
+   static const u8 zero_addr[ETH_ALEN] = { 0 };
 
bcm43xx_macfilter_set(bcm, offset, zero_addr);
 }
 
 static void bcm43xx_write_mac_bssid_templates(struct bcm43xx_private *bcm)
 {
+   static const u8 zero_addr[ETH_ALEN] = { 0 };
+   struct bcm43xx_interface *iface;
const u8 *mac = (const u8 *)(bcm->net_dev->dev_addr);
-   const u8 *bssid = bcm->bssid;
+   const u8 *bssid = NULL;
u8 mac_bssid[ETH_ALEN * 2];
int i;
 
+   list_for_each_entry(iface, &bcm->interfaces.list, list) {
+   if (iface->type != IEEE80211_IF_TYPE_MNTR &&
+   iface->bssid) {
+   bssid = iface->bssid;
+   break;
+   }
+   }
+   if (!bssid)
+   bssid = zero_addr;
+
memcpy(mac_bssid, mac, ETH_ALEN);
memcpy(mac_bssid + ETH_ALEN, bssid, ETH_ALEN);
 
@@ -1438,15 +1450,15 @@
 
 static void handle_irq_ps(struct bcm43xx_private *bcm)
 {
-   if (bcm->iw_mode == IW_MODE_MASTER) {
+   if (bcm->interfaces.opmode_ap) {
///TODO: PS TBTT
} else {
if (1/*FIXME: the last PSpoll frame was sent successfully */)
bcm43xx_power_saving_ctl_bits(bcm, -1, -1);
}
-   if (bcm->iw_mode == IW_MODE_ADHOC)
+   bcm

Re: [PATCH] Add some new card IDs to hostap_cs

2006-05-01 Thread Pavel Roskin
On Mon, 2006-05-01 at 11:04 -0700, Jean Tourrilhes wrote:
> Marcin Juszkiewicz wrote :
> > 
> > When I use pcmcia-cs then my Pretec WiFi card is handled by hostap
> > driver and everything is working fine. Recently I switched to
> > pcmciautils and after card insert orinoco modules are loaded. I prefer
> > to use hostap modules because they work the same under 2.4 and 2.6
> > kernels (with orinoco I have to use 0.13e ones because never ones does
> > not work under 2.4/arm).
> 
>   I'm sorry, but I have to veto part of your patch because it's
> clear you don't know what you are doing.
>   Some of those cards are Orinoco or Symbol cards.

I agree.  Please don't apply this patch.

-- 
Regards,
Pavel Roskin

-
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


Re: IP1000 gigabit nic driver

2006-05-01 Thread Pekka Enberg
Hi David,

On Mon, 2006-05-01 at 12:32 +0100, David Vrabel wrote:
> It was clocking the MII management interface (MDC) at 500 Hz so each PHY
> register access took some 130 ms, and many registers accesses were being
> done on initialization. According to the datasheet, the maximum
> frequency for MDC is 2.5 MHz.  Delays have been adjusted accordingly.

Thanks. Merged your patch.

Pekka

[PATCH] IP1000 Gigabit Ethernet device driver

This is a cleaned up fork of the IP1000A device driver:

  http://www.icplus.com.tw/driver-pp-IP1000A.html

Open issues:

  - ipg_probe() looks really fishy and doesn't handle all errors
(e.g. ioremap failing).
  - ipg_nic_do_ioctl() is playing games with user-space pointer
and lets userspace do PCI access. I think we should nuke the
ioctl. Arjan suggested ethtool ioctl instead, but we don't
seem to have that kind of functionality now anyway.

Changelog:

  - Kill 2.2 and 2.4 compatability macros (Pekka)
  - Use proper module API (Pekka)
  - Use proper PCI API (Pekka)
  - Use netdev_priv (Pekka)
  - Consolidate headers to one file (Pekka)
  - Use __iomem annotations (Pekka)
  - Use iomap instead of read/out for I/O (Pekka)
  - Remove obfuscating register access macros (Pekka)
  - Remove changelogs (David)
  - Remove ether_crc_le() and use crc32_le() instead (David)
  - No more nonsense with root_dev. ipg_remove() now works (David)
  - Move PHY and MAC address initialization into the ipg_probe().  It was
previously filling in the MAC address on open which breaks some user
space. (David)
  - Folded ipg_nic_init into ipg_probe since it was broke otherwise (David)
  - Reduce delays when reading/writing the PHY registers so we clock the
MII management interface at 2.5 MHz (the maximum according to the
datasheet) instead of 500 Hz. (David)

The patch is 128 KB in size, so I am not including it in this
mail. You can find the patch here:

  http://www.cs.helsinki.fi/u/penberg/linux/ip1000-driver.patch

Signed-off-by: David Vrabel <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>

-
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


Re: [PATCH] Add some new card IDs to hostap_cs

2006-05-01 Thread Jean Tourrilhes
Marcin Juszkiewicz wrote :
> 
> When I use pcmcia-cs then my Pretec WiFi card is handled by hostap
> driver and everything is working fine. Recently I switched to
> pcmciautils and after card insert orinoco modules are loaded. I prefer
> to use hostap modules because they work the same under 2.4 and 2.6
> kernels (with orinoco I have to use 0.13e ones because never ones does
> not work under 2.4/arm).

I'm sorry, but I have to veto part of your patch because it's
clear you don't know what you are doing.
Some of those cards are Orinoco or Symbol cards. The HostAP
driver do *NOT* properly support them (try to scan or to use ad-hoc
mode). Only the Orinoco driver do support those cards.
Therefore, the HostAP driver should never bind to those cards.

My howto do explain those things in details. Please don't do
those kind of patches as it will break support for those of use using
those cards.

> + PCMCIA_DEVICE_MANF_CARD(0x0089, 0x0001), /* "Intel PRO/Wireless
2011" */

That's a Symbol card. I know, I have one.

> + /*card "3Com AirConnect"*/
> + PCMCIA_DEVICE_PROD_ID12("3Com", "3CRWE737A AirConnect Wireless LAN PC 
> Card",
> + 0x90952d33, 0xfa4f2ce9),

That's a Symbol card. I know, I have two.

> + /*card "MELCO WLI-PCM-L11"*/
> + PCMCIA_DEVICE_PROD_ID12( "MELCO", "WLI-PCM-L11",
> + 0xc549cac9, 0xc2f6de9b),
> +
> + /*card "MELCO WLI-PCM-L11G"*/
> + PCMCIA_DEVICE_PROD_ID12( "MELCO", "WLI-PCM-L11G",
> + 0xfebebb55, 0x6db62357),
> +
> + /*card "MELCO WLI-PCM-L11G"*/
> + PCMCIA_DEVICE_PROD_ID12( "BUFFALO", "WLI-PCM-L11G",
> + 0x6cdab6ea, 0xc364d25d),
> +
> + /*card "Buffalo WLI2-CF-S11"*/
> + PCMCIA_DEVICE_PROD_ID12( "BUFFALO", "WLI2-CF-S11",
> + 0x798caeca, 0xe38746ab),
> +

I believe, from the report I got, that those are Orinoco cards.

> + /*card "NCR WaveLAN/IEEE Adapter"*/
> + PCMCIA_DEVICE_PROD_ID12( "NCR", "WaveLAN/IEEE",
> + 0x7b03a1a1, 0x1e9b31cf),

That's an Orinoco card. I know, I have zillion of them.

Regards,

Jean
-
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


Re: RtNetlink in wireless.c and netlink_broadcast(uevent_sock,...) - newbie

2006-05-01 Thread Jean Tourrilhes
Xu Nakajima wrote :
> 
> Hello,
> 
> I saw that in the wireless linux stack, there is usage
> 
> of sending messages to user space via the RtNetlink
> event channel : 
> in net/core/wireless.c,  wireless_send_event() method
> calls rtmsg_iwinfo() which calls
> netlink_broadcast(rtnl, skb, 0, RTNLGRP_LINK,
> GFP_ATOMIC); (it fills a struct with 
> rtnetlink_fill_iwinfo before).
> 
> On the other hand, I see that for example, in the case
> of 
> sending messeges to userspace udev socket, the
> netlink_broadcast() call is with a different
> mecahinsm;  
> In lib/kobject_uevent.c, there is the following call
> netlink_broadcast(uevent_sock, skb, 0, 1, GFP_KERNEL);
> 
> Is there something special about RtNetlink event
> channel
> which makes it needed fot wireless.c (for example)? 
> While udev can use some other mechanism ?
> What is special about RtNetlink event channel
> in comaprison to non RtNetlink channels?

Netlink is a generic socket mechanism. On top of Netlink, you
can have multiple types of sockets, the same way that on top of TCP
sockets you can implement various protocols, such as HTTP, NFS, SSH...
RtNetlink was the first Netlink protocol implemented and is
the Netlink protocol used to configure network interfaces. In the file
net/core/rtnetlink.c, you will find that there are many actions that
generates RtNetlink events. Together with wireless events, they give
you a very detailed view of what's happening with network interfaces.
The udev-netlink protocol is quite recent and a completely
different Netlink ptotocol that uses a different packet format. As far
as exporting network information, it is very crude, because the goal
of udev is not managing network interfaces. Yes, udev does duplicate
some RtNetlink events, but the overlap is not so much, so that's ok.

Good luck...

Jean
-
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


Re: [PATCH 4/6] tg3: Add reset_phy parameter to chip reset functions

2006-05-01 Thread Michael Chan
On Sat, 2006-04-29 at 18:59 -0700, David S. Miller wrote:
> From: "Michael Chan" <[EMAIL PROTECTED]>
> Date: Fri, 28 Apr 2006 16:36:08 -0700
> 
> > Add a reset_phy parameter to tg3_reset_hw() and tg3_init_hw(). With
> > the full chip reset during MAC address change, the automatic PHY reset
> > during chip reset will cause a link down and bonding will not work
> > properly as a result. With this reset_phy parameter, we can do a chip
> > reset without link down when changing MAC address or MTU.
> > 
> > Signed-off-by: Gary Zambrano <[EMAIL PROTECTED]>
> > Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
> 
> Applied.
> 
> Doesn't the signalling interface between the MAC and the
> PHY get reset during a chip reset and couldn't that cause
> problems if we bypass the PHY reset?

The PHY reset is needed if the PHY was previously put into low power
mode. In the cases where we reset the chip due to MTU or MAC address
changes, the power settings are not changed and therefore PHY reset is
not needed.

-
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


Fw: [Bugme-new] [Bug 6471] New: sky2 problem with Marvell 88E8055

2006-05-01 Thread Andrew Morton


Begin forwarded message:

Date: Mon, 1 May 2006 05:20:30 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 6471] New: sky2 problem with Marvell 88E8055


http://bugzilla.kernel.org/show_bug.cgi?id=6471

   Summary: sky2 problem with Marvell 88E8055
Kernel Version: 2.6.17-rc3
Status: NEW
  Severity: high
 Owner: [EMAIL PROTECTED]
 Submitter: [EMAIL PROTECTED]


Most recent kernel where this bug did not occur: 2.6.17-rc3
Distribution: Gentoo
Hardware Environment: Fujitsu-Siemens E8110, ethernet Card Marvell 88E8055
Software Environment:
Problem Description:
Unable to connect, sometimes kernel hangs

Steps to reproduce:
boot, modprobe sky2, dhclient -d eth1

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
-
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


Re: tw32_f() in tg3_write_mem()

2006-05-01 Thread Michael Chan
On Sun, 2006-04-30 at 23:07 -0700, David S. Miller wrote:
> From: "Michael Chan" <[EMAIL PROTECTED]>
> Date: Sun, 30 Apr 2006 22:05:40 -0700
> 
> > Reading back the data register is a safe thing to do. This
> > guarantees that the data is written before we change the address
> > register to the zero value. Without the read, there is a danger of
> > the value being written to SRAM address 0 instead of the desired
> > address.
> 
> Writes can be posted, but they cannot be reordered can they?
> 

Right, reordering is not allowed unless the relaxed ordering attribute
is set. The read back here is not to guarantee ordering. Those SRAM
address and data registers require "set-up" times for the SRAM writes
and reads to work correctly. The "set-up" times are met either with
config. cycles or with a read when using MMIO cycles. No udelays are
needed, just a read will do.

-
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


[1/1] AIO sendfile() implementation.

2006-05-01 Thread Evgeniy Polyakov
Kevent [1] based AIO sendfile() implementation.

Patch can be found in archive [2] and is attached. 
It is called /tmp/aio_sendfile.1 and depends on full kevent patchset
kevent_full.diff.2, which was recenly sent to netdev@ [3].

Patch is fairly trivial - just use file->f_op->sendpage() for page
sending, all asynchronous mechanism lives in page propagation into VFS
cache.

1. kevent system
http://tservice.net.ru/~s0mbre/old/?section=projects&item=kevent

2. kevent archive
http://tservice.net.ru/~s0mbre/archive/kevent/

3. full kevent patchset
http://marc.theaimsgroup.com/?l=linux-netdev&m=114631895701710&w=2

Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>

diff --git a/kernel/kevent/kevent_aio.c b/kernel/kevent/kevent_aio.c
index f72107a..249fbc2 100644
--- a/kernel/kevent/kevent_aio.c
+++ b/kernel/kevent/kevent_aio.c
@@ -31,6 +31,8 @@
 #include 
 #include 
 
+#include 
+
 #define KEVENT_AIO_DEBUG
 
 #ifdef KEVENT_AIO_DEBUG
@@ -47,7 +49,7 @@ struct kevent_aio_private
loff_t  processed;
atomic_tbio_page_num;
struct completion   bio_complete;
-   struct file *file;
+   struct file *file, *sock;
struct work_struct  work;
 };
 
@@ -320,15 +322,15 @@ static int kevent_mpage_readpages(struct
 
 static size_t kevent_aio_vfs_read_actor(struct kevent *k, struct page *kpage, 
size_t len)
 {
-#if 0
struct kevent_aio_private *priv = k->priv;
-   struct kevent *n;
+   size_t ret;
+   
+   ret = priv->sock->f_op->sendpage(priv->sock, kpage, 0, len, 
&priv->sock->f_pos, 1);
 
-   n = kevent_alloc(GFP_KERNEL);
-   if (!n)
-   return -ENOMEM;
-#endif 
-   return len;
+   dprintk("%s: k=%p, page=%p, len=%zu, ret=%zd.\n", 
+   __func__, k, kpage, len, ret);
+
+   return ret;
 }
 
 static int kevent_aio_vfs_read(struct kevent *k, 
@@ -444,21 +446,28 @@ static void kevent_aio_work(void *data)
 static int kevent_aio_enqueue(struct kevent *k)
 {
int err;
-   struct file *file;
+   struct file *file, *sock;
struct inode *inode;
struct kevent_aio_private *priv;
int fd = k->event.id.raw[0];
int num = k->event.id.raw[1];
+   int s = k->event.ret_data[0];
size_t size;
 
err = -ENODEV;
file = fget(fd);
if (!file)
goto err_out_exit;
+   
+   sock = fget(s);
+   if (!sock)
+   goto err_out_fput_file;
 
err = -EINVAL;
if (!file->f_dentry || !file->f_dentry->d_inode)
goto err_out_fput;
+   if (!sock->f_dentry || !sock->f_dentry->d_inode)
+   goto err_out_fput;
 
inode = igrab(file->f_dentry->d_inode);
if (!inode)
@@ -477,6 +486,7 @@ static int kevent_aio_enqueue(struct kev
priv->size = size;
priv->offset = 0;
priv->file = file;
+   priv->sock = sock;
INIT_WORK(&priv->work, kevent_aio_work, k);
k->priv = priv;
 
@@ -492,6 +502,8 @@ static int kevent_aio_enqueue(struct kev
 err_out_iput:
iput(inode);
 err_out_fput:
+   fput(sock);
+err_out_fput_file:
fput(file);
 err_out_exit:
 
@@ -503,6 +515,7 @@ static int kevent_aio_dequeue(struct kev
struct kevent_aio_private *priv = k->priv;
struct inode *inode = k->st->origin;
struct file *file = priv->file;
+   struct file *sock = priv->sock;
 
kevent_storage_dequeue(k->st, k);
flush_scheduled_work();
@@ -512,6 +525,7 @@ static int kevent_aio_dequeue(struct kev
k->priv = NULL;
iput(inode);
fput(file);
+   fput(sock);
 
return 0;
 }
@@ -533,6 +547,9 @@ asmlinkage long sys_aio_sendfile(int ctl
 
ukread.id.raw[0] = fd;
ukread.id.raw[1] = num;
+   ukread.ret_data[0] = s;
+
+   dprintk("%s: fd=%d, s=%d, num=%d.\n", __func__, fd, s, num);
 
file = fget_light(ctl_fd, &fput_needed);
if (!file)

-- 
Evgeniy Polyakov
-
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


Re: VLAN subinterfaces, bridges and udev

2006-05-01 Thread Ben Greear

Marco d'Itri wrote:

[Please Cc me, I am not subscribed to netdev.]

Can I rely on the presence of the $DEVPATH/driver symlink (e.g.
/sys/class/net/eth0/driver) to check if a network interface is a "real"
device insteaf of a VLAN or a bridge?


To distinguish I use a VLAN specific IOCTL (GET_VLAN_REALDEV_NAME_CMD).
If that IOCTL has no error, then it is a VLAN.

I don't know if there is a similar trick for bridges.

Thanks,
Ben


--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc  http://www.candelatech.com

-
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


Re: wireless softmac origin (net/ieee80211/softmac)

2006-05-01 Thread Joseph Jezak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ian Brown wrote:
> Hello,
> I am looking at 2.6.17-rc3 kernel.
> I wonder: what is the origin of softmac in
> 2.6.17-rc3 kernel ?
> I see in the *.c files under that folder:
> Copyright (c) 2005, 2006 Johannes Berg <[EMAIL PROTECTED]>
> *  Joseph Jezak <[EMAIL PROTECTED]>
> *  Larry Finger <[EMAIL PROTECTED]>
> *  Danny van Dyk <[EMAIL PROTECTED]>
> *  Michael Buesch <[EMAIL PROTECTED]>
> 
> Is this softmac layer was written from scratch ? or was it
> taken (fully/partially) from softmac in the devicescape linux kernel
> stack ?
> http://devicescape.com/
> 
> Best,
> IB
> -
> 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
> 

It was written from scratch.

- -Joe
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEVht7wGq7BLLARfoRAspnAJ9vQC8EUnzN9efWpJZijVNDnsSUIwCfUiVZ
1nsWLEQr+iA0BG18tUKoY8c=
=GRht
-END PGP SIGNATURE-
-
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


wireless softmac origin (net/ieee80211/softmac)

2006-05-01 Thread Ian Brown

Hello,
I am looking at 2.6.17-rc3 kernel.
I wonder: what is the origin of softmac in
2.6.17-rc3 kernel ?
I see in the *.c files under that folder:
Copyright (c) 2005, 2006 Johannes Berg <[EMAIL PROTECTED]>
*  Joseph Jezak <[EMAIL PROTECTED]>
*  Larry Finger <[EMAIL PROTECTED]>
*  Danny van Dyk <[EMAIL PROTECTED]>
*  Michael Buesch <[EMAIL PROTECTED]>

Is this softmac layer was written from scratch ? or was it
taken (fully/partially) from softmac in the devicescape linux kernel stack ?
http://devicescape.com/

Best,
IB
-
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


[PATCH] au1000_eth.c: use ether_crc() from

2006-05-01 Thread Herbert Valerio Riedel
since the au1000 driver already selects the CRC32 routines, simply replace
the internal ether_crc() implementation with the semantically equivalent
one from 

Signed-off-by: Herbert Valerio Riedel <[EMAIL PROTECTED]>


---

 drivers/net/au1000_eth.c |   18 +-
 1 files changed, 1 insertions(+), 17 deletions(-)

9360df5368de8fc7dcaacf9b7ca446af94c4
diff --git a/drivers/net/au1000_eth.c b/drivers/net/au1000_eth.c
index 29adebb..0823cb8 100644
--- a/drivers/net/au1000_eth.c
+++ b/drivers/net/au1000_eth.c
@@ -52,6 +52,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2070,23 +2071,6 @@ static void au1000_tx_timeout(struct net
netif_wake_queue(dev);
 }
 
-
-static unsigned const ethernet_polynomial = 0x04c11db7U;
-static inline u32 ether_crc(int length, unsigned char *data)
-{
-int crc = -1;
-
-while(--length >= 0) {
-   unsigned char current_octet = *data++;
-   int bit;
-   for (bit = 0; bit < 8; bit++, current_octet >>= 1)
-   crc = (crc << 1) ^
-   ((crc < 0) ^ (current_octet & 1) ? 
-ethernet_polynomial : 0);
-}
-return crc;
-}
-
 static void set_rx_mode(struct net_device *dev)
 {
struct au1000_private *aup = (struct au1000_private *) dev->priv;
-- 
1.2.6

-
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


Re: IP1000 gigabit nic driver

2006-05-01 Thread David Vrabel

David Vrabel wrote:


- something (PHY reset/auto negotiation?) takes 2-3 seconds and
  appears to be done with interrupts disabled.


It was clocking the MII management interface (MDC) at 500 Hz so each PHY
register access took some 130 ms, and many registers accesses were being
done on initialization. According to the datasheet, the maximum
frequency for MDC is 2.5 MHz.  Delays have been adjusted accordingly.

David Vrabel
Reduce delays when reading/writing the PHY registers so we clock the
MII management interface at 2.5 MHz (the maximum according to the
datasheet) instead of 500 Hz.

Signed-off-by: David Vrabel <[EMAIL PROTECTED]>

Index: linux-source-2.6.16/drivers/net/ipg.c
===
--- linux-source-2.6.16.orig/drivers/net/ipg.c  2006-05-01 11:52:32.555800238 
+0100
+++ linux-source-2.6.16/drivers/net/ipg.c   2006-05-01 12:08:45.316188064 
+0100
@@ -176,13 +176,13 @@
 (IPG_PC_MGMTCLK_LO | (IPG_PC_MGMTDATA & 0) | IPG_PC_MGMTDIR |
  phyctrlpolarity), ioaddr + IPG_PHYCTRL);
 
-   mdelay(IPG_PC_PHYCTRLWAIT);
+   ndelay(IPG_PC_PHYCTRLWAIT_NS);
 
iowrite8(IPG_PC_RSVD_MASK &
 (IPG_PC_MGMTCLK_HI | (IPG_PC_MGMTDATA & 0) | IPG_PC_MGMTDIR |
  phyctrlpolarity), ioaddr + IPG_PHYCTRL);
 
-   mdelay(IPG_PC_PHYCTRLWAIT);
+   ndelay(IPG_PC_PHYCTRLWAIT_NS);
 }
 
 static void send_end(void __iomem * ioaddr, u8 phyctrlpolarity)
@@ -198,7 +198,7 @@
iowrite8(IPG_PC_RSVD_MASK & (IPG_PC_MGMTCLK_LO | phyctrlpolarity),
 ioaddr + IPG_PHYCTRL);
 
-   mdelay(IPG_PC_PHYCTRLWAIT);
+   ndelay(IPG_PC_PHYCTRLWAIT_NS);
 
bit_data =
((ioread8(ioaddr + IPG_PHYCTRL) & IPG_PC_MGMTDATA) >> 1) & 1;
@@ -206,7 +206,7 @@
iowrite8(IPG_PC_RSVD_MASK & (IPG_PC_MGMTCLK_HI | phyctrlpolarity),
 ioaddr + IPG_PHYCTRL);
 
-   mdelay(IPG_PC_PHYCTRLWAIT);
+   ndelay(IPG_PC_PHYCTRLWAIT_NS);
return bit_data;
 }
 
@@ -290,14 +290,14 @@
  (IPG_PC_MGMTDATA & databit) | IPG_PC_MGMTDIR |
  phyctrlpolarity), ioaddr + IPG_PHYCTRL);
 
-   mdelay(IPG_PC_PHYCTRLWAIT);
+   ndelay(IPG_PC_PHYCTRLWAIT_NS);
 
iowrite8(IPG_PC_RSVD_MASK &
 (IPG_PC_MGMTCLK_HI |
  (IPG_PC_MGMTDATA & databit) | IPG_PC_MGMTDIR |
  phyctrlpolarity), ioaddr + IPG_PHYCTRL);
 
-   mdelay(IPG_PC_PHYCTRLWAIT);
+   ndelay(IPG_PC_PHYCTRLWAIT_NS);
}
 
send_three_state(ioaddr, phyctrlpolarity);
@@ -403,14 +403,14 @@
  (IPG_PC_MGMTDATA & databit) | IPG_PC_MGMTDIR |
  phyctrlpolarity), ioaddr + IPG_PHYCTRL);
 
-   mdelay(IPG_PC_PHYCTRLWAIT);
+   ndelay(IPG_PC_PHYCTRLWAIT_NS);
 
iowrite8(IPG_PC_RSVD_MASK &
 (IPG_PC_MGMTCLK_HI |
  (IPG_PC_MGMTDATA & databit) | IPG_PC_MGMTDIR |
  phyctrlpolarity), ioaddr + IPG_PHYCTRL);
 
-   mdelay(IPG_PC_PHYCTRLWAIT);
+   ndelay(IPG_PC_PHYCTRLWAIT_NS);
}
 
/* The last cycle is a tri-state, so read from the PHY.
@@ -421,7 +421,7 @@
 (IPG_PC_MGMTCLK_LO | phyctrlpolarity),
 ioaddr + IPG_PHYCTRL);
 
-   mdelay(IPG_PC_PHYCTRLWAIT);
+   ndelay(IPG_PC_PHYCTRLWAIT_NS);
 
field[j] |= ((ioread8(ioaddr + IPG_PHYCTRL) &
  IPG_PC_MGMTDATA) >> 1)
@@ -431,7 +431,7 @@
 (IPG_PC_MGMTCLK_HI | phyctrlpolarity),
 ioaddr + IPG_PHYCTRL);
 
-   mdelay(IPG_PC_PHYCTRLWAIT);
+   ndelay(IPG_PC_PHYCTRLWAIT_NS);
 
}
 }
Index: linux-source-2.6.16/drivers/net/ipg.h
===
--- linux-source-2.6.16.orig/drivers/net/ipg.h  2006-05-01 12:08:58.343035854 
+0100
+++ linux-source-2.6.16/drivers/net/ipg.h   2006-05-01 12:09:37.282602113 
+0100
@@ -672,10 +672,10 @@
 /* Number of IPG_AC_RESETWAIT timeperiods before declaring timeout. */
 #define IPG_AC_RESET_TIMEOUT 0x0A
 
-/* Minimum number of miliseconds used to toggle MDC clock during
+/* Minimum number of nanoseconds used to toggle MDC clock during
  * MII/GMII register access.
  */
-#define IPG_PC_PHYCTRLWAIT   0x01
+#defineIPG_PC_PHYCTRLWAIT_NS   200
 
 #defineIPG_TFDLIST_LENGTH  0x100
 


[PATCH 001/100] TCP congestion module: add TCP-LP supporting for 2.6.16

2006-05-01 Thread Wong Edison

TCP Low Priority is a distributed algorithm whose goal is to utilize only
the excess network bandwidth as compared to the ``fair share`` of
bandwidth as targeted by TCP. Available from:
 http://www.ece.rice.edu/~akuzma/Doc/akuzma/TCP-LP.pdf

See http://www-ece.rice.edu/networks/TCP-LP/ for their implementation.
Our group take the following changes from
the original TCP-LP implementation:
 o We use newReno in most core CA handling. Only add some checking
   within cong_avoid.
 o Error correcting in remote HZ, therefore remote HZ will be keeped
   on checking and updating.
 o Handling calculation of One-Way-Delay (OWD) within rtt_sample, sicne
   OWD have a similar meaning as RTT. Also correct the buggy formular.
 o Handle reaction for Early Congestion Indication (ECI) within
   pkts_acked, as mentioned within pseudo code.
 o OWD is handled in relative format, where local time stamp will in
   tcp_time_stamp format.

Port from 2.4.19 to 2.6.16 as module by:
 Wong Hoi Sing Edison <[EMAIL PROTECTED]>
 Hung Hing Lun <[EMAIL PROTECTED]>

Signed-off-by: Wong Hoi Sing Edison <[EMAIL PROTECTED]>


diff -urN linux-2.6.16.1/net/ipv4/Kconfig linux/net/ipv4/Kconfig
--- linux-2.6.16.1/net/ipv4/Kconfig 2006-03-28 14:49:02.0 +0800
+++ linux/net/ipv4/Kconfig  2006-04-19 02:40:27.0 +0800
@@ -531,6 +531,27 @@
properties, though is known to have fairness issues.
See http://www-lce.eng.cam.ac.uk/~ctk21/scalable/

+config TCP_CONG_LP
+   tristate "TCP Low Priority"
+   depends on EXPERIMENTAL
+   default n
+   ---help---
+   TCP Low Priority (TCP-LP), a distributed algorithm whose goal is
+   to utiliza only the excess network bandwidth as compared to the
+   ``fair share`` of bandwidth as targeted by TCP.
+   See http://www-ece.rice.edu/networks/TCP-LP/
+
+config TCP_CONG_LP_DEBUG
+   bool "TCP-LP Debug"
+   depends on TCP_CONG_LP
+   default n
+   ---help---
+   Turn on/off the debug message for TCP-LP. The debug message will
+   print to default kernel debug log file, e.g. /var/log/debug as
+   default. You can use dmesg to obtain the log too.
+   
+   If unsure, say N.
+
endmenu

config TCP_CONG_BIC
diff -urN linux-2.6.16.1/net/ipv4/Makefile linux/net/ipv4/Makefile
--- linux-2.6.16.1/net/ipv4/Makefile2006-03-28 14:49:02.0 +0800
+++ linux/net/ipv4/Makefile 2006-04-19 02:40:27.0 +0800
@@ -41,6 +41,7 @@
obj-$(CONFIG_TCP_CONG_HTCP) += tcp_htcp.o
obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o
obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o
+obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o

obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
  xfrm4_output.o
diff -urN linux-2.6.16.1/net/ipv4/tcp_lp.c linux/net/ipv4/tcp_lp.c
--- linux-2.6.16.1/net/ipv4/tcp_lp.c1970-01-01 08:00:00.0 +0800
+++ linux/net/ipv4/tcp_lp.c 2006-04-25 15:54:54.0 +0800
@@ -0,0 +1,343 @@
+/*
+ * TCP Low Priority (TCP-LP)
+ *
+ * TCP Low Priority is a distributed algorithm whose goal is to utilize only
+ *   the excess network bandwidth as compared to the ``fair share`` of
+ *   bandwidth as targeted by TCP. Available from:
+ * http://www.ece.rice.edu/~akuzma/Doc/akuzma/TCP-LP.pdf
+ *
+ * Original Author:
+ *   Aleksandar Kuzmanovic <[EMAIL PROTECTED]>
+ *
+ * See http://www-ece.rice.edu/networks/TCP-LP/ for their implementation.
+ * As of 2.6.13, Linux supports pluggable congestion control algorithms.
+ * Due to the limitation of the API, we take the following changes from
+ * the original TCP-LP implementation:
+ *   o We use newReno in most core CA handling. Only add some checking
+ * within cong_avoid.
+ *   o Error correcting in remote HZ, therefore remote HZ will be keeped
+ * on checking and updating.
+ *   o Handling calculation of One-Way-Delay (OWD) within rtt_sample, sicne
+ * OWD have a similar meaning as RTT. Also correct the buggy formular.
+ *   o Handle reaction for Early Congestion Indication (ECI) within
+ * pkts_acked, as mentioned within pseudo code.
+ *   o OWD is handled in relative format, where local time stamp will in
+ * tcp_time_stamp format.
+ *
+ * Port from 2.4.19 to 2.6.16 as module by:
+ *   Wong Hoi Sing Edison <[EMAIL PROTECTED]>
+ *   Hung Hing Lun <[EMAIL PROTECTED]>
+ *
+ * Version: $Id: tcp_lp.c,v 1.20 2006-04-22 06:34:20 hswong3i Exp $
+ */
+
+#include 
+#include 
+#include 
+
+#ifndef CONFIG_TCP_CONG_LP_DEBUG
+#define CONFIG_TCP_CONG_LP_DEBUG 0
+#endif
+
+/* resolution of owd */
+#define LP_RESOL   1000
+
+/**
+ * enum tcp_lp_state
+ * @LP_VALID_RHZ: is remote HZ valid?
+ * @LP_VALID_OWD: is OWD valid?
+ * @LP_WITHIN_THR: are we within threshold?
+ * @LP_WITHIN_INF: are we within inference?
+ *
+ * TCP-LP's state flags.
+ * We create this set of state flag mainly for debugging.
+ */
+enum tcp_lp_state {
+   LP_VALID_RHZ = (1 << 0),
+   LP_VALID_OWD = (1 << 1),
+   LP_WITHIN_THR = (1 << 3),
+   LP_WIT

Re: IP1000 gigabit nic driver

2006-05-01 Thread Pekka Enberg
On Mon, 2006-05-01 at 00:40 +0100, David Vrabel wrote:
> Still pending.  Also:
> 
>  - something (PHY reset/auto negotiation?) takes 2-3 seconds and
>appears to be done with interrupts disabled.

Are you seeing this at module initialization? Does Sysrq-t show anything
useful?

Pekka

-
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


Re: IP1000 gigabit nic driver

2006-05-01 Thread Pekka Enberg
On Mon, 2006-05-01 at 00:40 +0100, David Vrabel wrote:
> Thanks for doing this Pekka.  I've fixed up some stuff and given it some 
> brief testing on a 100BaseT network and it seems to work now.

Thanks! I merged your stuff and pushed out an updated patch.

Pekka

[PATCH] IP1000 Gigabit Ethernet device driver

This is a cleaned up fork of the IP1000A device driver:

  http://www.icplus.com.tw/driver-pp-IP1000A.html

Open issues:

  - ipg_probe() looks really fishy and doesn't handle all errors
(e.g. ioremap failing).
  - ipg_nic_do_ioctl() is playing games with user-space pointer.
We should use ethtool ioctl instead as suggested by Arjan.
  - something (PHY reset/auto negotiation?) takes 2-3 seconds and
appears to be done with interrupts disabled.

Changelog:

  - Kill 2.2 and 2.4 compatability macros
  - Use proper module API
  - Use proper PCI API
  - Use netdev_priv
  - Consolidate headers to one file
  - Use __iomem annotations
  - Use iomap instead of read/out for I/O
  - Remove obfuscating register access macros
  - Remove changelogs
  - Remove ether_crc_le() -- use crc32_le() instead.
  - No more nonsense with root_dev -- ipg_remove() now works.
  - Move PHY and MAC address initialization into the ipg_probe().  It was
previously filling in the MAC address on open which breaks some user
space.
  - Folded ipg_nic_init into ipg_probe since it was broke otherwise.

I don't have the hardware, so I don't know if I broke anything.
The patch is 128 KB in size, so I am not including it in this
mail. You can find the patch here:

  http://www.cs.helsinki.fi/u/penberg/linux/ip1000-driver.patch

Signed-off-by: David Vrabel <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>

-
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


Re: [PATCH 0/3] Eleminate HZ from AX.25, NETROM and ROSE kernel interfaces

2006-05-01 Thread David S. Miller

Ralf, I have all of your patches queued up, I'll review them
and merge them in soon.

Thanks a lot.
-
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