Merge 3.14-rc4 into staging-next.

Contact:	Kay Sievers <kay.sievers@vrfy.org>

Description:

		 Shows the list of currently configured

		 tty devices used for the console,

		 like 'tty1 ttyS0'.

		 console devices, like 'tty1 ttyS0'.

		 The last entry in the file is the active

		 device connected to /dev/console.

		 The file supports poll() to detect virtual

has to request that the PCI layer set up the MSI capability for this

device.

4.2.1 pci_enable_msi_range

4.2.1 pci_enable_msi

int pci_enable_msi(struct pci_dev *dev)

A successful call allocates ONE interrupt to the device, regardless

of how many MSIs the device supports.  The device is switched from

pin-based interrupt mode to MSI mode.  The dev->irq number is changed

to a new number which represents the message signaled interrupt;

consequently, this function should be called before the driver calls

request_irq(), because an MSI is delivered via a vector that is

different from the vector of a pin-based interrupt.

4.2.2 pci_enable_msi_range

int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec)

	return pci_enable_msi_range(pdev, nvec, nvec);

}

Note, unlike pci_enable_msi_exact() function, which could be also used to

enable a particular number of MSI-X interrupts, pci_enable_msi_range()

returns either a negative errno or 'nvec' (not negative errno or 0 - as

pci_enable_msi_exact() does).

4.2.1.3 Single MSI mode

The most notorious example of the request type described above is

	return pci_enable_msi_range(pdev, 1, 1);

}

4.2.2 pci_disable_msi

Note, unlike pci_enable_msi() function, which could be also used to

enable the single MSI mode, pci_enable_msi_range() returns either a

negative errno or 1 (not negative errno or 0 - as pci_enable_msi()

does).

4.2.3 pci_enable_msi_exact

int pci_enable_msi_exact(struct pci_dev *dev, int nvec)

This variation on pci_enable_msi_range() call allows a device driver to

request exactly 'nvec' MSIs.

If this function returns a negative number, it indicates an error and

the driver should not attempt to request any more MSI interrupts for

this device.

By contrast with pci_enable_msi_range() function, pci_enable_msi_exact()

returns zero in case of success, which indicates MSI interrupts have been

successfully allocated.

4.2.4 pci_disable_msi

void pci_disable_msi(struct pci_dev *dev)

Failure to do so results in a BUG_ON(), leaving the device with

MSI enabled and thus leaking its vector.

4.2.3 pci_msi_vec_count

4.2.4 pci_msi_vec_count

int pci_msi_vec_count(struct pci_dev *dev)

static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)

{

	return pci_enable_msi_range(adapter->pdev, adapter->msix_entries,

	return pci_enable_msix_range(adapter->pdev, adapter->msix_entries,

				     1, nvec);

}

static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)

{

	return pci_enable_msi_range(adapter->pdev, adapter->msix_entries,

	return pci_enable_msix_range(adapter->pdev, adapter->msix_entries,

				     FOO_DRIVER_MINIMUM_NVEC, nvec);

}

static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)

{

	return pci_enable_msi_range(adapter->pdev, adapter->msix_entries,

	return pci_enable_msix_range(adapter->pdev, adapter->msix_entries,

				     nvec, nvec);

}

Note, unlike pci_enable_msix_exact() function, which could be also used to

enable a particular number of MSI-X interrupts, pci_enable_msix_range()

returns either a negative errno or 'nvec' (not negative errno or 0 - as

pci_enable_msix_exact() does).

4.3.1.3 Specific requirements to the number of MSI-X interrupts

As noted above, there could be devices that can not operate with just any

any error code other than -ENOSPC indicates a fatal error and should not

be retried.

4.3.2 pci_disable_msix

4.3.2 pci_enable_msix_exact

int pci_enable_msix_exact(struct pci_dev *dev,

			  struct msix_entry *entries, int nvec)

This variation on pci_enable_msix_range() call allows a device driver to

request exactly 'nvec' MSI-Xs.

If this function returns a negative number, it indicates an error and

the driver should not attempt to allocate any more MSI-X interrupts for

this device.

By contrast with pci_enable_msix_range() function, pci_enable_msix_exact()

returns zero in case of success, which indicates MSI-X interrupts have been

successfully allocated.

Another version of a routine that enables MSI-X mode for a device with

specific requirements described in chapter 4.3.1.3 might look like this:

/*

 * Assume 'minvec' and 'maxvec' are non-zero

 */

static int foo_driver_enable_msix(struct foo_adapter *adapter,

				  int minvec, int maxvec)

{

	int rc;

	minvec = roundup_pow_of_two(minvec);

	maxvec = rounddown_pow_of_two(maxvec);

	if (minvec > maxvec)

		return -ERANGE;

retry:

	rc = pci_enable_msix_exact(adapter->pdev,

				   adapter->msix_entries, maxvec);

	/*

	 * -ENOSPC is the only error code allowed to be analyzed

	 */

	if (rc == -ENOSPC) {

		if (maxvec == 1)

			return -ENOSPC;

		maxvec /= 2;

		if (minvec > maxvec)

			return -ENOSPC;

		goto retry;

	} else if (rc < 0) {

		return rc;

	}

	return maxvec;

}

4.3.3 pci_disable_msix

void pci_disable_msix(struct pci_dev *dev)

  compatible = "ti,omap3-beagle", "ti,omap3"

- OMAP3 Tobi with Overo : Commercial expansion board with daughter board

  compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3"

  compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3"

- OMAP4 SDP : Software Development Board

  compatible = "ti,omap4-sdp", "ti,omap4430"

STMicroelectronics SoC DWMAC glue layer controller

The device node has following properties.

Required properties:

 - compatible	: Can be "st,stih415-dwmac", "st,stih416-dwmac" or

   "st,stid127-dwmac".

 - reg		: Offset of the glue configuration register map in system

   configuration regmap pointed by st,syscon property and size.

 - reg-names	: Should be "sti-ethconf".

 - st,syscon	: Should be phandle to system configuration node which

   encompases this glue registers.

 - st,tx-retime-src: On STi Parts for Giga bit speeds, 125Mhz clocks can be

   wired up in from different sources. One via TXCLK pin and other via CLK_125

   pin. This wiring is totally board dependent. However the retiming glue

   logic should be configured accordingly. Possible values for this property

	   "txclk" - if 125Mhz clock is wired up via txclk line.

	   "clk_125" - if 125Mhz clock is wired up via clk_125 line.

   This property is only valid for Giga bit setup( GMII, RGMII), and it is

   un-used for non-giga bit (MII and RMII) setups. Also note that internal

   clockgen can not generate stable 125Mhz clock.

 - st,ext-phyclk: This boolean property indicates who is generating the clock

  for tx and rx. This property is only valid for RMII case where the clock can

  be generated from the MAC or PHY.

 - clock-names: should be "sti-ethclk".

 - clocks: Should point to ethernet clockgen which can generate phyclk.

Example:

ethernet0: dwmac@fe810000 {

	device_type 	= "network";

	compatible	= "st,stih416-dwmac", "snps,dwmac", "snps,dwmac-3.710";

	reg 		= <0xfe810000 0x8000>, <0x8bc 0x4>;

	reg-names	= "stmmaceth", "sti-ethconf";

	interrupts	= <0 133 0>, <0 134 0>, <0 135 0>;

	interrupt-names	= "macirq", "eth_wake_irq", "eth_lpi";

	phy-mode	= "mii";

	st,syscon	= <&syscfg_rear>;

	snps,pbl 	= <32>;

	snps,mixed-burst;

	resets		= <&softreset STIH416_ETH0_SOFTRESET>;

	reset-names	= "stmmaceth";

	pinctrl-0	= <&pinctrl_mii0>;

	pinctrl-names 	= "default";

	clocks		= <&CLK_S_GMAC0_PHY>;

	clock-names	= "stmmaceth";

};

The 3Com Etherlink Plus (3c505) driver.

This driver now uses DMA.  There is currently no support for PIO operation.

The default DMA channel is 6; this is _not_ autoprobed, so you must

make sure you configure it correctly.  If loading the driver as a

module, you can do this with "modprobe 3c505 dma=n".  If the driver is

linked statically into the kernel, you must either use an "ether="

statement on the command line, or change the definition of ELP_DMA in 3c505.h.

The driver will warn you if it has to fall back on the compiled in

default DMA channel. 

If no base address is given at boot time, the driver will autoprobe

ports 0x300, 0x280 and 0x310 (in that order).  If no IRQ is given, the driver

will try to probe for it.

The driver can be used as a loadable module.

Theoretically, one instance of the driver can now run multiple cards,

in the standard way (when loading a module, say "modprobe 3c505

io=0x300,0x340 irq=10,11 dma=6,7" or whatever).  I have not tested

this, though.

The driver may now support revision 2 hardware; the dependency on

being able to read the host control register has been removed.  This

is also untested, since I don't have a suitable card.

Known problems:

 I still see "DMA upload timed out" messages from time to time.  These

seem to be fairly non-fatal though.

 The card is old and slow.

To do:

 Improve probe/setup code

 Test multicast and promiscuous operation

Authors:

 The driver is mainly written by Craig Southeren, email

 <craigs@ineluki.apana.org.au>.

 Parts of the driver (adapting the driver to 1.1.4+ kernels,

 IRQ/address detection, some changes) and this README by

 Juha Laiho <jlaiho@ichaos.nullnet.fi>.

 DMA mode, more fixes, etc, by Philip Blundell <pjb27@cam.ac.uk>

 Multicard support, Software configurable DMA, etc., by

 Christopher Collins <ccollins@pcug.org.au>