linux-toradex.git/drivers/net/cxgb3, branch v2.6.27.17 Linux kernel for Apalis and Colibri modules cxgb3 - remove duplicate tests in lro 2008-12-13T23:29:30+00:00 Divy Le Ray divy@chelsio.com 2008-09-05T05:34:13+00:00 8695c0e41ee6fcfce99b7335565d6b1a2e2fbda8 commit 004f23b9d3874efc81d2d1cf18fd0fe48dc2f26f upstream. The generic lro code checks TCP flags/options. Remove duplicate tests done in the driver. Signed-off-by: Divy Le Ray <divy@chelsio.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Cc: Hannes Reinecke <hare@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 004f23b9d3874efc81d2d1cf18fd0fe48dc2f26f upstream.

The generic lro code checks TCP flags/options.
Remove duplicate tests done in the driver.

Signed-off-by: Divy Le Ray <divy@chelsio.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Cc: Hannes Reinecke <hare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
cxgb3 - fix race in EEH 2008-12-13T23:29:30+00:00 Divy Le Ray divy@chelsio.com 2008-09-25T14:05:28+00:00 12fbd593c2d5f88f30bb00f80f8dc3d174dae2ba commit 0ca41c0413a4d9ca58767d53d23accea9aa1cdef upstream. A SGE queue set timer might access registers while in EEH recovery, triggering an EEH error loop. Stop all timers early in EEH process. Signed-off-by: Divy Le Ray <divy@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net> Cc: Karsten Keil <kkeil@novell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 0ca41c0413a4d9ca58767d53d23accea9aa1cdef upstream.

A SGE queue set timer might access registers while in EEH recovery,
triggering an EEH error loop. Stop all timers early in EEH process.

Signed-off-by: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Karsten Keil <kkeil@novell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
cxgb3: Allow 64KB firmware images. 2008-07-29T21:48:42+00:00 Steve Wise swise@opengridcomputing.com 2008-07-26T20:40:56+00:00 8051367586314ab005dacead790a3b2e4e3dcc58 Starting with FW version 7.0, the driver needs to allow larger images. Signed-off-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> 
Starting with FW version 7.0, the driver needs to allow larger images.

Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
dma-mapping: add the device argument to dma_mapping_error() 2008-07-26T19:00:03+00:00 FUJITA Tomonori fujita.tomonori@lab.ntt.co.jp 2008-07-26T02:44:49+00:00 8d8bb39b9eba32dd70e87fd5ad5c5dd4ba118e06 Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER architecture does: This enables us to cleanly fix the Calgary IOMMU issue that some devices are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423). I think that per-device dma_mapping_ops support would be also helpful for KVM people to support PCI passthrough but Andi thinks that this makes it difficult to support the PCI passthrough (see the above thread). So I CC'ed this to KVM camp. Comments are appreciated. A pointer to dma_mapping_ops to struct dev_archdata is added. If the pointer is non NULL, DMA operations in asm/dma-mapping.h use it. If it's NULL, the system-wide dma_ops pointer is used as before. If it's useful for KVM people, I plan to implement a mechanism to register a hook called when a new pci (or dma capable) device is created (it works with hot plugging). It enables IOMMUs to set up an appropriate dma_mapping_ops per device. The major obstacle is that dma_mapping_error doesn't take a pointer to the device unlike other DMA operations. So x86 can't have dma_mapping_ops per device. Note all the POWER IOMMUs use the same dma_mapping_error function so this is not a problem for POWER but x86 IOMMUs use different dma_mapping_error functions. The first patch adds the device argument to dma_mapping_error. The patch is trivial but large since it touches lots of drivers and dma-mapping.h in all the architecture. This patch: dma_mapping_error() doesn't take a pointer to the device unlike other DMA operations. So we can't have dma_mapping_ops per device. Note that POWER already has dma_mapping_ops per device but all the POWER IOMMUs use the same dma_mapping_error function. x86 IOMMUs use device argument. [akpm@linux-foundation.org: fix sge] [akpm@linux-foundation.org: fix svc_rdma] [akpm@linux-foundation.org: build fix] [akpm@linux-foundation.org: fix bnx2x] [akpm@linux-foundation.org: fix s2io] [akpm@linux-foundation.org: fix pasemi_mac] [akpm@linux-foundation.org: fix sdhci] [akpm@linux-foundation.org: build fix] [akpm@linux-foundation.org: fix sparc] [akpm@linux-foundation.org: fix ibmvscsi] Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Muli Ben-Yehuda <muli@il.ibm.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Avi Kivity <avi@qumranet.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER
architecture does:

This enables us to cleanly fix the Calgary IOMMU issue that some devices
are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423).

I think that per-device dma_mapping_ops support would be also helpful for
KVM people to support PCI passthrough but Andi thinks that this makes it
difficult to support the PCI passthrough (see the above thread).  So I
CC'ed this to KVM camp.  Comments are appreciated.

A pointer to dma_mapping_ops to struct dev_archdata is added.  If the
pointer is non NULL, DMA operations in asm/dma-mapping.h use it.  If it's
NULL, the system-wide dma_ops pointer is used as before.

If it's useful for KVM people, I plan to implement a mechanism to register
a hook called when a new pci (or dma capable) device is created (it works
with hot plugging).  It enables IOMMUs to set up an appropriate
dma_mapping_ops per device.

The major obstacle is that dma_mapping_error doesn't take a pointer to the
device unlike other DMA operations.  So x86 can't have dma_mapping_ops per
device.  Note all the POWER IOMMUs use the same dma_mapping_error function
so this is not a problem for POWER but x86 IOMMUs use different
dma_mapping_error functions.

The first patch adds the device argument to dma_mapping_error.  The patch
is trivial but large since it touches lots of drivers and dma-mapping.h in
all the architecture.

This patch:

dma_mapping_error() doesn't take a pointer to the device unlike other DMA
operations.  So we can't have dma_mapping_ops per device.

Note that POWER already has dma_mapping_ops per device but all the POWER
IOMMUs use the same dma_mapping_error function.  x86 IOMMUs use device
argument.

[akpm@linux-foundation.org: fix sge]
[akpm@linux-foundation.org: fix svc_rdma]
[akpm@linux-foundation.org: build fix]
[akpm@linux-foundation.org: fix bnx2x]
[akpm@linux-foundation.org: fix s2io]
[akpm@linux-foundation.org: fix pasemi_mac]
[akpm@linux-foundation.org: fix sdhci]
[akpm@linux-foundation.org: build fix]
[akpm@linux-foundation.org: fix sparc]
[akpm@linux-foundation.org: fix ibmvscsi]
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Muli Ben-Yehuda <muli@il.ibm.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Avi Kivity <avi@qumranet.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6 2008-07-18T09:39:39+00:00 David S. Miller davem@davemloft.net 2008-07-18T09:39:39+00:00 49997d75152b3d23c53b0fa730599f2f74c92c65 Conflicts: Documentation/powerpc/booting-without-of.txt drivers/atm/Makefile drivers/net/fs_enet/fs_enet-main.c drivers/pci/pci-acpi.c net/8021q/vlan.c net/iucv/iucv.c 
Conflicts:

	Documentation/powerpc/booting-without-of.txt
	drivers/atm/Makefile
	drivers/net/fs_enet/fs_enet-main.c
	drivers/pci/pci-acpi.c
	net/8021q/vlan.c
	net/iucv/iucv.c
RDMA/cxgb3: Fixes for zero STag 2008-07-15T06:48:53+00:00 Steve Wise swise@opengridcomputing.com 2008-07-15T06:48:53+00:00 4ab928f69208d240d3681336f34589e4b151824f Handling the zero STag in receive work request requires some extra logic in the driver: - Only set the QP_PRIV bit for kernel mode QPs. - Add a zero STag build function for recv wrs. The uP needs a PBL allocated and passed down in the recv WR so it can construct a HW PBL for the zero STag S/G entries. Note: we need to place a few restrictions on zero STag usage because of this: 1) all SGEs in a recv WR must either be zero STag or not. No mixing. 2) an individual SGE length cannot exceed 128MB for a zero-stag SGE. This should be OK since it's not really practical to allocate such a large chunk of pinned contiguous DMA mapped memory. - Add an optimized non-zero-STag recv wr format for kernel users. This is needed to optimize both zero and non-zero STag cracking in the recv path for kernel users. - Remove the iwch_ prefix from the static build functions. - Bump required FW version. Signed-off-by: Steve Wise <swise@opengridcomputing.com> 
Handling the zero STag in receive work request requires some extra
logic in the driver:

 - Only set the QP_PRIV bit for kernel mode QPs.

- Add a zero STag build function for recv wrs. The uP needs a PBL
  allocated and passed down in the recv WR so it can construct a HW
  PBL for the zero STag S/G entries.  Note: we need to place a few
  restrictions on zero STag usage because of this:

  1) all SGEs in a recv WR must either be zero STag or not.  No mixing.

  2) an individual SGE length cannot exceed 128MB for a zero-stag SGE.
     This should be OK since it's not really practical to allocate
     such a large chunk of pinned contiguous DMA mapped memory.

- Add an optimized non-zero-STag recv wr format for kernel users.
  This is needed to optimize both zero and non-zero STag cracking in
  the recv path for kernel users.

 - Remove the iwch_ prefix from the static build functions.

 - Bump required FW version.

Signed-off-by: Steve Wise <swise@opengridcomputing.com>
RDMA/cxgb3: Add support for protocol statistics 2008-07-15T06:48:48+00:00 Steve Wise swise@opengridcomputing.com 2008-07-15T06:48:48+00:00 14cc180f7b032f8484c1a3d0533b1129ffe307fd - Add a new rdma ctl command called RDMA_GET_MIB to the cxgb3 low level driver to obtain the protocol mib from the rnic hardware. - Add new iw_cxgb3 provider method to get the MIB from the low level driver. Signed-off-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Roland Dreier <rolandd@cisco.com> 
- Add a new rdma ctl command called RDMA_GET_MIB to the cxgb3 low
  level driver to obtain the protocol mib from the rnic hardware.

- Add new iw_cxgb3 provider method to get the MIB from the low level
  driver.

Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
cxgb3 - Add iscsi support 2008-07-11T05:20:33+00:00 Karen Xie kxie@chelsio.com 2008-07-08T16:32:34+00:00 9439f749441f3a7c2c8ef9e32b698cfe9ed60f48 Add iSCSI (S3xx) support. Signed-off-by: Karen Xie <kxie@chelsio.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> 
Add iSCSI (S3xx) support.

Signed-off-by: Karen Xie <kxie@chelsio.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
cxgb3: treat firmware data as const 2008-07-10T13:26:26+00:00 David Woodhouse dwmw2@infradead.org 2008-05-23T23:10:55+00:00 2c733a16784021c7c6a0c10e800937f0645d0a36 Signed-off-by: David Woodhouse <dwmw2@infradead.org> 
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
vlan: move struct vlan_dev_info to private header 2008-07-08T10:23:57+00:00 Patrick McHardy kaber@trash.net 2008-07-08T10:23:57+00:00 22d1ba74bbafa96d3f425cc12714d3fe8675183f Hide struct vlan_dev_info from drivers to prevent them from growing more creative ways to use it. Provide accessors for the two drivers that currently use it. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> 
Hide struct vlan_dev_info from drivers to prevent them from growing
more creative ways to use it. Provide accessors for the two drivers
that currently use it.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>