2008-11-03 20:51:53

by Jeff Garzik

[permalink] [raw]
Subject: [git patches] net driver fixes for 2.6.28-rc


Please pull from 'davem-fixes' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git davem-fixes

to receive the following updates:

drivers/net/Kconfig | 18 +++++++++++++++---
drivers/net/fs_enet/fs_enet-main.c | 6 ++++--
drivers/net/mv643xx_eth.c | 9 ++++++---
3 files changed, 25 insertions(+), 8 deletions(-)

Alexey Dobriyan (1):
fs_enet: fix polling

Jeff Kirsher (1):
net: kconfig cleanup

Lennert Buytenhek (1):
mv643xx_eth: fix SMI bus access timeouts

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f749b40..11f143f 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2010,9 +2010,13 @@ config IGB_LRO
If in doubt, say N.

config IGB_DCA
- bool "Enable DCA"
+ bool "Direct Cache Access (DCA) Support"
default y
depends on IGB && DCA && !(IGB=y && DCA=m)
+ ---help---
+ Say Y here if you want to use Direct Cache Access (DCA) in the
+ driver. DCA is a method for warming the CPU cache before data
+ is used, with the intent of lessening the impact of cache misses.

source "drivers/net/ixp2000/Kconfig"

@@ -2437,9 +2441,13 @@ config IXGBE
will be called ixgbe.

config IXGBE_DCA
- bool
+ bool "Direct Cache Access (DCA) Support"
default y
depends on IXGBE && DCA && !(IXGBE=y && DCA=m)
+ ---help---
+ Say Y here if you want to use Direct Cache Access (DCA) in the
+ driver. DCA is a method for warming the CPU cache before data
+ is used, with the intent of lessening the impact of cache misses.

config IXGB
tristate "Intel(R) PRO/10GbE support"
@@ -2489,9 +2497,13 @@ config MYRI10GE
will be called myri10ge.

config MYRI10GE_DCA
- bool
+ bool "Direct Cache Access (DCA) Support"
default y
depends on MYRI10GE && DCA && !(MYRI10GE=y && DCA=m)
+ ---help---
+ Say Y here if you want to use Direct Cache Access (DCA) in the
+ driver. DCA is a method for warming the CPU cache before data
+ is used, with the intent of lessening the impact of cache misses.

config NETXEN_NIC
tristate "NetXen Multi port (1/10) Gigabit Ethernet NIC"
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index cb51c1f..a6f49d0 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -1099,7 +1099,9 @@ static int __devinit fs_enet_probe(struct of_device *ofdev,
ndev->stop = fs_enet_close;
ndev->get_stats = fs_enet_get_stats;
ndev->set_multicast_list = fs_set_multicast_list;
-
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ ndev->poll_controller = fs_enet_netpoll;
+#endif
if (fpi->use_napi)
netif_napi_add(ndev, &fep->napi, fs_enet_rx_napi,
fpi->napi_weight);
@@ -1209,7 +1211,7 @@ static void __exit fs_cleanup(void)
static void fs_enet_netpoll(struct net_device *dev)
{
disable_irq(dev->irq);
- fs_enet_interrupt(dev->irq, dev, NULL);
+ fs_enet_interrupt(dev->irq, dev);
enable_irq(dev->irq);
}
#endif
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index a9c8c08..b9dcdbd 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -1066,9 +1066,12 @@ static int smi_wait_ready(struct mv643xx_eth_shared_private *msp)
return 0;
}

- if (!wait_event_timeout(msp->smi_busy_wait, smi_is_done(msp),
- msecs_to_jiffies(100)))
- return -ETIMEDOUT;
+ if (!smi_is_done(msp)) {
+ wait_event_timeout(msp->smi_busy_wait, smi_is_done(msp),
+ msecs_to_jiffies(100));
+ if (!smi_is_done(msp))
+ return -ETIMEDOUT;
+ }

return 0;
}


2008-11-03 21:29:38

by David Miller

[permalink] [raw]
Subject: Re: [git patches] net driver fixes for 2.6.28-rc

From: Jeff Garzik <[email protected]>
Date: Mon, 3 Nov 2008 15:51:22 -0500

>
> Please pull from 'davem-fixes' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git davem-fixes
>
> to receive the following updates:

Pulled, thanks a lot Jeff.

2008-11-03 22:08:20

by Marcel Holtmann

[permalink] [raw]
Subject: Re: [git patches] net driver fixes for 2.6.28-rc

Hi Jeff,

> Please pull from 'davem-fixes' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
> davem-fixes
>
> to receive the following updates:
>
> drivers/net/Kconfig | 18 +++++++++++++++---
> drivers/net/fs_enet/fs_enet-main.c | 6 ++++--
> drivers/net/mv643xx_eth.c | 9 ++++++---
> 3 files changed, 25 insertions(+), 8 deletions(-)

are you also queuing patches for drivers/net/usb/hso.c, because the
current state of that driver is fully broken. It oopses and shows up
with a WLAN RFKILL switch instead of WWAN. Also it has some weird
disconnect race with the TTY layer. Some patches have been posted, but
seems that nobody has picked them up so far.

Regards

Marcel

2008-11-03 22:54:48

by David Miller

[permalink] [raw]
Subject: Re: [git patches] net driver fixes for 2.6.28-rc

From: Marcel Holtmann <[email protected]>
Date: Mon, 3 Nov 2008 23:07:58 +0100

> are you also queuing patches for drivers/net/usb/hso.c, because the
> current state of that driver is fully broken. It oopses and shows up
> with a WLAN RFKILL switch instead of WWAN. Also it has some weird
> disconnect race with the TTY layer. Some patches have been posted,
> but seems that nobody has picked them up so far.

The person submitting those patches is, frankly, creating a lot
of confusion.

He can't clone my tree or pull from it, then Greg KH tries to
take the fixes from him, and that doesn't go smoothly either.

2008-11-03 22:59:43

by Jeff Garzik

[permalink] [raw]
Subject: Re: [git patches] net driver fixes for 2.6.28-rc

Marcel Holtmann wrote:
> Hi Jeff,
>
>> Please pull from 'davem-fixes' branch of
>> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
>> davem-fixes
>>
>> to receive the following updates:
>>
>> drivers/net/Kconfig | 18 +++++++++++++++---
>> drivers/net/fs_enet/fs_enet-main.c | 6 ++++--
>> drivers/net/mv643xx_eth.c | 9 ++++++---
>> 3 files changed, 25 insertions(+), 8 deletions(-)
>
> are you also queuing patches for drivers/net/usb/hso.c, because the
> current state of that driver is fully broken. It oopses and shows up
> with a WLAN RFKILL switch instead of WWAN. Also it has some weird
> disconnect race with the TTY layer. Some patches have been posted, but
> seems that nobody has picked them up so far.

Last patch sent me was sent on 9/16 by Denis Joseph Barrow; I replied
and never received a response after that.

Patches welcome...

I don't see any hso patches on
http://patchwork.ozlabs.org/project/netdev/list/ nor in my inbox, so I'm
guessing that no one sent me or netdev any hso patches.

Jeff

2008-11-04 07:51:52

by Jonathan McDowell

[permalink] [raw]
Subject: Re: [git patches] net driver fixes for 2.6.28-rc


In article <[email protected]> (earth.lists.linux-kernel) you wrote:
> Marcel Holtmann wrote:
> > are you also queuing patches for drivers/net/usb/hso.c, because the
> > current state of that driver is fully broken. It oopses and shows up
> > with a WLAN RFKILL switch instead of WWAN. Also it has some weird
> > disconnect race with the TTY layer. Some patches have been posted, but
> > seems that nobody has picked them up so far.

> Last patch sent me was sent on 9/16 by Denis Joseph Barrow; I replied
> and never received a response after that.

> Patches welcome...

> I don't see any hso patches on
> http://patchwork.ozlabs.org/project/netdev/list/ nor in my inbox, so I'm
> guessing that no one sent me or netdev any hso patches.

I sent the below to netdev@, Greg K-H and Andrew Bird (the people listed
in hso.c). I can't see it in the netdev archives but it did hit lkml ok
at:

http://lkml.org/lkml/2008/10/30/92

A subsequent fix for the rfkill layer has also been sent (and that did
hit netdev ok and got acked), but this hso cleanup is still appropriate.

The WLAN/WWAN change is obviously a one line fix but I didn't see any
point sending a patch for it until I knew I was going to get some sort
of response about it; I can knock one up if that's helpful.

Original message:

[PATCH] Cleanup hso rfkill error handling

Yup, this appears to be the problem, thanks. I think &hso_net->net->dev
is more intuitive for the error message, so I've used that. I've also
added missing line endings on the error messages and set our local
rfkill structure element to NULL on failure so we don't try to call
rfkill_unregister on driver removal if we failed to register at all.

The patch below Works For Me (TM); the device is detected fine, can be
removed without problems and connects ok. I'll have a prod at why the
rfkill stuff isn't working next, but I believe this cleanup of the error
handling is appropriate no matter what the issue with registration is.

Signed-Off-By: Jonathan McDowell <[email protected]>

-----
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 1164c52..9d9622b 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -2184,19 +2184,20 @@ static void hso_create_rfkill(struct hso_device *hso_dev,
struct usb_interface *interface)
{
struct hso_net *hso_net = dev2net(hso_dev);
- struct device *dev = hso_dev->dev;
+ struct device *dev = &hso_net->net->dev;
char *rfkn;

hso_net->rfkill = rfkill_allocate(&interface_to_usbdev(interface)->dev,
RFKILL_TYPE_WLAN);
if (!hso_net->rfkill) {
- dev_err(dev, "%s - Out of memory", __func__);
+ dev_err(dev, "%s - Out of memory\n", __func__);
return;
}
rfkn = kzalloc(20, GFP_KERNEL);
if (!rfkn) {
rfkill_free(hso_net->rfkill);
- dev_err(dev, "%s - Out of memory", __func__);
+ hso_net->rfkill = NULL;
+ dev_err(dev, "%s - Out of memory\n", __func__);
return;
}
snprintf(rfkn, 20, "hso-%d",
@@ -2209,7 +2210,8 @@ static void hso_create_rfkill(struct hso_device *hso_dev,
kfree(rfkn);
hso_net->rfkill->name = NULL;
rfkill_free(hso_net->rfkill);
- dev_err(dev, "%s - Failed to register rfkill", __func__);
+ hso_net->rfkill = NULL;
+ dev_err(dev, "%s - Failed to register rfkill\n", __func__);
return;
}
}
-----

J.

--
Web [ 101 things you can't have too much of : 42 - Pepsi. ]
site: http:// [ ] Made by
http://www.earth.li/~noodles/ [ ] HuggieTag 0.0.23

2008-11-04 08:27:47

by Marcel Holtmann

[permalink] [raw]
Subject: Re: [git patches] net driver fixes for 2.6.28-rc

Hi Jonathan,

>>> are you also queuing patches for drivers/net/usb/hso.c, because the
>>> current state of that driver is fully broken. It oopses and shows up
>>> with a WLAN RFKILL switch instead of WWAN. Also it has some weird
>>> disconnect race with the TTY layer. Some patches have been posted,
>>> but
>>> seems that nobody has picked them up so far.
>
>> Last patch sent me was sent on 9/16 by Denis Joseph Barrow; I replied
>> and never received a response after that.
>
>> Patches welcome...
>
>> I don't see any hso patches on
>> http://patchwork.ozlabs.org/project/netdev/list/ nor in my inbox,
>> so I'm
>> guessing that no one sent me or netdev any hso patches.
>
> I sent the below to netdev@, Greg K-H and Andrew Bird (the people
> listed
> in hso.c). I can't see it in the netdev archives but it did hit lkml
> ok
> at:
>
> http://lkml.org/lkml/2008/10/30/92
>
> A subsequent fix for the rfkill layer has also been sent (and that did
> hit netdev ok and got acked), but this hso cleanup is still
> appropriate.

It is not only appropriate, it is needed, because otherwise the driver
is oopsing.

> The WLAN/WWAN change is obviously a one line fix but I didn't see any
> point sending a patch for it until I knew I was going to get some sort
> of response about it; I can knock one up if that's helpful.

Send a patch for it.

> Original message:
>
> [PATCH] Cleanup hso rfkill error handling
>
> Yup, this appears to be the problem, thanks. I think &hso_net->net-
> >dev
> is more intuitive for the error message, so I've used that. I've also
> added missing line endings on the error messages and set our local
> rfkill structure element to NULL on failure so we don't try to call
> rfkill_unregister on driver removal if we failed to register at all.
>
> The patch below Works For Me (TM); the device is detected fine, can be
> removed without problems and connects ok. I'll have a prod at why the
> rfkill stuff isn't working next, but I believe this cleanup of the
> error
> handling is appropriate no matter what the issue with registration is.
>
> Signed-Off-By: Jonathan McDowell <[email protected]>

I have this patch running now and it works. Without it the device is
not usable at all.

Acked-by: Marcel Holtmann <[email protected]>

Regards

Marcel

2008-11-06 05:43:30

by Jeff Garzik

[permalink] [raw]
Subject: Re: [git patches] net driver fixes for 2.6.28-rc

Jonathan McDowell wrote:
> In article <[email protected]> (earth.lists.linux-kernel) you wrote:
>> Marcel Holtmann wrote:
>>> are you also queuing patches for drivers/net/usb/hso.c, because the
>>> current state of that driver is fully broken. It oopses and shows up
>>> with a WLAN RFKILL switch instead of WWAN. Also it has some weird
>>> disconnect race with the TTY layer. Some patches have been posted, but
>>> seems that nobody has picked them up so far.
>
>> Last patch sent me was sent on 9/16 by Denis Joseph Barrow; I replied
>> and never received a response after that.
>
>> Patches welcome...
>
>> I don't see any hso patches on
>> http://patchwork.ozlabs.org/project/netdev/list/ nor in my inbox, so I'm
>> guessing that no one sent me or netdev any hso patches.
>
> I sent the below to netdev@, Greg K-H and Andrew Bird (the people listed
> in hso.c). I can't see it in the netdev archives but it did hit lkml ok
> at:
>
> http://lkml.org/lkml/2008/10/30/92
>
> A subsequent fix for the rfkill layer has also been sent (and that did
> hit netdev ok and got acked), but this hso cleanup is still appropriate.
>
> The WLAN/WWAN change is obviously a one line fix but I didn't see any
> point sending a patch for it until I knew I was going to get some sort
> of response about it; I can knock one up if that's helpful.
>
> Original message:
>
> [PATCH] Cleanup hso rfkill error handling
>
> Yup, this appears to be the problem, thanks. I think &hso_net->net->dev
> is more intuitive for the error message, so I've used that. I've also
> added missing line endings on the error messages and set our local
> rfkill structure element to NULL on failure so we don't try to call
> rfkill_unregister on driver removal if we failed to register at all.
>
> The patch below Works For Me (TM); the device is detected fine, can be
> removed without problems and connects ok. I'll have a prod at why the
> rfkill stuff isn't working next, but I believe this cleanup of the error
> handling is appropriate no matter what the issue with registration is.
>
> Signed-Off-By: Jonathan McDowell <[email protected]>
>
> -----
> diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
> index 1164c52..9d9622b 100644
> --- a/drivers/net/usb/hso.c
> +++ b/drivers/net/usb/hso.c
> @@ -2184,19 +2184,20 @@ static void hso_create_rfkill(struct hso_device *hso_dev,
> struct usb_interface *interface)
> {
> struct hso_net *hso_net = dev2net(hso_dev);
> - struct device *dev = hso_dev->dev;
> + struct device *dev = &hso_net->net->dev;
> char *rfkn;
>
> hso_net->rfkill = rfkill_allocate(&interface_to_usbdev(interface)->dev,
> RFKILL_TYPE_WLAN);
> if (!hso_net->rfkill) {
> - dev_err(dev, "%s - Out of memory", __func__);
> + dev_err(dev, "%s - Out of memory\n", __func__);
> return;
> }
> rfkn = kzalloc(20, GFP_KERNEL);
> if (!rfkn) {
> rfkill_free(hso_net->rfkill);
> - dev_err(dev, "%s - Out of memory", __func__);
> + hso_net->rfkill = NULL;
> + dev_err(dev, "%s - Out of memory\n", __func__);
> return;
> }
> snprintf(rfkn, 20, "hso-%d",
> @@ -2209,7 +2210,8 @@ static void hso_create_rfkill(struct hso_device *hso_dev,
> kfree(rfkn);
> hso_net->rfkill->name = NULL;
> rfkill_free(hso_net->rfkill);
> - dev_err(dev, "%s - Failed to register rfkill", __func__);
> + hso_net->rfkill = NULL;
> + dev_err(dev, "%s - Failed to register rfkill\n", __func__);
> return;

applied