[PATCH 1/10] cxgb3 - main header files

From: Divy Le Ray <[EMAIL PROTECTED]> This patch implements the main header files of the Chelsio T3 network driver. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/adapter.h | 250 drivers/net/cxgb3/common.h | 704 ++

[PATCH 7/10] cxgb3 - offload header files

From: Divy Le Ray <[EMAIL PROTECTED]> This patch implements the offload operations header files for the Chelsio T3 network adapter's driver. Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]> --- drivers/net/cxgb3/cxgb3_ctl_defs.h | 142 drivers/net/cxgb3/cxgb3_defs.h | 99 ++ drivers/n

[PATCH 0/10] cxgb3: Chelsio T3 1G/10G ethernet device driver

Hi, I resubmit the patch supporting the latest Chelsio T3 adapter. It incoporpates feedbacks from Stephen and Jan. This patch adds support for the latest Chelsio adapter, T3. It is built against 2.6.19. A corresponding monolithic patch against 2.6.19 is posted at the following URL: http://servi

Re: [PATCH 2/10] cxgb3 - main source file

O > + * If we have multiple receive queues per port serviced by NAPI we need one > + * netdevice per queue as NAPI operates on netdevices. We already have one > + * netdevice, namely the one associated with the interface, so we use dummy > + * ones for any additional queues. Note that these netde

Re: [PATCH] Add Broadcom PHY support

On Fri, 2006-09-15 at 16:15 -0400, Amy Fong wrote: > [PATCH] Add Broadcom PHY support > > This patch adds a driver to support the bcm5421s and bcm5461s PHY > > Kernel version: linux-2.6.18-rc6 > > Signed-off-by: Amy Fong Some 5421's need special initialisation (see drivers/net/sungem_phy.c),

Re: [RFC] rfkill - Add support for input key to control wireless radio

On 12/3/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote: Hi, This patch is a resend of a patch I has been send to the linux kernel and netdev list earlier. The most recent version of a few weeks back didn't compile since I missed 1 line in my patch that changed include/linux/input.h. This patch wil

Re: 2.6.19-rc6-mm2: uli526x only works after reload

On Fri, Dec 01, 2006 at 02:08:28AM +0100, Rafael J. Wysocki wrote: > On Thursday, 30 November 2006 22:32, Rafael J. Wysocki wrote: > > [Trimmed the Cc list a bit.] > > > > On Thursday, 30 November 2006 22:12, Andrew Morton wrote: > > > On Thu, 30 Nov 2006 21:21:27 +0100 > > > "Rafael J. Wysocki" <

Re: [RFC] rfkill - Add support for input key to control wireless radio

Hi, > > This patch is a resend of a patch I has been send to the linux kernel > > and netdev list earlier. The most recent version of a few weeks back > > didn't compile since I missed 1 line in my patch that changed > > include/linux/input.h. > > > > This patch will offer the handling of radiokey

Re: Intel 82559 NIC corrupted EEPROM

On 12/1/06, John <[EMAIL PROTECTED]> wrote: > can you try adding mdelay(100); in e100_eeprom_load before the for loop, > and then change the multiple udelay(4) to mdelay(1) in e100_eeprom_read I applied the attached patch. Loading the driver now takes around one minute :-) ouch, but yep, that

Re: [RFC] rfkill - Add support for input key to control wireless radio

On Sun, 3 Dec 2006 23:28:11 +0100 Ivo van Doorn wrote: > rfkill with the fixes as suggested by Arjan. > - instead of a semaphore a mutex is now being used. > - open_count changing is now locked by the mutex. > > --- > > diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig > ind

2.6.19-git6 header error

linux-2.6.19-git6/usr/include/linux/netfilter.h requires linux/rcupdate.h, which does not exist in exported headers make[3]: *** [/var/linsrc/linux-2.6.19-git6/usr/include/linux/.check.netfilter.h] Error 1 make[2]: *** [linux] Error 2 make[1]: *** [headers_check] Error 2 make: *** [vmlinux] Error

Re: 2.6.19-git6 header error

On Mon, 4 Dec 2006 17:03:24 -0800 Randy Dunlap wrote: > linux-2.6.19-git6/usr/include/linux/netfilter.h requires linux/rcupdate.h, > which does not exist in exported headers > make[3]: *** > [/var/linsrc/linux-2.6.19-git6/usr/include/linux/.check.netfilter.h] Error 1 > make[2]: *** [linux] Error

Re: [PATCH v2 04/13] Connection Manager

On Mon, Dec 04, 2006 at 07:45:52AM -0800, Roland Dreier ([EMAIL PROTECTED]) wrote: > > This and a lot of other changes in this driver definitely says you > > implement your own stack of protocols on top of infiniband hardware. > > ...but I do know this driver is for 10-gig ethernet HW. It is f

Re: [PATCH v2 04/13] Connection Manager

> It is for iwarp/rdma from description. Yes, iWARP on top of 10G ethernet. > If it is 10ge, then why does it parse incomping packet headers and > implements initial tcp state machine? To establish connections to run RDMA over, I guess. iWARP is RDMA over TCP. - R. - To unsubscribe from th

Re: [PATCH v2 04/13] Connection Manager

On Mon, Dec 04, 2006 at 10:20:51AM -0600, Steve Wise ([EMAIL PROTECTED]) wrote: > > > This and a lot of other changes in this driver definitely says you > > > implement your own stack of protocols on top of infiniband hardware. > > > > ...but I do know this driver is for 10-gig ethernet HW. > >

Re: [PATCH v2 04/13] Connection Manager

On Mon, Dec 04, 2006 at 09:13:59PM -0800, Roland Dreier ([EMAIL PROTECTED]) wrote: > > It is for iwarp/rdma from description. > > Yes, iWARP on top of 10G ethernet. > > > If it is 10ge, then why does it parse incomping packet headers and > > implements initial tcp state machine? > > To estab

Re: [PATCH v2 04/13] Connection Manager

> So will each new NIC implement some parts of TCP stack in theirs drivers? I hope not. The driver we merged (amso1100) did it completely in FW, with a separate MAC and IP interface for the RDMA connections. I think we better understand the Chelsio driver pretty well and think it over carefully

Re: [PATCH] Add Broadcom PHY support

> On Fri, 2006-09-15 at 16:15 -0400, Amy Fong wrote: > > [PATCH] Add Broadcom PHY support > > > > This patch adds a driver to support the bcm5421s and bcm5461s PHY > > > > Kernel version: linux-2.6.18-rc6 > > > > Signed-off-by: Amy Fong > > Some 5421's need special initialisation (see drivers

Re: [PATCH] Add Broadcom PHY support

> I believe that this fiber enabling can be done by defining config_init in the > phy_driver struct. > > struct phy_driver { > > /* Called to initialize the PHY, >* including after a reset */ > int (*config_init)(struct phy_device *phydev); > > }; Well... I don't know fo

Re: -mm merge plans for 2.6.20

Andrew Morton wrote: via-pata-controller-xfer-fixes.patch via-pata-controller-xfer-fixes-fix.patch Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the reporter as fixing things, so these two shouldn't be needed. libata_resume_fix.patch I thought this was resolved long

Re: -mm merge plans for 2.6.20

On Mon, 04 Dec 2006 23:56:42 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > via-pata-controller-xfer-fixes.patch > > via-pata-controller-xfer-fixes-fix.patch > > Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the > reporter as fixing things, so these

Oops in pata_pdc2027x

Hi all, I get an oops during initialisation of the pata_pdc2027x module on a POWER 285 machine. This is on a very recent Linus kernel tree (ff51a98799931256b555446b2f5675db08de6229) with Paulus' powerpc tree (that has now been merged). The oops looks like this: --

Re: -mm merge plans for 2.6.20

On Mon, Dec 04 2006, Andrew Morton wrote: > > > > > libata_resume_fix.patch > > > > I thought this was resolved long ago? Are there still open reports that > > this solves, where upstream doesn't work? > > Heck, I don't know. I'm not aware of any, and resume works for me. Did that patch ever

<    1   2   3   4   5