Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6

---------------------------

What:	SCTP_GET_PEER_ADDRS_NUM_OLD, SCTP_GET_PEER_ADDRS_OLD,

	SCTP_GET_LOCAL_ADDRS_NUM_OLD, SCTP_GET_LOCAL_ADDRS_OLD

When: 	June 2009

Why:    A newer version of the options have been introduced in 2005 that

	removes the limitions of the old API.  The sctp library has been

        converted to use these new options at the same time.  Any user

	space app that directly uses the old options should convert to using

	the new options.

Who:	Vlad Yasevich <vladislav.yasevich@hp.com>

---------------------------

What:	CONFIG_THERMAL_HWMON

When:	January 2009

Why:	This option was introduced just to allow older lm-sensors userspace

	to keep working over the upgrade to 2.6.26. At the scheduled time of

	removal fixed lm-sensors (2.x or 3.x) should be readily available.

Who:	Rene Herman <rene.herman@gmail.com>

---------------------------

What:	Code that is now under CONFIG_WIRELESS_EXT_SYSFS

	(in net/core/net-sysfs.c)

When:	After the only user (hal) has seen a release with the patches

	for enough time, probably some time in 2010.

Why:	Over 1K .text/.data size reduction, data is available in other

	ways (ioctls)

Who:	Johannes Berg <johannes@sipsolutions.net>

fail_over_mac

	Specifies whether active-backup mode should set all slaves to

	the same MAC address (the traditional behavior), or, when

	enabled, change the bond's MAC address when changing the

	active interface (i.e., fail over the MAC address itself).

	Fail over MAC is useful for devices that cannot ever alter

	their MAC address, or for devices that refuse incoming

	broadcasts with their own source MAC (which interferes with

	the ARP monitor).

	The down side of fail over MAC is that every device on the

	network must be updated via gratuitous ARP, vs. just updating

	a switch or set of switches (which often takes place for any

	traffic, not just ARP traffic, if the switch snoops incoming

	traffic to update its tables) for the traditional method.  If

	the gratuitous ARP is lost, communication may be disrupted.

	When fail over MAC is used in conjuction with the mii monitor,

	devices which assert link up prior to being able to actually

	transmit and receive are particularly susecptible to loss of

	the gratuitous ARP, and an appropriate updelay setting may be

	required.

	A value of 0 disables fail over MAC, and is the default.  A

	value of 1 enables fail over MAC.  This option is enabled

	automatically if the first slave added cannot change its MAC

	address.  This option may be modified via sysfs only when no

	slaves are present in the bond.

	This option was added in bonding version 3.2.0.

	the same MAC address at enslavement (the traditional

	behavior), or, when enabled, perform special handling of the

	bond's MAC address in accordance with the selected policy.

	Possible values are:

	none or 0

		This setting disables fail_over_mac, and causes

		bonding to set all slaves of an active-backup bond to

		the same MAC address at enslavement time.  This is the

		default.

	active or 1

		The "active" fail_over_mac policy indicates that the

		MAC address of the bond should always be the MAC

		address of the currently active slave.  The MAC

		address of the slaves is not changed; instead, the MAC

		address of the bond changes during a failover.

		This policy is useful for devices that cannot ever

		alter their MAC address, or for devices that refuse

		incoming broadcasts with their own source MAC (which

		interferes with the ARP monitor).

		The down side of this policy is that every device on

		the network must be updated via gratuitous ARP,

		vs. just updating a switch or set of switches (which

		often takes place for any traffic, not just ARP

		traffic, if the switch snoops incoming traffic to

		update its tables) for the traditional method.  If the

		gratuitous ARP is lost, communication may be

		disrupted.

		When this policy is used in conjuction with the mii

		monitor, devices which assert link up prior to being

		able to actually transmit and receive are particularly

		susecptible to loss of the gratuitous ARP, and an

		appropriate updelay setting may be required.

	follow or 2

		The "follow" fail_over_mac policy causes the MAC

		address of the bond to be selected normally (normally

		the MAC address of the first slave added to the bond).

		However, the second and subsequent slaves are not set

		to this MAC address while they are in a backup role; a

		slave is programmed with the bond's MAC address at

		failover time (and the formerly active slave receives

		the newly active slave's MAC address).

		This policy is useful for multiport devices that

		either become confused or incur a performance penalty

		when multiple ports are programmed with the same MAC

		address.

	The default policy is none, unless the first slave cannot

	change its MAC address, in which case the active policy is

	selected by default.

	This option may be modified via sysfs only when no slaves are

	present in the bond.

	This option was added in bonding version 3.2.0.  The "follow"

	policy was added in bonding version 3.3.0.

lacp_rate

	Specifies the number of bonding devices to create for this

	instance of the bonding driver.  E.g., if max_bonds is 3, and

	the bonding driver is not already loaded, then bond0, bond1

	and bond2 will be created.  The default value is 1.

	and bond2 will be created.  The default value is 1.  Specifying

	a value of 0 will load bonding, but will not create any devices.

miimon

		swapped with the new curr_active_slave that was

		chosen.

num_grat_arp

	Specifies the number of gratuitous ARPs to be issued after a

	failover event.  One gratuitous ARP is issued immediately after

	the failover, subsequent ARPs are sent at a rate of one per link

	monitor interval (arp_interval or miimon, whichever is active).

	The valid range is 0 - 255; the default value is 1.  This option

	affects only the active-backup mode.  This option was added for

	bonding version 3.3.0.

primary

	A string (eth0, eth2, etc) specifying which slave is the

DM9000 Network driver

=====================

Copyright 2008 Simtec Electronics,

	  Ben Dooks <ben@simtec.co.uk> <ben-linux@fluff.org>

Introduction

------------

This file describes how to use the DM9000 platform-device based network driver

that is contained in the files drivers/net/dm9000.c and drivers/net/dm9000.h.

The driver supports three DM9000 variants, the DM9000E which is the first chip

supported as well as the newer DM9000A and DM9000B devices. It is currently

maintained and tested by Ben Dooks, who should be CC: to any patches for this

driver.

Defining the platform device

----------------------------

The minimum set of resources attached to the platform device are as follows:

    1) The physical address of the address register

    2) The physical address of the data register

    3) The IRQ line the device's interrupt pin is connected to.

These resources should be specified in that order, as the ordering of the

two address regions is important (the driver expects these to be address

and then data).

An example from arch/arm/mach-s3c2410/mach-bast.c is:

static struct resource bast_dm9k_resource[] = {

	[0] = {

		.start = S3C2410_CS5 + BAST_PA_DM9000,

		.end   = S3C2410_CS5 + BAST_PA_DM9000 + 3,

		.flags = IORESOURCE_MEM,

	},

	[1] = {

		.start = S3C2410_CS5 + BAST_PA_DM9000 + 0x40,

		.end   = S3C2410_CS5 + BAST_PA_DM9000 + 0x40 + 0x3f,

		.flags = IORESOURCE_MEM,

	},

	[2] = {

		.start = IRQ_DM9000,

		.end   = IRQ_DM9000,

		.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,

	}

};

static struct platform_device bast_device_dm9k = {

	.name		= "dm9000",

	.id		= 0,

	.num_resources	= ARRAY_SIZE(bast_dm9k_resource),

	.resource	= bast_dm9k_resource,

};

Note the setting of the IRQ trigger flag in bast_dm9k_resource[2].flags,

as this will generate a warning if it is not present. The trigger from

the flags field will be passed to request_irq() when registering the IRQ

handler to ensure that the IRQ is setup correctly.

This shows a typical platform device, without the optional configuration

platform data supplied. The next example uses the same resources, but adds

the optional platform data to pass extra configuration data:

static struct dm9000_plat_data bast_dm9k_platdata = {

	.flags		= DM9000_PLATF_16BITONLY,

};

static struct platform_device bast_device_dm9k = {

	.name		= "dm9000",

	.id		= 0,

	.num_resources	= ARRAY_SIZE(bast_dm9k_resource),

	.resource	= bast_dm9k_resource,

	.dev		= {

		.platform_data = &bast_dm9k_platdata,

	}

};

The platform data is defined in include/linux/dm9000.h and described below.

Platform data

-------------

Extra platform data for the DM9000 can describe the IO bus width to the

device, whether or not an external PHY is attached to the device and

the availability of an external configuration EEPROM.

The flags for the platform data .flags field are as follows:

DM9000_PLATF_8BITONLY

	The IO should be done with 8bit operations.

DM9000_PLATF_16BITONLY

	The IO should be done with 16bit operations.

DM9000_PLATF_32BITONLY

	The IO should be done with 32bit operations.

DM9000_PLATF_EXT_PHY

	The chip is connected to an external PHY.

DM9000_PLATF_NO_EEPROM

	This can be used to signify that the board does not have an

	EEPROM, or that the EEPROM should be hidden from the user.

DM9000_PLATF_SIMPLE_PHY

	Switch to using the simpler PHY polling method which does not

	try and read the MII PHY state regularly. This is only available

	when using the internal PHY. See the section on link state polling

	for more information.

	The config symbol DM9000_FORCE_SIMPLE_PHY_POLL, Kconfig entry

	"Force simple NSR based PHY polling" allows this flag to be

	forced on at build time.

PHY Link state polling

----------------------

The driver keeps track of the link state and informs the network core

about link (carrier) availablilty. This is managed by several methods

depending on the version of the chip and on which PHY is being used.

For the internal PHY, the original (and currently default) method is

to read the MII state, either when the status changes if we have the

necessary interrupt support in the chip or every two seconds via a

periodic timer.

To reduce the overhead for the internal PHY, there is now the option

of using the DM9000_FORCE_SIMPLE_PHY_POLL config, or DM9000_PLATF_SIMPLE_PHY

platform data option to read the summary information without the

expensive MII accesses. This method is faster, but does not print

as much information.

When using an external PHY, the driver currently has to poll the MII

link status as there is no method for getting an interrupt on link change.

DM9000A / DM9000B

-----------------

These chips are functionally similar to the DM9000E and are supported easily

by the same driver. The features are:

   1) Interrupt on internal PHY state change. This means that the periodic

      polling of the PHY status may be disabled on these devices when using

      the internal PHY.

   2) TCP/UDP checksum offloading, which the driver does not currently support.

ethtool

-------

The driver supports the ethtool interface for access to the driver

state information, the PHY state and the EEPROM.

icmp_ratelimit - INTEGER

	Limit the maximal rates for sending ICMP packets whose type matches

	icmp_ratemask (see below) to specific targets.

	0 to disable any limiting, otherwise the maximal rate in jiffies(1)

	Default: 100

	0 to disable any limiting,

	otherwise the minimal space between responses in milliseconds.

	Default: 1000

icmp_ratemask - INTEGER

	Mask made of ICMP types for which rates are being limited.

	autoconfigured addresses.

	Default: 16

disable_ipv6 - BOOLEAN

	Disable IPv6 operation.

	Default: FALSE (enable IPv6 operation)

accept_dad - INTEGER

	Whether to accept DAD (Duplicate Address Detection).

	0: Disable DAD

	1: Enable DAD (default)

	2: Enable DAD, and disable IPv6 operation if MAC-based duplicate

	   link-local address has been found.

icmp/*:

ratelimit - INTEGER

	Limit the maximal rates for sending ICMPv6 packets.

	0 to disable any limiting, otherwise the maximal rate in jiffies(1)

	Default: 100

	0 to disable any limiting,

	otherwise the minimal space between responses in milliseconds.

	Default: 1000

IPv6 Update by: