* Re: [net-next v2 26/71] xscale: Move the Intel XScale IXP drivers
From: Lennert Buytenhek @ 2011-07-31 8:38 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, sassmann, Krzysztof Halasa
In-Reply-To: <1312082850-24914-27-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jul 30, 2011 at 08:26:45PM -0700, Jeff Kirsher wrote:
> Move the Intel XScale IXP drivers into drivers/net/ethernet/xscale/
> and make the necessary Kconfig and Makefile changes.
>
> CC: Krzysztof Halasa <khc@pm.waw.pl>
> CC: Lennert Buytenhek <kernel@wantstofly.org>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> [...]
>
> rename drivers/net/{ => ethernet/xscale}/ixp2000/Kconfig (76%)
This is pretty deeply nested, but OK.
Acked-by: Lennert Buytenhek <kernel@wantstofly.org>
^ permalink raw reply
* Re: [net-next v2 69/71] xircom: Move the Xircom driver
From: Dominik Brodowski @ 2011-07-31 8:52 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, sassmann, psheer
In-Reply-To: <1312082850-24914-70-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jul 30, 2011 at 08:27:28PM -0700, Jeff Kirsher wrote:
> Move the Xircom driver into drivers/net/ethernet/xircom/ and
> make the necessary Kconfig and Makefile changes.
>
> CC: <psheer@icon.co.za>
> CC: Dominik Brodowski <linux@dominikbrodowski.net>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/xircom/Kconfig | 26 ++++++++++++++++++++
> drivers/net/ethernet/xircom/Makefile | 5 ++++
> .../net/{pcmcia => ethernet/xircom}/xirc2ps_cs.c | 0
> drivers/net/pcmcia/Kconfig | 9 -------
> drivers/net/pcmcia/Makefile | 1 -
> 7 files changed, 33 insertions(+), 10 deletions(-)
> create mode 100644 drivers/net/ethernet/xircom/Kconfig
> create mode 100644 drivers/net/ethernet/xircom/Makefile
> rename drivers/net/{pcmcia => ethernet/xircom}/xirc2ps_cs.c (100%)
>
> diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
> index df8940d..f011665 100644
> --- a/drivers/net/ethernet/Kconfig
> +++ b/drivers/net/ethernet/Kconfig
> @@ -160,5 +160,6 @@ source "drivers/net/ethernet/toshiba/Kconfig"
> source "drivers/net/ethernet/tundra/Kconfig"
> source "drivers/net/ethernet/via/Kconfig"
> source "drivers/net/ethernet/xilinx/Kconfig"
> +source "drivers/net/ethernet/xircom/Kconfig"
>
> endif # ETHERNET
> diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
> index 09f26b6..7f3b73c 100644
> --- a/drivers/net/ethernet/Makefile
> +++ b/drivers/net/ethernet/Makefile
> @@ -69,3 +69,4 @@ obj-$(CONFIG_NET_VENDOR_TOSHIBA) += toshiba/
> obj-$(CONFIG_NET_VENDOR_TUNDRA) += tundra/
> obj-$(CONFIG_NET_VENDOR_VIA) += via/
> obj-$(CONFIG_NET_VENDOR_XILINX) += xilinx/
> +obj-$(CONFIG_NET_VENDOR_XIRCOM) += xircom/
> diff --git a/drivers/net/ethernet/xircom/Kconfig b/drivers/net/ethernet/xircom/Kconfig
> new file mode 100644
> index 0000000..0e01524
> --- /dev/null
> +++ b/drivers/net/ethernet/xircom/Kconfig
> @@ -0,0 +1,26 @@
> +#
> +# Xircom network device configuration
> +#
> +
> +config NET_VENDOR_XIRCOM
> + bool "Xircom devices"
> + depends on PCMCIA
> + ---help---
> + If you have a network (Ethernet) card belonging to this class, say Y
> + and read the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all
> + the questions about Xircom cards. If you say Y, you will be asked for
> + your specific card in the following questions.
> +
> +config PCMCIA_XIRC2PS
> + tristate "Xircom 16-bit PCMCIA support"
> + depends on NET_VENDOR_XIRCOM && PCMCIA
> + ---help---
> + Say Y here if you intend to attach a Xircom 16-bit PCMCIA (PC-card)
> + Ethernet or Fast Ethernet card to your computer.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called xirc2ps_cs. If unsure, say N.
> diff --git a/drivers/net/ethernet/xircom/Makefile b/drivers/net/ethernet/xircom/Makefile
> new file mode 100644
> index 0000000..3b7aebd
> --- /dev/null
> +++ b/drivers/net/ethernet/xircom/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for the Xircom network device drivers.
> +#
> +
> +obj-$(CONFIG_PCMCIA_XIRC2PS) += xirc2ps_cs.o
> diff --git a/drivers/net/pcmcia/xirc2ps_cs.c b/drivers/net/ethernet/xircom/xirc2ps_cs.c
> similarity index 100%
> rename from drivers/net/pcmcia/xirc2ps_cs.c
> rename to drivers/net/ethernet/xircom/xirc2ps_cs.c
> diff --git a/drivers/net/pcmcia/Kconfig b/drivers/net/pcmcia/Kconfig
> index 80d291e..12e7ae4 100644
> --- a/drivers/net/pcmcia/Kconfig
> +++ b/drivers/net/pcmcia/Kconfig
> @@ -21,15 +21,6 @@ menuconfig NET_PCMCIA
>
> if NET_PCMCIA && PCMCIA
>
> -config PCMCIA_XIRC2PS
> - tristate "Xircom 16-bit PCMCIA support"
> - help
> - Say Y here if you intend to attach a Xircom 16-bit PCMCIA (PC-card)
> - Ethernet or Fast Ethernet card to your computer.
> -
> - To compile this driver as a module, choose M here: the module will be
> - called xirc2ps_cs. If unsure, say N.
> -
> config ARCNET_COM20020_CS
> tristate "COM20020 ARCnet PCMCIA support"
> depends on ARCNET_COM20020
> diff --git a/drivers/net/pcmcia/Makefile b/drivers/net/pcmcia/Makefile
> index ccf5535..618e816 100644
> --- a/drivers/net/pcmcia/Makefile
> +++ b/drivers/net/pcmcia/Makefile
> @@ -3,7 +3,6 @@
> #
>
> # 16-bit client drivers
> -obj-$(CONFIG_PCMCIA_XIRC2PS) += xirc2ps_cs.o
> obj-$(CONFIG_ARCNET_COM20020_CS)+= com20020_cs.o
>
> obj-$(CONFIG_PCMCIA_IBMTR) += ibmtr_cs.o
> --
> 1.7.6
>
^ permalink raw reply
* Re: [PATCH] net/smsc911x: add device tree probe support
From: Grant Likely @ 2011-07-31 0:42 UTC (permalink / raw)
To: Shawn Guo
Cc: Nicolas Pitre, patches, netdev, devicetree-discuss,
Steve Glendinning, Shawn Guo, David S. Miller, linux-arm-kernel
In-Reply-To: <20110729171314.GC2241@S2100-06.ap.freescale.net>
On Sat, Jul 30, 2011 at 01:13:15AM +0800, Shawn Guo wrote:
> On Fri, Jul 29, 2011 at 10:26:29AM -0600, Grant Likely wrote:
> > On Sat, Jul 30, 2011 at 12:03:44AM +0800, Shawn Guo wrote:
> > > On Fri, Jul 29, 2011 at 09:47:23AM -0600, Grant Likely wrote:
> > > > On Fri, Jul 29, 2011 at 10:36:26AM +0800, Shawn Guo wrote:
> > > > > Since I do not get any suggestion here, I'm going to follow the driver
> > > > > name to use '911' as the model number. Please tell me if there is any
> > > > > better one.
> > > >
> > > > What is the manufacturer part name? lan9111 or lan91c11? The
> > > > manufacturer's documented part number is almost always preferred.
> > > >
> > > I just posted the v2 of the patch, and chose to use 'smsc,lan9115'
> > > which is the first model supported in the driver. This is the same
> > > approach I used with i.mx device bindings.
> >
> > You haven't answered the question.
> >
> For 9115 example, the part number in data sheet is "LAN9115".
Okay, good. Thanks.
g.
^ permalink raw reply
* Re: [RFC net-next v2 00/71] Organize/Move of the Ethernet drivers in drivers/net/
From: Alexey Dobriyan @ 2011-07-31 15:45 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev
> drivers/net/{ => ethernet/3com}/3c501.c
I for one appreciate that Linux has short overall directory
structure. At work we have like 5-6 directories before
actual code and it sucks very much.
> have tab-completion actually work
What do you mean?
^ permalink raw reply
* Re: [net-next v2 09/71] smsc: Move the SMC (SMSC) drivers
From: Nicolas Pitre @ 2011-07-31 16:47 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, netdev, gospo, sassmann, Donald Becker, Erik Stahlman,
Dustin McIntire, Steve Glendinning, David Hinds
In-Reply-To: <1312082850-24914-10-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, 30 Jul 2011, Jeff Kirsher wrote:
> Moves the SMC (SMSC) drivers into drivers/net/ethernet/smsc/ and the
> necessary Kconfig and Makefile changes. Also did some cleanup
> of NET_VENDOR_SMC Kconfig tag for the 8390 based drivers.
>
> CC: Nicolas Pitre <nico@fluxnic.net>
> CC: Donald Becker <becker@scyld.com>
> CC: Erik Stahlman <erik@vt.edu>
> CC: Dustin McIntire <dustin@sensoria.com>
> CC: Steve Glendinning <steve.glendinning@smsc.com>
> CC: David Hinds <dahinds@users.sourceforge.net>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
> ---
> MAINTAINERS | 6 +-
> drivers/net/Kconfig | 105 ----------------
> drivers/net/Makefile | 7 -
> drivers/net/ethernet/8390/Kconfig | 21 +---
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/smsc/Kconfig | 128 ++++++++++++++++++++
> drivers/net/ethernet/smsc/Makefile | 11 ++
> drivers/net/{ => ethernet/smsc}/epic100.c | 0
> drivers/net/{ => ethernet/smsc}/smc911x.c | 0
> drivers/net/{ => ethernet/smsc}/smc911x.h | 0
> drivers/net/{ => ethernet/smsc}/smc9194.c | 0
> drivers/net/{ => ethernet/smsc}/smc9194.h | 0
> .../net/{pcmcia => ethernet/smsc}/smc91c92_cs.c | 0
> drivers/net/{ => ethernet/smsc}/smc91x.c | 0
> drivers/net/{ => ethernet/smsc}/smc91x.h | 0
> drivers/net/{ => ethernet/smsc}/smsc911x.c | 0
> drivers/net/{ => ethernet/smsc}/smsc911x.h | 0
> drivers/net/{ => ethernet/smsc}/smsc9420.c | 0
> drivers/net/{ => ethernet/smsc}/smsc9420.h | 0
> drivers/net/pcmcia/Kconfig | 11 --
> drivers/net/pcmcia/Makefile | 1 -
> 22 files changed, 148 insertions(+), 144 deletions(-)
> create mode 100644 drivers/net/ethernet/smsc/Kconfig
> create mode 100644 drivers/net/ethernet/smsc/Makefile
> rename drivers/net/{ => ethernet/smsc}/epic100.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smc911x.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smc911x.h (100%)
> rename drivers/net/{ => ethernet/smsc}/smc9194.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smc9194.h (100%)
> rename drivers/net/{pcmcia => ethernet/smsc}/smc91c92_cs.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smc91x.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smc91x.h (100%)
> rename drivers/net/{ => ethernet/smsc}/smsc911x.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smsc911x.h (100%)
> rename drivers/net/{ => ethernet/smsc}/smsc9420.c (100%)
> rename drivers/net/{ => ethernet/smsc}/smsc9420.h (100%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index eb35265..31c76f4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5831,7 +5831,7 @@ F: mm/sl?b.c
> SMC91x ETHERNET DRIVER
> M: Nicolas Pitre <nico@fluxnic.net>
> S: Odd Fixes
> -F: drivers/net/smc91x.*
> +F: drivers/net/ethernet/smsc/smc91x.*
>
> SMM665 HARDWARE MONITOR DRIVER
> M: Guenter Roeck <linux@roeck-us.net>
> @@ -5866,13 +5866,13 @@ M: Steve Glendinning <steve.glendinning@smsc.com>
> L: netdev@vger.kernel.org
> S: Supported
> F: include/linux/smsc911x.h
> -F: drivers/net/smsc911x.*
> +F: drivers/net/ethernet/smsc/smsc911x.*
>
> SMSC9420 PCI ETHERNET DRIVER
> M: Steve Glendinning <steve.glendinning@smsc.com>
> L: netdev@vger.kernel.org
> S: Supported
> -F: drivers/net/smsc9420.*
> +F: drivers/net/ethernet/smsc/smsc9420.*
>
> SN-IA64 (Itanium) SUB-PLATFORM
> M: Jes Sorensen <jes@sgi.com>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 8879506..c0aa2e3 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -508,39 +508,6 @@ config BFIN_MAC_USE_HWSTAMP
> help
> To support the IEEE 1588 Precision Time Protocol (PTP), select y here
>
> -config SMC9194
> - tristate "SMC 9194 support"
> - depends on NET_VENDOR_SMC && (ISA || MAC && BROKEN)
> - select CRC32
> - ---help---
> - This is support for the SMC9xxx based Ethernet cards. Choose this
> - option if you have a DELL laptop with the docking station, or
> - another SMC9192/9194 based chipset. Say Y if you want it compiled
> - into the kernel, and read the file
> - <file:Documentation/networking/smc9.txt> and the Ethernet-HOWTO,
> - available from <http://www.tldp.org/docs.html#howto>.
> -
> - To compile this driver as a module, choose M here. The module
> - will be called smc9194.
> -
> -config SMC91X
> - tristate "SMC 91C9x/91C1xxx support"
> - select CRC32
> - select MII
> - depends on ARM || M32R || SUPERH || \
> - MIPS || BLACKFIN || MN10300 || COLDFIRE
> - help
> - This is a driver for SMC's 91x series of Ethernet chipsets,
> - including the SMC91C94 and the SMC91C111. Say Y if you want it
> - compiled into the kernel, and read the file
> - <file:Documentation/networking/smc9.txt> and the Ethernet-HOWTO,
> - available from <http://www.tldp.org/docs.html#howto>.
> -
> - This driver is also available as a module ( = code which can be
> - inserted in and removed from the running kernel whenever you want).
> - The module will be called smc91x. If you want to compile it as a
> - module, say M here and read <file:Documentation/kbuild/modules.txt>.
> -
> config PXA168_ETH
> tristate "Marvell pxa168 ethernet support"
> depends on CPU_PXA168
> @@ -655,44 +622,6 @@ config GRETH
> help
> Say Y here if you want to use the Aeroflex Gaisler GRETH Ethernet MAC.
>
> -config SMC911X
> - tristate "SMSC LAN911[5678] support"
> - select CRC32
> - select MII
> - depends on ARM || SUPERH || MN10300
> - help
> - This is a driver for SMSC's LAN911x series of Ethernet chipsets
> - including the new LAN9115, LAN9116, LAN9117, and LAN9118.
> - Say Y if you want it compiled into the kernel,
> - and read the Ethernet-HOWTO, available from
> - <http://www.tldp.org/docs.html#howto>.
> -
> - This driver is also available as a module. The module will be
> - called smc911x. If you want to compile it as a module, say M
> - here and read <file:Documentation/kbuild/modules.txt>
> -
> -config SMSC911X
> - tristate "SMSC LAN911x/LAN921x families embedded ethernet support"
> - depends on ARM || SUPERH || BLACKFIN || MIPS || MN10300
> - select CRC32
> - select MII
> - select PHYLIB
> - ---help---
> - Say Y here if you want support for SMSC LAN911x and LAN921x families
> - of ethernet controllers.
> -
> - To compile this driver as a module, choose M here and read
> - <file:Documentation/networking/net-modules.txt>. The module
> - will be called smsc911x.
> -
> -config SMSC911X_ARCH_HOOKS
> - def_bool n
> - depends on SMSC911X
> - help
> - If the arch enables this, it allows the arch to implement various
> - hooks for more comprehensive interrupt control and also to override
> - the source of the MAC address.
> -
> config NET_VENDOR_RACAL
> bool "Racal-Interlan (Micom) NI cards"
> depends on ISA
> @@ -1091,33 +1020,6 @@ config SIS900
> To compile this driver as a module, choose M here: the module
> will be called sis900. This is recommended.
>
> -config EPIC100
> - tristate "SMC EtherPower II"
> - depends on NET_PCI && PCI
> - select CRC32
> - select MII
> - help
> - This driver is for the SMC EtherPower II 9432 PCI Ethernet NIC,
> - which is based on the SMC83c17x (EPIC/100).
> - More specific information and updates are available from
> - <http://www.scyld.com/network/epic100.html>.
> -
> -config SMSC9420
> - tristate "SMSC LAN9420 PCI ethernet adapter support"
> - depends on NET_PCI && PCI
> - select CRC32
> - select PHYLIB
> - select SMSC_PHY
> - help
> - This is a driver for SMSC's LAN9420 PCI ethernet adapter.
> - Say Y if you want it compiled into the kernel,
> - and read the Ethernet-HOWTO, available from
> - <http://www.tldp.org/docs.html#howto>.
> -
> - This driver is also available as a module. The module will be
> - called smsc9420. If you want to compile it as a module, say M
> - here and read <file:Documentation/kbuild/modules.txt>
> -
> config SUNDANCE
> tristate "Sundance Alta support"
> depends on NET_PCI && PCI
> @@ -1834,13 +1736,6 @@ config MYRI10GE_DCA
> driver. DCA is a method for warming the CPU cache before data
> is used, with the intent of lessening the impact of cache misses.
>
> -config NETXEN_NIC
> - tristate "NetXen Multi port (1/10) Gigabit Ethernet NIC"
> - depends on PCI
> - select FW_LOADER
> - help
> - This enables the support for NetXen's Gigabit Ethernet card.
> -
> config NIU
> tristate "Sun Neptune 10Gbit Ethernet support"
> depends on PCI
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 8e41978..4dfa35c 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -55,8 +55,6 @@ obj-$(CONFIG_MACE) += mace.o
> obj-$(CONFIG_BMAC) += bmac.o
>
> obj-$(CONFIG_TLAN) += tlan.o
> -obj-$(CONFIG_EPIC100) += epic100.o
> -obj-$(CONFIG_SMSC9420) += smsc9420.o
> obj-$(CONFIG_SIS190) += sis190.o
> obj-$(CONFIG_SIS900) += sis900.o
> obj-$(CONFIG_R6040) += r6040.o
> @@ -95,7 +93,6 @@ obj-$(CONFIG_NET) += Space.o loopback.o
> obj-$(CONFIG_SEEQ8005) += seeq8005.o
> obj-$(CONFIG_NET_SB1000) += sb1000.o
> obj-$(CONFIG_HP100) += hp100.o
> -obj-$(CONFIG_SMC9194) += smc9194.o
> obj-$(CONFIG_FEC) += fec.o
> obj-$(CONFIG_FEC_MPC52xx) += fec_mpc52xx.o
> ifeq ($(CONFIG_FEC_MPC52xx_MDIO),y)
> @@ -178,9 +175,6 @@ obj-$(CONFIG_IBMVETH) += ibmveth.o
> obj-$(CONFIG_S2IO) += s2io.o
> obj-$(CONFIG_VXGE) += vxge/
> obj-$(CONFIG_MYRI10GE) += myri10ge/
> -obj-$(CONFIG_SMC91X) += smc91x.o
> -obj-$(CONFIG_SMC911X) += smc911x.o
> -obj-$(CONFIG_SMSC911X) += smsc911x.o
> obj-$(CONFIG_PXA168_ETH) += pxa168_eth.o
> obj-$(CONFIG_BFIN_MAC) += bfin_mac.o
> obj-$(CONFIG_DM9000) += dm9000.o
> @@ -227,7 +221,6 @@ obj-$(CONFIG_NETCONSOLE) += netconsole.o
>
> obj-$(CONFIG_FS_ENET) += fs_enet/
>
> -obj-$(CONFIG_NETXEN_NIC) += netxen/
> obj-$(CONFIG_NIU) += niu.o
> obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
> obj-$(CONFIG_SFC) += sfc/
> diff --git a/drivers/net/ethernet/8390/Kconfig b/drivers/net/ethernet/8390/Kconfig
> index 072c641..1c48e4f 100644
> --- a/drivers/net/ethernet/8390/Kconfig
> +++ b/drivers/net/ethernet/8390/Kconfig
> @@ -262,22 +262,9 @@ config STNIC
>
> If unsure, say N.
>
> -config NET_VENDOR_SMC
> - bool "Western Digital/SMC cards"
> - depends on NET_VENDOR_8390 && (ISA || MCA || EISA || MAC)
> - ---help---
> - If you have a network (Ethernet) card belonging to this class, say Y
> - and read the Ethernet-HOWTO, available from
> - <http://www.tldp.org/docs.html#howto>.
> -
> - Note that the answer to this question doesn't directly affect the
> - kernel: saying N will just cause the configurator to skip all
> - the questions about Western Digital cards. If you say Y, you will be
> - asked for your specific card in the following questions.
> -
> config ULTRAMCA
> tristate "SMC Ultra MCA support"
> - depends on NET_VENDOR_SMC && MCA
> + depends on NET_VENDOR_8390 && MCA
> select CRC32
> ---help---
> If you have a network (Ethernet) card of this type and are running
> @@ -289,7 +276,7 @@ config ULTRAMCA
>
> config ULTRA
> tristate "SMC Ultra support"
> - depends on NET_VENDOR_SMC && ISA
> + depends on NET_VENDOR_8390 && ISA
> select CRC32
> ---help---
> If you have a network (Ethernet) card of this type, say Y and read
> @@ -308,7 +295,7 @@ config ULTRA
>
> config ULTRA32
> tristate "SMC Ultra32 EISA support"
> - depends on NET_VENDOR_SMC && EISA
> + depends on NET_VENDOR_8390 && EISA
> select CRC32
> ---help---
> If you have a network (Ethernet) card of this type, say Y and read
> @@ -320,7 +307,7 @@ config ULTRA32
>
> config WD80x3
> tristate "WD80*3 support"
> - depends on NET_VENDOR_SMC && ISA
> + depends on NET_VENDOR_8390 && ISA
> select CRC32
> ---help---
> If you have a network (Ethernet) card of this type, say Y and read
> diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
> index ab591bb..ed5836c 100644
> --- a/drivers/net/ethernet/Kconfig
> +++ b/drivers/net/ethernet/Kconfig
> @@ -18,5 +18,6 @@ source "drivers/net/ethernet/broadcom/Kconfig"
> source "drivers/net/ethernet/chelsio/Kconfig"
> source "drivers/net/ethernet/intel/Kconfig"
> source "drivers/net/ethernet/qlogic/Kconfig"
> +source "drivers/net/ethernet/smsc/Kconfig"
>
> endif # ETHERNET
> diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
> index d8cf120..983fd27 100644
> --- a/drivers/net/ethernet/Makefile
> +++ b/drivers/net/ethernet/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_NET_VENDOR_BROADCOM) += broadcom/
> obj-$(CONFIG_NET_VENDOR_CHELSIO) += chelsio/
> obj-$(CONFIG_NET_VENDOR_INTEL) += intel/
> obj-$(CONFIG_NET_VENDOR_QLOGIC) += qlogic/
> +obj-$(CONFIG_NET_VENDOR_SMSC) += smsc/
> diff --git a/drivers/net/ethernet/smsc/Kconfig b/drivers/net/ethernet/smsc/Kconfig
> new file mode 100644
> index 0000000..dbb3069
> --- /dev/null
> +++ b/drivers/net/ethernet/smsc/Kconfig
> @@ -0,0 +1,128 @@
> +#
> +# Western Digital/SMC network device configuration
> +#
> +
> +config NET_VENDOR_SMSC
> + bool "SMC (SMSC)/Western Digital devices"
> + depends on ARM || ISA || MAC || ARM || MIPS || M32R || SUPERH || \
> + BLACKFIN || MN10300 || COLDFIRE || PCI || PCMCIA
> + ---help---
> + If you have a network (Ethernet) card belonging to this class, say Y
> + and read the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all
> + the questions about SMC/Western Digital cards. If you say Y, you will
> + be asked for your specific card in the following questions.
> +
> +config SMC9194
> + tristate "SMC 9194 support"
> + depends on NET_VENDOR_SMSC && (ISA || MAC && BROKEN)
> + select CRC32
> + ---help---
> + This is support for the SMC9xxx based Ethernet cards. Choose this
> + option if you have a DELL laptop with the docking station, or
> + another SMC9192/9194 based chipset. Say Y if you want it compiled
> + into the kernel, and read the file
> + <file:Documentation/networking/smc9.txt> and the Ethernet-HOWTO,
> + available from <http://www.tldp.org/docs.html#howto>.
> +
> + To compile this driver as a module, choose M here. The module
> + will be called smc9194.
> +
> +config SMC91X
> + tristate "SMC 91C9x/91C1xxx support"
> + select CRC32
> + select MII
> + depends on NET_VENDOR_SMSC && (ARM || M32R || SUPERH || \
> + MIPS || BLACKFIN || MN10300 || COLDFIRE)
> + ---help---
> + This is a driver for SMC's 91x series of Ethernet chipsets,
> + including the SMC91C94 and the SMC91C111. Say Y if you want it
> + compiled into the kernel, and read the file
> + <file:Documentation/networking/smc9.txt> and the Ethernet-HOWTO,
> + available from <http://www.tldp.org/docs.html#howto>.
> +
> + This driver is also available as a module ( = code which can be
> + inserted in and removed from the running kernel whenever you want).
> + The module will be called smc91x. If you want to compile it as a
> + module, say M here and read <file:Documentation/kbuild/modules.txt>.
> +
> +config PCMCIA_SMC91C92
> + tristate "SMC 91Cxx PCMCIA support"
> + depends NET_VENDOR_SMSC && PCMCIA
> + select CRC32
> + select MII
> + ---help---
> + Say Y here if you intend to attach an SMC 91Cxx compatible PCMCIA
> + (PC-card) Ethernet or Fast Ethernet card to your computer.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called smc91c92_cs. If unsure, say N.
> +
> +config EPIC100
> + tristate "SMC EtherPower II"
> + depends on NET_VENDOR_SMSC && PCI
> + select CRC32
> + select MII
> + ---help---
> + This driver is for the SMC EtherPower II 9432 PCI Ethernet NIC,
> + which is based on the SMC83c17x (EPIC/100).
> + More specific information and updates are available from
> + <http://www.scyld.com/network/epic100.html>.
> +
> +config SMC911X
> + tristate "SMSC LAN911[5678] support"
> + select CRC32
> + select MII
> + depends on NET_VENDOR_SMSC && (ARM || SUPERH || MN10300)
> + ---help---
> + This is a driver for SMSC's LAN911x series of Ethernet chipsets
> + including the new LAN9115, LAN9116, LAN9117, and LAN9118.
> + Say Y if you want it compiled into the kernel,
> + and read the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
> +
> + This driver is also available as a module. The module will be
> + called smc911x. If you want to compile it as a module, say M
> + here and read <file:Documentation/kbuild/modules.txt>
> +
> +config SMSC911X
> + tristate "SMSC LAN911x/LAN921x families embedded ethernet support"
> + depends on NET_VENDOR_SMSC && (ARM || SUPERH || BLACKFIN || \
> + MIPS || MN10300)
> + select CRC32
> + select MII
> + select PHYLIB
> + ---help---
> + Say Y here if you want support for SMSC LAN911x and LAN921x families
> + of ethernet controllers.
> +
> + To compile this driver as a module, choose M here and read
> + <file:Documentation/networking/net-modules.txt>. The module
> + will be called smsc911x.
> +
> +config SMSC911X_ARCH_HOOKS
> + def_bool n
> + depends on SMSC911X
> + ---help---
> + If the arch enables this, it allows the arch to implement various
> + hooks for more comprehensive interrupt control and also to override
> + the source of the MAC address.
> +
> +config SMSC9420
> + tristate "SMSC LAN9420 PCI ethernet adapter support"
> + depends on NET_VENDOR_SMSC && PCI
> + select CRC32
> + select PHYLIB
> + select SMSC_PHY
> + ---help---
> + This is a driver for SMSC's LAN9420 PCI ethernet adapter.
> + Say Y if you want it compiled into the kernel,
> + and read the Ethernet-HOWTO, available from
> + <http://www.tldp.org/docs.html#howto>.
> +
> + This driver is also available as a module. The module will be
> + called smsc9420. If you want to compile it as a module, say M
> + here and read <file:Documentation/kbuild/modules.txt>
> diff --git a/drivers/net/ethernet/smsc/Makefile b/drivers/net/ethernet/smsc/Makefile
> new file mode 100644
> index 0000000..f3438de
> --- /dev/null
> +++ b/drivers/net/ethernet/smsc/Makefile
> @@ -0,0 +1,11 @@
> +#
> +# Makefile for the SMSC network device drivers.
> +#
> +
> +obj-$(CONFIG_SMC9194) += smc9194.o
> +obj-$(CONFIG_SMC91X) += smc91x.o
> +obj-$(CONFIG_PCMCIA_SMC91C92) += smc91c92_cs.o
> +obj-$(CONFIG_EPIC100) += epic100.o
> +obj-$(CONFIG_SMSC9420) += smsc9420.o
> +obj-$(CONFIG_SMC911X) += smc911x.o
> +obj-$(CONFIG_SMSC911X) += smsc911x.o
> diff --git a/drivers/net/epic100.c b/drivers/net/ethernet/smsc/epic100.c
> similarity index 100%
> rename from drivers/net/epic100.c
> rename to drivers/net/ethernet/smsc/epic100.c
> diff --git a/drivers/net/smc911x.c b/drivers/net/ethernet/smsc/smc911x.c
> similarity index 100%
> rename from drivers/net/smc911x.c
> rename to drivers/net/ethernet/smsc/smc911x.c
> diff --git a/drivers/net/smc911x.h b/drivers/net/ethernet/smsc/smc911x.h
> similarity index 100%
> rename from drivers/net/smc911x.h
> rename to drivers/net/ethernet/smsc/smc911x.h
> diff --git a/drivers/net/smc9194.c b/drivers/net/ethernet/smsc/smc9194.c
> similarity index 100%
> rename from drivers/net/smc9194.c
> rename to drivers/net/ethernet/smsc/smc9194.c
> diff --git a/drivers/net/smc9194.h b/drivers/net/ethernet/smsc/smc9194.h
> similarity index 100%
> rename from drivers/net/smc9194.h
> rename to drivers/net/ethernet/smsc/smc9194.h
> diff --git a/drivers/net/pcmcia/smc91c92_cs.c b/drivers/net/ethernet/smsc/smc91c92_cs.c
> similarity index 100%
> rename from drivers/net/pcmcia/smc91c92_cs.c
> rename to drivers/net/ethernet/smsc/smc91c92_cs.c
> diff --git a/drivers/net/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
> similarity index 100%
> rename from drivers/net/smc91x.c
> rename to drivers/net/ethernet/smsc/smc91x.c
> diff --git a/drivers/net/smc91x.h b/drivers/net/ethernet/smsc/smc91x.h
> similarity index 100%
> rename from drivers/net/smc91x.h
> rename to drivers/net/ethernet/smsc/smc91x.h
> diff --git a/drivers/net/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
> similarity index 100%
> rename from drivers/net/smsc911x.c
> rename to drivers/net/ethernet/smsc/smsc911x.c
> diff --git a/drivers/net/smsc911x.h b/drivers/net/ethernet/smsc/smsc911x.h
> similarity index 100%
> rename from drivers/net/smsc911x.h
> rename to drivers/net/ethernet/smsc/smsc911x.h
> diff --git a/drivers/net/smsc9420.c b/drivers/net/ethernet/smsc/smsc9420.c
> similarity index 100%
> rename from drivers/net/smsc9420.c
> rename to drivers/net/ethernet/smsc/smsc9420.c
> diff --git a/drivers/net/smsc9420.h b/drivers/net/ethernet/smsc/smsc9420.h
> similarity index 100%
> rename from drivers/net/smsc9420.h
> rename to drivers/net/ethernet/smsc/smsc9420.h
> diff --git a/drivers/net/pcmcia/Kconfig b/drivers/net/pcmcia/Kconfig
> index 72aa257..f5a738f 100644
> --- a/drivers/net/pcmcia/Kconfig
> +++ b/drivers/net/pcmcia/Kconfig
> @@ -31,17 +31,6 @@ config PCMCIA_FMVJ18X
> To compile this driver as a module, choose M here: the module will be
> called fmvj18x_cs. If unsure, say N.
>
> -config PCMCIA_SMC91C92
> - tristate "SMC 91Cxx PCMCIA support"
> - select CRC32
> - select MII
> - help
> - Say Y here if you intend to attach an SMC 91Cxx compatible PCMCIA
> - (PC-card) Ethernet or Fast Ethernet card to your computer.
> -
> - To compile this driver as a module, choose M here: the module will be
> - called smc91c92_cs. If unsure, say N.
> -
> config PCMCIA_XIRC2PS
> tristate "Xircom 16-bit PCMCIA support"
> help
> diff --git a/drivers/net/pcmcia/Makefile b/drivers/net/pcmcia/Makefile
> index c2b8b44..f9c9883 100644
> --- a/drivers/net/pcmcia/Makefile
> +++ b/drivers/net/pcmcia/Makefile
> @@ -4,7 +4,6 @@
>
> # 16-bit client drivers
> obj-$(CONFIG_PCMCIA_FMVJ18X) += fmvj18x_cs.o
> -obj-$(CONFIG_PCMCIA_SMC91C92) += smc91c92_cs.o
> obj-$(CONFIG_PCMCIA_XIRC2PS) += xirc2ps_cs.o
> obj-$(CONFIG_ARCNET_COM20020_CS)+= com20020_cs.o
>
> --
> 1.7.6
>
^ permalink raw reply
* Re: [net-next v2 11/71] ni5010: Move the Racal-Interlan (Micom) driver
From: Andreas Mohr @ 2011-07-31 16:57 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, netdev, gospo, sassmann, Jan-Pascal van Best, Andreas Mohr
In-Reply-To: <1312082850-24914-12-git-send-email-jeffrey.t.kirsher@intel.com>
Hi,
On Sat, Jul 30, 2011 at 08:26:30PM -0700, Jeff Kirsher wrote:
> Moves the Racal-Interlan driver into drivers/net/ethernet/racal/ and
> make the necessary Kconfig and Makefile changes.
Acked-by: Andreas Mohr <andi@lisas.de>
---
Sorry, I had intended to reply to the original RFC,
but due to vacation backlog that got swept under the rug.
Since it's a simple move it seems to be fine.
One minor nit, however: since ni5210 (as seen in some other patch)
got moved to its respective NON-racal location (due to using a specific
chipset),
a short Kconfig addition explaining the whereabouts of ni5210
(and perhaps some other OEM chipset Racal cards?) would be useful.
Thank you for the probably long overdue cleanup of drivers/net/
into something more specific and thus much more easy on the eye :)
Andreas Mohr
^ permalink raw reply
* Re: [RFC net-next v2 00/71] Organize/Move of the Ethernet drivers in drivers/net/
From: Jeff Kirsher @ 2011-07-31 19:00 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: netdev@vger.kernel.org
In-Reply-To: <20110731154515.GA3357@p183.telecom.by>
[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]
On Sun, 2011-07-31 at 08:45 -0700, Alexey Dobriyan wrote:
> > drivers/net/{ => ethernet/3com}/3c501.c
>
> I for one appreciate that Linux has short overall directory
> structure. At work we have like 5-6 directories before
> actual code and it sucks very much.
I agree to some degree. I agree that it nice to only have to go 2-3
layers deep to get to code, but it is also not useful to wade through
357 files in a directory.
drivers/net/ is the largest directory under drivers/ and is 2 times
larger than the next largest directory in drivers/. There are 2255
files/directories in /drivers/net/ and majority are Ethernet drivers.
It has gotten to a point where there needed to be an additional level(s)
of organization. So yes, you have to dig a bit deeper (but it is
logical).
drivers/media/ is the next largest at 23 MB with 1526 files.
>
> > have tab-completion actually work
>
> What do you mean?
What I meant was that tab-completion not becoming not useful when you
get >20 results, you usually end up having to type the entire file name
for what you want. It is nice to type 1-2 characters (and then <tab>)
and get back <5 potential or exact results. David actually brought this
up as an advantage to the new directory structure, which I agree with.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next v2 11/71] ni5010: Move the Racal-Interlan (Micom) driver
From: Jeff Kirsher @ 2011-07-31 19:20 UTC (permalink / raw)
To: Andreas Mohr
Cc: davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com,
sassmann@redhat.com, Jan-Pascal van Best
In-Reply-To: <20110731165702.GA6334@rhlx01.hs-esslingen.de>
[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]
On Sun, 2011-07-31 at 09:57 -0700, Andreas Mohr wrote:
> Hi,
>
> On Sat, Jul 30, 2011 at 08:26:30PM -0700, Jeff Kirsher wrote:
> > Moves the Racal-Interlan driver into drivers/net/ethernet/racal/ and
> > make the necessary Kconfig and Makefile changes.
>
> Acked-by: Andreas Mohr <andi@lisas.de>
>
> ---
>
> Sorry, I had intended to reply to the original RFC,
> but due to vacation backlog that got swept under the rug.
>
> Since it's a simple move it seems to be fine.
>
> One minor nit, however: since ni5210 (as seen in some other patch)
> got moved to its respective NON-racal location (due to using a specific
> chipset),
> a short Kconfig addition explaining the whereabouts of ni5210
> (and perhaps some other OEM chipset Racal cards?) would be useful.
Sounds good, would you be up for sending my a patch against my tree and
I can fold it into my current patchset? Or do you want to just send a
patch later on? I know what your intention is, I am just not sure how
you would like it to show up in the Kconfig.
My git tree with this patch series applied is:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-organize
>
> Thank you for the probably long overdue cleanup of drivers/net/
> into something more specific and thus much more easy on the eye :)
Thanks, it is nice to hear.
>
> Andreas Mohr
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next v2 35/71] skge/sky2/mv643xx/pxa168: Move the Marvell Ethernet drivers
From: Stephen Hemminger @ 2011-07-31 22:11 UTC (permalink / raw)
To: Jeff Kirsher, Sachin Sanap
Cc: davem, netdev, gospo, sassmann, Zhangfei Gao, Philip Rakity,
Mark Brown, Lennert Buytenhek
In-Reply-To: <1312082850-24914-36-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, 30 Jul 2011 20:26:54 -0700
Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> MARVELL MWIFIEX WIRELESS DRIVER
> @@ -5816,8 +5816,7 @@ SKGE, SKY2 10/100/1000 GIGABIT ETHERNET DRIVERS
> M: Stephen Hemminger <shemminger@linux-foundation.org>
> L: netdev@vger.kernel.org
> S: Maintained
> -F: drivers/net/skge.*
> -F: drivers/net/sky2.*
> +F: drivers/net/ethernet/marvell/sk*
The old SysKonnect fddi driver should probably be moved in there
as well. It is called skfp.c
I don't maintain that one, it is unmaintained.
^ permalink raw reply
* Re: [net-next v2 35/71] skge/sky2/mv643xx/pxa168: Move the Marvell Ethernet drivers
From: Joe Perches @ 2011-07-31 22:27 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jeff Kirsher, Sachin Sanap, davem, netdev, gospo, sassmann,
Zhangfei Gao, Philip Rakity, Mark Brown, Lennert Buytenhek
In-Reply-To: <20110731151116.647e9974@nehalam.ftrdhcpuser.net>
On Sun, 2011-07-31 at 15:11 -0700, Stephen Hemminger wrote:
> On Sat, 30 Jul 2011 20:26:54 -0700
> Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> > MARVELL MWIFIEX WIRELESS DRIVER
> > @@ -5816,8 +5816,7 @@ SKGE, SKY2 10/100/1000 GIGABIT ETHERNET DRIVERS
> > M: Stephen Hemminger <shemminger@linux-foundation.org>
> > L: netdev@vger.kernel.org
> > S: Maintained
> > -F: drivers/net/skge.*
> > -F: drivers/net/sky2.*
> > +F: drivers/net/ethernet/marvell/sk*
> The old SysKonnect fddi driver should probably be moved in there
> as well. It is called skfp.c
fddi isn't ethernet so I think skfp.c should not be moved there.
^ permalink raw reply
* Re: [RFC net-next v2 00/71] Organize/Move of the Ethernet drivers in drivers/net/
From: David Miller @ 2011-08-01 0:42 UTC (permalink / raw)
To: adobriyan; +Cc: jeffrey.t.kirsher, netdev
In-Reply-To: <20110731154515.GA3357@p183.telecom.by>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Sun, 31 Jul 2011 18:45:16 +0300
>> have tab-completion actually work
>
> What do you mean?
Try to type a path down into drivers/net/ then try to use TAB
completion to finish the path to some driver file.
It's painful and you have to give it so much context before it'll do
anything that it completely negates the benefits of TAB completion.
^ permalink raw reply
* Re: [net-next v2 35/71] skge/sky2/mv643xx/pxa168: Move the Marvell Ethernet drivers
From: Jeff Kirsher @ 2011-08-01 2:43 UTC (permalink / raw)
To: Joe Perches
Cc: Stephen Hemminger, Sachin Sanap, davem@davemloft.net,
netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com,
Zhangfei Gao, Philip Rakity, Mark Brown, Lennert Buytenhek
In-Reply-To: <1312151237.11635.5.camel@Joe-Laptop>
[-- Attachment #1: Type: text/plain, Size: 870 bytes --]
On Sun, 2011-07-31 at 15:27 -0700, Joe Perches wrote:
> On Sun, 2011-07-31 at 15:11 -0700, Stephen Hemminger wrote:
> > On Sat, 30 Jul 2011 20:26:54 -0700
> > Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> > > MARVELL MWIFIEX WIRELESS DRIVER
> > > @@ -5816,8 +5816,7 @@ SKGE, SKY2 10/100/1000 GIGABIT ETHERNET DRIVERS
> > > M: Stephen Hemminger <shemminger@linux-foundation.org>
> > > L: netdev@vger.kernel.org
> > > S: Maintained
> > > -F: drivers/net/skge.*
> > > -F: drivers/net/sky2.*
> > > +F: drivers/net/ethernet/marvell/sk*
> > The old SysKonnect fddi driver should probably be moved in there
> > as well. It is called skfp.c
>
> fddi isn't ethernet so I think skfp.c should not be moved there.
>
>
Joe is right, the skfp (fddi) driver would go in driver/net/fddi/, which
is the next set of follow on patches I am working on.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next v2 35/71] skge/sky2/mv643xx/pxa168: Move the Marvell Ethernet drivers
From: Jeff Kirsher @ 2011-08-01 2:35 UTC (permalink / raw)
To: Joe Perches
Cc: Stephen Hemminger, Sachin Sanap, davem@davemloft.net,
netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com,
Zhangfei Gao, Philip Rakity, Mark Brown, Lennert Buytenhek
In-Reply-To: <1312151237.11635.5.camel@Joe-Laptop>
[-- Attachment #1: Type: text/plain, Size: 868 bytes --]
On Sun, 2011-07-31 at 15:27 -0700, Joe Perches wrote:
> On Sun, 2011-07-31 at 15:11 -0700, Stephen Hemminger wrote:
> > On Sat, 30 Jul 2011 20:26:54 -0700
> > Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> > > MARVELL MWIFIEX WIRELESS DRIVER
> > > @@ -5816,8 +5816,7 @@ SKGE, SKY2 10/100/1000 GIGABIT ETHERNET DRIVERS
> > > M: Stephen Hemminger <shemminger@linux-foundation.org>
> > > L: netdev@vger.kernel.org
> > > S: Maintained
> > > -F: drivers/net/skge.*
> > > -F: drivers/net/sky2.*
> > > +F: drivers/net/ethernet/marvell/sk*
> > The old SysKonnect fddi driver should probably be moved in there
> > as well. It is called skfp.c
>
> fddi isn't ethernet so I think skfp.c should not be moved there.
>
>
Joe is right, the skfp (fddi) driver would go in driver/net/fddi/, which
is the next set of follow on patches I am working on.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* RE: [net-next v2 09/71] smsc: Move the SMC (SMSC) drivers
From: Amit Salecha @ 2011-08-01 6:09 UTC (permalink / raw)
To: Jeff Kirsher, David Miller
Cc: netdev, gospo@redhat.com, sassmann@redhat.com, Nicolas Pitre,
Donald Becker, Erik Stahlman, Dustin McIntire, Steve Glendinning,
David Hinds
In-Reply-To: <1312082850-24914-10-git-send-email-jeffrey.t.kirsher@intel.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Jeff Kirsher
> Sent: Sunday, July 31, 2011 8:56 AM
> Subject: [net-next v2 09/71] smsc: Move the SMC (SMSC) drivers
>
> Moves the SMC (SMSC) drivers into drivers/net/ethernet/smsc/ and the
> necessary Kconfig and Makefile changes. Also did some cleanup
> of NET_VENDOR_SMC Kconfig tag for the 8390 based drivers.
>
> CC: Nicolas Pitre <nico@fluxnic.net>
> CC: Donald Becker <becker@scyld.com>
> CC: Erik Stahlman <erik@vt.edu>
> CC: Dustin McIntire <dustin@sensoria.com>
> CC: Steve Glendinning <steve.glendinning@smsc.com>
> CC: David Hinds <dahinds@users.sourceforge.net>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> -config NETXEN_NIC
> - tristate "NetXen Multi port (1/10) Gigabit Ethernet NIC"
> - depends on PCI
> - select FW_LOADER
> - help
> - This enables the support for NetXen's Gigabit Ethernet card.
> -
>
> -obj-$(CONFIG_NETXEN_NIC) += netxen/
> obj-$(CONFIG_NIU) += niu.o
> obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
> obj-$(CONFIG_SFC) += sfc/
I didn't get reason for above netxen_nic changes.
-Amit
^ permalink raw reply
* RE: [net-next v2 09/71] smsc: Move the SMC (SMSC) drivers
From: Jeff Kirsher @ 2011-08-01 6:16 UTC (permalink / raw)
To: Amit Salecha
Cc: David Miller, netdev, gospo@redhat.com, sassmann@redhat.com,
Nicolas Pitre, Donald Becker, Erik Stahlman, Dustin McIntire,
Steve Glendinning, David Hinds
In-Reply-To: <99737F4847ED0A48AECC9F4A1974A4B80FE464E9E5@MNEXMB2.qlogic.org>
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
On Sun, 2011-07-31 at 23:09 -0700, Amit Salecha wrote:
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Jeff Kirsher
> > Sent: Sunday, July 31, 2011 8:56 AM
> > Subject: [net-next v2 09/71] smsc: Move the SMC (SMSC) drivers
> >
> > Moves the SMC (SMSC) drivers into drivers/net/ethernet/smsc/ and the
> > necessary Kconfig and Makefile changes. Also did some cleanup
> > of NET_VENDOR_SMC Kconfig tag for the 8390 based drivers.
> >
> > CC: Nicolas Pitre <nico@fluxnic.net>
> > CC: Donald Becker <becker@scyld.com>
> > CC: Erik Stahlman <erik@vt.edu>
> > CC: Dustin McIntire <dustin@sensoria.com>
> > CC: Steve Glendinning <steve.glendinning@smsc.com>
> > CC: David Hinds <dahinds@users.sourceforge.net>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > ---
> > -config NETXEN_NIC
> > - tristate "NetXen Multi port (1/10) Gigabit Ethernet NIC"
> > - depends on PCI
> > - select FW_LOADER
> > - help
> > - This enables the support for NetXen's Gigabit Ethernet card.
> > -
> >
> > -obj-$(CONFIG_NETXEN_NIC) += netxen/
> > obj-$(CONFIG_NIU) += niu.o
> > obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
> > obj-$(CONFIG_SFC) += sfc/
>
> I didn't get reason for above netxen_nic changes.
>
> -Amit
>
Hmm, it looks like changes destined for the previous patch (the QLogic
patch) got applied to this patch. I will clean this up.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] net: add Documentation/networking/scaling.txt
From: Tom Herbert @ 2011-08-01 6:56 UTC (permalink / raw)
To: rdunlap, linux-doc, davem, netdev; +Cc: willemb
[-- Attachment #1: Type: TEXT/PLAIN, Size: 17646 bytes --]
Describes RSS, RPS, RFS, accelerated RFS, and XPS.
Signed-off-by: Tom Herbert <therbert@google.com>
---
Documentation/networking/scaling.txt | 346 ++++++++++++++++++++++++++++++++++
1 files changed, 346 insertions(+), 0 deletions(-)
create mode 100644 Documentation/networking/scaling.txt
diff --git a/Documentation/networking/scaling.txt b/Documentation/networking/scaling.txt
new file mode 100644
index 0000000..aa51f0f
--- /dev/null
+++ b/Documentation/networking/scaling.txt
@@ -0,0 +1,346 @@
+Scaling in the Linux Networking Stack
+
+
+Introduction
+============
+
+This document describes a set of complementary techniques in the Linux
+networking stack to increase parallelism and improve performance (in
+throughput, latency, CPU utilization, etc.) for multi-processor systems.
+
+The following technologies are described:
+
+ RSS: Receive Side Scaling
+ RPS: Receive Packet Steering
+ RFS: Receive Flow Steering
+ Accelerated Receive Flow Steering
+ XPS: Transmit Packet Steering
+
+
+RSS: Receive Side Scaling
+=========================
+
+Contemporary NICs support multiple receive queues (multi-queue), which
+can be used to distribute packets amongst CPUs for processing. The NIC
+distributes packets by applying a filter to each packet to assign it to
+one of a small number of logical flows. Packets for each flow are
+steered to a separate receive queue, which in turn can be processed by
+separate CPUs. This mechanism is generally known as “Receive-side
+Scaling” (RSS).
+
+The filter used in RSS is typically a hash function over the network or
+transport layer headers-- for example, a 4-tuple hash over IP addresses
+and TCP ports of a packet. The most common hardware implementation of
+RSS uses a 128 entry indirection table where each entry stores a queue
+number. The receive queue for a packet is determined by masking out the
+low order seven bits of the computed hash for the packet (usually a
+Toeplitz hash), taking this number as a key into the indirection table
+and reading the corresponding value.
+
+Some advanced NICs allow steering packets to queues based on
+programmable filters. For example, webserver bound TCP port 80 packets
+can be directed to their own receive queue. Such “n-tuple” filters can
+be configured from ethtool (--config-ntuple).
+
+== RSS Configuration
+
+The driver for a multi-queue capable NIC typically provides a module
+parameter specifying the number of hardware queues to configure. In the
+bnx2x driver, for instance, this parameter is called num_queues. A
+typical RSS configuration would be to have one receive queue for each
+CPU if the device supports enough queues, or otherwise at least one for
+each cache domain at a particular cache level (L1, L2, etc.).
+
+The indirection table of an RSS device, which resolves a queue by masked
+hash, is usually programmed by the driver at initialization. The
+default mapping is to distribute the queues evenly in the table, but the
+indirection table can be retrieved and modified at runtime using ethtool
+commands (--show-rxfh-indir and --set-rxfh-indir). Modifying the
+indirection table could be done to to give different queues different
+relative weights.
+
+== RSS IRQ Configuration
+
+Each receive queue has a separate IRQ associated with it. The NIC
+triggers this to notify a CPU when new packets arrive on the given
+queue. The signaling path for PCIe devices uses message signaled
+interrupts (MSI-X), that can route each interrupt to a particular CPU.
+The active mapping of queues to IRQs can be determined from
+/proc/interrupts. By default, all IRQs are routed to CPU0. Because a
+non-negligible part of packet processing takes place in receive
+interrupt handling, it is advantageous to spread receive interrupts
+between CPUs. To manually adjust the IRQ affinity of each interrupt see
+Documentation/IRQ-affinity. On some systems, the irqbalance daemon is
+running and will try to dynamically optimize this setting.
+
+
+RPS: Receive Packet Steering
+============================
+
+Receive Packet Steering (RPS) is logically a software implementation of
+RSS. Being in software, it is necessarily called later in the datapath.
+Whereas RSS selects the queue and hence CPU that will run the hardware
+interrupt handler, RPS selects the CPU to perform protocol processing
+above the interrupt handler. This is accomplished by placing the packet
+on the desired CPU’s backlog queue and waking up the CPU for processing.
+RPS has some advantages over RSS: 1) it can be used with any NIC, 2)
+software filters can easily be added to handle new protocols, 3) it does
+not increase hardware device interrupt rate (but does use IPIs).
+
+RPS is called during bottom half of the receive interrupt handler, when
+a driver sends a packet up the network stack with netif_rx() or
+netif_receive_skb(). These call the get_rps_cpu() function, which
+selects the queue that should process a packet.
+
+The first step in determining the target CPU for RPS is to calculate a
+flow hash over the packet’s addresses or ports (2-tuple or 4-tuple hash
+depending on the protocol). This serves as a consistent hash of the
+associated flow of the packet. The hash is either provided by hardware
+or will be computed in the stack. Capable hardware can pass the hash in
+the receive descriptor for the packet, this would usually be the same
+hash used for RSS (e.g. computed Toeplitz hash). The hash is saved in
+skb->rx_hash and can be used elsewhere in the stack as a hash of the
+packet’s flow.
+
+Each receive hardware qeueue has associated list of CPUs which can
+process packets received on the queue for RPS. For each received
+packet, an index into the list is computed from the flow hash modulo the
+size of the list. The indexed CPU is the target for processing the
+packet, and the packet is queued to the tail of that CPU’s backlog
+queue. At the end of the bottom half routine, inter-processor interrupts
+(IPIs) are sent to any CPUs for which packets have been queued to their
+backlog queue. The IPI wakes backlog processing on the remote CPU, and
+any queued packets are then processed up the networking stack. Note that
+the list of CPUs can be configured separately for each hardware receive
+queue.
+
+== RPS Configuration
+
+RPS requires a kernel compiled with the CONFIG_RPS flag (on by default
+for smp). Even when compiled in, it is disabled without any
+configuration. The list of CPUs to which RPS may forward traffic can be
+configured for each receive queue using the sysfs file entry:
+
+ /sys/class/net/<dev>/queues/rx-<n>/rps_cpus
+
+This file implements a bitmap of CPUs. RPS is disabled when it is zero
+(the default), in which case packets are processed on the interrupting
+CPU. IRQ-affinity.txt explains how CPUs are assigned to the bitmap.
+
+For a single queue device, a typical RPS configuration would be to set
+the rps_cpus to the CPUs in the same cache domain of the interrupting
+CPU for a queue. If NUMA locality is not an issue, this could also be
+all CPUs in the system. At high interrupt rate, it might wise to exclude
+the interrupting CPU from the map since that already performs much work.
+
+For a multi-queue system, if RSS is configured so that a receive queue
+is mapped to each CPU, then RPS is probably redundant and unnecessary.
+If there are fewer queues than CPUs, then RPS might be beneficial if the
+rps_cpus for each queue are the ones that share the same cache domain as
+the interrupting CPU for the queue.
+
+RFS: Receive Flow Steering
+==========================
+
+While RPS steers packet solely based on hash, and thus generally
+provides good load distribution, it does not take into account
+application locality. This is accomplished by Receive Flow Steering
+(RFS). The goal of RFS is to increase datacache hitrate by steering
+kernel processing of packets to the CPU where the application thread
+consuming the packet is running. RFS relies on the same RPS mechanisms
+to enqueue packets onto the backlog of another CPU and to wake that CPU.
+
+In RFS, packets are not forwarded directly by the value of their hash,
+but the hash is used as index into a flow lookup table. This table maps
+flows to the CPUs where those flows are being processed. The flow hash
+(see RPS section above) is used to calculate the index into this table.
+The CPU recorded in each entry is the one which last processed the flow,
+and if there is not a valid CPU for an entry, then packets mapped to
+that entry are steered using plain RPS.
+
+To avoid out of order packets (ie. when scheduler moves a thread with
+outstanding receive packets on) there are two levels of flow tables used
+by RFS: rps_sock_flow_table and rps_dev_flow_table.
+
+rps_sock_table is a global flow table. Each table value is a CPU index
+and is populated by recvmsg and sendmsg (specifically, inet_recvmsg(),
+inet_sendmsg(), inet_sendpage() and tcp_splice_read()). This table
+contains the *desired* CPUs for flows.
+
+rps_dev_flow_table is specific to each hardware receive queue of each
+device. Each table value stores a CPU index and a counter. The CPU
+index represents the *current* CPU that is assigned to processing the
+matching flows.
+
+The counter records the length of this CPU's backlog when a packet in
+this flow was last enqueued. Each backlog queue has a head counter that
+is incremented on dequeue. A tail counter is computed as head counter +
+queue length. In other words, the counter in rps_dev_flow_table[i]
+records the last element in flow i that has been enqueued onto the
+currently designated CPU for flow i (of course, entry i is actually
+selected by hash and multiple flows may hash to the same entry i).
+
+And now the trick for avoiding out of order packets: when selecting the
+CPU for packet processing (from get_rps_cpu()) the rps_sock_flow table
+and the rps_dev_flow table of the queue that the packet was received on
+are compared. If the desired CPU for the flow (found in the
+rps_sock_flow table) matches the current CPU (found in the rps_dev_flow
+table), the packet is enqueud onto that CPU’s backlog. If they differ,
+the current cpu is updated to match the desired CPU if one of the
+following is true:
+
+- The current CPU's queue head counter >= the recorded tail counter
+ value in rps_dev_flow[i]
+- The current CPU is unset (equal to NR_CPUS)
+- The current CPU is offline
+
+After this check, the packet is sent to the (possibly updated) current
+CPU. These rules aim to ensure that a flow only moves to a new CPU when
+there are no packets outstanding on the old CPU, as the outstanding
+packets could arrive later than those about to be processed on the new
+CPU.
+
+== RFS Configuration
+
+RFS is only available if the kernel flag CONFIG_RFS is enabled (on by
+default for smp). The functionality is disabled without any
+configuration. The number of entries in the global flow table is set
+through:
+
+ /proc/sys/net/core/rps_sock_flow_entries
+
+The number of entries in the per queue flow table are set through:
+
+ /sys/class/net/<dev>/queues/tx-<n>/rps_flow_cnt
+
+Both of these need to be set before RFS is enabled for a receive queue.
+Values for both of these are rounded up to the nearest power of two. The
+suggested flow count depends on the expected number active connections
+at any given time, which may be significantly less than the number of
+open connections. We have found that a value of 32768 for
+rps_sock_flow_entries works fairly well on a moderately loaded server.
+
+For a single queue device, the rps_flow_cnt value for the single queue
+would normally be configured to the same value as rps_sock_flow_entries.
+For a multi-queue device, the rps_flow_cnt for each queue might be
+configured as rps_sock_flow_entries / N, where N is the number of
+queues. So for instance, if rps_flow_entries is set to 32768 and there
+are 16 configured receive queues, rps_flow_cnt for each queue might be
+configured as 2048.
+
+
+Accelerated RFS
+===============
+
+Accelerated RFS is to RFS what RSS is to RPS: a hardware-accelerated
+load balancing mechanism that uses soft state to steer flows based on
+where the thread consuming the packets of each flow is running.
+Accelerated RFS should perform better than RFS since packets are sent
+directly to a CPU local to the thread consuming the data. The target CPU
+will either be the same CPU where the application runs, or at least a
+CPU which is local to the application thread’s CPU in the cache
+hierarchy.
+
+To enable accelerated RFS, the networking stack calls the
+ndo_rx_flow_steer driver function to communicate the desired hardware
+queue for packets matching a particular flow. The network stack
+automatically calls this function every time a flow entry in
+rps_dev_flow_table is updated. The driver in turn uses a device specific
+method to program the NIC to steer the packets.
+
+The hardware queue for a flow is derived from the CPU recorded in
+rps_dev_flow_table. The stack consults a CPU to hardware queue map which
+is maintained by the NIC driver. This is an autogenerated reverse map of
+the IRQ affinity table shown by /proc/interrupts. Drivers can use
+functions in the cpu_rmap (“cpu affinitiy reverse map”) kernel library
+to populate the map. For each CPU, the corresponding queue in the map is
+set to be one whose processing CPU is closest in cache locality.
+
+== Accelerated RFS Configuration
+
+Accelerated RFS is only available if the kernel is compiled with
+CONFIG_RFS_ACCEL and support is provided by the NIC device and driver.
+It also requires that ntuple filtering is enabled via ethtool. The map
+of CPU to queues is automatically deduced from the IRQ affinities
+configured for each receive queue by the driver, so no additional
+configuration should be necessary.
+
+XPS: Transmit Packet Steering
+=============================
+
+Transmit Packet Steering is a mechanism for intelligently selecting
+which transmit queue to use when transmitting a packet on a multi-queue
+device. To accomplish this, a mapping from CPU to hardware queue(s) is
+recorded. The goal of this mapping is usually to assign queues
+exclusively to a subset of CPUs, where the transmit completions for
+these queues are processed on a CPU within this set. This choice
+provides two benefits. First, contention on the device queue lock is
+significantly reduced since fewer CPUs contend for the same queue
+(contention can be eliminated completely if each CPU has its own
+transmit queue). Secondly, cache miss rate on transmit completion is
+reduced, in particular for data cache lines that hold the sk_buff
+structures.
+
+XPS is configured per transmit queue by setting a bitmap of CPUs that
+may use that queue to transmit. The reverse mapping, from CPUs to
+transmit queues, is computed and maintained for each network device.
+When transmitting the first packet in a flow, the function
+get_xps_queue() is called to select a queue. This function uses the ID
+of the running CPU as a key into the CPU to queue lookup table. If the
+ID matches a single queue, that is used for transmission. If multiple
+queues match, one is selected by using the flow hash to compute an index
+into the set.
+
+The queue chosen for transmitting a particular flow is saved in the
+corresponding socket structure for the flow (e.g. a TCP connection).
+This transmit queue is used for subsequent packets sent on the flow to
+prevent out of order (ooo) packets. The choice also amortizes the cost
+of calling get_xps_queues() over all packets in the connection. To avoid
+ooo packets, the queue for a flow can subsequently only be changed if
+skb->ooo_okay is set for a packet in the flow. This flag indicates that
+there are no outstanding packets in the flow, so the transmit queue can
+change without the risk of generating out of order packets. The
+transport layer is responsible for setting ooo_okay appropriately. TCP,
+for instance, sets the flag when all data for a connection has been
+acknowledged.
+
+
+== XPS Configuration
+
+XPS is only available if the kernel flag CONFIG_XPS is enabled (on by
+default for smp). The functionality is disabled without any
+configuration, in which case the the transmit queue for a packet is
+selected by using a flow hash as an index into the set of all transmit
+queues for the device. To enable XPS, the bitmap of CPUs that may use a
+transmit queue is configured using the sysfs file entry:
+
+/sys/class/net/<dev>/queues/tx-<n>/xps_cpus
+
+XPS is disabled when it is zero (the default). IRQ-affinity.txt explains
+how CPUs are assigned to the bitmap.
+
+For a network device with a single transmission queue, XPS configuration
+has no effect, since there is no choice in this case. In a multi-queue
+system, XPS is usually configured so that each CPU maps onto one queue.
+If there are as many queues as there are CPUs in the system, then each
+queue can also map onto one CPU, resulting in exclusive pairings that
+experience no contention. If there are fewer queues than CPUs, then the
+best CPUs to share a given queue are probably those that share the cache
+with the CPU that processes transmit completions for that queue
+(transmit interrupts).
+
+
+Further Information
+===================
+RPS and RFS were introduced in kernel 2.6.35. XPS was incorporated into
+2.6.38. Original patches were submitted by Tom Herbert
+(therbert@google.com)
+
+
+Accelerated RFS was introduced in 2.6.35. Original patches were
+submitted by Ben Hutchings (bhutchings@solarflare.com)
+
+Authors:
+Tom Herbert (therbert@google.com)
+Willem de Bruijn (willemb@google.com)
+
--
1.7.3.1
^ permalink raw reply related
* Re: net-next-2.6 [PATCH 0/7] dccp: add support for dynamic parameter updates
From: David Miller @ 2011-08-01 7:10 UTC (permalink / raw)
To: gerrit; +Cc: dccp, netdev
In-Reply-To: <1311600996-6712-1-git-send-email-gerrit@erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Mon, 25 Jul 2011 07:36:29 -0600
> I have also placed this in into a fresh (today's) copy of net-next-2.6, on
>
> git://eden-feed.erg.abdn.ac.uk/net-next-2.6 [subtree 'dccp']
I did a test pull and this URL doesn't work:
[davem@dokdo net-next]$ git pull git://eden-feed.erg.abdn.ac.uk/net-next-2.6 dccp
fatal: The remote end hung up unexpectedly
[davem@dokdo net-next]$ git pull git://eden-feed.erg.abdn.ac.uk/net-next-2.6
fatal: The remote end hung up unexpectedly
[davem@dokdo net-next]$
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] be2net: cleanup and refactor stats code
From: David Miller @ 2011-08-01 8:54 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <1311657015-23465-2-git-send-email-sathya.perla@emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Tue, 26 Jul 2011 10:40:14 +0530
> In preparation for 64-bit stats interface, the following cleanups help
> streamline the code:
> 1) made some more rx/tx stats stored by driver 64 bit
> 2) made some HW stas (err/drop counters) stored in be_drv_stats 32 bit to
> keep the code simple as BE provides 32-bit counters only.
> 3) removed duplication of netdev stats in ethtool
> 4) removed some un-necessary stats and fixed some names
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/2] be2net: use stats-sync to read/write 64-bit stats
From: David Miller @ 2011-08-01 8:55 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <1311657015-23465-3-git-send-email-sathya.perla@emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Tue, 26 Jul 2011 10:40:15 +0530
> 64-bit stats in be2net are written/read as follows using the stats-sync
> interface for safe access in 32-bit archs:
>
> 64-bit sync writer reader
> stats
> ------------------------------------------------------------------------------
> tx_stats tx_stats->sync be_xmit be_get_stats64,
> ethtool
> tx-compl tx_stats->sync_compl tx-compl-processing ethtool
> rx-stats rx_stats->sync rx-compl-processing be_get_stats64,
> ethtool,
> eqd-update
>
> This patch is based on Stephen Hemminger's earlier patch on the same issue...
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH] ipv6: some RCU conversions
From: David Miller @ 2011-08-01 8:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1311837183.2697.37.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 28 Jul 2011 09:13:03 +0200
> ICMP and ND are not fast path, but still we can avoid changing idev
> refcount, using RCU.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH] ipv6: use RCU in inet6_csk_xmit()
From: David Miller @ 2011-08-01 8:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1311860627.2346.9.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 28 Jul 2011 15:43:47 +0200
> Use RCU to avoid changing dst_entry refcount in fast path.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH] ipv6: avoid a dst_entry refcount change in ipv6_destopt_rcv()
From: David Miller @ 2011-08-01 8:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1311861635.2346.14.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 28 Jul 2011 16:00:35 +0200
> ipv6_destopt_rcv() runs with rcu_read_lock(), so there is no need to
> take a temporay reference on dst_entry, even if skb is freed by
> ip6_parse_tlv()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH] ip6tnl: avoid touching dst refcount in ip6_tnl_xmit2()
From: David Miller @ 2011-08-01 8:56 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1311863545.2346.21.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 28 Jul 2011 16:32:25 +0200
> Even using percpu stats, we still hit tunnel dst_entry refcount in
> ip6_tnl_xmit2()
>
> Since we are in RCU locked section, we can use skb_dst_set_noref() and
> avoid these atomic operations, leaving dst shared on cpus.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH net-next 0/5] qlcnic: Fixes and debug support
From: David Miller @ 2011-08-01 8:57 UTC (permalink / raw)
To: anirban.chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1311982230-10543-6-git-send-email-anirban.chakraborty@qlogic.com>
From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Date: Fri, 29 Jul 2011 16:30:30 -0700
> Please apply the series to net-next. Thanks.
Queued up for net-next
^ permalink raw reply
* Re: [PATCH 1/2] bna: Remove Unnecessary CNA Check
From: David Miller @ 2011-08-01 8:56 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <1311889767-9848-1-git-send-email-rmody@brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Thu, 28 Jul 2011 14:49:26 -0700
> Change details:
> - ioc->cna is always set to 1 for eth functions, remove the check that
> asserts IOC is in CNA mode in bfa_ioc_firmware_lock() and
> bfa_ioc_firmware_unlock() in bfa_ioc_ct.c.
>
> Signed-off-by: Rasesh Mody <rmody@brocade.com>
Queued up for net-next
^ 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