* Re: PATCH 2.6.17-rc5 tulip free_irq() called too late
From: Grant Grundler @ 2006-06-08 17:01 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Grant Grundler, Andrew Morton, netdev, Val Henson
In-Reply-To: <44883778.8000209@pobox.com>
On Thu, Jun 08, 2006 at 10:43:04AM -0400, Jeff Garzik wrote:
...
> Perhaps cp_close() in 8139cp.c could be an example of a good ordering?
> It stops the chip, syncs irqs, frees irq, then frees [thus unmapping]
> the rings.
Here is a new patch that moves free_irq() into tulip_down().
The resulting code is structured the same as cp_close().
While I believe the code is correct, I'm not real happy
that tulip_up() and tulip_down() don't both deal with IRQs.
(ie not symetrical). Oh well, I can submit another patch
for that if Val doesn't want to wrangle that herself.
This is compile tested only.
I'll drop it on ia64/parisc servers later and retest.
thanks,
grant
Index: drivers/net/tulip/tulip_core.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/net/tulip/tulip_core.c,v
retrieving revision 1.35
diff -u -p -r1.35 tulip_core.c
--- drivers/net/tulip/tulip_core.c 23 Apr 2006 15:18:28 -0000 1.35
+++ drivers/net/tulip/tulip_core.c 8 Jun 2006 16:25:43 -0000
@@ -18,11 +18,11 @@
#define DRV_NAME "tulip"
#ifdef CONFIG_TULIP_NAPI
-#define DRV_VERSION "1.1.13-NAPI" /* Keep at least for test */
+#define DRV_VERSION "1.1.14-NAPI" /* Keep at least for test */
#else
-#define DRV_VERSION "1.1.13"
+#define DRV_VERSION "1.1.14"
#endif
-#define DRV_RELDATE "December 15, 2004"
+#define DRV_RELDATE "May 6, 2006"
#include <linux/module.h>
@@ -743,6 +745,11 @@ static void tulip_down (struct net_devic
/* Stop the Tx and Rx processes. */
tulip_stop_rxtx(tp);
+ spin_unlock_irqrestore (&tp->lock, flags);
+
+ synchronize_irq(dev->irq);
+ free_irq (dev->irq, dev);
+
/* prepare receive buffers */
tulip_refill_rx(dev);
@@ -752,7 +759,6 @@ static void tulip_down (struct net_devic
if (ioread32 (ioaddr + CSR6) != 0xffffffff)
tp->stats.rx_missed_errors += ioread32 (ioaddr + CSR8) & 0xffff;
- spin_unlock_irqrestore (&tp->lock, flags);
init_timer(&tp->timer);
tp->timer.data = (unsigned long)dev;
@@ -774,14 +780,13 @@ static int tulip_close (struct net_devic
int i;
netif_stop_queue (dev);
tulip_down (dev);
if (tulip_debug > 1)
printk (KERN_DEBUG "%s: Shutting down ethercard, status was %2.2x.\n",
dev->name, ioread32 (ioaddr + CSR5));
- free_irq (dev->irq, dev);
/* Free all the skbuffs in the Rx queue. */
for (i = 0; i < RX_RING_SIZE; i++) {
@@ -1750,7 +1757,6 @@ static int tulip_suspend (struct pci_dev
tulip_down(dev);
netif_device_detach(dev);
- free_irq(dev->irq, dev);
pci_save_state(pdev);
pci_disable_device(pdev);
^ permalink raw reply
* [PATCH RESEND] e100/e1000: fixes and pci error recovery
From: Auke Kok @ 2006-06-08 16:32 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linas Vepstas, Jesse Brandeburg, Auke Kok, Kok, Auke, NetDev
Jeff,
This is a resend of several earlier sent (and Acked) patches for e100 and
e1000. They are available on our git server and contain:
in branch upstream-fixes:
[1] e1000: fix irq sharing when running ethtool test
[2] e1000: remove risky prefetch on next_skb->data
against netdev-2.6#upstream-fixes e82b0f2cc21be905e504573483fa9542b15df96f
[ please note that patch 2 will need manual merging into #upstream ]
in branch upstream:
[3] e100: add PCI Error Recovery
[4] e1000: add PCI Error Recovery
against netdev-2.6#upstream 983f27d37d4fc72c252835cb2ee3103b360735a6
Please pull:
into #upstream-fixes:
git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-fixes
into #upstream:
git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream
Cheers,
Auke
Refs
[1] http://marc.theaimsgroup.com/?l=linux-netdev&m=114928689932374&w=2
[2] http://marc.theaimsgroup.com/?l=linux-netdev&m=114954878609885&w=2
[3] http://marc.theaimsgroup.com/?l=linux-netdev&m=114436228823926&w=2
[4] http://marc.theaimsgroup.com/?l=linux-pci&m=114325705604534&w=2
^ permalink raw reply
* Re: [PATCH 2/2] PHYLIB/gianfar: Use phy_ethtool_get_link() for get_link op
From: Nathaniel Case @ 2006-06-08 16:22 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andy Fleming, netdev, galak
In-Reply-To: <44884363.6080907@garzik.org>
This patch makes the gianfar ethtool code use phy_ethtool_get_link()
instead of ethtool_op_get_link().
Signed-off-by: Nate Case <ncase@xes-inc.com>
---
--- a/drivers/net/gianfar_ethtool.c 2006-06-05 11:27:19.000000000 -0500
+++ b/drivers/net/gianfar_ethtool.c 2006-06-04 19:31:01.000000000 -0500
@@ -228,6 +228,18 @@
buf[i] = gfar_read(&theregs[i]);
}
+static u32 gfar_get_link(struct net_device *dev)
+{
+ struct gfar_private *priv = netdev_priv(dev);
+ struct phy_device *phydev = priv->phydev;
+
+ if (NULL == phydev)
+ return 0;
+
+ return phy_ethtool_get_link(phydev);
+}
+
+
/* Convert microseconds to ethernet clock ticks, which changes
* depending on what speed the controller is running at */
static unsigned int gfar_usecs2ticks(struct gfar_private *priv, unsigned int usecs)
@@ -574,7 +578,7 @@
.get_drvinfo = gfar_gdrvinfo,
.get_regs_len = gfar_reglen,
.get_regs = gfar_get_regs,
- .get_link = ethtool_op_get_link,
+ .get_link = gfar_get_link,
.get_coalesce = gfar_gcoalesce,
.set_coalesce = gfar_scoalesce,
.get_ringparam = gfar_gringparam,
^ permalink raw reply
* Re: [PATCH 5/5] ehea: makefile and Kconfig
From: Randy.Dunlap @ 2006-06-08 16:21 UTC (permalink / raw)
To: Jan-Bernd Themann; +Cc: netdev, meder, raisch, themann, tklein
In-Reply-To: <4487F435.7090007@de.ibm.com>
On Thu, 08 Jun 2006 11:56:05 +0200 Jan-Bernd Themann wrote:
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
>
>
> drivers/net/ehea/Kconfig | 6 ++++++
> drivers/net/ehea/Makefile | 7 +++++++
> 2 files changed, 13 insertions(+)
>
>
>
> --- linux-2.6.16-rc5-orig/drivers/net/ehea/Makefile 1969-12-31 16:00:00.000000000 -0800
> +++ kernel/drivers/net/ehea/Makefile 2006-06-08 01:58:28.839212488 -0700
> @@ -0,0 +1,7 @@
> +#
> +# Makefile for the eHEA ethernet device driver for IBM eServer System p
> +#
> +
> +ehea_mod-objs = ehea_main.o ehea_phyp.o ehea_qmr.o ehea_ethtool.o ehea_phyp.o
> +obj-$(CONFIG_EHEA) += ehea_mod.o
> +
> --- linux-2.6.16-rc5-orig/drivers/net/ehea/Kconfig 1969-12-31 16:00:00.000000000 -0800
> +++ kernel/drivers/net/ehea/Kconfig 2006-06-08 01:58:28.842212032 -0700
> @@ -0,0 +1,6 @@
> +config EHEA
> + tristate "eHEA Ethernet support"
> + depends on IBMEBUS
> + ---help---
> + This driver supports the IBM pSeries ethernet adapter
> +
Hi,
Will you be modifying drivers/net/Makefile and drivers/net/Kconfig
to use these files?
And "help" text is normally indented (convention is 2 spaces)
since (from Documentation/kbuild/kconfig-language.txt):
The end of the help text is determined by
the indentation level, this means it ends at the first line which has
a smaller indentation than the first line of the help text.
---
~Randy
^ permalink raw reply
* Re: New tulip maintainer...
From: Grant Grundler @ 2006-06-08 16:06 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Val Henson, Grant Grundler, Andrew Morton, Netdev List
In-Reply-To: <44884528.2040804@garzik.org>
On Thu, Jun 08, 2006 at 11:41:28AM -0400, Jeff Garzik wrote:
> Now that we have a new tulip maintainer, perhaps a resend of the
> long-outstanding tulip phy patches could be resent?
All the tulip patches I have are archived here:
ftp://ftp.parisc-linux.org/patches/
Anything else tulip I've been involved with is available
via CVS from cvs.parisc-linux.org/linux-2.6/
Thibaut Varene has also committed his changes to that CVS.
thanks,
grant
^ permalink raw reply
* Re: [PATCH 2.6.17-rc6-mm1 ] net: RFC 3828-compliant UDP-Lite support
From: Gerrit Renker @ 2006-06-08 16:03 UTC (permalink / raw)
To: Alan Cox
Cc: davem, kuznet, pekkas, jmorris, yoshfuji, kaber, linux-kernel,
netdev
In-Reply-To: <1149778072.22124.6.camel@localhost.localdomain>
Quoting Alan Cox:
| Ar Iau, 2006-06-08 am 11:50 +0100, ysgrifennodd Gerrit Renker:
| > + UDP-Lite introduces a new socket type, the SOCK_LDGRAM (note the L) for
| > + lightweight, connection-less services. These are the socket options:
|
| This is not the intended use of the socket API when distinguishing
| between services. The socket() call has a protocol field that is usually
| unused and it exists precisely to disambiguate multiple protocols with
| the same generic behaviour but different properties.
|
| s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);
|
| is probably the right way to do this, keeping 0 "default" as before
| meaning IPPROTO_UDP
Understood. Please, anyone, disregard or un-apply the previous UDP-Lite patch.
A revised patch will be prepared and posted as soon as testing permits.
^ permalink raw reply
* [PATCH] s2io: netpoll support
From: Brian Haley @ 2006-06-08 16:01 UTC (permalink / raw)
To: netdev; +Cc: jgarzik
[-- Attachment #1: Type: text/plain, Size: 264 bytes --]
This adds netpoll support for things like netconsole/kgdboe to the s2io
10GbE driver.
This duplicates some code from s2io_poll() as I wanted to be
least-invasive, someone from Neterion might have other thoughts?
Signed-off-by: Brian Haley <brian.haley@hp.com>
[-- Attachment #2: s2io.netpoll.patch --]
[-- Type: text/x-patch, Size: 1831 bytes --]
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index 79208f4..c2c5f46 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -2575,6 +2575,53 @@ no_rx:
#endif
/**
+ * s2io_netpoll - Rx interrupt service handler for netpoll support
+ * @dev : pointer to the device structure.
+ * Description:
+ * Polling 'interrupt' - used by things like netconsole to send skbs
+ * without having to re-enable interrupts. It's not called while
+ * the interrupt routine is executing.
+ */
+
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void s2io_netpoll(struct net_device *dev)
+{
+ nic_t *nic = dev->priv;
+ mac_info_t *mac_control;
+ struct config_param *config;
+ XENA_dev_config_t __iomem *bar0 = nic->bar0;
+ u64 val64;
+ int i;
+
+ atomic_inc(&nic->isr_cnt);
+
+ /* Disable all interrupts */
+ en_dis_able_nic_intrs(nic, ENA_ALL_INTRS, DISABLE_INTRS);
+
+ mac_control = &nic->mac_control;
+ config = &nic->config;
+
+ val64 = readq(&bar0->rx_traffic_int);
+ writeq(val64, &bar0->rx_traffic_int);
+
+ for (i = 0; i < config->rx_ring_num; i++)
+ rx_intr_handler(&mac_control->rings[i]);
+
+ for (i = 0; i < config->rx_ring_num; i++) {
+ if (fill_rx_buffers(nic, i) == -ENOMEM) {
+ DBG_PRINT(ERR_DBG, "%s:Out of memory", dev->name);
+ DBG_PRINT(ERR_DBG, " in Rx Netpoll!!\n");
+ break;
+ }
+ }
+ /* Re-enable all interrupts */
+ en_dis_able_nic_intrs(nic, ENA_ALL_INTRS, ENABLE_INTRS);
+ atomic_dec(&nic->isr_cnt);
+ return;
+}
+#endif
+
+/**
* rx_intr_handler - Rx interrupt handler
* @nic: device private variable.
* Description:
@@ -6210,6 +6257,10 @@ Defaulting to INTA\n");
dev->weight = 32;
#endif
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ dev->poll_controller = s2io_netpoll;
+#endif
+
dev->features |= NETIF_F_SG | NETIF_F_IP_CSUM;
if (sp->high_dma_flag == TRUE)
dev->features |= NETIF_F_HIGHDMA;
^ permalink raw reply related
* Re: PATCH 2.6.17-rc5 tulip free_irq() called too late
From: Grant Grundler @ 2006-06-08 15:47 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Grant Grundler, Andrew Morton, netdev, Val Henson
In-Reply-To: <4488448C.8050504@pobox.com>
On Thu, Jun 08, 2006 at 11:38:52AM -0400, Jeff Garzik wrote:
> >Can we call free_irq() from tulip_down()?
>
> I'm sure you can answer that yourself. If it doesn't cause problems
> elsewhere, yes. Otherwise, no. :)
Yeah, well, I was hoping you would "Just Know" (tm). :)
Research takes time.
> Did you read the example I cited, cp_close() ?
Yes - after I sent the mail. It looks good to me too.
thanks,
grant
^ permalink raw reply
* Re: [PATCH] pcnet32 driver NAPI support
From: Lennart Sorensen @ 2006-06-08 15:44 UTC (permalink / raw)
To: Don Fry; +Cc: netdev
In-Reply-To: <20060607223245.GA13584@us.ibm.com>
On Wed, Jun 07, 2006 at 03:32:45PM -0700, Don Fry wrote:
> One other problem I ran into. I applied the patch but it will not
> compile because rl_active is never defined. I have worked around it but
Doh! I thought I cleaned up all my "weird code" from my own version.
Because of the platform I work with having 4 pcnet32 ports, and a slow
poke 266MHz geode, we can't handle full traffic load, so to keep the
system responsive to pause processing receives when we pass a certain
number of packets per second. rl_active is part of that. I meant to
remove all of it, apparently I didn't read every line of my patch
carefully enough. :(
Well at least this ought to clean up my work a bit.
Len Sorensen
^ permalink raw reply
* New tulip maintainer...
From: Jeff Garzik @ 2006-06-08 15:41 UTC (permalink / raw)
To: Val Henson, Grant Grundler, Andrew Morton; +Cc: Netdev List
Now that we have a new tulip maintainer, perhaps a resend of the
long-outstanding tulip phy patches could be resent?
With an active tulip maintainer, the "too-long mdelay" would hopefully
only exist temporarily -- with the proper fix being to move that code
into a kernel thread (workqueue?) long term.
Jeff
^ permalink raw reply
* Re: PATCH 2.6.17-rc5 tulip free_irq() called too late
From: Jeff Garzik @ 2006-06-08 15:38 UTC (permalink / raw)
To: Grant Grundler; +Cc: Andrew Morton, netdev, Val Henson
In-Reply-To: <20060608153235.GD8246@colo.lackof.org>
Grant Grundler wrote:
> Ok...I think I understand what you are driving at here.
> The case is when CPU vector is enabled and shared but
> one device _without_ an interrupt handler is registered
> is still yanking on the interrupt line. It will cause
> linux to disable the line since the IRQ isn't being handled.
Correct.
> Can we call free_irq() from tulip_down()?
I'm sure you can answer that yourself. If it doesn't cause problems
elsewhere, yes. Otherwise, no. :)
Did you read the example I cited, cp_close() ?
Jeff
^ permalink raw reply
* Re: PATCH 2.6.17-rc5 tulip free_irq() called too late
From: Grant Grundler @ 2006-06-08 15:36 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Grant Grundler, Andrew Morton, netdev, Val Henson
In-Reply-To: <44884317.8070601@pobox.com>
On Thu, Jun 08, 2006 at 11:32:39AM -0400, Jeff Garzik wrote:
> >The chip IRQ gets turned off in tulip_down().
> >It won't be screaming for very long.
>
> Then you admit that you add a race.
Yes - I realized that after I hit <send> :(
...
> >In the shared IRQ case, I expect free_irq() to unlink this instance
> >of the tulip interrupt handler from the CPU vector list. If that
>
> Irrelevant -- that doesn't stop the tulip hardware from raising the irq,
> nor stop the system from attempting to deliver it [in all cases]. In
> the shared interrupt case, that means that another driver's irq handler
> will be called for an event tulip hardware raised.
*nod*
thanks,
grant
^ permalink raw reply
* Re: [PATCH 2/2] PHYLIB/gianfar: Use phy_ethtool_get_link() for get_link op
From: Jeff Garzik @ 2006-06-08 15:33 UTC (permalink / raw)
To: Nathaniel Case; +Cc: Andy Fleming, netdev, galak
In-Reply-To: <1149779939.30343.7.camel@localhost.localdomain>
Nathaniel Case wrote:
> On Thu, 2006-06-08 at 10:58 -0400, Jeff Garzik wrote:
>>> +static u32 gfar_get_link(struct net_device *dev)
>>> +{
>>> + struct gfar_private *priv = netdev_priv(dev);
>>> + struct phy_device *phydev = priv->phydev;
>>> +
>>> + if (NULL == phydev)
>>> + return -ENODEV;
>> NAK, return code obviously wrong
>
> Thanks. I think we can just return 0 for that case. Updated patch
> follows.
>
> Signed-off-by: Nate Case <ncase@xes-inc.com>
Sigh. See rule #6: http://linux.yyz.us/patch-format.html
You excised the patch description, which means your patch can no longer
be applied correctly by scripts.
Jeff
^ permalink raw reply
* Re: PATCH 2.6.17-rc5 tulip free_irq() called too late
From: Jeff Garzik @ 2006-06-08 15:32 UTC (permalink / raw)
To: Grant Grundler; +Cc: Andrew Morton, netdev, Val Henson
In-Reply-To: <20060608152221.GC8246@colo.lackof.org>
Grant Grundler wrote:
> On Thu, Jun 08, 2006 at 10:43:04AM -0400, Jeff Garzik wrote:
>> (CC'ing our newly minted tulip maintainer, Val)
>
> Excellent!
> Has MAINTAINERS file been updated? :)
It should be updated, yes.
>> Calling free_irq() while the chip is still active is just a bad idea,
>> because the chip could raise an interrupt, creating a
>> screaming-interrupts situation. Consider especially the case of shared
>> interrupts here, as a concrete example of how this won't work.
>
> The chip IRQ gets turned off in tulip_down().
> It won't be screaming for very long.
Then you admit that you add a race.
> No one will hear it screaming and no one will care.
False. Easy counter-example already provided: Shared interrupts.
For some IRQ architectures, even without shared interrupts, this could
easily trigger the kernel's screaming-irq detection code.
> Secondly, if tulip has a problem with shared IRQs, it's already there.
> We would have called free_irq() anyway - just a bit later.
Yes... AFTER we told the chip to stop DMA'ing, and delivering interrupts.
I'm frankly surprised you don't see the obvious, natural ordering. You
stop the hardware from wanting to deliver interrupts, before
unregistering the irq handler. IOW you turn out the lights, before
leaving the room.
> In the shared IRQ case, I expect free_irq() to unlink this instance
> of the tulip interrupt handler from the CPU vector list. If that
Irrelevant -- that doesn't stop the tulip hardware from raising the irq,
nor stop the system from attempting to deliver it [in all cases]. In
the shared interrupt case, that means that another driver's irq handler
will be called for an event tulip hardware raised.
Jeff
^ permalink raw reply
* Re: PATCH 2.6.17-rc5 tulip free_irq() called too late
From: Grant Grundler @ 2006-06-08 15:32 UTC (permalink / raw)
To: Grant Grundler; +Cc: Jeff Garzik, Andrew Morton, netdev, Val Henson
In-Reply-To: <20060608152221.GC8246@colo.lackof.org>
On Thu, Jun 08, 2006 at 09:22:21AM -0600, Grant Grundler wrote:
> > Perhaps cp_close() in 8139cp.c could be an example of a good ordering?
> > It stops the chip, syncs irqs, frees irq, then frees [thus unmapping]
> > the rings.
>
> Sorry, I don't see how it matters if we disable chip IRQ first
> or unlink from CPU IRQ list first. Does it?
Ok...I think I understand what you are driving at here.
The case is when CPU vector is enabled and shared but
one device _without_ an interrupt handler is registered
is still yanking on the interrupt line. It will cause
linux to disable the line since the IRQ isn't being handled.
This is only possible in the shared IRQ case.
Can we call free_irq() from tulip_down()?
I have the feeling this is going to cause alot more code movement.
thanks,
grant
^ permalink raw reply
* Re: PATCH 2.6.17-rc5 tulip free_irq() called too late
From: Grant Grundler @ 2006-06-08 15:22 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Grant Grundler, Andrew Morton, netdev, Val Henson
In-Reply-To: <44883778.8000209@pobox.com>
On Thu, Jun 08, 2006 at 10:43:04AM -0400, Jeff Garzik wrote:
> (CC'ing our newly minted tulip maintainer, Val)
Excellent!
Has MAINTAINERS file been updated? :)
...
> NAK. This is a band-aid, and one that creates new problems even as it
> attempts to solve problems.
You failed to demonstrate that below. Any other objections?
> Calling free_irq() while the chip is still active is just a bad idea,
> because the chip could raise an interrupt, creating a
> screaming-interrupts situation. Consider especially the case of shared
> interrupts here, as a concrete example of how this won't work.
The chip IRQ gets turned off in tulip_down().
It won't be screaming for very long.
No one will hear it screaming and no one will care.
The decision to bring down the NIC was already made.
Secondly, if tulip has a problem with shared IRQs, it's already there.
We would have called free_irq() anyway - just a bit later.
In the shared IRQ case, I expect free_irq() to unlink this instance
of the tulip interrupt handler from the CPU vector list. If that
doesn't happen, I could consider that an arch specific bug,
not a tulip driver bug.
> Perhaps cp_close() in 8139cp.c could be an example of a good ordering?
> It stops the chip, syncs irqs, frees irq, then frees [thus unmapping]
> the rings.
Sorry, I don't see how it matters if we disable chip IRQ first
or unlink from CPU IRQ list first. Does it?
thanks,
grant
^ permalink raw reply
* Re: [PATCH 2/2] PHYLIB/gianfar: Use phy_ethtool_get_link() for get_link op
From: Nathaniel Case @ 2006-06-08 15:18 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andy Fleming, netdev, galak
In-Reply-To: <44883B0E.5090802@garzik.org>
On Thu, 2006-06-08 at 10:58 -0400, Jeff Garzik wrote:
> > +static u32 gfar_get_link(struct net_device *dev)
> > +{
> > + struct gfar_private *priv = netdev_priv(dev);
> > + struct phy_device *phydev = priv->phydev;
> > +
> > + if (NULL == phydev)
> > + return -ENODEV;
>
> NAK, return code obviously wrong
Thanks. I think we can just return 0 for that case. Updated patch
follows.
Signed-off-by: Nate Case <ncase@xes-inc.com>
--- a/drivers/net/gianfar_ethtool.c 2006-06-05 11:27:19.000000000 -0500
+++ b/drivers/net/gianfar_ethtool.c 2006-06-04 19:31:01.000000000 -0500
@@ -228,6 +228,18 @@
buf[i] = gfar_read(&theregs[i]);
}
+static u32 gfar_get_link(struct net_device *dev)
+{
+ struct gfar_private *priv = netdev_priv(dev);
+ struct phy_device *phydev = priv->phydev;
+
+ if (NULL == phydev)
+ return 0;
+
+ return phy_ethtool_get_link(phydev);
+}
+
+
/* Convert microseconds to ethernet clock ticks, which changes
* depending on what speed the controller is running at */
static unsigned int gfar_usecs2ticks(struct gfar_private *priv, unsigned int usecs)
@@ -574,7 +578,7 @@
.get_drvinfo = gfar_gdrvinfo,
.get_regs_len = gfar_reglen,
.get_regs = gfar_get_regs,
- .get_link = ethtool_op_get_link,
+ .get_link = gfar_get_link,
.get_coalesce = gfar_gcoalesce,
.set_coalesce = gfar_scoalesce,
.get_ringparam = gfar_gringparam,
^ permalink raw reply
* Re: [PATCH 1/9] NetXen 1G/10G ethernet driver patch with corrections
From: Pradeep Dalvi @ 2006-06-08 14:55 UTC (permalink / raw)
To: Andi Kleen
Cc: Linsys Contractor Amit S. Kale, Kernel Netdev Mailing List,
Sanjeev Jorapur, UNM Project Staff
In-Reply-To: <200606071149.51879.ak@suse.de>
diff -u linux-2.6.16.20/drivers/net/netxen/netxen_nic_ethtool.c
linux-2.6.16.20/drivers/net/netxen/netxen_nic_ethtool.c
--- linux-2.6.16.20/drivers/net/netxen/netxen_nic_ethtool.c 2006-06-06
06:58:11.000000000 -0700
+++ linux-2.6.16.20/drivers/net/netxen/netxen_nic_ethtool.c 2006-06-08
06:52:09.000000000 -0700
@@ -240,6 +240,95 @@
return NETXEN_NIC_REGS_LEN;
}
+struct netxen_niu_regs {
+ netxen_crbword_t reg[NETXEN_NIC_REGS_COUNT];
+};
+
+static struct netxen_niu_regs niu_registers[] = {
+ {
+ /* GB Mode */
+ {
+ NETXEN_NIU_GB_SERDES_RESET,
+ NETXEN_NIU_GB0_MII_MODE,
+ NETXEN_NIU_GB1_MII_MODE,
+ NETXEN_NIU_GB2_MII_MODE,
+ NETXEN_NIU_GB3_MII_MODE,
+ NETXEN_NIU_GB0_GMII_MODE,
+ NETXEN_NIU_GB1_GMII_MODE,
+ NETXEN_NIU_GB2_GMII_MODE,
+ NETXEN_NIU_GB3_GMII_MODE,
+ NETXEN_NIU_REMOTE_LOOPBACK,
+ NETXEN_NIU_GB0_HALF_DUPLEX,
+ NETXEN_NIU_GB1_HALF_DUPLEX,
+ NETXEN_NIU_RESET_SYS_FIFOS,
+ NETXEN_NIU_GB_CRC_DROP,
+ NETXEN_NIU_GB_DROP_WRONGADDR,
+ NETXEN_NIU_TEST_MUX_CTL,
+
+ NETXEN_NIU_GB_MAC_CONFIG_0(0),
+ NETXEN_NIU_GB_MAC_CONFIG_1(0),
+ NETXEN_NIU_GB_HALF_DUPLEX_CTRL(0),
+ NETXEN_NIU_GB_MAX_FRAME_SIZE(0),
+ NETXEN_NIU_GB_TEST_REG(0),
+ NETXEN_NIU_GB_MII_MGMT_CONFIG(0),
+ NETXEN_NIU_GB_MII_MGMT_COMMAND(0),
+ NETXEN_NIU_GB_MII_MGMT_ADDR(0),
+ NETXEN_NIU_GB_MII_MGMT_CTRL(0),
+ NETXEN_NIU_GB_MII_MGMT_STATUS(0),
+ NETXEN_NIU_GB_MII_MGMT_INDICATE(0),
+ NETXEN_NIU_GB_INTERFACE_CTRL(0),
+ NETXEN_NIU_GB_INTERFACE_STATUS(0),
+ NETXEN_NIU_GB_STATION_ADDR_0(0),
+ NETXEN_NIU_GB_STATION_ADDR_1(0),
+ -1,
+ }
+ },
+ {
+ /* XG Mode */
+ {
+ NETXEN_NIU_XG_SINGLE_TERM,
+ NETXEN_NIU_XG_DRIVE_HI,
+ NETXEN_NIU_XG_DRIVE_LO,
+ NETXEN_NIU_XG_DTX,
+ NETXEN_NIU_XG_DEQ,
+ NETXEN_NIU_XG_WORD_ALIGN,
+ NETXEN_NIU_XG_RESET,
+ NETXEN_NIU_XG_POWER_DOWN,
+ NETXEN_NIU_XG_RESET_PLL,
+ NETXEN_NIU_XG_SERDES_LOOPBACK,
+ NETXEN_NIU_XG_DO_BYTE_ALIGN,
+ NETXEN_NIU_XG_TX_ENABLE,
+ NETXEN_NIU_XG_RX_ENABLE,
+ NETXEN_NIU_XG_STATUS,
+ NETXEN_NIU_XG_PAUSE_THRESHOLD,
+ NETXEN_NIU_XGE_CONFIG_0,
+ NETXEN_NIU_XGE_CONFIG_1,
+ NETXEN_NIU_XGE_IPG,
+ NETXEN_NIU_XGE_STATION_ADDR_0_HI,
+ NETXEN_NIU_XGE_STATION_ADDR_0_1,
+ NETXEN_NIU_XGE_STATION_ADDR_1_LO,
+ NETXEN_NIU_XGE_STATUS,
+ NETXEN_NIU_XGE_MAX_FRAME_SIZE,
+ NETXEN_NIU_XGE_PAUSE_FRAME_VALUE,
+ NETXEN_NIU_XGE_TX_BYTE_CNT,
+ NETXEN_NIU_XGE_TX_FRAME_CNT,
+ NETXEN_NIU_XGE_RX_BYTE_CNT,
+ NETXEN_NIU_XGE_RX_FRAME_CNT,
+ NETXEN_NIU_XGE_AGGR_ERROR_CNT,
+ NETXEN_NIU_XGE_MULTICAST_FRAME_CNT,
+ NETXEN_NIU_XGE_UNICAST_FRAME_CNT,
+ NETXEN_NIU_XGE_CRC_ERROR_CNT,
+ NETXEN_NIU_XGE_OVERSIZE_FRAME_ERR,
+ NETXEN_NIU_XGE_UNDERSIZE_FRAME_ERR,
+ NETXEN_NIU_XGE_LOCAL_ERROR_CNT,
+ NETXEN_NIU_XGE_REMOTE_ERROR_CNT,
+ NETXEN_NIU_XGE_CONTROL_CHAR_CNT,
+ NETXEN_NIU_XGE_PAUSE_FRAME_CNT,
+ -1,
+ }
+ }
+};
+
static void
netxen_nic_get_regs(struct net_device *dev, struct ethtool_regs *regs,
void *p)
{
@@ -248,6 +337,7 @@
netxen_crbword_t mode, *regs_buff = p;
unsigned long flags;
void *addr;
+ int i, window;
memset(p, 0, NETXEN_NIC_REGS_LEN);
regs->version = (1 << 24) | (adapter->ahw.revision_id << 16) |
@@ -260,176 +350,18 @@
/* Common registers to all the modes */
NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_STRAP_VALUE_SAVE_HIGHER,
®s_buff[2]);
- switch (mode) {
- case 4:{ /* XGB Mode */
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_SINGLE_TERM,
- ®s_buff[3]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_DRIVE_HI,
- ®s_buff[4]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_DRIVE_LO,
- ®s_buff[5]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_DTX,
- ®s_buff[6]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_DEQ,
- ®s_buff[7]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_WORD_ALIGN,
- ®s_buff[8]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_RESET,
- ®s_buff[9]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_POWER_DOWN,
- ®s_buff[10]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_RESET_PLL,
- ®s_buff[11]);
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_XG_SERDES_LOOPBACK, ®s_buff[12]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_DO_BYTE_ALIGN,
- ®s_buff[13]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_TX_ENABLE,
- ®s_buff[14]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_RX_ENABLE,
- ®s_buff[15]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_STATUS,
- ®s_buff[16]);
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_XG_PAUSE_THRESHOLD, ®s_buff[17]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XGE_CONFIG_0,
- ®s_buff[18]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XGE_CONFIG_1,
- ®s_buff[19]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XGE_IPG,
- ®s_buff[20]);
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_XGE_STATION_ADDR_0_HI, ®s_buff[21]);
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_XGE_STATION_ADDR_0_1, ®s_buff[22]);
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_XGE_STATION_ADDR_1_LO, ®s_buff[23]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XGE_STATUS,
- ®s_buff[24]);
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_XGE_MAX_FRAME_SIZE, ®s_buff[25]);
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_XGE_PAUSE_FRAME_VALUE, ®s_buff[26]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XGE_TX_BYTE_CNT,
- ®s_buff[27]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XGE_TX_FRAME_CNT,
- ®s_buff[28]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XGE_RX_BYTE_CNT,
- ®s_buff[29]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XGE_RX_FRAME_CNT,
- ®s_buff[30]);
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_XGE_AGGR_ERROR_CNT, ®s_buff[31]);
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_XGE_MULTICAST_FRAME_CNT,
- ®s_buff[32]);
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_XGE_UNICAST_FRAME_CNT, ®s_buff[33]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XGE_CRC_ERROR_CNT,
- ®s_buff[34]);
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_XGE_OVERSIZE_FRAME_ERR, ®s_buff[35]);
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_XGE_UNDERSIZE_FRAME_ERR,
- ®s_buff[36]);
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_XGE_LOCAL_ERROR_CNT, ®s_buff[37]);
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_XGE_REMOTE_ERROR_CNT, ®s_buff[38]);
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_XGE_CONTROL_CHAR_CNT, ®s_buff[39]);
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_XGE_PAUSE_FRAME_CNT, ®s_buff[40]);
- break;
- }
+ /* GB/XGB Mode */
+ mode = (mode/2) - 1;
+ window = 0;
+ if(mode <= 1) {
+ for ( i = 3; niu_registers[mode].reg[i - 3] != -1; i++) {
+ /* GB: port specific registers */
+ if(mode == 0 && i >= 19)
+ window = port->portnum * 0x10000;
- case 2:{ /* GB Mode */
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB_SERDES_RESET,
- ®s_buff[3]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB0_MII_MODE,
- ®s_buff[4]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB1_MII_MODE,
- ®s_buff[5]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB2_MII_MODE,
- ®s_buff[6]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB3_MII_MODE,
- ®s_buff[7]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB0_GMII_MODE,
- ®s_buff[8]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB1_GMII_MODE,
- ®s_buff[9]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB2_GMII_MODE,
- ®s_buff[10]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB3_GMII_MODE,
- ®s_buff[11]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_REMOTE_LOOPBACK,
- ®s_buff[12]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB0_HALF_DUPLEX,
- ®s_buff[13]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB1_HALF_DUPLEX,
- ®s_buff[14]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_RESET_SYS_FIFOS,
- ®s_buff[15]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB_CRC_DROP,
- ®s_buff[16]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB_DROP_WRONGADDR,
- ®s_buff[17]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_TEST_MUX_CTL,
- ®s_buff[18]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB_MAC_CONFIG_0
- (port->portnum),
- ®s_buff[19]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB_MAC_CONFIG_1
- (port->portnum),
- ®s_buff[20]);
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_GB_HALF_DUPLEX_CTRL(port->portnum),
- ®s_buff[21]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB_MAX_FRAME_SIZE
- (port->portnum),
- ®s_buff[22]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB_TEST_REG
- (port->portnum),
- ®s_buff[23]);
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB_MII_MGMT_CONFIG
- (port->portnum),
- ®s_buff[24]);
NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_GB_MII_MGMT_COMMAND(port->portnum),
- ®s_buff[25]);
-
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB_MII_MGMT_ADDR
- (port->portnum),
- ®s_buff[26]);
-
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB_MII_MGMT_CTRL
- (port->portnum),
- ®s_buff[27]);
-
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB_MII_MGMT_STATUS
- (port->portnum),
- ®s_buff[28]);
-
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_GB_MII_MGMT_INDICATE(port->portnum),
- ®s_buff[29]);
-
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB_INTERFACE_CTRL
- (port->portnum),
- ®s_buff[30]);
-
- NETXEN_NIC_LOCKED_READ_REG
- (NETXEN_NIU_GB_INTERFACE_STATUS(port->portnum),
- ®s_buff[31]);
-
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB_STATION_ADDR_0
- (port->portnum),
- ®s_buff[32]);
-
- NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_GB_STATION_ADDR_1
- (port->portnum),
- ®s_buff[33]);
- break;
+ (niu_registers[mode].reg[i - 3] + window,
+ ®s_buff[i]);
}
}
write_unlock_irqrestore(&adapter->adapter_lock, flags);
On Wed, 2006-06-07 at 11:49 +0200, Andi Kleen wrote:
> On Wednesday 07 June 2006 11:39, Linsys Contractor Amit S. Kale wrote:
>
> > + switch (mode) {
>
> ... You could save a lot of code by using a table and a loop over the registers.
>
>
> > + case 4:{ /* XGB Mode */
> > + NETXEN_NIC_LOCKED_READ_REG(NETXEN_NIU_XG_SINGLE_TERM,
> > + ®s_buff[3]);
>
>
> -Andi
>
>
--
pradeep
^ permalink raw reply
* Re: [PATCH 2/2] PHYLIB/gianfar: Use phy_ethtool_get_link() for get_link op
From: Jeff Garzik @ 2006-06-08 14:58 UTC (permalink / raw)
To: Nathaniel Case; +Cc: Andy Fleming, netdev, galak
In-Reply-To: <1149551334.10700.48.camel@localhost.localdomain>
Nathaniel Case wrote:
> This patch makes the gianfar ethtool code use phy_ethtool_get_link() instead of
> ethtool_op_get_link().
>
> Patch depends on previous one (1/2).
>
> Signed-off-by: Nate Case <ncase@xes-inc.com>
>
> ---
>
> --- a/drivers/net/gianfar_ethtool.c 2006-06-05 11:27:19.000000000 -0500
> +++ b/drivers/net/gianfar_ethtool.c 2006-06-04 19:31:01.000000000 -0500
> @@ -228,6 +228,18 @@
> buf[i] = gfar_read(&theregs[i]);
> }
>
> +static u32 gfar_get_link(struct net_device *dev)
> +{
> + struct gfar_private *priv = netdev_priv(dev);
> + struct phy_device *phydev = priv->phydev;
> +
> + if (NULL == phydev)
> + return -ENODEV;
NAK, return code obviously wrong
^ permalink raw reply
* Re: EHEA: Is there a size limit below 80K for patches?
From: Jeff Garzik @ 2006-06-08 14:48 UTC (permalink / raw)
To: Christoph Raisch
Cc: Heiko J Schick, Jan-Bernd Themann, Marcus Eder, netdev, ossthema,
Thomas OS Klein
In-Reply-To: <OF56CA8BB9.67AC7182-ONC1257187.003F6F35-C1257187.00430AFF@de.ibm.com>
Christoph Raisch wrote:
> well, now I'm confused...
> 2 People, two opinions....
>
>
> Here's a URL for a complete tarball, "sharing" the download location with
> our other driver.
> http://prdownloads.sourceforge.net/ibmehcad/ehea_EHEA_0002.tgz
>
> We're waiting for a sourceforge project now since 9 days to put out a tgz,
> and it looks like many other people get upset right now by their response
> time.
>
> So what's the "right"/preferred way to proceed?
Patches and new drivers should always go to the mailing list......
except for the case where they are too big to be posted to the mailing
list. For that special case, a URL to a patch should be posted.
Jeff
^ permalink raw reply
* PATCH to correct dump of WPA IE
From: Larry Finger @ 2006-06-08 14:47 UTC (permalink / raw)
To: netdev, John Linville
In net/ieee80211/softmac/ieee80211softmac_wx.c, there is a bug that prints extended sign information
whenever the byte value exceeds 0x7f. The following patch changes the printk to use a u8 cast to
limit the output to 2 digits. This bug was first noticed by Dan Williams <dcbw@redhat.com>. This
patch applies to the current master branch of the Linville tree.
Signed-Off-By: Larry Finger <Larry.Finger@lwfinger.net>
diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c b/net/ieee80211/softmac/ieee80211softmac_wx.c
index 27edb2b..55c5c26 100644
--- a/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -388,7 +388,7 @@ ieee80211softmac_wx_set_genie(struct net
memcpy(mac->wpa.IE, extra, wrqu->data.length);
dprintk(KERN_INFO PFX "generic IE set to ");
for (i=0;i<wrqu->data.length;i++)
- dprintk("%.2x", mac->wpa.IE[i]);
+ dprintk("%.2x", (u8)mac->wpa.IE[i]);
dprintk("\n");
mac->wpa.IElen = wrqu->data.length;
} else {
^ permalink raw reply related
* Re: PATCH 2.6.17-rc5 tulip free_irq() called too late
From: Jeff Garzik @ 2006-06-08 14:43 UTC (permalink / raw)
To: Grant Grundler, Andrew Morton; +Cc: netdev, Val Henson
In-Reply-To: <20060531195234.GA4967@colo.lackof.org>
(CC'ing our newly minted tulip maintainer, Val)
Grant Grundler wrote:
> Jeff,
> SLES10 testing exposed an MCA that was confirmed to be a DMA IO TLB miss.
> This means tulip device was attempting to DMA to memory that was already
> unmapped. The test was crashing in the "ifconfig down" step when a 4-port
> tulip card was under this work load:
>
> while :
> do
> ifconfig eth24 up
> ifconfig eth25 up
> ifconfig eth26 up
> ifconfig eth27 up
> # Pound both interfaces with ethtool
> for i in `seq 1000`
> do
> ethtool eth24 &>/dev/null
> ethtool eth25 &>/dev/null
> ethtool eth26 &>/dev/null
> ethtool eth27 &>/dev/null
> done
>
> # Bring interfaces down
> echo ifconfig $nic1 down
> ifconfig eth24 down
> ifconfig eth25 down
> ifconfig eth26 down
> ifconfig eth27 down
>
> sleep 5
> done
>
>
> [ And yes, I know tulip doesn't support ethtool. Don't ask.
> It's still a sore point at the moment. Just consider it
> a delay loop or use "sleep 5" instead. ]
>
> The real "network load" comes from another box(en) running 4 instances
> of "ping -f -s 1450 192.168.x.y" where "x.y" is the subnet/IP of eth24-27.
> The parisc and ia64 machines will crash in minutes.
>
> I believe the problem is a race condition between an interrupt coming
> in and the tulip_down() code path. Moving the "free_irq()" to before
> tulip_down() call fixes the problem. I've been able to run the above
> test for several hours now.
NAK. This is a band-aid, and one that creates new problems even as it
attempts to solve problems.
Calling free_irq() while the chip is still active is just a bad idea,
because the chip could raise an interrupt, creating a
screaming-interrupts situation. Consider especially the case of shared
interrupts here, as a concrete example of how this won't work.
Perhaps cp_close() in 8139cp.c could be an example of a good ordering?
It stops the chip, syncs irqs, frees irq, then frees [thus unmapping]
the rings.
Jeff
^ permalink raw reply
* Re: [PATCH 2.6.17-rc6-mm1 ] net: RFC 3828-compliant UDP-Lite support
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-06-08 14:38 UTC (permalink / raw)
To: alan
Cc: gerrit, davem, kuznet, pekkas, jmorris, kaber, linux-kernel,
netdev, yoshfuji
In-Reply-To: <1149778072.22124.6.camel@localhost.localdomain>
In article <1149778072.22124.6.camel@localhost.localdomain> (at Thu, 08 Jun 2006 15:47:52 +0100), Alan Cox <alan@lxorguk.ukuu.org.uk> says:
> Ar Iau, 2006-06-08 am 11:50 +0100, ysgrifennodd Gerrit Renker:
> > + UDP-Lite introduces a new socket type, the SOCK_LDGRAM (note the L) for
> > + lightweight, connection-less services. These are the socket options:
:
> s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);
>
> is probably the right way to do this, keeping 0 "default" as before
> meaning IPPROTO_UDP
I do think so, too.
--yoshfuji
^ permalink raw reply
* Re: [PATCH 2.6.17-rc6-mm1 ] net: RFC 3828-compliant UDP-Lite support
From: Alan Cox @ 2006-06-08 14:47 UTC (permalink / raw)
To: Gerrit Renker
Cc: davem, kuznet, pekkas, jmorris, yoshfuji, kaber, linux-kernel,
netdev
In-Reply-To: <200606081150.34018@this-message-has-been-logged>
Ar Iau, 2006-06-08 am 11:50 +0100, ysgrifennodd Gerrit Renker:
> + UDP-Lite introduces a new socket type, the SOCK_LDGRAM (note the L) for
> + lightweight, connection-less services. These are the socket options:
This is not the intended use of the socket API when distinguishing
between services. The socket() call has a protocol field that is usually
unused and it exists precisely to disambiguate multiple protocols with
the same generic behaviour but different properties.
s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);
is probably the right way to do this, keeping 0 "default" as before
meaning IPPROTO_UDP
^ permalink raw reply
* [PATCH] myri10ge update
From: Brice Goglin @ 2006-06-08 14:25 UTC (permalink / raw)
To: netdev; +Cc: akpm
The following patch updates the myri10ge to 1.0.0, with the following changes:
* Switch to dma_alloc_coherent API.
* Avoid PCI burst when writing the firmware on chipset with unaligned completions.
* Use ethtool_op_set_tx_hw_csum instead of ethtool_op_set_tx_csum.
* Include linux/dma-mapping.h to bring DMA_32/64BIT_MASK on all architectures
(was missing at least on alpha).
* Some typo and warning fixes.
Please apply.
Note that Andrew's myri10ge-alpha-build-fix.patch would conflict,
but it does not seem to have been merged in netdev-2.6 anyway.
Thanks.
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Andrew J. Gallatin <gallatin@myri.com>
drivers/net/myri10ge/myri10ge.c | 57 +++++++++++++++++++-----------
1 file changed, 37 insertions(+), 20 deletions(-)
diff -urNp linux-mm.old/drivers/net/myri10ge/myri10ge.c linux-mm/drivers/net/myri10ge/myri10ge.c
--- linux-mm.old/drivers/net/myri10ge/myri10ge.c 2006-06-04 08:51:00.000000000 -0400
+++ linux-mm/drivers/net/myri10ge/myri10ge.c 2006-06-07 11:28:20.000000000 -0400
@@ -44,6 +44,7 @@
#include <linux/string.h>
#include <linux/module.h>
#include <linux/pci.h>
+#include <linux/dma-mapping.h>
#include <linux/etherdevice.h>
#include <linux/if_ether.h>
#include <linux/if_vlan.h>
@@ -62,7 +63,6 @@
#include <net/checksum.h>
#include <asm/byteorder.h>
#include <asm/io.h>
-#include <asm/pci.h>
#include <asm/processor.h>
#ifdef CONFIG_MTRR
#include <asm/mtrr.h>
@@ -71,7 +71,7 @@
#include "myri10ge_mcp.h"
#include "myri10ge_mcp_gen_header.h"
-#define MYRI10GE_VERSION_STR "0.9.0"
+#define MYRI10GE_VERSION_STR "1.0.0"
MODULE_DESCRIPTION("Myricom 10G driver (10GbE)");
MODULE_AUTHOR("Maintainer: help@myri.com");
@@ -480,7 +478,19 @@ static int myri10ge_load_hotplug_firmwar
goto abort_with_fw;
crc = crc32(~0, fw->data, fw->size);
- memcpy_toio(mgp->sram + MYRI10GE_FW_OFFSET, fw->data, fw->size);
+ if (mgp->tx.boundary == 2048) {
+ /* Avoid PCI burst on chipset with unaligned completions. */
+ int i;
+ __iomem u32 *ptr = (__iomem u32 *) (mgp->sram +
+ MYRI10GE_FW_OFFSET);
+ for (i = 0; i < fw->size / 4; i++) {
+ __raw_writel(((u32 *) fw->data)[i], ptr + i);
+ wmb();
+ }
+ } else {
+ myri10ge_pio_copy(mgp->sram + MYRI10GE_FW_OFFSET, fw->data,
+ fw->size);
+ }
/* corruption checking is good for parity recovery and buggy chipset */
memcpy_fromio(fw->data, mgp->sram + MYRI10GE_FW_OFFSET, fw->size);
reread_crc = crc32(~0, fw->data, fw->size);
@@ -536,6 +548,7 @@ static int myri10ge_load_firmware(struct
u32 dma_low, dma_high, size;
int status, i;
+ size = 0;
status = myri10ge_load_hotplug_firmware(mgp, &size);
if (status) {
dev_warn(&mgp->pdev->dev, "hotplug firmware loading failed\n");
@@ -778,7 +791,7 @@ myri10ge_submit_8rx(struct mcp_kreq_ethe
}
/*
- * Set of routunes to get a new receive buffer. Any buffer which
+ * Set of routines to get a new receive buffer. Any buffer which
* crosses a 4KB boundary must start on a 4KB boundary due to PCIe
* wdma restrictions. We also try to align any smaller allocation to
* at least a 16 byte boundary for efficiency. We assume the linux
@@ -1349,7 +1362,7 @@ static struct ethtool_ops myri10ge_ethto
.get_rx_csum = myri10ge_get_rx_csum,
.set_rx_csum = myri10ge_set_rx_csum,
.get_tx_csum = ethtool_op_get_tx_csum,
- .set_tx_csum = ethtool_op_set_tx_csum,
+ .set_tx_csum = ethtool_op_set_tx_hw_csum,
.get_sg = ethtool_op_get_sg,
.set_sg = ethtool_op_set_sg,
#ifdef NETIF_F_TSO
@@ -2615,12 +2628,13 @@ static int myri10ge_probe(struct pci_dev
dev_err(&pdev->dev, "Error %d setting DMA mask\n", status);
goto abort_with_netdev;
}
- mgp->cmd = pci_alloc_consistent(pdev, sizeof(*mgp->cmd), &mgp->cmd_bus);
+ mgp->cmd = dma_alloc_coherent(&pdev->dev, sizeof(*mgp->cmd),
+ &mgp->cmd_bus, GFP_KERNEL);
if (mgp->cmd == NULL)
goto abort_with_netdev;
- mgp->fw_stats = pci_alloc_consistent(pdev, sizeof(*mgp->fw_stats),
- &mgp->fw_stats_bus);
+ mgp->fw_stats = dma_alloc_coherent(&pdev->dev, sizeof(*mgp->fw_stats),
+ &mgp->fw_stats_bus, GFP_KERNEL);
if (mgp->fw_stats == NULL)
goto abort_with_cmd;
@@ -2659,8 +2673,8 @@ static int myri10ge_probe(struct pci_dev
/* allocate rx done ring */
bytes = myri10ge_max_intr_slots * sizeof(*mgp->rx_done.entry);
- mgp->rx_done.entry =
- pci_alloc_consistent(pdev, bytes, &mgp->rx_done.bus);
+ mgp->rx_done.entry = dma_alloc_coherent(&pdev->dev, bytes,
+ &mgp->rx_done.bus, GFP_KERNEL);
if (mgp->rx_done.entry == NULL)
goto abort_with_ioremap;
memset(mgp->rx_done.entry, 0, bytes);
@@ -2750,7 +2762,8 @@ abort_with_firmware:
abort_with_rx_done:
bytes = myri10ge_max_intr_slots * sizeof(*mgp->rx_done.entry);
- pci_free_consistent(pdev, bytes, mgp->rx_done.entry, mgp->rx_done.bus);
+ dma_free_coherent(&pdev->dev, bytes,
+ mgp->rx_done.entry, mgp->rx_done.bus);
abort_with_ioremap:
iounmap(mgp->sram);
@@ -2760,11 +2775,12 @@ abort_with_wc:
if (mgp->mtrr >= 0)
mtrr_del(mgp->mtrr, mgp->iomem_base, mgp->board_span);
#endif
- pci_free_consistent(pdev, sizeof(*mgp->fw_stats),
- mgp->fw_stats, mgp->fw_stats_bus);
+ dma_free_coherent(&pdev->dev, sizeof(*mgp->fw_stats),
+ mgp->fw_stats, mgp->fw_stats_bus);
abort_with_cmd:
- pci_free_consistent(pdev, sizeof(*mgp->cmd), mgp->cmd, mgp->cmd_bus);
+ dma_free_coherent(&pdev->dev, sizeof(*mgp->cmd),
+ mgp->cmd, mgp->cmd_bus);
abort_with_netdev:
@@ -2799,7 +2815,8 @@ static void myri10ge_remove(struct pci_d
myri10ge_dummy_rdma(mgp, 0);
bytes = myri10ge_max_intr_slots * sizeof(*mgp->rx_done.entry);
- pci_free_consistent(pdev, bytes, mgp->rx_done.entry, mgp->rx_done.bus);
+ dma_free_coherent(&pdev->dev, bytes,
+ mgp->rx_done.entry, mgp->rx_done.bus);
iounmap(mgp->sram);
@@ -2807,19 +2824,20 @@ static void myri10ge_remove(struct pci_d
if (mgp->mtrr >= 0)
mtrr_del(mgp->mtrr, mgp->iomem_base, mgp->board_span);
#endif
- pci_free_consistent(pdev, sizeof(*mgp->fw_stats),
- mgp->fw_stats, mgp->fw_stats_bus);
+ dma_free_coherent(&pdev->dev, sizeof(*mgp->fw_stats),
+ mgp->fw_stats, mgp->fw_stats_bus);
- pci_free_consistent(pdev, sizeof(*mgp->cmd), mgp->cmd, mgp->cmd_bus);
+ dma_free_coherent(&pdev->dev, sizeof(*mgp->cmd),
+ mgp->cmd, mgp->cmd_bus);
free_netdev(netdev);
pci_set_drvdata(pdev, NULL);
}
-#define PCI_DEVICE_ID_MYIRCOM_MYRI10GE_Z8E 0x0008
+#define PCI_DEVICE_ID_MYRICOM_MYRI10GE_Z8E 0x0008
static struct pci_device_id myri10ge_pci_tbl[] = {
- {PCI_DEVICE(PCI_VENDOR_ID_MYRICOM, PCI_DEVICE_ID_MYIRCOM_MYRI10GE_Z8E)},
+ {PCI_DEVICE(PCI_VENDOR_ID_MYRICOM, PCI_DEVICE_ID_MYRICOM_MYRI10GE_Z8E)},
{0},
};
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox