* Re: [PATCH 13/13] cxgb3 - test MSI capabilities
From: Jeff Garzik @ 2007-08-14 5:47 UTC (permalink / raw)
To: Divy Le Ray; +Cc: netdev, linux-kernel, swise
In-Reply-To: <20070811063036.8239.27320.stgit@speedy5>
Divy Le Ray wrote:
> From: Divy Le Ray <divy@chelsio.com>
>
> Check that the HW in really in MSI/MSI-X mode
> when it was succesfully enabled.
>
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
> ---
>
> drivers/net/cxgb3/cxgb3_main.c | 42 ++++++++++++++++++++++++++++++++++++++++
> drivers/net/cxgb3/regs.h | 4 ++++
> 2 files changed, 46 insertions(+), 0 deletions(-)
we really don't need to be adding this to each driver
^ permalink raw reply
* Re: [PATCH 12/13] cxgb3 - log and clear PEX errors
From: Jeff Garzik @ 2007-08-14 5:46 UTC (permalink / raw)
To: Divy Le Ray; +Cc: netdev, linux-kernel, swise
In-Reply-To: <20070811063031.8221.70512.stgit@speedy5>
Divy Le Ray wrote:
> From: Divy Le Ray <divy@chelsio.com>
>
> Clear pciE PEX errors late at module load time.
> Log details when PEX errors occur.
>
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
> ---
>
> drivers/net/cxgb3/t3_hw.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
ACK 10-12
^ permalink raw reply
* Re: [PATCH 9/13] cxgb3 - Update internal memory management
From: Jeff Garzik @ 2007-08-14 5:45 UTC (permalink / raw)
To: Divy Le Ray; +Cc: netdev, linux-kernel, swise
In-Reply-To: <20070811063015.8166.66861.stgit@speedy5>
Divy Le Ray wrote:
> From: Divy Le Ray <divy@chelsio.com>
>
> Set PM1 internal memory to round robin mode
>
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
why?
^ permalink raw reply
* Re: [PATCH 8/13] cxgb3 - log adapter derial number
From: Jeff Garzik @ 2007-08-14 5:45 UTC (permalink / raw)
To: Divy Le Ray; +Cc: netdev, linux-kernel, swise
In-Reply-To: <20070811063010.8148.57462.stgit@speedy5>
Divy Le Ray wrote:
> From: Divy Le Ray <divy@chelsio.com>
>
> Log HW serial number when cxgb3 module is loaded.
>
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
> ---
>
> drivers/net/cxgb3/common.h | 2 ++
> drivers/net/cxgb3/cxgb3_main.c | 6 ++++--
> drivers/net/cxgb3/t3_hw.c | 3 ++-
> 3 files changed, 8 insertions(+), 3 deletions(-)
ACK patches 6-8
^ permalink raw reply
* Re: [PATCH 5/13] cxgb3 - Expose HW memory page info
From: Jeff Garzik @ 2007-08-14 5:44 UTC (permalink / raw)
To: Divy Le Ray; +Cc: netdev, linux-kernel, swise
In-Reply-To: <20070811062954.8094.33064.stgit@speedy5>
Divy Le Ray wrote:
> From: Divy Le Ray <divy@chelsio.com>
>
> Let the RDMA driver get HW page info to work around HW issues.
> Assign explicit enum values.
>
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
"HW issues" -- you need to go into far more detail, when adding a new
interface. what hw issues? why was this the best/only solution?
^ permalink raw reply
* Re: [PATCH 4/13] cxgb3 - use immediate data for offload Tx
From: Jeff Garzik @ 2007-08-14 5:43 UTC (permalink / raw)
To: Divy Le Ray; +Cc: netdev, linux-kernel, swise
In-Reply-To: <20070811062949.8076.42523.stgit@speedy5>
Divy Le Ray wrote:
> From: Divy Le Ray <divy@chelsio.com>
>
> Send small TX_DATA work requests as immediate data even when
> there are fragments.
>
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
> ---
>
> drivers/net/cxgb3/sge.c | 17 +++++++++++------
> 1 files changed, 11 insertions(+), 6 deletions(-)
needs additional explanation. don't just describe the new post-change
behavior, describe why this change is needed.
^ permalink raw reply
* Re: [PATCH 6/24] make atomic_read() behave consistently on frv
From: Nick Piggin @ 2007-08-14 5:42 UTC (permalink / raw)
To: Chris Snook
Cc: David Howells, linux-kernel, linux-arch, torvalds, netdev, akpm,
ak, heiko.carstens, davem, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl
In-Reply-To: <46BFFDBD.6080804@redhat.com>
Chris Snook wrote:
> David Howells wrote:
>
>> Chris Snook <csnook@redhat.com> wrote:
>>
>>> cpu_relax() contains a barrier, so it should do the right thing. For
>>> non-smp
>>> architectures, I'm concerned about interacting with interrupt
>>> handlers. Some
>>> drivers do use atomic_* operations.
>>
>>
>> I'm not sure that actually answers my question. Why not smp_rmb()?
>>
>> David
>
>
> I would assume because we want to waste time efficiently even on non-smp
> architectures, rather than frying the CPU or draining the battery.
> Certain looping execution patterns can cause the CPU to operate above
> thermal design power. I have fans on my workstation that only ever come
> on when running LINPACK, and that's generally memory bandwidth-bound.
> Just imagine what happens when you're executing the same few
> non-serializing instructions in a tight loop without ever stalling on
> memory fetches, or being scheduled out.
>
> If there's another reason, I'd like to hear it too, because I'm just
> guessing here.
Well if there is only one memory location involved, then smp_rmb() isn't
going to really do anything anyway, so it would be incorrect to use it.
Consider that smp_rmb basically will do anything from flushing the
pipeline to invalidating loads speculatively executed out of order. AFAIK
it will not control the visibility of stores coming from other CPUs (that
is up to the cache coherency).
--
SUSE Labs, Novell Inc.
^ permalink raw reply
* Re: [PATCH 3/13] cxgb3 - SGE doorbell overflow warning
From: Jeff Garzik @ 2007-08-14 5:42 UTC (permalink / raw)
To: Divy Le Ray; +Cc: netdev, linux-kernel, swise
In-Reply-To: <20070811062944.8058.38057.stgit@speedy5>
Divy Le Ray wrote:
> From: Divy Le Ray <divy@chelsio.com>
>
> Log doorbell Fifo overflow
>
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
> ---
>
> drivers/net/cxgb3/regs.h | 8 ++++++++
> drivers/net/cxgb3/sge.c | 4 ++++
> 2 files changed, 12 insertions(+), 0 deletions(-)
ACK, but not applied since patch #2 was not applied
^ permalink raw reply
* Re: [PATCH 2/13] cxgb3 - Update rx coalescing length
From: Jeff Garzik @ 2007-08-14 5:41 UTC (permalink / raw)
To: Divy Le Ray; +Cc: netdev, linux-kernel, swise
In-Reply-To: <20070811062939.8040.31490.stgit@speedy5>
Divy Le Ray wrote:
> From: Divy Le Ray <divy@chelsio.com>
>
> Set max Rx coalescing length to 12288
>
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
> ---
>
> drivers/net/cxgb3/common.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
> index c46c249..55922ed 100644
> --- a/drivers/net/cxgb3/common.h
> +++ b/drivers/net/cxgb3/common.h
> @@ -104,7 +104,7 @@ enum {
> PROTO_SRAM_LINES = 128, /* size of TP sram */
> };
>
> -#define MAX_RX_COALESCING_LEN 16224U
> +#define MAX_RX_COALESCING_LEN 12288U
neither the patch nor description explains -why-
^ permalink raw reply
* Re: [PATCH 1/13] cxgb3 - MAC workaround update
From: Jeff Garzik @ 2007-08-14 5:41 UTC (permalink / raw)
To: Divy Le Ray; +Cc: netdev, linux-kernel, swise
In-Reply-To: <20070811062933.8022.51781.stgit@speedy5>
Divy Le Ray wrote:
> From: Divy Le Ray <divy@chelsio.com>
>
> Update the MAC workaround to deal with switches that do not
> honor pause frames.
>
> Signed-off-by: Divy Le Ray <divy@chelsio.com>
> ---
>
> drivers/net/cxgb3/common.h | 1 +
> drivers/net/cxgb3/xgmac.c | 22 +++++++++++-----------
> 2 files changed, 12 insertions(+), 11 deletions(-)
applied
^ permalink raw reply
* Re: [patch 18/18] 3c59x maintainer
From: Jeff Garzik @ 2007-08-14 5:38 UTC (permalink / raw)
To: akpm; +Cc: netdev, klassert
In-Reply-To: <200708102105.l7AL5RYL008998@imap1.linux-foundation.org>
akpm@linux-foundation.org wrote:
> From: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
>
> Add 3c59x maintainer.
>
> Signed-off-by: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> MAINTAINERS | 6 ++++++
> 1 files changed, 6 insertions(+)
>
> diff -puN MAINTAINERS~add-3c59x-maintainer MAINTAINERS
> --- a/MAINTAINERS~add-3c59x-maintainer
> +++ a/MAINTAINERS
> @@ -97,6 +97,12 @@ M: philb@gnu.org
> L: netdev@vger.kernel.org
> S: Maintained
>
> +3C59X NETWORK DRIVER
> +P: Steffen Klassert
> +M: klassert@mathematik.tu-chemnitz.de
> +L: netdev@vger.kernel.org
> +S: Maintained
applied
thanks Steffen!
^ permalink raw reply
* Re: [patch 17/18] 3c59x: fix duplex configuration
From: Jeff Garzik @ 2007-08-14 5:38 UTC (permalink / raw)
To: akpm; +Cc: netdev, klassert, mb-tmp-ohtmvyyn.xreary.bet, protasnb
In-Reply-To: <200708102105.l7AL5Q2h008995@imap1.linux-foundation.org>
akpm@linux-foundation.org wrote:
> From: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
>
> A special sequence of ifconfig up/down and plug/unplug the cable can break
> the duplex configuration of the driver.
>
> Setting
> vp->mii.full_duplex = vp->full_duplex
> in vortex_up should fix this.
>
> Addresses Bug 8575 3c59x duplex configuration broken
> http://bugzilla.kernel.org/show_bug.cgi?id=8575
>
> Cc: Martin Buck <mb-tmp-ohtmvyyn.xreary.bet@gromit.dyndns.org>
> Signed-off-by: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
> Cc: Natalie Protasevich <protasnb@gmail.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> drivers/net/3c59x.c | 1 +
> 1 files changed, 1 insertion(+)
applied
^ permalink raw reply
* Re: [patch 15/18] drivers/net: remove superfluous memset
From: Jeff Garzik @ 2007-08-14 5:38 UTC (permalink / raw)
To: akpm; +Cc: netdev, m.kozlowski
In-Reply-To: <200708102105.l7AL5PRA008989@imap1.linux-foundation.org>
akpm@linux-foundation.org wrote:
> From: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
>
> This patch covers something like this:
>
> dev = alloc_*dev(...
> ...
> priv = netdev_priv(dev);
> memset(priv, 0, sizeof(*priv));
>
> The memset() here is superfluous. alloc_netdev() uses kzalloc()
> to allocate needed memory so there is no need to zero the priv region
> twice.
>
> Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> drivers/net/fs_enet/fs_enet-main.c | 1 -
> drivers/net/myri10ge/myri10ge.c | 1 -
> drivers/net/netxen/netxen_nic_main.c | 1 -
> drivers/net/sunlance.c | 1 -
> drivers/net/usb/pegasus.c | 1 -
> drivers/net/usb/rtl8150.c | 1 -
> 6 files changed, 6 deletions(-)
applied
^ permalink raw reply
* Re: [patch 13/18] natsemi: fix netdev error acounting
From: Jeff Garzik @ 2007-08-14 5:36 UTC (permalink / raw)
To: akpm; +Cc: netdev, loveminix, protasnb, thockin
In-Reply-To: <200708102105.l7AL5NBY008983@imap1.linux-foundation.org>
akpm@linux-foundation.org wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
>
> When a detailed netdev error is counted, we also must account for it in the
> aggregated error count.
>
> Addresses http://bugzilla.kernel.org/show_bug.cgi?id=8106
>
> Cc: Tim Hockin <thockin@hockin.org>
> Cc: Jeff Garzik <jeff@garzik.org>
> Cc: Chongfeng Hu <loveminix@yahoo.com.cn>
> Cc: Natalie Protasevich <protasnb@gmail.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
applied
^ permalink raw reply
* Re: [patch 12/18] e1000: #if 0 two functions
From: Jeff Garzik @ 2007-08-14 5:36 UTC (permalink / raw)
To: akpm, auke-jan.h.kok; +Cc: netdev, bunk
In-Reply-To: <200708102105.l7AL5M0O008980@imap1.linux-foundation.org>
akpm@linux-foundation.org wrote:
> From: Adrian Bunk <bunk@stusta.de>
>
> e1000_{read,write}_pci_cfg() are no longer used.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> Cc: Auke Kok <auke-jan.h.kok@intel.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> drivers/net/e1000/e1000_hw.h | 2 --
> drivers/net/e1000/e1000_main.c | 4 ++++
> 2 files changed, 4 insertions(+), 2 deletions(-)
if it's truly dead code in upstream, we should just remove it from e1000
^ permalink raw reply
* Re: [patch 10/18] ax88796 printk fixes
From: Jeff Garzik @ 2007-08-14 5:35 UTC (permalink / raw)
To: akpm; +Cc: netdev
In-Reply-To: <200708102105.l7AL5Lxg008974@imap1.linux-foundation.org>
akpm@linux-foundation.org wrote:
> From: Andrew Morton <akpm@linux-foundation.org>
>
> drivers/net/ax88796.c: In function `ax_probe':
> drivers/net/ax88796.c:825: warning: size_t format, different type arg (arg 4)
> drivers/net/ax88796.c:825: warning: size_t format, different type arg (arg 5)
>
> resource_size_t isn't size_t.
>
> Cc: Jeff Garzik <jeff@garzik.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> drivers/net/ax88796.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
applied
^ permalink raw reply
* Re: [patch 09/18] Clean up duplicate includes in drivers/net/
From: Jeff Garzik @ 2007-08-14 5:34 UTC (permalink / raw)
To: akpm; +Cc: netdev, jesper.juhl, linville
In-Reply-To: <200708102105.l7AL5Ko8008971@imap1.linux-foundation.org>
akpm@linux-foundation.org wrote:
> From: Jesper Juhl <jesper.juhl@gmail.com>
>
> This patch cleans up duplicate includes in
> drivers/net/
>
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
> Acked-by: "John W. Linville" <linville@tuxdriver.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> drivers/net/atl1/atl1_main.c | 1 -
> drivers/net/bfin_mac.c | 5 -----
> drivers/net/bonding/bond_sysfs.c | 1 -
> drivers/net/fs_enet/fs_enet-main.c | 2 --
> drivers/net/gianfar.h | 1 -
> drivers/net/gianfar_ethtool.c | 1 -
> drivers/net/irda/kingsun-sir.c | 1 -
> drivers/net/irda/mcs7780.c | 1 -
> drivers/net/mipsnet.c | 1 -
> drivers/net/netxen/netxen_nic_main.c | 1 -
> drivers/net/qla3xxx.c | 1 -
> drivers/net/tsi108_eth.c | 1 -
> drivers/net/wireless/ipw2200.h | 1 -
> drivers/net/wireless/zd1211rw/zd_def.h | 1 -
> 14 files changed, 19 deletions(-)
applied
^ permalink raw reply
* Re: [PATCH 6/24] make atomic_read() behave consistently on frv
From: Nick Piggin @ 2007-08-14 5:34 UTC (permalink / raw)
To: paulmck
Cc: Herbert Xu, csnook, dhowells, linux-kernel, linux-arch, torvalds,
netdev, akpm, ak, heiko.carstens, davem, schwidefsky, wensong,
horms, wjiang, cfriesen, zlynx, rpjday, jesper.juhl
In-Reply-To: <20070813060302.GF13410@linux.vnet.ibm.com>
Paul E. McKenney wrote:
> On Mon, Aug 13, 2007 at 01:15:52PM +0800, Herbert Xu wrote:
>
>>Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
>>
>>>On Sat, Aug 11, 2007 at 08:54:46AM +0800, Herbert Xu wrote:
>>>
>>>>Chris Snook <csnook@redhat.com> wrote:
>>>>
>>>>>cpu_relax() contains a barrier, so it should do the right thing. For
>>>>>non-smp architectures, I'm concerned about interacting with interrupt
>>>>>handlers. Some drivers do use atomic_* operations.
>>>>
>>>>What problems with interrupt handlers? Access to int/long must
>>>>be atomic or we're in big trouble anyway.
>>>
>>>Reordering due to compiler optimizations. CPU reordering does not
>>>affect interactions with interrupt handlers on a given CPU, but
>>>reordering due to compiler code-movement optimization does. Since
>>>volatile can in some cases suppress code-movement optimizations,
>>>it can affect interactions with interrupt handlers.
>>
>>If such reordering matters, then you should use one of the
>>*mb macros or barrier() rather than relying on possibly
>>hidden volatile cast.
>
>
> If communicating among CPUs, sure. However, when communicating between
> mainline and interrupt/NMI handlers on the same CPU, the barrier() and
> most expecially the *mb() macros are gross overkill. So there really
> truly is a place for volatile -- not a large place, to be sure, but a
> place nonetheless.
I really would like all volatile users to go away and be replaced
by explicit barriers. It makes things nicer and more explicit... for
atomic_t type there probably aren't many optimisations that can be
made which volatile would disallow (in actual kernel code), but for
others (eg. bitops, maybe atomic ops in UP kernels), there would be.
Maybe it is the safe way to go, but it does obscure cases where there
is a real need for barriers.
Many atomic operations are allowed to be reordered between CPUs, so
I don't have a good idea for the rationale to order them within the
CPU (also loads and stores to long and ptr types are not ordered like
this, although we do consider those to be atomic operations too).
barrier() in a way is like enforcing sequential memory ordering
between process and interrupt context, wheras volatile is just
enforcing coherency of a single memory location (and as such is
cheaper).
What do you think of this crazy idea?
/* Enforce a compiler barrier for only operations to location X.
* Call multiple times to provide an ordering between multiple
* memory locations. Other memory operations can be assumed by
* the compiler to remain unchanged and may be reordered
*/
#define order(x) asm volatile("" : "+m" (x))
--
SUSE Labs, Novell Inc.
^ permalink raw reply
* Re: [patch 08/18] 3c59x: check return of pci_enable_device()
From: Jeff Garzik @ 2007-08-14 5:33 UTC (permalink / raw)
To: akpm, mark; +Cc: netdev, klassert
In-Reply-To: <200708102105.l7AL5Jje008968@imap1.linux-foundation.org>
akpm@linux-foundation.org wrote:
> From: Mark Hindley <mark@hindley.org.uk>
>
> Check return of pci_enable_device in vortex_up().
>
> Signed-off-by: Mark Hindley <mark@hindley.org.uk>
> Acked-by: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> drivers/net/3c59x.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff -puN drivers/net/3c59x.c~3c59x-check-return-of-pci_enable_device drivers/net/3c59x.c
> --- a/drivers/net/3c59x.c~3c59x-check-return-of-pci_enable_device
> +++ a/drivers/net/3c59x.c
> @@ -1490,13 +1490,17 @@ vortex_up(struct net_device *dev)
> struct vortex_private *vp = netdev_priv(dev);
> void __iomem *ioaddr = vp->ioaddr;
> unsigned int config;
> - int i, mii_reg1, mii_reg5;
> + int i, mii_reg1, mii_reg5, err;
>
> if (VORTEX_PCI(vp)) {
> pci_set_power_state(VORTEX_PCI(vp), PCI_D0); /* Go active */
> if (vp->pm_state_valid)
> pci_restore_state(VORTEX_PCI(vp));
> - pci_enable_device(VORTEX_PCI(vp));
> + err = pci_enable_device(VORTEX_PCI(vp));
> + if (err) {
> + printk(KERN_WARNING "%s: Could not enable device \n",
> + dev->name);
> + }
I would strongly prefer that vortex_up return a value, since all the
important callers of this function can themselves return an error back
to the system.
we can definitely return a meaningful return value here, if
pci_enable_device() fails, and I would rather not apply a patch that
fails to propagate a serious condition (pci_enable_device failure is
indeed serious) when it is possible to do so
^ permalink raw reply
* Re: [patch 06/18] PCI-X/PCI-Express read control interfaces: use them in myrinet
From: Jeff Garzik @ 2007-08-14 5:30 UTC (permalink / raw)
To: akpm, brice; +Cc: netdev, peter.oruba, rolandd, shemminger
In-Reply-To: <200708102105.l7AL5H0a008960@imap1.linux-foundation.org>
akpm@linux-foundation.org wrote:
> From: "Peter Oruba" <peter.oruba@amd.com>
>
> These driver changes incorporate the proposed PCI-X / PCI-Express read byte
> count interface. Reading and setting those valuse doesn't take place
> "manually", instead wrapping functions are called to allow quirks for some
> PCI bridges.
>
> Signed-off by: Peter Oruba <peter.oruba@amd.com>
> Based on work by Stephen Hemminger <shemminger@linux-foundation.org>
> Cc: Roland Dreier <rolandd@cisco.com>
> Cc: Brice Goglin <brice@myri.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> drivers/net/myri10ge/myri10ge.c | 3 +--
> 1 files changed, 1 insertion(+), 2 deletions(-)
>
> diff -puN drivers/net/myri10ge/myri10ge.c~pci-x-pci-express-read-control-interfaces-myrinet drivers/net/myri10ge/myri10ge.c
> --- a/drivers/net/myri10ge/myri10ge.c~pci-x-pci-express-read-control-interfaces-myrinet
> +++ a/drivers/net/myri10ge/myri10ge.c
> @@ -2884,8 +2884,7 @@ static int myri10ge_probe(struct pci_dev
> status);
> goto abort_with_netdev;
> }
> - val = (val & ~PCI_EXP_DEVCTL_READRQ) | (5 << 12);
> - status = pci_write_config_word(pdev, cap + PCI_EXP_DEVCTL, val);
> + status = pcie_set_readrq(pdev, 4096);
I presume Brice will resend this one to me, next time he pushes...
^ permalink raw reply
* Re: [PATCH 1/1] Use the pause counter to avoid a needless device reset
From: Jeff Garzik @ 2007-08-14 5:28 UTC (permalink / raw)
To: Brice Goglin; +Cc: netdev
In-Reply-To: <46BABBF6.30001@myri.com>
Brice Goglin wrote:
> Use the pause counter to avoid a needless device reset, and
> print a message telling the admin that our link partner is
> flow controlling us down to 0 pkts/sec.
>
> Signed-off-by: Brice Goglin <brice@myri.com>
> ---
> drivers/net/myri10ge/myri10ge.c | 25 ++++++++++++++++++-------
> 1 file changed, 18 insertions(+), 7 deletions(-)
applied
please prefix your subject lines like this:
[PATCH m/n] myri10ge:
so that the automated tools (git-am from the git package) properly
provide a one-line summary for your patch. for more info also see
http://linux.yyz.us/patch-format.html
^ permalink raw reply
* Re: [patch 04/18] via-rhine: disable rx_copybreak on archs that don't allow unaligned DMA access
From: Jeff Garzik @ 2007-08-14 5:27 UTC (permalink / raw)
To: akpm; +Cc: netdev, jailbird, ink, romieu
In-Reply-To: <200708102105.l7AL5FUp008954@imap1.linux-foundation.org>
akpm@linux-foundation.org wrote:
> From: Dustin Marquess <jailbird@alcatraz.fdf.net>
>
> Patch to disable the rx_copybreak feature on hardware architectures that
> don't allow unaligned DMA access.
>
> #ifdef code taken from tulip_core.c. Problem pointed out by Ivan
> Kokshaysky.
>
> Signed-off-by: Dustin Marquess <jailbird@alcatraz.fdf.net>
> Cc: Francois Romieu <romieu@fr.zoreil.com>
> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
> Cc: Jeff Garzik <jeff@garzik.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> drivers/net/via-rhine.c | 6 ++++++
> 1 files changed, 6 insertions(+)
applied
^ permalink raw reply
* Re: [patch 03/18] drivers/net/ns83820.c: add paramter to disable autonegotiation
From: Jeff Garzik @ 2007-08-14 5:25 UTC (permalink / raw)
To: akpm; +Cc: netdev, dan, bcrl, dan, jgarzik
In-Reply-To: <200708102105.l7AL5ERH008951@imap1.linux-foundation.org>
applied the ethtool part of this
^ permalink raw reply
* Re: [PATCH 5/6] e1000e: error handling for pci_map_single calls.
From: Jeff Garzik @ 2007-08-14 5:15 UTC (permalink / raw)
To: Auke Kok; +Cc: netdev, akpm, andi
In-Reply-To: <20070810200102.21509.97953.stgit@localhost.localdomain>
Auke Kok wrote:
> index d14cc4b..0e80406 100644
> --- a/drivers/net/e1000e/ethtool.c
> +++ b/drivers/net/e1000e/ethtool.c
> @@ -1042,6 +1044,10 @@ static int e1000_setup_desc_rings(struct e1000_adapter *adapter)
> tx_ring->buffer_info[i].dma =
> pci_map_single(pdev, skb->data, skb->len,
> PCI_DMA_TODEVICE);
> + if (pci_dma_mapping_error(tx_ring->buffer_info[i].dma)) {
> + ret_val = 4;
> + goto err_nomem;
> + }
> tx_desc->buffer_addr = cpu_to_le64(
> tx_ring->buffer_info[i].dma);
> tx_desc->lower.data = cpu_to_le32(skb->len);
> @@ -1059,7 +1065,7 @@ static int e1000_setup_desc_rings(struct e1000_adapter *adapter)
> size = rx_ring->count * sizeof(struct e1000_buffer);
> rx_ring->buffer_info = kmalloc(size, GFP_KERNEL);
> if (!rx_ring->buffer_info) {
> - ret_val = 4;
> + ret_val = 5;
> goto err_nomem;
> }
> memset(rx_ring->buffer_info, 0, size);
> @@ -1068,7 +1074,7 @@ static int e1000_setup_desc_rings(struct e1000_adapter *adapter)
> rx_ring->desc = dma_alloc_coherent(&pdev->dev, rx_ring->size,
> &rx_ring->dma, GFP_KERNEL);
> if (!rx_ring->desc) {
> - ret_val = 5;
> + ret_val = 6;
> goto err_nomem;
> }
> memset(rx_ring->desc, 0, rx_ring->size);
> @@ -1093,7 +1099,7 @@ static int e1000_setup_desc_rings(struct e1000_adapter *adapter)
>
> skb = alloc_skb(2048 + NET_IP_ALIGN, GFP_KERNEL);
> if (!skb) {
> - ret_val = 6;
> + ret_val = 7;
> goto err_nomem;
> }
> skb_reserve(skb, NET_IP_ALIGN);
> @@ -1101,6 +1107,10 @@ static int e1000_setup_desc_rings(struct e1000_adapter *adapter)
> rx_ring->buffer_info[i].dma =
> pci_map_single(pdev, skb->data, 2048,
> PCI_DMA_FROMDEVICE);
> + if (pci_dma_mapping_error(rx_ring->buffer_info[i].dma)) {
> + ret_val = 8;
> + goto err_nomem;
> + }
> rx_desc->buffer_addr =
> cpu_to_le64(rx_ring->buffer_info[i].dma);
> memset(skb->data, 0x00, skb->len);
this function is a bit fragile if two additional error checks cause a
'ret_val' ripple effect throughout the function.
> diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
> index 51c9024..8ebe238 100644
> --- a/drivers/net/e1000e/netdev.c
> +++ b/drivers/net/e1000e/netdev.c
> @@ -195,6 +195,11 @@ map_skb:
> buffer_info->dma = pci_map_single(pdev, skb->data,
> adapter->rx_buffer_len,
> PCI_DMA_FROMDEVICE);
> + if (pci_dma_mapping_error(buffer_info->dma)) {
> + dev_err(&pdev->dev, "RX DMA map failed\n");
> + adapter->rx_dma_failed++;
> + break;
> + }
>
> rx_desc = E1000_RX_DESC(*rx_ring, i);
> rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma);
> @@ -255,6 +260,13 @@ static void e1000_alloc_rx_buffers_ps(struct e1000_adapter *adapter,
> ps_page->page,
> 0, PAGE_SIZE,
> PCI_DMA_FROMDEVICE);
> + if (pci_dma_mapping_error(
> + ps_page->dma)) {
> + dev_err(&adapter->pdev->dev,
> + "RX DMA page map failed\n");
> + adapter->rx_dma_failed++;
> + goto no_buffers;
> + }
> }
> /*
> * Refresh the desc even if buffer_addrs
> @@ -286,6 +298,14 @@ static void e1000_alloc_rx_buffers_ps(struct e1000_adapter *adapter,
> buffer_info->dma = pci_map_single(pdev, skb->data,
> adapter->rx_ps_bsize0,
> PCI_DMA_FROMDEVICE);
> + if (pci_dma_mapping_error(buffer_info->dma)) {
> + dev_err(&pdev->dev, "RX DMA map failed\n");
> + adapter->rx_dma_failed++;
> + /* cleanup skb */
> + dev_kfree_skb_any(skb);
> + buffer_info->skb = NULL;
> + break;
> + }
>
> rx_desc->read.buffer_addr[0] = cpu_to_le64(buffer_info->dma);
>
> @@ -374,6 +394,11 @@ check_page:
> buffer_info->page, 0,
> PAGE_SIZE,
> PCI_DMA_FROMDEVICE);
> + if (pci_dma_mapping_error(buffer_info->dma)) {
> + dev_err(&adapter->pdev->dev, "RX DMA page map failed\n");
> + adapter->rx_dma_failed++;
> + break;
> + }
>
> rx_desc = E1000_RX_DESC(*rx_ring, i);
> rx_desc->buffer_addr = cpu_to_le64(buffer_info->dma);
> @@ -3214,6 +3239,11 @@ static int e1000_tx_map(struct e1000_adapter *adapter,
> skb->data + offset,
> size,
> PCI_DMA_TODEVICE);
> + if (pci_dma_mapping_error(buffer_info->dma)) {
> + dev_err(&adapter->pdev->dev, "TX DMA map failed\n");
> + adapter->tx_dma_failed++;
> + return -1;
> + }
> buffer_info->next_to_watch = i;
>
> len -= size;
> @@ -3247,6 +3277,13 @@ static int e1000_tx_map(struct e1000_adapter *adapter,
> offset,
> size,
> PCI_DMA_TODEVICE);
> + if (pci_dma_mapping_error(buffer_info->dma)) {
> + dev_err(&adapter->pdev->dev,
> + "TX DMA page map failed\n");
> + adapter->tx_dma_failed++;
> + return -1;
> + }
> +
> buffer_info->next_to_watch = i;
>
> len -= size;
> @@ -3512,9 +3549,15 @@ static int e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
> if (skb->protocol == htons(ETH_P_IP))
> tx_flags |= E1000_TX_FLAGS_IPV4;
>
> - e1000_tx_queue(adapter, tx_flags,
> - e1000_tx_map(adapter, skb, first,
> - max_per_txd, nr_frags, mss));
> + count = e1000_tx_map(adapter, skb, first, max_per_txd, nr_frags, mss);
> + if (count < 0) {
> + /* handle pci_map_single() error in e1000_tx_map */
> + dev_kfree_skb_any(skb);
> + spin_unlock_irqrestore(&adapter->tx_queue_lock, irq_flags);
> + return NETDEV_TX_BUSY;
> + }
> +
> + e1000_tx_queue(adapter, tx_flags, count);
are you really supposed to free the skb, if you are returning
NETDEV_TX_BUSY? My memory is rusty but that seems strange
^ permalink raw reply
* Re: [PATCH 2/6] e1000e: remove namespace collisions with e1000
From: Jeff Garzik @ 2007-08-14 5:13 UTC (permalink / raw)
To: Auke Kok; +Cc: netdev, akpm, andi
In-Reply-To: <20070810200047.21509.46779.stgit@localhost.localdomain>
Auke Kok wrote:
> To prevent future collisions we rename all extern's from e1000_
> to e1000e_*. The list of changed symbols was taken from e1000.h
> Compile tested with CONFIG_E1000=y and CONFIG_E1000E=y.
>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> ---
>
> drivers/net/e1000e/82571.c | 129 +++++++++++++-------------
> drivers/net/e1000e/e1000.h | 194 +++++++++++++++++++--------------------
> drivers/net/e1000e/es2lan.c | 118 ++++++++++++------------
> drivers/net/e1000e/ethtool.c | 62 ++++++------
> drivers/net/e1000e/ich8lan.c | 92 +++++++++---------
> drivers/net/e1000e/lib.c | 210 +++++++++++++++++++++---------------------
> drivers/net/e1000e/netdev.c | 168 +++++++++++++++++-----------------
> drivers/net/e1000e/param.c | 8 +-
> drivers/net/e1000e/phy.c | 138 ++++++++++++++--------------
> 9 files changed, 559 insertions(+), 560 deletions(-)
if you grep around this effort was already started using the 'e1e_'
prefix. I like the shorter prefix, but your call ultimately. Either
way, make sure to make the driver consistent there too.
e1e_flush(), e1e_wphy(), etc.
Overall I still want to push the driver towards shorter function and
variable names. Things like
e1000e_get_speed_and_duplex_fiber_serdes are just way too long.
Jeff
^ 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