openkylin
/
linux
mirror of https://gitee.com/openkylin/linux.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into mips-for-linux-next 

Conflicts:
    include/linux/ssb/ssb_driver_gige.h

Also resolves a logical merge conflict in drivers/net/ethernet/broadcom/-
bgmac.c due to change of an API.
This commit is contained in:
Ralf Baechle 2013-02-21 16:16:55 +01:00
parent 8bfc245f9a a0b1c42951
commit edb15d83a8
2761 changed files with 162944 additions and 85692 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
Documentation/ABI/testing/sysfs-bus-event_source-devices-events Normal file
View File

@ -0,0 +1,62 @@
What: /sys/devices/cpu/events/
/sys/devices/cpu/events/branch-misses
/sys/devices/cpu/events/cache-references
/sys/devices/cpu/events/cache-misses
/sys/devices/cpu/events/stalled-cycles-frontend
/sys/devices/cpu/events/branch-instructions
/sys/devices/cpu/events/stalled-cycles-backend
/sys/devices/cpu/events/instructions
/sys/devices/cpu/events/cpu-cycles
Date: 2013/01/08
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Generic performance monitoring events
A collection of performance monitoring events that may be
supported by many/most CPUs. These events can be monitored
using the 'perf(1)' tool.
The contents of each file would look like:
event=0xNNNN
where 'N' is a hex digit and the number '0xNNNN' shows the
"raw code" for the perf event identified by the file's
"basename".
What: /sys/devices/cpu/events/PM_LD_MISS_L1
/sys/devices/cpu/events/PM_LD_REF_L1
/sys/devices/cpu/events/PM_CYC
/sys/devices/cpu/events/PM_BRU_FIN
/sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
/sys/devices/cpu/events/PM_BRU_MPRED
/sys/devices/cpu/events/PM_INST_CMPL
/sys/devices/cpu/events/PM_CMPLU_STALL
Date: 2013/01/08
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Linux Powerpc mailing list <linuxppc-dev@ozlabs.org>
Description: POWER-systems specific performance monitoring events
A collection of performance monitoring events that may be
supported by the POWER CPU. These events can be monitored
using the 'perf(1)' tool.
These events may not be supported by other CPUs.
The contents of each file would look like:
event=0xNNNN
where 'N' is a hex digit and the number '0xNNNN' shows the
"raw code" for the perf event identified by the file's
"basename".
Further, multiple terms like 'event=0xNNNN' can be specified
and separated with comma. All available terms are defined in
the /sys/bus/event_source/devices/<dev>/format file.

13
Documentation/ABI/testing/sysfs-devices-power_resources_D0 Normal file
View File

@ -0,0 +1,13 @@
What: /sys/devices/.../power_resources_D0/
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../power_resources_D0/ directory is only
present for device objects representing ACPI device nodes that
use ACPI power resources for power management.
If present, it contains symbolic links to device directories
representing ACPI power resources that need to be turned on for
the given device node to be in ACPI power state D0. The names
of the links are the same as the names of the directories they
point to.

14
Documentation/ABI/testing/sysfs-devices-power_resources_D1 Normal file
View File

@ -0,0 +1,14 @@
What: /sys/devices/.../power_resources_D1/
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../power_resources_D1/ directory is only
present for device objects representing ACPI device nodes that
use ACPI power resources for power management and support ACPI
power state D1.
If present, it contains symbolic links to device directories
representing ACPI power resources that need to be turned on for
the given device node to be in ACPI power state D1. The names
of the links are the same as the names of the directories they
point to.

14
Documentation/ABI/testing/sysfs-devices-power_resources_D2 Normal file
View File

@ -0,0 +1,14 @@
What: /sys/devices/.../power_resources_D2/
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../power_resources_D2/ directory is only
present for device objects representing ACPI device nodes that
use ACPI power resources for power management and support ACPI
power state D2.
If present, it contains symbolic links to device directories
representing ACPI power resources that need to be turned on for
the given device node to be in ACPI power state D2. The names
of the links are the same as the names of the directories they
point to.

14
Documentation/ABI/testing/sysfs-devices-power_resources_D3hot Normal file
View File

@ -0,0 +1,14 @@
What: /sys/devices/.../power_resources_D3hot/
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../power_resources_D3hot/ directory is only
present for device objects representing ACPI device nodes that
use ACPI power resources for power management and support ACPI
power state D3hot.
If present, it contains symbolic links to device directories
representing ACPI power resources that need to be turned on for
the given device node to be in ACPI power state D3hot. The
names of the links are the same as the names of the directories
they point to.

20
Documentation/ABI/testing/sysfs-devices-power_state Normal file
View File

@ -0,0 +1,20 @@
What: /sys/devices/.../power_state
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../power_state attribute is only present for
device objects representing ACPI device nodes that provide power
management methods.
If present, it contains a string representing the current ACPI
power state of the given device node. Its possible values,
"D0", "D1", "D2", "D3hot", and "D3cold", reflect the power state
names defined by the ACPI specification (ACPI 4 and above).
If the device node uses shared ACPI power resources, this state
determines a list of power resources required not to be turned
off. However, some power resources needed by the device node in
higher-power (lower-number) states may also be ON because of
some other devices using them at the moment.
This attribute is read-only.

23
Documentation/ABI/testing/sysfs-devices-real_power_state Normal file
View File

@ -0,0 +1,23 @@
What: /sys/devices/.../real_power_state
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../real_power_state attribute is only present
for device objects representing ACPI device nodes that provide
power management methods and use ACPI power resources for power
management.
If present, it contains a string representing the real ACPI
power state of the given device node as returned by the _PSC
control method or inferred from the configuration of power
resources. Its possible values, "D0", "D1", "D2", "D3hot", and
"D3cold", reflect the power state names defined by the ACPI
specification (ACPI 4 and above).
In some situations the value of this attribute may be different
from the value of the /sys/devices/.../power_state attribute for
the same device object. If that happens, some shared power
resources used by the device node are only ON because of some
other devices using them at the moment.
This attribute is read-only.

12
Documentation/ABI/testing/sysfs-devices-resource_in_use Normal file
View File

@ -0,0 +1,12 @@
What: /sys/devices/.../resource_in_use
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../resource_in_use attribute is only present
for device objects representing ACPI power resources.
If present, it contains a number (0 or 1) representing the
current status of the given power resource (0 means that the
resource is not in use and therefore it has been turned off).
This attribute is read-only.

47
Documentation/ABI/testing/sysfs-platform-ts5500 Normal file
View File

@ -0,0 +1,47 @@
What: /sys/devices/platform/ts5500/adc
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Indicates the presence of an A/D Converter. If it is present,
it will display "1", otherwise "0".
What: /sys/devices/platform/ts5500/ereset
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Indicates the presence of an external reset. If it is present,
it will display "1", otherwise "0".
What: /sys/devices/platform/ts5500/id
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Product ID of the TS board. TS-5500 ID is 0x60.
What: /sys/devices/platform/ts5500/jumpers
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Bitfield showing the jumpers' state. If a jumper is present,
the corresponding bit is set. For instance, 0x0e means jumpers
2, 3 and 4 are set.
What: /sys/devices/platform/ts5500/rs485
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Indicates the presence of the RS485 option. If it is present,
it will display "1", otherwise "0".
What: /sys/devices/platform/ts5500/sram
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Indicates the presence of the SRAM option. If it is present,
it will display "1", otherwise "0".

4
Documentation/DocBook/80211.tmpl
View File

@ -107,8 +107,8 @@
!Finclude/net/cfg80211.h key_params
!Finclude/net/cfg80211.h survey_info_flags
!Finclude/net/cfg80211.h survey_info
!Finclude/net/cfg80211.h beacon_parameters
!Finclude/net/cfg80211.h plink_actions
!Finclude/net/cfg80211.h cfg80211_beacon_data
!Finclude/net/cfg80211.h cfg80211_ap_settings
!Finclude/net/cfg80211.h station_parameters
!Finclude/net/cfg80211.h station_info_flags
!Finclude/net/cfg80211.h rate_info_flags

37
Documentation/PCI/MSI-HOWTO.txt
View File

@ -127,15 +127,42 @@ on the number of vectors that can be allocated; pci_enable_msi_block()
returns as soon as it finds any constraint that doesn't allow the
call to succeed.
4.2.3 pci_disable_msi
4.2.3 pci_enable_msi_block_auto
int pci_enable_msi_block_auto(struct pci_dev *dev, unsigned int *count)
This variation on pci_enable_msi() call allows a device driver to request
the maximum possible number of MSIs. The MSI specification only allows
interrupts to be allocated in powers of two, up to a maximum of 2^5 (32).
If this function returns a positive number, it indicates that it has
succeeded and the returned value is the number of allocated interrupts. In
this case, the function enables MSI on this device and updates dev->irq to
be the lowest of the new interrupts assigned to it. The other interrupts
assigned to the device are in the range dev->irq to dev->irq + returned
value - 1.
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.
If the device driver needs to know the number of interrupts the device
supports it can pass the pointer count where that number is stored. The
device driver must decide what action to take if pci_enable_msi_block_auto()
succeeds, but returns a value less than the number of interrupts supported.
If the device driver does not need to know the number of interrupts
supported, it can set the pointer count to NULL.
4.2.4 pci_disable_msi
void pci_disable_msi(struct pci_dev *dev)
This function should be used to undo the effect of pci_enable_msi() or
pci_enable_msi_block(). Calling it restores dev->irq to the pin-based
interrupt number and frees the previously allocated message signaled
interrupt(s). The interrupt may subsequently be assigned to another
device, so drivers should not cache the value of dev->irq.
pci_enable_msi_block() or pci_enable_msi_block_auto(). Calling it restores
dev->irq to the pin-based interrupt number and frees the previously
allocated message signaled interrupt(s). The interrupt may subsequently be
assigned to another device, so drivers should not cache the value of
dev->irq.
Before calling this function, a device driver must always call free_irq()
on any interrupt for which it previously called request_irq().

4
Documentation/acpi/enumeration.txt
View File

@ -63,8 +63,8 @@ from ACPI tables.
Currently the kernel is not able to automatically determine from which ACPI
device it should make the corresponding platform device so we need to add
the ACPI device explicitly to acpi_platform_device_ids list defined in
drivers/acpi/scan.c. This limitation is only for the platform devices, SPI
and I2C devices are created automatically as described below.
drivers/acpi/acpi_platform.c. This limitation is only for the platform
devices, SPI and I2C devices are created automatically as described below.
SPI serial bus support
~~~~~~~~~~~~~~~~~~~~~~

77
Documentation/acpi/scan_handlers.txt Normal file
View File

@ -0,0 +1,77 @@
ACPI Scan Handlers
Copyright (C) 2012, Intel Corporation
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
During system initialization and ACPI-based device hot-add, the ACPI namespace
is scanned in search of device objects that generally represent various pieces
of hardware. This causes a struct acpi_device object to be created and
registered with the driver core for every device object in the ACPI namespace
and the hierarchy of those struct acpi_device objects reflects the namespace
layout (i.e. parent device objects in the namespace are represented by parent
struct acpi_device objects and analogously for their children). Those struct
acpi_device objects are referred to as "device nodes" in what follows, but they
should not be confused with struct device_node objects used by the Device Trees
parsing code (although their role is analogous to the role of those objects).
During ACPI-based device hot-remove device nodes representing pieces of hardware
being removed are unregistered and deleted.
The core ACPI namespace scanning code in drivers/acpi/scan.c carries out basic
initialization of device nodes, such as retrieving common configuration
information from the device objects represented by them and populating them with
appropriate data, but some of them require additional handling after they have
been registered. For example, if the given device node represents a PCI host
bridge, its registration should cause the PCI bus under that bridge to be
enumerated and PCI devices on that bus to be registered with the driver core.
Similarly, if the device node represents a PCI interrupt link, it is necessary
to configure that link so that the kernel can use it.
Those additional configuration tasks usually depend on the type of the hardware
component represented by the given device node which can be determined on the
basis of the device node's hardware ID (HID). They are performed by objects
called ACPI scan handlers represented by the following structure:
struct acpi_scan_handler {
const struct acpi_device_id *ids;
struct list_head list_node;
int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id);
void (*detach)(struct acpi_device *dev);
};
where ids is the list of IDs of device nodes the given handler is supposed to
take care of, list_node is the hook to the global list of ACPI scan handlers
maintained by the ACPI core and the .attach() and .detach() callbacks are
executed, respectively, after registration of new device nodes and before
unregistration of device nodes the handler attached to previously.
The namespace scanning function, acpi_bus_scan(), first registers all of the
device nodes in the given namespace scope with the driver core. Then, it tries
to match a scan handler against each of them using the ids arrays of the
available scan handlers. If a matching scan handler is found, its .attach()
callback is executed for the given device node. If that callback returns 1,
that means that the handler has claimed the device node and is now responsible
for carrying out any additional configuration tasks related to it. It also will
be responsible for preparing the device node for unregistration in that case.
The device node's handler field is then populated with the address of the scan
handler that has claimed it.
If the .attach() callback returns 0, it means that the device node is not
interesting to the given scan handler and may be matched against the next scan
handler in the list. If it returns a (negative) error code, that means that
the namespace scan should be terminated due to a serious error. The error code
returned should then reflect the type of the error.
The namespace trimming function, acpi_bus_trim(), first executes .detach()
callbacks from the scan handlers of all device nodes in the given namespace
scope (if they have scan handlers). Next, it unregisters all of the device
nodes in that scope.
ACPI scan handlers can be added to the list maintained by the ACPI core with the
help of the acpi_scan_add_handler() function taking a pointer to the new scan
handler as an argument. The order in which scan handlers are added to the list
is the order in which they are matched against device nodes during namespace
scans.
All scan handles must be added to the list before acpi_bus_scan() is run for the
first time and they cannot be removed from it.

2
Documentation/arm64/memory.txt
View File

@ -35,6 +35,8 @@ ffffffbc00000000 ffffffbdffffffff 8GB vmemmap
ffffffbe00000000 ffffffbffbbfffff ~8GB [guard, future vmmemap]
ffffffbffbc00000 ffffffbffbdfffff 2MB earlyprintk device
ffffffbffbe00000 ffffffbffbe0ffff 64KB PCI I/O space
ffffffbbffff0000 ffffffbcffffffff ~2MB [guard]

2
Documentation/atomic_ops.txt
View File

@ -253,6 +253,8 @@ This performs an atomic exchange operation on the atomic variable v, setting
the given new value. It returns the old value that the atomic variable v had
just before the operation.
atomic_xchg requires explicit memory barriers around the operation.
int atomic_cmpxchg(atomic_t *v, int old, int new);
This performs an atomic compare exchange operation on the atomic value v,

2
Documentation/cgroups/00-INDEX
View File

@ -4,8 +4,6 @@ blkio-controller.txt
- Description for Block IO Controller, implementation and usage details.
cgroups.txt
- Control Groups definition, implementation details, examples and API.
cgroup_event_listener.c
- A user program for cgroup listener.
cpuacct.txt
- CPU Accounting Controller; account CPU usage for groups of tasks.
cpusets.txt

3
Documentation/cgroups/memcg_test.txt
View File

@ -399,8 +399,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
9.10 Memory thresholds
Memory controller implements memory thresholds using cgroups notification
API. You can use Documentation/cgroups/cgroup_event_listener.c to test
it.
API. You can use tools/cgroup/cgroup_event_listener.c to test it.
(Shell-A) Create cgroup and run event listener
# mkdir /cgroup/A

6
Documentation/cpu-freq/cpu-drivers.txt
View File

@ -111,6 +111,12 @@ policy->governor must contain the "default policy" for
For setting some of these values, the frequency table helpers might be
helpful. See the section 2 for more information on them.
SMP systems normally have same clock source for a group of cpus. For these the
.init() would be called only once for the first online cpu. Here the .init()
routine must initialize policy->cpus with mask of all possible cpus (Online +
Offline) that share the clock. Then the core would copy this mask onto
policy->related_cpus and will reset policy->cpus to carry only online cpus.
1.3 verify
------------

8
Documentation/cpu-freq/user-guide.txt
View File

@ -190,11 +190,11 @@ scaling_max_freq show the current "policy limits" (in
first set scaling_max_freq, then
scaling_min_freq.
affected_cpus : List of CPUs that require software coordination
of frequency.
affected_cpus : List of Online CPUs that require software
coordination of frequency.
related_cpus : List of CPUs that need some sort of frequency
coordination, whether software or hardware.
related_cpus : List of Online + Offline CPUs that need software
coordination of frequency.
scaling_driver : Hardware driver for cpufreq.

2
Documentation/devicetree/bindings/arm/atmel-aic.txt
View File

@ -4,7 +4,7 @@ Required properties:
- compatible: Should be "atmel,<chip>-aic"
- interrupt-controller: Identifies the node as an interrupt controller.
- interrupt-parent: For single AIC system, it is an empty property.
- #interrupt-cells: The number of cells to define the interrupts. It sould be 3.
- #interrupt-cells: The number of cells to define the interrupts. It should be 3.
The first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet).
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:

4
Documentation/devicetree/bindings/arm/gic.txt
View File

@ -42,7 +42,7 @@ Main node required properties:
Optional
- interrupts : Interrupt source of the parent interrupt controller on
secondary GICs, or VGIC maintainance interrupt on primary GIC (see
secondary GICs, or VGIC maintenance interrupt on primary GIC (see
below).
- cpu-offset : per-cpu offset within the distributor and cpu interface
@ -74,7 +74,7 @@ Required properties:
virtual interface control register base and size. The 2nd additional
region is the GIC virtual cpu interface register base and size.
- interrupts : VGIC maintainance interrupt.
- interrupts : VGIC maintenance interrupt.
Example:

27
Documentation/devicetree/bindings/arm/kirkwood.txt Normal file
View File

@ -0,0 +1,27 @@
Marvell Kirkwood Platforms Device Tree Bindings
-----------------------------------------------
Boards with a SoC of the Marvell Kirkwood
shall have the following property:
Required root node property:
compatible: must contain "marvell,kirkwood";
In order to support the kirkwood cpufreq driver, there must be a node
cpus/cpu@0 with three clocks, "cpu_clk", "ddrclk" and "powersave",
where the "powersave" clock is a gating clock used to switch the CPU
between the "cpu_clk" and the "ddrclk".
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
compatible = "marvell,sheeva-88SV131";
clocks = <&core_clk 1>, <&core_clk 3>, <&gate_clk 11>;
clock-names = "cpu_clk", "ddrclk", "powersave";
};

6
Documentation/devicetree/bindings/arm/omap/omap.txt
View File

@ -39,16 +39,16 @@ Boards:
- OMAP3 Tobi with Overo : Commercial expansion board with daughter board
compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3"
- OMAP4 SDP : Software Developement Board
- OMAP4 SDP : Software Development Board
compatible = "ti,omap4-sdp", "ti,omap4430"
- OMAP4 PandaBoard : Low cost community board
compatible = "ti,omap4-panda", "ti,omap4430"
- OMAP3 EVM : Software Developement Board for OMAP35x, AM/DM37x
- OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
compatible = "ti,omap3-evm", "ti,omap3"
- AM335X EVM : Software Developement Board for AM335x
- AM335X EVM : Software Development Board for AM335x
compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3"
- AM335X Bone : Low cost community board

55
Documentation/devicetree/bindings/arm/psci.txt Normal file
View File

@ -0,0 +1,55 @@
* Power State Coordination Interface (PSCI)
Firmware implementing the PSCI functions described in ARM document number
ARM DEN 0022A ("Power State Coordination Interface System Software on ARM
processors") can be used by Linux to initiate various CPU-centric power
operations.
Issue A of the specification describes functions for CPU suspend, hotplug
and migration of secure software.
Functions are invoked by trapping to the privilege level of the PSCI
firmware (specified as part of the binding below) and passing arguments
in a manner similar to that specified by AAPCS:
r0 => 32-bit Function ID / return value
{r1 - r3} => Parameters
Note that the immediate field of the trapping instruction must be set
to #0.
Main node required properties:
- compatible : Must be "arm,psci"
- method : The method of calling the PSCI firmware. Permitted
values are:
"smc" : SMC #0, with the register assignments specified
in this binding.
"hvc" : HVC #0, with the register assignments specified
in this binding.
Main node optional properties:
- cpu_suspend : Function ID for CPU_SUSPEND operation
- cpu_off : Function ID for CPU_OFF operation
- cpu_on : Function ID for CPU_ON operation
- migrate : Function ID for MIGRATE operation
Example:
psci {
compatible = "arm,psci";
method = "smc";
cpu_suspend = <0x95c10000>;
cpu_off = <0x95c10001>;
cpu_on = <0x95c10002>;
migrate = <0x95c10003>;
};

73
Documentation/devicetree/bindings/clock/prima2-clock.txt Normal file
View File

@ -0,0 +1,73 @@
* Clock bindings for CSR SiRFprimaII
Required properties:
- compatible: Should be "sirf,prima2-clkc"
- reg: Address and length of the register set
- interrupts: Should contain clock controller interrupt
- #clock-cells: Should be <1>
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. The following is a full list of prima2
clocks and IDs.
Clock ID
---------------------------
rtc 0
osc 1
pll1 2
pll2 3
pll3 4
mem 5
sys 6
security 7
dsp 8
gps 9
mf 10
io 11
cpu 12
uart0 13
uart1 14
uart2 15
tsc 16
i2c0 17
i2c1 18
spi0 19
spi1 20
pwmc 21
efuse 22
pulse 23
dmac0 24
dmac1 25
nand 26
audio 27
usp0 28
usp1 29
usp2 30
vip 31
gfx 32
mm 33
lcd 34
vpp 35
mmc01 36
mmc23 37
mmc45 38
usbpll 39
usb0 40
usb1 41
Examples:
clks: clock-controller@88000000 {
compatible = "sirf,prima2-clkc";
reg = <0x88000000 0x1000>;
interrupts = <3>;
#clock-cells = <1>;
};
i2c0: i2c@b00e0000 {
cell-index = <0>;
compatible = "sirf,prima2-i2c";
reg = <0xb00e0000 0x10000>;
interrupts = <24>;
clocks = <&clks 17>;
};

22
Documentation/devicetree/bindings/drm/exynos/g2d.txt Normal file
View File

@ -0,0 +1,22 @@
Samsung 2D Graphic Accelerator using DRM frame work
Samsung FIMG2D is a graphics 2D accelerator which supports Bit Block Transfer.
We set the drawing-context registers for configuring rendering parameters and
then start rendering.
This driver is for SOCs which contain G2D IPs with version 4.1.
Required properties:
-compatible:
should be "samsung,exynos-g2d-41".
-reg:
physical base address of the controller and length
of memory mapped region.
-interrupts:
interrupt combiner values.
Example:
g2d {
compatible = "samsung,exynos-g2d-41";
reg = <0x10850000 0x1000>;
interrupts = <0 91 0>;
};

18
Documentation/devicetree/bindings/i2c/ina209.txt Normal file
View File

@ -0,0 +1,18 @@
ina209 properties
Required properties:
- compatible: Must be "ti,ina209"
- reg: I2C address
Optional properties:
- shunt-resistor
Shunt resistor value in micro-Ohm
Example:
temp-sensor@4c {
compatible = "ti,ina209";
reg = <0x4c>;
shunt-resistor = <5000>;
};

64
Documentation/devicetree/bindings/i2c/max6697.txt Normal file
View File

@ -0,0 +1,64 @@
max6697 properties
Required properties:
- compatible:
Should be one of
maxim,max6581
maxim,max6602
maxim,max6622
maxim,max6636
maxim,max6689
maxim,max6693
maxim,max6694
maxim,max6697
maxim,max6698
maxim,max6699
- reg: I2C address
Optional properties:
- smbus-timeout-disable
Set to disable SMBus timeout. If not specified, SMBus timeout will be
enabled.
- extended-range-enable
Only valid for MAX6581. Set to enable extended temperature range.
Extended temperature will be disabled if not specified.
- beta-compensation-enable
Only valid for MAX6693 and MX6694. Set to enable beta compensation on
remote temperature channel 1.
Beta compensation will be disabled if not specified.
- alert-mask
Alert bit mask. Alert disabled for bits set.
Select bit 0 for local temperature, bit 1..7 for remote temperatures.
If not specified, alert will be enabled for all channels.
- over-temperature-mask
Over-temperature bit mask. Over-temperature reporting disabled for
bits set.
Select bit 0 for local temperature, bit 1..7 for remote temperatures.
If not specified, over-temperature reporting will be enabled for all
channels.
- resistance-cancellation
Boolean for all chips other than MAX6581. Set to enable resistance
cancellation on remote temperature channel 1.
For MAX6581, resistance cancellation enabled for all channels if
specified as boolean, otherwise as per bit mask specified.
Only supported for remote temperatures (bit 1..7).
If not specified, resistance cancellation will be disabled for all
channels.
- transistor-ideality
For MAX6581 only. Two values; first is bit mask, second is ideality
select value as per MAX6581 data sheet. Select bit 1..7 for remote
channels.
Transistor ideality will be initialized to default (1.008) if not
specified.
Example:
temp-sensor@1a {
compatible = "maxim,max6697";
reg = <0x1a>;
smbus-timeout-disable;
resistance-cancellation;
alert-mask = <0x72>;
over-temperature-mask = <0x7f>;
};

53
Documentation/devicetree/bindings/input/imx-keypad.txt Normal file
View File

@ -0,0 +1,53 @@
* Freescale i.MX Keypad Port(KPP) device tree bindings
The KPP is designed to interface with a keypad matrix with 2-point contact
or 3-point contact keys. The KPP is designed to simplify the software task
of scanning a keypad matrix. The KPP is capable of detecting, debouncing,
and decoding one or multiple keys pressed simultaneously on a keypad.
Required SoC Specific Properties:
- compatible: Should be "fsl,<soc>-kpp".
- reg: Physical base address of the KPP and length of memory mapped
region.
- interrupts: The KPP interrupt number to the CPU(s).
- clocks: The clock provided by the SoC to the KPP. Some SoCs use dummy
clock(The clock for the KPP is provided by the SoCs automatically).
Required Board Specific Properties:
- pinctrl-names: The definition can be found at
pinctrl/pinctrl-bindings.txt.
- pinctrl-0: The definition can be found at
pinctrl/pinctrl-bindings.txt.
- linux,keymap: The definition can be found at
bindings/input/matrix-keymap.txt.
Example:
kpp: kpp@73f94000 {
compatible = "fsl,imx51-kpp", "fsl,imx21-kpp";
reg = <0x73f94000 0x4000>;
interrupts = <60>;
clocks = <&clks 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_kpp_1>;
linux,keymap = <0x00000067 /* KEY_UP */
0x0001006c /* KEY_DOWN */
0x00020072 /* KEY_VOLUMEDOWN */
0x00030066 /* KEY_HOME */
0x0100006a /* KEY_RIGHT */
0x01010069 /* KEY_LEFT */
0x0102001c /* KEY_ENTER */
0x01030073 /* KEY_VOLUMEUP */
0x02000040 /* KEY_F6 */
0x02010042 /* KEY_F8 */
0x02020043 /* KEY_F9 */
0x02030044 /* KEY_F10 */
0x0300003b /* KEY_F1 */
0x0301003c /* KEY_F2 */
0x0302003d /* KEY_F3 */
0x03030074>; /* KEY_POWER */
};

9
Documentation/devicetree/bindings/input/lpc32xx-key.txt
View File

@ -1,19 +1,22 @@
NXP LPC32xx Key Scan Interface
This binding is based on the matrix-keymap binding with the following
changes:
Required Properties:
- compatible: Should be "nxp,lpc3220-key"
- reg: Physical base address of the controller and length of memory mapped
region.
- interrupts: The interrupt number to the cpu.
- keypad,num-rows: Number of rows and columns, e.g. 1: 1x1, 6: 6x6
- keypad,num-columns: Must be equal to keypad,num-rows since LPC32xx only
supports square matrices
- nxp,debounce-delay-ms: Debounce delay in ms
- nxp,scan-delay-ms: Repeated scan period in ms
- linux,keymap: the key-code to be reported when the key is pressed
and released, see also
Documentation/devicetree/bindings/input/matrix-keymap.txt
Note: keypad,num-rows and keypad,num-columns are required, and must be equal
since LPC32xx only supports square matrices
Example:
key@40050000 {

8
Documentation/devicetree/bindings/input/matrix-keymap.txt
View File

@ -9,6 +9,12 @@ Required properties:
row << 24 | column << 16 | key-code
Optional properties:
Properties for the number of rows and columns are optional because some
drivers will use fixed values for these.
- keypad,num-rows: Number of row lines connected to the keypad controller.
- keypad,num-columns: Number of column lines connected to the keypad
controller.
Some users of this binding might choose to specify secondary keymaps for
cases where there is a modifier key such as a Fn key. Proposed names
for said properties are "linux,fn-keymap" or with another descriptive
@ -17,3 +23,5 @@ word for the modifier other from "Fn".
Example:
linux,keymap = < 0x00030012
0x0102003a >;
keypad,num-rows = <2>;
keypad,num-columns = <8>;

22
Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
View File

@ -1,7 +1,18 @@
* Tegra keyboard controller
The key controller has maximum 24 pins to make matrix keypad. Any pin
can be configured as row or column. The maximum column pin can be 8
and maximum row pins can be 16 for Tegra20/Tegra30.
Required properties:
- compatible: "nvidia,tegra20-kbc"
- reg: Register base address of KBC.
- interrupts: Interrupt number for the KBC.
- nvidia,kbc-row-pins: The KBC pins which are configured as row. This is an
array of pin numbers which is used as rows.
- nvidia,kbc-col-pins: The KBC pins which are configured as column. This is an
array of pin numbers which is used as column.
- linux,keymap: The keymap for keys as described in the binding document
devicetree/bindings/input/matrix-keymap.txt.
Optional properties, in addition to those specified by the shared
matrix-keyboard bindings:
@ -19,5 +30,16 @@ Example:
keyboard: keyboard {
compatible = "nvidia,tegra20-kbc";
reg = <0x7000e200 0x100>;
interrupts = <0 85 0x04>;
nvidia,ghost-filter;
nvidia,debounce-delay-ms = <640>;
nvidia,kbc-row-pins = <0 1 2>; /* pin 0, 1, 2 as rows */
nvidia,kbc-col-pins = <11 12 13>; /* pin 11, 12, 13 as columns */
linux,keymap = <0x00000074
0x00010067
0x00020066
0x01010068
0x02000069
0x02010070
0x02020071>;
};

13
Documentation/devicetree/bindings/input/omap-keypad.txt
View File

@ -6,19 +6,16 @@ A key can be placed at each intersection of a unique row and a unique column.
The keypad controller can sense a key-press and key-release and report the
event using a interrupt to the cpu.
This binding is based on the matrix-keymap binding with the following
changes:
keypad,num-rows and keypad,num-columns are required.
Required SoC Specific Properties:
- compatible: should be one of the following
- "ti,omap4-keypad": For controllers compatible with omap4 keypad
controller.
Required Board Specific Properties, in addition to those specified by
the shared matrix-keyboard bindings:
- keypad,num-rows: Number of row lines connected to the keypad
controller.
- keypad,num-columns: Number of column lines connected to the
keypad controller.
Optional Properties specific to linux:
- linux,keypad-no-autorepeat: do no enable autorepeat feature.

6
Documentation/devicetree/bindings/input/tca8418_keypad.txt
View File

@ -1,8 +1,10 @@
This binding is based on the matrix-keymap binding with the following
changes:
keypad,num-rows and keypad,num-columns are required.
Required properties:
- compatible: "ti,tca8418"
- reg: the I2C address
- interrupts: IRQ line number, should trigger on falling edge
- keypad,num-rows: The number of rows
- keypad,num-columns: The number of columns
- linux,keymap: Keys definitions, see keypad-matrix.

0
Documentation/devicetree/bindings/gpio/leds-ns2.txt → Documentation/devicetree/bindings/leds/leds-ns2.txt
View File

91
Documentation/devicetree/bindings/mfd/tps6507x.txt Executable file
View File

@ -0,0 +1,91 @@
TPS6507x Power Management Integrated Circuit
Required properties:
- compatible: "ti,tps6507x"
- reg: I2C slave address
- regulators: This is the list of child nodes that specify the regulator
initialization data for defined regulators. Not all regulators for the
given device need to be present. The definition for each of these nodes
is defined using the standard binding for regulators found at
Documentation/devicetree/bindings/regulator/regulator.txt.
The regulator is matched with the regulator-compatible.
The valid regulator-compatible values are:
tps6507x: vdcdc1, vdcdc2, vdcdc3, vldo1, vldo2
- xxx-supply: Input voltage supply regulator.
These entries are required if regulators are enabled for a device.
Missing of these properties can cause the regulator registration
fails.
If some of input supply is powered through battery or always-on
supply then also it is require to have these parameters with proper
node handle of always on power supply.
tps6507x:
vindcdc1_2-supply: VDCDC1 and VDCDC2 input.
vindcdc3-supply : VDCDC3 input.
vldo1_2-supply : VLDO1 and VLDO2 input.
Regulator Optional properties:
- defdcdc_default: It's property of DCDC2 and DCDC3 regulators.
0: If defdcdc pin of DCDC2/DCDC3 is pulled to GND.
1: If defdcdc pin of DCDC2/DCDC3 is driven HIGH.
If this property is not defined, it defaults to 0 (not enabled).
Example:
pmu: tps6507x@48 {
compatible = "ti,tps6507x";
reg = <0x48>;
vindcdc1_2-supply = <&vbat>;
vindcdc3-supply = <...>;
vinldo1_2-supply = <...>;
regulators {
#address-cells = <1>;
#size-cells = <0>;
vdcdc1_reg: regulator@0 {
regulator-compatible = "VDCDC1";
reg = <0>;
regulator-min-microvolt = <3150000>;
regulator-max-microvolt = <3450000>;
regulator-always-on;
regulator-boot-on;
};
vdcdc2_reg: regulator@1 {
regulator-compatible = "VDCDC2";
reg = <1>;
regulator-min-microvolt = <1710000>;
regulator-max-microvolt = <3450000>;
regulator-always-on;
regulator-boot-on;
defdcdc_default = <1>;
};
vdcdc3_reg: regulator@2 {
regulator-compatible = "VDCDC3";
reg = <2>;
regulator-min-microvolt = <950000>
regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-boot-on;
defdcdc_default = <1>;
};
ldo1_reg: regulator@3 {
regulator-compatible = "LDO1";
reg = <3>;
regulator-min-microvolt = <1710000>;
regulator-max-microvolt = <1890000>;
regulator-always-on;
regulator-boot-on;
};
ldo2_reg: regulator@4 {
regulator-compatible = "LDO2";
reg = <4>;
regulator-min-microvolt = <1140000>;
regulator-max-microvolt = <1320000>;
regulator-always-on;
regulator-boot-on;
};
};
};

2
Documentation/devicetree/bindings/mips/cavium/dma-engine.txt
View File

@ -1,7 +1,7 @@
* DMA Engine.
The Octeon DMA Engine transfers between the Boot Bus and main memory.
The DMA Engine will be refered to by phandle by any device that is
The DMA Engine will be referred to by phandle by any device that is
connected to it.
Properties:

8
Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
View File

@ -4,18 +4,18 @@
The Synopsis designware mobile storage host controller is used to interface
a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
differences between the core Synopsis dw mshc controller properties described
by synposis-dw-mshc.txt and the properties used by the Samsung Exynos specific
by synopsis-dw-mshc.txt and the properties used by the Samsung Exynos specific
extensions to the Synopsis Designware Mobile Storage Host Controller.
Required Properties:
* compatible: should be
- "samsung,exynos4210-dw-mshc": for controllers with Samsung Exynos4210
specific extentions.
specific extensions.
- "samsung,exynos4412-dw-mshc": for controllers with Samsung Exynos4412
specific extentions.
specific extensions.
- "samsung,exynos5250-dw-mshc": for controllers with Samsung Exynos5250
specific extentions.
specific extensions.
* samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface
unit (ciu) clock. This property is applicable only for Exynos5 SoC's and

2
Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
View File

@ -55,5 +55,5 @@ Example:
};
Note: This example shows both SoC specific and board specific properties
in a single device node. The properties can be actually be seperated
in a single device node. The properties can be actually be separated
into SoC specific node and board specific node.

2
Documentation/devicetree/bindings/net/cpsw.txt
View File

@ -24,6 +24,8 @@ Required properties:
Optional properties:
- ti,hwmods : Must be "cpgmac0"
- no_bd_ram : Must be 0 or 1
- dual_emac : Specifies Switch to act as Dual EMAC
- dual_emac_res_vlan : Specifies VID to be used to segregate the ports
Note: "ti,hwmods" field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.

60
Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt Normal file
View File

@ -0,0 +1,60 @@
* Allwinner A1X Pin Controller
The pins controlled by sunXi pin controller are organized in banks,
each bank has 32 pins. Each pin has 7 multiplexing functions, with
the first two functions being GPIO in and out. The configuration on
the pins includes drive strength and pull-up.
Required properties:
- compatible: "allwinner,<soc>-pinctrl". Supported SoCs for now are:
sun5i-a13.
- reg: Should contain the register physical address and length for the
pin controller.
Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices.
A pinctrl node should contain at least one subnodes representing the
pinctrl groups available on the machine. Each subnode will list the
pins it needs, and how they should be configured, with regard to muxer
configuration, drive strength and pullups. If one of these options is
not set, its actual value will be unspecified.
Required subnode-properties:
- allwinner,pins: List of strings containing the pin name.
- allwinner,function: Function to mux the pins listed above to.
Optional subnode-properties:
- allwinner,drive: Integer. Represents the current sent to the pin
0: 10 mA
1: 20 mA
2: 30 mA
3: 40 mA
- allwinner,pull: Integer.
0: No resistor
1: Pull-up resistor
2: Pull-down resistor
Examples:
pinctrl@01c20800 {
compatible = "allwinner,sun5i-a13-pinctrl";
reg = <0x01c20800 0x400>;
#address-cells = <1>;
#size-cells = <0>;
uart1_pins_a: uart1@0 {
allwinner,pins = "PE10", "PE11";
allwinner,function = "uart1";
allwinner,drive = <0>;
allwinner,pull = <0>;
};
uart1_pins_b: uart1@1 {
allwinner,pins = "PG3", "PG4";
allwinner,function = "uart1";
allwinner,drive = <0>;
allwinner,pull = <0>;
};
};

120
Documentation/devicetree/bindings/pinctrl/nvidia,tegra114-pinmux.txt Normal file
View File

@ -0,0 +1,120 @@
NVIDIA Tegra114 pinmux controller
The Tegra114 pinctrl binding is very similar to the Tegra20 and Tegra30
pinctrl binding, as described in nvidia,tegra20-pinmux.txt and
nvidia,tegra30-pinmux.txt. In fact, this document assumes that binding as
a baseline, and only documents the differences between the two bindings.
Required properties:
- compatible: "nvidia,tegra114-pinmux"
- reg: Should contain the register physical address and length for each of
the pad control and mux registers. The first bank of address must be the
driver strength pad control register address and second bank address must
be pinmux register address.
Tegra114 adds the following optional properties for pin configuration subnodes:
- nvidia,enable-input: Integer. Enable the pin's input path. 0: no, 1: yes.
- nvidia,open-drain: Integer. Enable open drain mode. 0: no, 1: yes.
- nvidia,lock: Integer. Lock the pin configuration against further changes
until reset. 0: no, 1: yes.
- nvidia,io-reset: Integer. Reset the IO path. 0: no, 1: yes.
- nvidia,rcv-sel: Integer. Select VIL/VIH receivers. 0: normal, 1: high.
- nvidia,drive-type: Integer. Valid range 0...3.
As with Tegra20 and Terga30, see the Tegra TRM for complete details regarding
which groups support which functionality.
Valid values for pin and group names are:
per-pin mux groups:
These all support nvidia,function, nvidia,tristate, nvidia,pull,
nvidia,enable-input, nvidia,lock. Some support nvidia,open-drain,
nvidia,io-reset and nvidia,rcv-sel.
ulpi_data0_po1, ulpi_data1_po2, ulpi_data2_po3, ulpi_data3_po4,
ulpi_data4_po5, ulpi_data5_po6, ulpi_data6_po7, ulpi_data7_po0,
ulpi_clk_py0, ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3, dap3_fs_pp0,
dap3_din_pp1, dap3_dout_pp2, dap3_sclk_pp3, pv0, pv1, sdmmc1_clk_pz0,
sdmmc1_cmd_pz1, sdmmc1_dat3_py4, sdmmc1_dat2_py5, sdmmc1_dat1_py6,
sdmmc1_dat0_py7, clk2_out_pw5, clk2_req_pcc5, hdmi_int_pn7, ddc_scl_pv4,
ddc_sda_pv5, uart2_rxd_pc3, uart2_txd_pc2, uart2_rts_n_pj6,
uart2_cts_n_pj5, uart3_txd_pw6, uart3_rxd_pw7, uart3_cts_n_pa1,
uart3_rts_n_pc0, pu0, pu1, pu2, pu3, pu4, pu5, pu6, gen1_i2c_sda_pc5,
gen1_i2c_scl_pc4, dap4_fs_pp4, dap4_din_pp5, dap4_dout_pp6, dap4_sclk_pp7,
clk3_out_pee0, clk3_req_pee1, gmi_wp_n_pc7, gmi_iordy_pi5, gmi_wait_pi7,
gmi_adv_n_pk0, gmi_clk_pk1, gmi_cs0_n_pj0, gmi_cs1_n_pj2, gmi_cs2_n_pk3,
gmi_cs3_n_pk4, gmi_cs4_n_pk2, gmi_cs6_n_pi3, gmi_cs7_n_pi6, gmi_ad0_pg0,
gmi_ad1_pg1, gmi_ad2_pg2, gmi_ad3_pg3, gmi_ad4_pg4, gmi_ad5_pg5,
gmi_ad6_pg6, gmi_ad7_pg7, gmi_ad8_ph0, gmi_ad9_ph1, gmi_ad10_ph2,
gmi_ad11_ph3, gmi_ad12_ph4, gmi_ad13_ph5, gmi_ad14_ph6, gmi_ad15_ph7,
gmi_a16_pj7, gmi_a17_pb0, gmi_a18_pb1, gmi_a19_pk7, gmi_wr_n_pi0,
gmi_oe_n_pi1, gmi_dqs_p_pj3, gmi_rst_n_pi4, gen2_i2c_scl_pt5,
gen2_i2c_sda_pt6, sdmmc4_clk_pcc4, sdmmc4_cmd_pt7, sdmmc4_dat0_paa0,
sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, sdmmc4_dat3_paa3, sdmmc4_dat4_paa4,
sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, sdmmc4_dat7_paa7, cam_mclk_pcc0,
pcc1, pbb0, cam_i2c_scl_pbb1, cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6,
pbb7, pcc2, pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, kb_row0_pr0, kb_row1_pr1,
kb_row2_pr2, kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, kb_row6_pr6,
kb_row7_pr7, kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_col0_pq0,
kb_col1_pq1, kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5,
kb_col6_pq6, kb_col7_pq7, clk_32k_out_pa0, sys_clk_req_pz5, core_pwr_req,
cpu_pwr_req, pwr_int_n, owr, dap1_fs_pn0, dap1_din_pn1, dap1_dout_pn2,
dap1_sclk_pn3, clk1_req_pee2, clk1_out_pw4, spdif_in_pk6, spdif_out_pk5,
dap2_fs_pa2, dap2_din_pa4, dap2_dout_pa5, dap2_sclk_pa3, dvfs_pwm_px0,
gpio_x1_aud_px1, gpio_x3_aud_px3, dvfs_clk_px2, gpio_x4_aud_px4,
gpio_x5_aud_px5, gpio_x6_aud_px6, gpio_x7_aud_px7, sdmmc3_clk_pa6,
sdmmc3_cmd_pa7, sdmmc3_dat0_pb7, sdmmc3_dat1_pb6, sdmmc3_dat2_pb5,
sdmmc3_dat3_pb4, hdmi_cec_pee3, sdmmc1_wp_n_pv3, sdmmc3_cd_n_pv2,
gpio_w2_aud_pw2, gpio_w3_aud_pw3, usb_vbus_en0_pn4, usb_vbus_en1_pn5,
sdmmc3_clk_lb_in_pee5, sdmmc3_clk_lb_out_pee4, reset_out_n.
drive groups:
These all support nvidia,pull-down-strength, nvidia,pull-up-strength,
nvidia,slew-rate-rising, nvidia,slew-rate-falling. Most but not all
support nvidia,high-speed-mode, nvidia,schmitt, nvidia,low-power-mode
and nvidia,drive-type.
ao1, ao2, at1, at2, at3, at4, at5, cdev1, cdev2, dap1, dap2, dap3, dap4,
dbg, sdio3, spi, uaa, uab, uart2, uart3, sdio1, ddc, gma, gme, gmf, gmg,
gmh, owr, uda.
Example:
pinmux: pinmux {
compatible = "nvidia,tegra114-pinmux";
reg = <0x70000868 0x148 /* Pad control registers */
0x70003000 0x40c>; /* PinMux registers */
};
Example board file extract:
pinctrl {
sdmmc4_default: pinmux {
sdmmc4_clk_pcc4 {
nvidia,pins = "sdmmc4_clk_pcc4",
nvidia,function = "sdmmc4";
nvidia,pull = <0>;
nvidia,tristate = <0>;
};
sdmmc4_dat0_paa0 {
nvidia,pins = "sdmmc4_dat0_paa0",
"sdmmc4_dat1_paa1",
"sdmmc4_dat2_paa2",
"sdmmc4_dat3_paa3",
"sdmmc4_dat4_paa4",
"sdmmc4_dat5_paa5",
"sdmmc4_dat6_paa6",
"sdmmc4_dat7_paa7";
nvidia,function = "sdmmc4";
nvidia,pull = <2>;
nvidia,tristate = <0>;
};
};
};
sdhci@78000400 {
pinctrl-names = "default";
pinctrl-0 = <&sdmmc4_default>;
};

140
Documentation/devicetree/bindings/pinctrl/ste,nomadik.txt Normal file
View File

@ -0,0 +1,140 @@
ST Ericsson Nomadik pinmux controller
Required properties:
- compatible: "stericsson,nmk-pinctrl", "stericsson,nmk-pinctrl-db8540",
"stericsson,nmk-pinctrl-stn8815"
- reg: Should contain the register physical address and length of the PRCMU.
Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
ST Ericsson's pin configuration nodes act as a container for an arbitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration
parameters, such as input, output, pull up, pull down...
The name of each subnode is not important; all subnodes should be enumerated
and processed purely based on their content.
Required subnode-properties:
- ste,pins : An array of strings. Each string contains the name of a pin or
group.
Optional subnode-properties:
- ste,function: A string containing the name of the function to mux to the
pin or group.
- ste,config: Handle of pin configuration node (e.g. ste,config = <&slpm_in_wkup_pdis>)
- ste,input : <0/1/2>
0: input with no pull
1: input with pull up,
2: input with pull down,
- ste,output: <0/1/2>
0: output low,
1: output high,
2: output (value is not specified).
- ste,sleep: <0/1>
0: sleep mode disable,
1: sleep mode enable.
- ste,sleep-input: <0/1/2/3>
0: sleep input with no pull,
1: sleep input with pull up,
2: sleep input with pull down.
3: sleep input and keep last input configuration (no pull, pull up or pull down).
- ste,sleep-output: <0/1/2>
0: sleep output low,
1: sleep output high,
2: sleep output (value is not specified).
- ste,sleep-gpio: <0/1>
0: disable sleep gpio mode,
1: enable sleep gpio mode.
- ste,sleep-wakeup: <0/1>
0: wake-up detection enabled,
1: wake-up detection disabled.
- ste,sleep-pull-disable: <0/1>
0: GPIO pull-up or pull-down resistor is enabled, when pin is an input,
1: GPIO pull-up and pull-down resistor are disabled.
Example board file extract:
pinctrl@80157000 {
compatible = "stericsson,nmk-pinctrl";
reg = <0x80157000 0x2000>;
pinctrl-names = "default";
slpm_in_wkup_pdis: slpm_in_wkup_pdis {
ste,sleep = <1>;
ste,sleep-input = <3>;
ste,sleep-wakeup = <1>;
ste,sleep-pull-disable = <0>;
};
slpm_out_hi_wkup_pdis: slpm_out_hi_wkup_pdis {
ste,sleep = <1>;
ste,sleep-output = <1>;
ste,sleep-wakeup = <1>;
ste,sleep-pull-disable = <0>;
};
slpm_out_wkup_pdis: slpm_out_wkup_pdis {
ste,sleep = <1>;
ste,sleep-output = <2>;
ste,sleep-wakeup = <1>;
ste,sleep-pull-disable = <0>;
};
uart0 {
uart0_default_mux: uart0_mux {
u0_default_mux {
ste,function = "u0";
ste,pins = "u0_a_1";
};
};
uart0_default_mode: uart0_default {
uart0_default_cfg1 {
ste,pins = "GPIO0", "GPIO2";
ste,input = <1>;
};
uart0_default_cfg2 {
ste,pins = "GPIO1", "GPIO3";
ste,output = <1>;
};
};
uart0_sleep_mode: uart0_sleep {
uart0_sleep_cfg1 {
ste,pins = "GPIO0", "GPIO2";
ste,config = <&slpm_in_wkup_pdis>;
};
uart0_sleep_cfg2 {
ste,pins = "GPIO1";
ste,config = <&slpm_out_hi_wkup_pdis>;
};
uart0_sleep_cfg3 {
ste,pins = "GPIO3";
ste,config = <&slpm_out_wkup_pdis>;
};
};
};
};
uart@80120000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x80120000 0x1000>;
interrupts = <0 11 0x4>;
pinctrl-names = "default","sleep";
pinctrl-0 = <&uart0_default_mux>, <&uart0_default_mode>;
pinctrl-1 = <&uart0_sleep_mode>;
};

13
Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt Normal file
View File

@ -0,0 +1,13 @@
* QNAP Power Off
QNAP NAS devices have a microcontroller controlling the main power
supply. This microcontroller is connected to UART1 of the Kirkwood and
Orion5x SoCs. Sending the charactor 'A', at 19200 baud, tells the
microcontroller to turn the power off. This driver adds a handler to
pm_power_off which is called to turn the power off.
Required Properties:
- compatible: Should be "qnap,power-off"
- reg: Address and length of the register set for UART1
- clocks: tclk clock

8
Documentation/devicetree/bindings/power_supply/restart-poweroff.txt Normal file
View File

@ -0,0 +1,8 @@
* Restart Power Off
Buffalo Linkstation LS-XHL and LS-CHLv2, and other devices power off
by restarting and letting u-boot keep hold of the machine until the
user presses a button.
Required Properties:
- compatible: Should be "restart-poweroff"

4
Documentation/devicetree/bindings/powerpc/fsl/srio.txt
View File

@ -8,9 +8,9 @@ Properties:
Definition: Must include "fsl,srio" for IP blocks with IP Block
Revision Register (SRIO IPBRR1) Major ID equal to 0x01c0.
Optionally, a compatiable string of "fsl,srio-vX.Y" where X is Major
Optionally, a compatible string of "fsl,srio-vX.Y" where X is Major
version in IP Block Revision Register and Y is Minor version. If this
compatiable is provided it should be ordered before "fsl,srio".
compatible is provided it should be ordered before "fsl,srio".
- reg
Usage: required

8
Documentation/devicetree/bindings/regulator/anatop-regulator.txt
View File

@ -9,6 +9,11 @@ Required properties:
- anatop-min-voltage: Minimum voltage of this regulator
- anatop-max-voltage: Maximum voltage of this regulator
Optional properties:
- anatop-delay-reg-offset: Anatop MFD step time register offset
- anatop-delay-bit-shift: Bit shift for the step time register
- anatop-delay-bit-width: Number of bits used in the step time register
Any property defined as part of the core regulator
binding, defined in regulator.txt, can also be used.
@ -23,6 +28,9 @@ Example:
anatop-reg-offset = <0x140>;
anatop-vol-bit-shift = <9>;
anatop-vol-bit-width = <5>;
anatop-delay-reg-offset = <0x170>;
anatop-delay-bit-shift = <24>;
anatop-delay-bit-width = <2>;
anatop-min-bit-val = <1>;
anatop-min-voltage = <725000>;
anatop-max-voltage = <1300000>;

152
Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt Normal file
View File

@ -0,0 +1,152 @@
* Samsung S5M8767 Voltage and Current Regulator
The Samsung S5M8767 is a multi-function device which includes volatage and
current regulators, rtc, charger controller and other sub-blocks. It is
interfaced to the host controller using a i2c interface. Each sub-block is
addressed by the host system using different i2c slave address. This document
describes the bindings for 'pmic' sub-block of s5m8767.
Required properties:
- compatible: Should be "samsung,s5m8767-pmic".
- reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
- s5m8767,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
units for buck2 when changing voltage using gpio dvs. Refer to [1] below
for additional information.
- s5m8767,pmic-buck3-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
units for buck3 when changing voltage using gpio dvs. Refer to [1] below
for additional information.
- s5m8767,pmic-buck4-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
units for buck4 when changing voltage using gpio dvs. Refer to [1] below
for additional information.
- s5m8767,pmic-buck-ds-gpios: GPIO specifiers for three host gpio's used
for selecting GPIO DVS lines. It is one-to-one mapped to dvs gpio lines.
[1] If none of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional
property is specified, the 's5m8767,pmic-buck[2/3/4]-dvs-voltage'
property should specify atleast one voltage level (which would be a
safe operating voltage).
If either of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional
property is specified, then all the eight voltage values for the
's5m8767,pmic-buck[2/3/4]-dvs-voltage' should be specified.
Optional properties:
- interrupt-parent: Specifies the phandle of the interrupt controller to which
the interrupts from s5m8767 are delivered to.
- interrupts: Interrupt specifiers for two interrupt sources.
- First interrupt specifier is for 'irq1' interrupt.
- Second interrupt specifier is for 'alert' interrupt.
- s5m8767,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs.
- s5m8767,pmic-buck3-uses-gpio-dvs: 'buck3' can be controlled by gpio dvs.
- s5m8767,pmic-buck4-uses-gpio-dvs: 'buck4' can be controlled by gpio dvs.
Additional properties required if either of the optional properties are used:
- s5m8767,pmic-buck234-default-dvs-idx: Default voltage setting selected from
the possible 8 options selectable by the dvs gpios. The value of this
property should be between 0 and 7. If not specified or if out of range, the
default value of this property is set to 0.
- s5m8767,pmic-buck-dvs-gpios: GPIO specifiers for three host gpio's used
for dvs. The format of the gpio specifier depends in the gpio controller.
Regulators: The regulators of s5m8767 that have to be instantiated should be
included in a sub-node named 'regulators'. Regulator nodes included in this
sub-node should be of the format as listed below.
regulator_name {
ldo1_reg: LDO1 {
regulator-name = "VDD_ALIVE_1.0V";
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1100000>;
regulator-always-on;
regulator-boot-on;
op_mode = <1>; /* Normal Mode */
};
};
The above regulator entries are defined in regulator bindings documentation
except op_mode description.
- op_mode: describes the different operating modes of the LDO's with
power mode change in SOC. The different possible values are,
0 - always off mode
1 - on in normal mode
2 - low power mode
3 - suspend mode
The following are the names of the regulators that the s5m8767 pmic block
supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
as per the datasheet of s5m8767.
- LDOn
- valid values for n are 1 to 28
- Example: LDO0, LD01, LDO28
- BUCKn
- valid values for n are 1 to 9.
- Example: BUCK1, BUCK2, BUCK9
The bindings inside the regulator nodes use the standard regulator bindings
which are documented elsewhere.
Example:
s5m8767_pmic@66 {
compatible = "samsung,s5m8767-pmic";
reg = <0x66>;
s5m8767,pmic-buck2-uses-gpio-dvs;
s5m8767,pmic-buck3-uses-gpio-dvs;
s5m8767,pmic-buck4-uses-gpio-dvs;
s5m8767,pmic-buck-default-dvs-idx = <0>;
s5m8767,pmic-buck-dvs-gpios = <&gpx0 0 1 0 0>, /* DVS1 */
<&gpx0 1 1 0 0>, /* DVS2 */
<&gpx0 2 1 0 0>; /* DVS3 */
s5m8767,pmic-buck-ds-gpios = <&gpx2 3 1 0 0>, /* SET1 */
<&gpx2 4 1 0 0>, /* SET2 */
<&gpx2 5 1 0 0>; /* SET3 */
s5m8767,pmic-buck2-dvs-voltage = <1350000>, <1300000>,
<1250000>, <1200000>,
<1150000>, <1100000>,
<1000000>, <950000>;
s5m8767,pmic-buck3-dvs-voltage = <1100000>, <1100000>,
<1100000>, <1100000>,
<1000000>, <1000000>,
<1000000>, <1000000>;
s5m8767,pmic-buck4-dvs-voltage = <1200000>, <1200000>,
<1200000>, <1200000>,
<1200000>, <1200000>,
<1200000>, <1200000>;
regulators {
ldo1_reg: LDO1 {
regulator-name = "VDD_ABB_3.3V";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
op_mode = <1>; /* Normal Mode */
};
ldo2_reg: LDO2 {
regulator-name = "VDD_ALIVE_1.1V";
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1100000>;
regulator-always-on;
};
buck1_reg: BUCK1 {
regulator-name = "VDD_MIF_1.2V";
regulator-min-microvolt = <950000>;
regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-boot-on;
};
};
};

27
Documentation/devicetree/bindings/regulator/tps51632-regulator.txt Normal file
View File

@ -0,0 +1,27 @@
TPS51632 Voltage regulators
Required properties:
- compatible: Must be "ti,tps51632"
- reg: I2C slave address
Optional properties:
- ti,enable-pwm-dvfs: Enable the DVFS voltage control through the PWM interface.
- ti,dvfs-step-20mV: The 20mV step voltage when PWM DVFS enabled. Missing this
will set 10mV step voltage in PWM DVFS mode. In normal mode, the voltage
step is 10mV as per datasheet.
Any property defined as part of the core regulator binding, defined in
regulator.txt, can also be used.
Example:
tps51632 {
compatible = "ti,tps51632";
reg = <0x43>;
regulator-name = "tps51632-vout";
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <1500000>;
regulator-boot-on;
ti,enable-pwm-dvfs;
ti,dvfs-step-20mV;
};

4
Documentation/devicetree/bindings/regulator/tps62360-regulator.txt
View File

@ -17,9 +17,9 @@ Optional properties:
- ti,vsel1-gpio: Gpio for controlling VSEL1 line.
If this property is missing, then assume that there is no GPIO
for vsel1 control.
- ti,vsel0-state-high: Inital state of vsel0 input is high.
- ti,vsel0-state-high: Initial state of vsel0 input is high.
If this property is missing, then assume the state as low (0).
- ti,vsel1-state-high: Inital state of vsel1 input is high.
- ti,vsel1-state-high: Initial state of vsel1 input is high.
If this property is missing, then assume the state as low (0).
Any property defined as part of the core regulator binding, defined in

2
Documentation/devicetree/bindings/rtc/s3c-rtc.txt
View File

@ -7,7 +7,7 @@ Required properties:
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: Two interrupt numbers to the cpu should be specified. First
interrupt number is the rtc alarm interupt and second interrupt number
interrupt number is the rtc alarm interrupt and second interrupt number
is the rtc tick interrupt. The number of cells representing a interrupt
depends on the parent interrupt controller.

12
Documentation/devicetree/bindings/spi/sh-msiof.txt Normal file
View File

@ -0,0 +1,12 @@
Renesas MSIOF spi controller
Required properties:
- compatible : "renesas,sh-msiof" for SuperH or
"renesas,sh-mobile-msiof" for SH Mobile series
- reg : Offset and length of the register set for the device
- interrupts : interrupt line used by MSIOF
Optional properties:
- num-cs : total number of chip-selects
- renesas,tx-fifo-size : Overrides the default tx fifo size given in words
- renesas,rx-fifo-size : Overrides the default rx fifo size given in words

4
Documentation/devicetree/bindings/vendor-prefixes.txt
View File

@ -14,6 +14,7 @@ bosch Bosch Sensortec GmbH
brcm Broadcom Corporation
cavium Cavium, Inc.
chrp Common Hardware Reference Platform
cirrus Cirrus Logic, Inc.
cortina Cortina Systems, Inc.
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
denx Denx Software Engineering
@ -42,6 +43,7 @@ powervr PowerVR (deprecated, use img)
qcom Qualcomm, Inc.
ramtron Ramtron International
realtek Realtek Semiconductor Corp.
renesas Renesas Electronics Corporation
samsung Samsung Semiconductor
sbs Smart Battery System
schindler Schindler
@ -50,8 +52,10 @@ simtek
sirf SiRF Technology, Inc.
snps Synopsys, Inc.
st STMicroelectronics
ste ST-Ericsson
stericsson ST-Ericsson
ti Texas Instruments
toshiba Toshiba Corporation
via VIA Technologies, Inc.
wlf Wolfson Microelectronics
wm Wondermedia Technologies, Inc.

2
Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
View File

@ -2,7 +2,7 @@
The Samsung's Watchdog controller is used for resuming system operation
after a preset amount of time during which the WDT reset event has not
occured.
occurred.
Required properties:
- compatible : should be "samsung,s3c2410-wdt"

9
Documentation/hwmon/coretemp
View File

@ -66,6 +66,7 @@ Process Processor TjMax(C)
i5 3470T 91
32nm Core i3/i5/i7 Processors
i7 2600 98
i7 660UM/640/620, 640LM/620, 620M, 610E 105
i5 540UM/520/430, 540M/520/450/430 105
i3 330E, 370M/350/330 90 rPGA, 105 BGA
@ -79,7 +80,10 @@ Process Processor TjMax(C)
P4505/P4500 90
32nm Atom Processors
S1260/1220 95
S1240 102
Z2460 90
Z2760 90
D2700/2550/2500 100
N2850/2800/2650/2600 100
@ -98,6 +102,7 @@ Process Processor TjMax(C)
45nm Atom Processors
D525/510/425/410 100
K525/510/425/410 100
Z670/650 90
Z560/550/540/530P/530/520PT/520/515/510PT/510P 90
Z510/500 90
@ -107,7 +112,11 @@ Process Processor TjMax(C)
330/230 125
E680/660/640/620 90
E680T/660T/640T/620T 110
E665C/645C 90
E665CT/645CT 110
CE4170/4150/4110 110
CE4200 series unknown
CE5300 series unknown
45nm Core2 Processors
Solo ULV SU3500/3300 100

93
Documentation/hwmon/ina209 Normal file
View File

@ -0,0 +1,93 @@
Kernel driver ina209
=====================
Supported chips:
* Burr-Brown / Texas Instruments INA209
Prefix: 'ina209'
Addresses scanned: -
Datasheet:
http://www.ti.com/lit/gpn/ina209
Author: Paul Hays <Paul.Hays@cattail.ca>
Author: Ira W. Snyder <iws@ovro.caltech.edu>
Author: Guenter Roeck <linux@roeck-us.net>
Description
-----------
The TI / Burr-Brown INA209 monitors voltage, current, and power on the high side
of a D.C. power supply. It can perform measurements and calculations in the
background to supply readings at any time. It includes a programmable
calibration multiplier to scale the displayed current and power values.
Sysfs entries
-------------
The INA209 chip is highly configurable both via hardwiring and via
the I2C bus. See the datasheet for details.
This tries to expose most monitoring features of the hardware via
sysfs. It does not support every feature of this chip.
in0_input shunt voltage (mV)
in0_input_highest shunt voltage historical maximum reading (mV)
in0_input_lowest shunt voltage historical minimum reading (mV)
in0_reset_history reset shunt voltage history
in0_max shunt voltage max alarm limit (mV)
in0_min shunt voltage min alarm limit (mV)
in0_crit_max shunt voltage crit max alarm limit (mV)
in0_crit_min shunt voltage crit min alarm limit (mV)
in0_max_alarm shunt voltage max alarm limit exceeded
in0_min_alarm shunt voltage min alarm limit exceeded
in0_crit_max_alarm shunt voltage crit max alarm limit exceeded
in0_crit_min_alarm shunt voltage crit min alarm limit exceeded
in1_input bus voltage (mV)
in1_input_highest bus voltage historical maximum reading (mV)
in1_input_lowest bus voltage historical minimum reading (mV)
in1_reset_history reset bus voltage history
in1_max bus voltage max alarm limit (mV)
in1_min bus voltage min alarm limit (mV)
in1_crit_max bus voltage crit max alarm limit (mV)
in1_crit_min bus voltage crit min alarm limit (mV)
in1_max_alarm bus voltage max alarm limit exceeded
in1_min_alarm bus voltage min alarm limit exceeded
in1_crit_max_alarm bus voltage crit max alarm limit exceeded
in1_crit_min_alarm bus voltage crit min alarm limit exceeded
power1_input power measurement (uW)
power1_input_highest power historical maximum reading (uW)
power1_reset_history reset power history
power1_max power max alarm limit (uW)
power1_crit power crit alarm limit (uW)
power1_max_alarm power max alarm limit exceeded
power1_crit_alarm power crit alarm limit exceeded
curr1_input current measurement (mA)
update_interval data conversion time; affects number of samples used
to average results for shunt and bus voltages.
General Remarks
---------------
The power and current registers in this chip require that the calibration
register is programmed correctly before they are used. Normally this is expected
to be done in the BIOS. In the absence of BIOS programming, the shunt resistor
voltage can be provided using platform data. The driver uses platform data from
the ina2xx driver for this purpose. If calibration register data is not provided
via platform data, the driver checks if the calibration register has been
programmed (ie has a value not equal to zero). If so, this value is retained.
Otherwise, a default value reflecting a shunt resistor value of 10 mOhm is
programmed into the calibration register.
Output Pins
-----------
Output pin programming is a board feature which depends on the BIOS. It is
outside the scope of a hardware monitoring driver to enable or disable output
pins.

16
Documentation/hwmon/it87
View File

@ -30,6 +30,14 @@ Supported chips:
Prefix: 'it8728'
Addresses scanned: from Super I/O config space (8 I/O ports)
Datasheet: Not publicly available
* IT8771E
Prefix: 'it8771'
Addresses scanned: from Super I/O config space (8 I/O ports)
Datasheet: Not publicly available
* IT8772E
Prefix: 'it8772'
Addresses scanned: from Super I/O config space (8 I/O ports)
Datasheet: Not publicly available
* IT8782F
Prefix: 'it8782'
Addresses scanned: from Super I/O config space (8 I/O ports)
@ -83,8 +91,8 @@ Description
-----------
This driver implements support for the IT8705F, IT8712F, IT8716F,
IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E, IT8781F, IT8782F,
IT8783E/F, and SiS950 chips.
IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E, IT8771E, IT8772E,
IT8782F, IT8783E/F, and SiS950 chips.
These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
joysticks and other miscellaneous stuff. For hardware monitoring, they
@ -118,8 +126,8 @@ The IT8726F is just bit enhanced IT8716F with additional hardware
for AMD power sequencing. Therefore the chip will appear as IT8716F
to userspace applications.
The IT8728F is considered compatible with the IT8721F, until a datasheet
becomes available (hopefully.)
The IT8728F, IT8771E, and IT8772E are considered compatible with the IT8721F,
until a datasheet becomes available (hopefully.)
Temperatures are measured in degrees Celsius. An alarm is triggered once
when the Overtemperature Shutdown limit is crossed.

3
Documentation/hwmon/jc42
View File

@ -17,12 +17,13 @@ Supported chips:
* Maxim MAX6604
Datasheets:
http://datasheets.maxim-ic.com/en/ds/MAX6604.pdf
* Microchip MCP9804, MCP9805, MCP98242, MCP98243, MCP9843
* Microchip MCP9804, MCP9805, MCP98242, MCP98243, MCP98244, MCP9843
Datasheets:
http://ww1.microchip.com/downloads/en/DeviceDoc/22203C.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/21977b.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/21996a.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/22153c.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/22327A.pdf
* NXP Semiconductors SE97, SE97B, SE98, SE98A
Datasheets:
http://www.nxp.com/documents/data_sheet/SE97.pdf

90
Documentation/hwmon/lm73 Normal file
View File

@ -0,0 +1,90 @@
Kernel driver lm73
==================
Supported chips:
* Texas Instruments LM73
Prefix: 'lm73'
Addresses scanned: I2C 0x48, 0x49, 0x4a, 0x4c, 0x4d, and 0x4e
Datasheet: Publicly available at the Texas Instruments website
http://www.ti.com/product/lm73
Author: Guillaume Ligneul <guillaume.ligneul@gmail.com>
Documentation: Chris Verges <kg4ysn@gmail.com>
Description
-----------
The LM73 is a digital temperature sensor. All temperature values are
given in degrees Celsius.
Measurement Resolution Support
------------------------------
The LM73 supports four resolutions, defined in terms of degrees C per
LSB: 0.25, 0.125, 0.0625, and 0.3125. Changing the resolution mode
affects the conversion time of the LM73's analog-to-digital converter.
From userspace, the desired resolution can be specified as a function of
conversion time via the 'update_interval' sysfs attribute for the
device. This attribute will normalize ranges of input values to the
maximum times defined for the resolution in the datasheet.
Resolution Conv. Time Input Range
(C/LSB) (msec) (msec)
--------------------------------------
0.25 14 0..14
0.125 28 15..28
0.0625 56 29..56
0.03125 112 57..infinity
--------------------------------------
The following examples show how the 'update_interval' attribute can be
used to change the conversion time:
$ echo 0 > update_interval
$ cat update_interval
14
$ cat temp1_input
24250
$ echo 22 > update_interval
$ cat update_interval
28
$ cat temp1_input
24125
$ echo 56 > update_interval
$ cat update_interval
56
$ cat temp1_input
24062
$ echo 85 > update_interval
$ cat update_interval
112
$ cat temp1_input
24031
As shown here, the lm73 driver automatically adjusts any user input for
'update_interval' via a step function. Reading back the
'update_interval' value after a write operation will confirm the
conversion time actively in use.
Mathematically, the resolution can be derived from the conversion time
via the following function:
g(x) = 0.250 * [log(x/14) / log(2)]
where 'x' is the output from 'update_interval' and 'g(x)' is the
resolution in degrees C per LSB.
Alarm Support
-------------
The LM73 features a simple over-temperature alarm mechanism. This
feature is exposed via the sysfs attributes.
The attributes 'temp1_max_alarm' and 'temp1_min_alarm' are flags
provided by the LM73 that indicate whether the measured temperature has
passed the 'temp1_max' and 'temp1_min' thresholds, respectively. These
values _must_ be read to clear the registers on the LM73.

16
Documentation/hwmon/max34440
View File

@ -16,6 +16,16 @@ Supported chips:
Prefixes: 'max34446'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34446.pdf
* Maxim MAX34460
PMBus 12-Channel Voltage Monitor & Sequencer
Prefix: 'max34460'
Addresses scanned: -
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34460.pdf
* Maxim MAX34461
PMBus 16-Channel Voltage Monitor & Sequencer
Prefix: 'max34461'
Addresses scanned: -
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34461.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
@ -26,6 +36,9 @@ Description
This driver supports hardware montoring for Maxim MAX34440 PMBus 6-Channel
Power-Supply Manager, MAX34441 PMBus 5-Channel Power-Supply Manager
and Intelligent Fan Controller, and MAX34446 PMBus Power-Supply Data Logger.
It also supports the MAX34460 and MAX34461 PMBus Voltage Monitor & Sequencers.
The MAX34460 supports 12 voltage channels, and the MAX34461 supports 16 voltage
channels.
The driver is a client driver to the core PMBus driver. Please see
Documentation/hwmon/pmbus for details on PMBus client drivers.
@ -109,3 +122,6 @@ temp[1-8]_reset_history Write any value to reset history.
temp7 and temp8 attributes only exist for MAX34440.
MAX34446 only supports temp[1-3].
MAX34460 supports attribute groups in[1-12] and temp[1-5].
MAX34461 supports attribute groups in[1-16] and temp[1-5].

58
Documentation/hwmon/max6697 Normal file
View File

@ -0,0 +1,58 @@
Kernel driver max6697
=====================
Supported chips:
* Maxim MAX6581
Prefix: 'max6581'
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6581.pdf
* Maxim MAX6602
Prefix: 'max6602'
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6602.pdf
* Maxim MAX6622
Prefix: 'max6622'
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6622.pdf
* Maxim MAX6636
Prefix: 'max6636'
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6636.pdf
* Maxim MAX6689
Prefix: 'max6689'
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6689.pdf
* Maxim MAX6693
Prefix: 'max6693'
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6693.pdf
* Maxim MAX6694
Prefix: 'max6694'
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6694.pdf
* Maxim MAX6697
Prefix: 'max6697'
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6697.pdf
* Maxim MAX6698
Prefix: 'max6698'
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6698.pdf
* Maxim MAX6699
Prefix: 'max6699'
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6699.pdf
Author:
Guenter Roeck <linux@roeck-us.net>
Description
-----------
This driver implements support for several MAX6697 compatible temperature sensor
chips. The chips support one local temperature sensor plus four, six, or seven
remote temperature sensors. Remote temperature sensors are diode-connected
thermal transitors, except for MAX6698 which supports three diode-connected
thermal transistors plus three thermistors in addition to the local temperature
sensor.
The driver provides the following sysfs attributes. temp1 is the local (chip)
temperature, temp[2..n] are remote temperatures. The actually supported
per-channel attributes are chip type and channel dependent.
tempX_input RO temperature
tempX_max RW temperature maximum threshold
tempX_max_alarm RO temperature maximum threshold alarm
tempX_crit RW temperature critical threshold
tempX_crit_alarm RO temperature critical threshold alarm
tempX_fault RO temperature diode fault (remote sensors only)

8
Documentation/hwmon/sysfs-interface
View File

@ -722,14 +722,14 @@ add/subtract if it has been divided before the add/subtract.
What to do if a value is found to be invalid, depends on the type of the
sysfs attribute that is being set. If it is a continuous setting like a
tempX_max or inX_max attribute, then the value should be clamped to its
limits using SENSORS_LIMIT(value, min_limit, max_limit). If it is not
continuous like for example a tempX_type, then when an invalid value is
written, -EINVAL should be returned.
limits using clamp_val(value, min_limit, max_limit). If it is not continuous
like for example a tempX_type, then when an invalid value is written,
-EINVAL should be returned.
Example1, temp1_max, register is a signed 8 bit value (-128 - 127 degrees):
long v = simple_strtol(buf, NULL, 10) / 1000;
v = SENSORS_LIMIT(v, -128, 127);
v = clamp_val(v, -128, 127);
/* write v to register */
Example2, fan divider setting, valid values 2, 4 and 8:

26
Documentation/hwmon/zl6100
View File

@ -121,12 +121,26 @@ in1_max_alarm Input voltage high alarm.
in1_lcrit_alarm Input voltage critical low alarm.
in1_crit_alarm Input voltage critical high alarm.
in2_label "vout1"
in2_input Measured output voltage.
in2_lcrit Critical minimum output Voltage.
in2_crit Critical maximum output voltage.
in2_lcrit_alarm Critical output voltage critical low alarm.
in2_crit_alarm Critical output voltage critical high alarm.
in2_label "vmon"
in2_input Measured voltage on VMON (ZL2004) or VDRV (ZL9101M,
ZL9117M) pin. Reported voltage is 16x the voltage on the
pin (adjusted internally by the chip).
in2_lcrit Critical minumum VMON/VDRV Voltage.
in2_crit Critical maximum VMON/VDRV voltage.
in2_lcrit_alarm VMON/VDRV voltage critical low alarm.
in2_crit_alarm VMON/VDRV voltage critical high alarm.
vmon attributes are supported on ZL2004, ZL9101M,
and ZL9117M only.
inX_label "vout1"
inX_input Measured output voltage.
inX_lcrit Critical minimum output Voltage.
inX_crit Critical maximum output voltage.
inX_lcrit_alarm Critical output voltage critical low alarm.
inX_crit_alarm Critical output voltage critical high alarm.
X is 3 for ZL2004, ZL9101M, and ZL9117M, 2 otherwise.
curr1_label "iout1"
curr1_input Measured output current.

2
Documentation/ioctl/ioctl-number.txt
View File

@ -179,7 +179,7 @@ Code Seq#(hex) Include File Comments
'V' C0 media/davinci/vpfe_capture.h conflict!
'V' C0 media/si4713.h conflict!
'W' 00-1F linux/watchdog.h conflict!
'W' 00-1F linux/wanrouter.h conflict!
'W' 00-1F linux/wanrouter.h conflict! (pre 3.9)
'W' 00-3F sound/asound.h conflict!
'X' all fs/xfs/xfs_fs.h conflict!
and fs/xfs/linux-2.6/xfs_ioctl32.h

23
Documentation/kbuild/makefiles.txt
View File

@ -1186,6 +1186,29 @@ When kbuild executes, the following steps are followed (roughly):
clean-files += *.dtb
DTC_FLAGS ?= -p 1024
dtc_cpp
This is just like dtc as describe above, except that the C pre-
processor is invoked upon the .dtsp file before compiling the result
with dtc.
In order for build dependencies to work, all files compiled using
dtc_cpp must use the C pre-processor's #include functionality and not
dtc's /include/ functionality.
Using the C pre-processor allows use of #define to create named
constants. In turn, the #defines will typically appear in a header
file, which may be shared with regular C code. Since the dtc language
represents a data structure rather than code in C syntax, similar
restrictions are placed on a header file included by a device tree
file as for a header file included by an assembly language file.
In particular, the C pre-processor is passed -x assembler-with-cpp,
which sets macro __ASSEMBLY__. __DTS__ is also set. These allow header
files to restrict their content to that compatible with device tree
source.
A central rule exists to create $(obj)/%.dtb from $(src)/%.dtsp;
architecture Makefiles do no need to explicitly write out that rule.
--- 6.8 Custom kbuild commands
When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand

16
Documentation/kernel-parameters.txt
View File

@ -1039,16 +1039,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
Claim all unknown PCI IDE storage controllers.
idle= [X86]
Format: idle=poll, idle=mwait, idle=halt, idle=nomwait
Format: idle=poll, idle=halt, idle=nomwait
Poll forces a polling idle loop that can slightly
improve the performance of waking up a idle CPU, but
will use a lot of power and make the system run hot.
Not recommended.
idle=mwait: On systems which support MONITOR/MWAIT but
the kernel chose to not use it because it doesn't save
as much power as a normal idle loop, use the
MONITOR/MWAIT idle loop anyways. Performance should be
the same as idle=poll.
idle=halt: Halt is forced to be used for CPU idle.
In such case C2/C3 won't be used again.
idle=nomwait: Disable mwait for CPU C-states
@ -1131,6 +1126,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
0 disables intel_idle and fall back on acpi_idle.
1 to 6 specify maximum depth of C-state.
intel_pstate= [X86]
disable
Do not enable intel_pstate as the default
scaling driver for the supported processors
intremap= [X86-64, Intel-IOMMU]
on enable Interrupt Remapping (default)
off disable Interrupt Remapping
@ -1886,10 +1886,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
wfi(ARM) instruction doesn't work correctly and not to
use it. This is also useful when using JTAG debugger.
no-hlt [BUGS=X86-32] Tells the kernel that the hlt
instruction doesn't work correctly and not to
use it.
no_file_caps Tells the kernel not to honor file capabilities. The
only way then for a file to be executed with privilege
is to be setuid root or executed by root.

2
Documentation/magic-number.txt
View File

@ -122,7 +122,7 @@ SLAB_C_MAGIC 0x4f17a36d kmem_cache mm/slab.c
COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c
I810_CARD_MAGIC 0x5072696E i810_card sound/oss/i810_audio.c
TRIDENT_CARD_MAGIC 0x5072696E trident_card sound/oss/trident.c
ROUTER_MAGIC 0x524d4157 wan_device include/linux/wanrouter.h
ROUTER_MAGIC 0x524d4157 wan_device [in wanrouter.h pre 3.9]
SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h
SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c
GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h

1
Documentation/memory-barriers.txt
View File

@ -1685,6 +1685,7 @@ explicit lock operations, described later). These include:
xchg();
cmpxchg();
atomic_xchg();
atomic_cmpxchg();
atomic_inc_return();
atomic_dec_return();

6
Documentation/networking/00-INDEX
View File

@ -52,8 +52,6 @@ de4x5.txt
- the Digital EtherWORKS DE4?? and DE5?? PCI Ethernet driver
decnet.txt
- info on using the DECnet networking layer in Linux.
depca.txt
- the Digital DEPCA/EtherWORKS DE1?? and DE2?? LANCE Ethernet driver
dl2k.txt
- README for D-Link DL2000-based Gigabit Ethernet Adapters (dl2k.ko).
dm9000.txt
@ -72,8 +70,6 @@ e1000e.txt
- README for the Intel Gigabit Ethernet Driver (e1000e).
eql.txt
- serial IP load balancing
ewrk3.txt
- the Digital EtherWORKS 3 DE203/4/5 Ethernet driver
fib_trie.txt
- Level Compressed Trie (LC-trie) notes: a structure for routing.
filter.txt
@ -126,8 +122,6 @@ ltpc.txt
- the Apple or Farallon LocalTalk PC card driver
mac80211-injection.txt
- HOWTO use packet injection with mac80211
multicast.txt
- Behaviour of cards under Multicast
multiqueue.txt
- HOWTO for multiqueue network device support.
netconsole.txt

203
Documentation/networking/DLINK.txt
View File

@ -1,203 +0,0 @@
Released 1994-06-13
CONTENTS:
1. Introduction.
2. License.
3. Files in this release.
4. Installation.
5. Problems and tuning.
6. Using the drivers with earlier releases.
7. Acknowledgments.
1. INTRODUCTION.
This is a set of Ethernet drivers for the D-Link DE-600/DE-620
pocket adapters, for the parallel port on a Linux based machine.
Some adapter "clones" will also work. Xircom is _not_ a clone...
These drivers _can_ be used as loadable modules,
and were developed for use on Linux 1.1.13 and above.
For use on Linux 1.0.X, or earlier releases, see below.
I have used these drivers for NFS, ftp, telnet and X-clients on
remote machines. Transmissions with ftp seems to work as
good as can be expected (i.e. > 80k bytes/sec) from a
parallel port...:-) Receive speeds will be about 60-80% of this.
Depending on your machine, somewhat higher speeds can be achieved.
All comments/fixes to Bjorn Ekwall (bj0rn@blox.se).
2. LICENSE.
This program is free software; you can redistribute it
and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 2, or (at your option) any later version.
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License for more
details.
You should have received a copy of the GNU General Public
License along with this program; if not, write to the Free
Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
02139, USA.
3. FILES IN THIS RELEASE.
README.DLINK This file.
de600.c The Source (may it be with You :-) for the DE-600
de620.c ditto for the DE-620
de620.h Macros for de620.c
If you are upgrading from the d-link tar release, there will
also be a "dlink-patches" file that will patch Linux 1.1.18:
linux/drivers/net/Makefile
linux/drivers/net/CONFIG
linux/drivers/net/MODULES
linux/drivers/net/Space.c
linux/config.in
Apply the patch by:
"cd /usr/src; patch -p0 < linux/drivers/net/dlink-patches"
The old source, "linux/drivers/net/d_link.c", can be removed.
4. INSTALLATION.
o Get the latest net binaries, according to current net.wisdom.
o Read the NET-2 and Ethernet HOWTOs and modify your setup.
o If your parallel port has a strange address or irq,
modify "linux/drivers/net/CONFIG" accordingly, or adjust
the parameters in the "tuning" section in the sources.
If you are going to use the drivers as loadable modules, do _not_
enable them while doing "make config", but instead make sure that
the drivers are included in "linux/drivers/net/MODULES".
If you are _not_ going to use the driver(s) as loadable modules,
but instead have them included in the kernel, remember to enable
the drivers while doing "make config".
o To include networking and DE600/DE620 support in your kernel:
# cd /linux
(as modules:)
# make config (answer yes on CONFIG_NET and CONFIG_INET)
(else included in the kernel:)
# make config (answer yes on CONFIG _NET, _INET and _DE600 or _DE620)
# make clean
# make zImage (or whatever magic you usually do)
o I use lilo to boot multiple kernels, so that I at least
can have one working kernel :-). If you do too, append
these lines to /etc/lilo/config:
image = /linux/zImage
label = newlinux
root = /dev/hda2 (or whatever YOU have...)
# /etc/lilo/install
o Do "sync" and reboot the new kernel with a D-Link
DE-600/DE-620 pocket adapter connected.
o The adapter can be configured with ifconfig eth?
where the actual number is decided by the kernel
when the drivers are initialized.
5. "PROBLEMS" AND TUNING,
o If you see error messages from the driver, and if the traffic
stops on the adapter, try to do "ifconfig" and "route" once
more, just as in "rc.inet1". This should take care of most
problems, including effects from power loss, or adapters that
aren't connected to the printer port in some way or another.
You can somewhat change the behaviour by enabling/disabling
the macro SHUTDOWN_WHEN_LOST in the "tuning" section.
For the DE-600 there is another macro, CHECK_LOST_DE600,
that you might want to read about in the "tuning" section.
o Some machines have trouble handling the parallel port and
the adapter at high speed. If you experience problems:
DE-600:
- The adapter is not recognized at boot, i.e. an Ethernet
address of 00:80:c8:... is not shown, try to add another
"; SLOW_DOWN_IO"
at DE600_SLOW_DOWN in the "tuning" section. As a last resort,
uncomment: "#define REALLY_SLOW_IO" (see <asm/io.h> for hints).
- You experience "timeout" messages: first try to add another
"; SLOW_DOWN_IO"
at DE600_SLOW_DOWN in the "tuning" section, _then_ try to
increase the value (original value: 5) at
"if (tickssofar < 5)" near line 422.
DE-620:
- Your parallel port might be "sluggish". To cater for
this, there are the macros LOWSPEED and READ_DELAY/WRITE_DELAY
in the "tuning" section. Your first step should be to enable
LOWSPEED, and after that you can "tune" the XXX_DELAY values.
o If the adapter _is_ recognized at boot but you get messages
about "Network Unreachable", then the problem is probably
_not_ with the driver. Check your net configuration instead
(ifconfig and route) in "rc.inet1".
o There is some rudimentary support for debugging, look at
the source. Use "-DDE600_DEBUG=3" or "-DDE620_DEBUG=3"
when compiling, or include it in "linux/drivers/net/CONFIG".
IF YOU HAVE PROBLEMS YOU CAN'T SOLVE: PLEASE COMPILE THE DRIVER
WITH DEBUGGING ENABLED, AND SEND ME THE RESULTING OUTPUT!
6. USING THE DRIVERS WITH EARLIER RELEASES.
The later 1.1.X releases of the Linux kernel include some
changes in the networking layer (a.k.a. NET3). This affects
these drivers in a few places. The hints that follow are
_not_ tested by me, since I don't have the disk space to keep
all releases on-line.
Known needed changes to date:
- release patchfile: some patches will fail, but they should
be easy to apply "by hand", since they are trivial.
(Space.c: d_link_init() is now called de600_probe())
- de600.c: change "mark_bh(NET_BH)" to "mark_bh(INET_BH)".
- de620.c: (maybe) change the code around "netif_rx(skb);" to be
similar to the code around "dev_rint(...)" in de600.c
7. ACKNOWLEDGMENTS.
These drivers wouldn't have been done without the base
(and support) from Ross Biro, and D-Link Systems Inc.
The driver relies upon GPL-ed source from D-Link Systems Inc.
and from Russel Nelson at Crynwr Software <nelson@crynwr.com>.
Additional input also from:
Donald Becker <becker@super.org>, Alan Cox <A.Cox@swansea.ac.uk>
and Fred N. van Kempen <waltje@uWalt.NL.Mugnet.ORG>
DE-600 alpha release primary victim^H^H^H^H^H^Htester:
- Erik Proper <erikp@cs.kun.nl>.
Good input also from several users, most notably
- Mark Burton <markb@ordern.demon.co.uk>.
DE-620 alpha release victims^H^H^H^H^H^H^Htesters:
- J. Joshua Kopper <kopper@rtsg.mot.com>
- Olav Kvittem <Olav.Kvittem@uninett.no>
- Germano Caronni <caronni@nessie.cs.id.ethz.ch>
- Jeremy Fitzhardinge <jeremy@suite.sw.oz.au>
Happy hacking!
Bjorn Ekwall == bj0rn@blox.se

2
Documentation/networking/LICENSE.qlcnic
View File

@ -1,4 +1,4 @@
Copyright (c) 2009-2011 QLogic Corporation
Copyright (c) 2009-2013 QLogic Corporation
QLogic Linux qlcnic NIC Driver
You may modify and redistribute the device driver code under the

79
Documentation/networking/cs89x0.txt
View File

@ -36,7 +36,6 @@ TABLE OF CONTENTS
4.1 Compiling the Driver as a Loadable Module
4.2 Compiling the driver to support memory mode
4.3 Compiling the driver to support Rx DMA
4.4 Compiling the Driver into the Kernel
5.0 TESTING AND TROUBLESHOOTING
5.1 Known Defects and Limitations
@ -364,84 +363,6 @@ The compile-time optionality for DMA was removed in the 2.3 kernel
series. DMA support is now unconditionally part of the driver. It is
enabled by the 'use_dma=1' module option.
4.4 COMPILING THE DRIVER INTO THE KERNEL
If your Linux distribution already has support for the cs89x0 driver
then simply copy the source file to the /usr/src/linux/drivers/net
directory to replace the original ones and run the make utility to
rebuild the kernel. See Step 3 for rebuilding the kernel.
If your Linux does not include the cs89x0 driver, you need to edit three
configuration files, copy the source file to the /usr/src/linux/drivers/net
directory, and then run the make utility to rebuild the kernel.
1. Edit the following configuration files by adding the statements as
indicated. (When possible, try to locate the added text to the section of the
file containing similar statements).
a.) In /usr/src/linux/drivers/net/Config.in, add:
tristate 'CS89x0 support' CONFIG_CS89x0
Example:
if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
tristate 'ICL EtherTeam 16i/32 support' CONFIG_ETH16I
fi
tristate 'CS89x0 support' CONFIG_CS89x0
tristate 'NE2000/NE1000 support' CONFIG_NE2000
if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
tristate 'NI5210 support' CONFIG_NI52
b.) In /usr/src/linux/drivers/net/Makefile, add the following lines:
ifeq ($(CONFIG_CS89x0),y)
L_OBJS += cs89x0.o
else
ifeq ($(CONFIG_CS89x0),m)
M_OBJS += cs89x0.o
endif
endif
c.) In /linux/drivers/net/Space.c file, add the line:
extern int cs89x0_probe(struct device *dev);
Example:
extern int ultra_probe(struct device *dev);
extern int wd_probe(struct device *dev);
extern int el2_probe(struct device *dev);
extern int cs89x0_probe(struct device *dev);
extern int ne_probe(struct device *dev);
extern int hp_probe(struct device *dev);
extern int hp_plus_probe(struct device *dev);
Also add:
#ifdef CONFIG_CS89x0
{ cs89x0_probe,0 },
#endif
2.) Copy the driver source files (cs89x0.c and cs89x0.h)
into the /usr/src/linux/drivers/net directory.
3.) Go to /usr/src/linux directory and run 'make config' followed by 'make'
(or make bzImage) to rebuild the kernel.
4.) Use the DOS 'setup' utility to disable plug and play on the NIC.
5.0 TESTING AND TROUBLESHOOTING
===============================================================================

92
Documentation/networking/depca.txt
View File

@ -1,92 +0,0 @@
DE10x
=====
Memory Addresses:
SW1 SW2 SW3 SW4
64K on on on on d0000 dbfff
off on on on c0000 cbfff
off off on on e0000 ebfff
32K on on off on d8000 dbfff
off on off on c8000 cbfff
off off off on e8000 ebfff
DBR ROM on on dc000 dffff
off on cc000 cffff
off off ec000 effff
Note that the 2K mode is set by SW3/SW4 on/off or off/off. Address
assignment is through the RBSA register.
I/O Address:
SW5
0x300 on
0x200 off
Remote Boot:
SW6
Disable on
Enable off
Remote Boot Timeout:
SW7
2.5min on
30s off
IRQ:
SW8 SW9 SW10 SW11 SW12
2 on off off off off
3 off on off off off
4 off off on off off
5 off off off on off
7 off off off off on
DE20x
=====
Memory Size:
SW3 SW4
64K on on
32K off on
2K on off
2K off off
Start Addresses:
SW1 SW2 SW3 SW4
64K on on on on c0000 cffff
on off on on d0000 dffff
off on on on e0000 effff
32K on on off off c8000 cffff
on off off off d8000 dffff
off on off off e8000 effff
Illegal off off - - - -
I/O Address:
SW5
0x300 on
0x200 off
Remote Boot:
SW6
Disable on
Enable off
Remote Boot Timeout:
SW7
2.5min on
30s off
IRQ:
SW8 SW9 SW10 SW11 SW12
5 on off off off off
9 off on off off off
10 off off on off off
11 off off off on off
15 off off off off on

46
Documentation/networking/ewrk3.txt
View File

@ -1,46 +0,0 @@
The EtherWORKS 3 driver in this distribution is designed to work with all
kernels > 1.1.33 (approx) and includes tools in the 'ewrk3tools'
subdirectory to allow set up of the card, similar to the MSDOS
'NICSETUP.EXE' tools provided on the DOS drivers disk (type 'make' in that
subdirectory to make the tools).
The supported cards are DE203, DE204 and DE205. All other cards are NOT
supported - refer to 'depca.c' for running the LANCE based network cards and
'de4x5.c' for the DIGITAL Semiconductor PCI chip based adapters from
Digital.
The ability to load this driver as a loadable module has been included and
used extensively during the driver development (to save those long reboot
sequences). To utilise this ability, you have to do 8 things:
0) have a copy of the loadable modules code installed on your system.
1) copy ewrk3.c from the /linux/drivers/net directory to your favourite
temporary directory.
2) edit the source code near line 1898 to reflect the I/O address and
IRQ you're using.
3) compile ewrk3.c, but include -DMODULE in the command line to ensure
that the correct bits are compiled (see end of source code).
4) if you are wanting to add a new card, goto 5. Otherwise, recompile a
kernel with the ewrk3 configuration turned off and reboot.
5) insmod ewrk3.o
[Alan Cox: Changed this so you can insmod ewrk3.o irq=x io=y]
[Adam Kropelin: Multiple cards now supported by irq=x1,x2 io=y1,y2]
6) run the net startup bits for your new eth?? interface manually
(usually /etc/rc.inet[12] at boot time).
7) enjoy!
Note that autoprobing is not allowed in loadable modules - the system is
already up and running and you're messing with interrupts.
To unload a module, turn off the associated interface
'ifconfig eth?? down' then 'rmmod ewrk3'.
The performance we've achieved so far has been measured through the 'ttcp'
tool at 975kB/s. This measures the total TCP stack performance which
includes the card, so don't expect to get much nearer the 1.25MB/s
theoretical Ethernet rate.
Enjoy!
Dave

11
Documentation/networking/filter.txt
View File

@ -17,12 +17,12 @@ creating filters.
LSF is much simpler than BPF. One does not have to worry about
devices or anything like that. You simply create your filter
code, send it to the kernel via the SO_ATTACH_FILTER ioctl and
code, send it to the kernel via the SO_ATTACH_FILTER option and
if your filter code passes the kernel check on it, you then
immediately begin filtering data on that socket.
You can also detach filters from your socket via the
SO_DETACH_FILTER ioctl. This will probably not be used much
SO_DETACH_FILTER option. This will probably not be used much
since when you close a socket that has a filter on it the
filter is automagically removed. The other less common case
may be adding a different filter on the same socket where you had another
@ -31,12 +31,19 @@ the old one and placing your new one in its place, assuming your
filter has passed the checks, otherwise if it fails the old filter
will remain on that socket.
SO_LOCK_FILTER option allows to lock the filter attached to a
socket. Once set, a filter cannot be removed or changed. This allows
one process to setup a socket, attach a filter, lock it then drop
privileges and be assured that the filter will be kept until the
socket is closed.
Examples
========
Ioctls-
setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_FILTER, &Filter, sizeof(Filter));
setsockopt(sockfd, SOL_SOCKET, SO_DETACH_FILTER, &value, sizeof(value));
setsockopt(sockfd, SOL_SOCKET, SO_LOCK_FILTER, &value, sizeof(value));
See the BSD bpf.4 manpage and the BSD Packet Filter paper written by
Steven McCanne and Van Jacobson of Lawrence Berkeley Laboratory.

19
Documentation/networking/ip-sysctl.txt
View File

@ -26,6 +26,11 @@ route/max_size - INTEGER
Maximum number of routes allowed in the kernel. Increase
this when using large numbers of interfaces and/or routes.
neigh/default/gc_thresh1 - INTEGER
Minimum number of entries to keep. Garbage collector will not
purge entries if there are fewer than this number.
Default: 256
neigh/default/gc_thresh3 - INTEGER
Maximum number of neighbor entries allowed. Increase this
when using large numbers of interfaces and when communicating
@ -125,17 +130,6 @@ somaxconn - INTEGER
Defaults to 128. See also tcp_max_syn_backlog for additional tuning
for TCP sockets.
tcp_abc - INTEGER
Controls Appropriate Byte Count (ABC) defined in RFC3465.
ABC is a way of increasing congestion window (cwnd) more slowly
in response to partial acknowledgments.
Possible values are:
0 increase cwnd once per acknowledgment (no ABC)
1 increase cwnd once per acknowledgment of full sized segment
2 allow increase cwnd by two if acknowledgment is
of two segments to compensate for delayed acknowledgments.
Default: 0 (off)
tcp_abort_on_overflow - BOOLEAN
If listening service is too slow to accept new connections,
reset them. Default state is FALSE. It means that if overflow
@ -214,7 +208,8 @@ tcp_ecn - INTEGER
congestion before having to drop packets.
Possible values are:
0 Disable ECN. Neither initiate nor accept ECN.
1 Always request ECN on outgoing connection attempts.
1 Enable ECN when requested by incoming connections and
also request ECN on outgoing connection attempts.
2 Enable ECN when requested by incoming connections
but do not request ECN on outgoing connections.
Default: 2

63
Documentation/networking/multicast.txt
View File

@ -1,63 +0,0 @@
Behaviour of Cards Under Multicast
==================================
This is how they currently behave, not what the hardware can do--for example,
the Lance driver doesn't use its filter, even though the code for loading
it is in the DEC Lance-based driver.
The following are requirements for multicasting
-----------------------------------------------
AppleTalk Multicast hardware filtering not important but
avoid cards only doing promisc
IP-Multicast Multicast hardware filters really help
IP-MRoute AllMulti hardware filters are of no help
Board Multicast AllMulti Promisc Filter
------------------------------------------------------------------------
3c501 YES YES YES Software
3c503 YES YES YES Hardware
3c505 YES NO YES Hardware
3c507 NO NO NO N/A
3c509 YES YES YES Software
3c59x YES YES YES Software
ac3200 YES YES YES Hardware
apricot YES PROMISC YES Hardware
arcnet NO NO NO N/A
at1700 PROMISC PROMISC YES Software
atp PROMISC PROMISC YES Software
cs89x0 YES YES YES Software
de4x5 YES YES YES Hardware
de600 NO NO NO N/A
de620 PROMISC PROMISC YES Software
depca YES PROMISC YES Hardware
dmfe YES YES YES Software(*)
e2100 YES YES YES Hardware
eepro YES PROMISC YES Hardware
eexpress NO NO NO N/A
ewrk3 YES PROMISC YES Hardware
hp-plus YES YES YES Hardware
hp YES YES YES Hardware
hp100 YES YES YES Hardware
ibmtr NO NO NO N/A
ioc3-eth YES YES YES Hardware
lance YES YES YES Software(#)
ne YES YES YES Hardware
ni52 <------------------ Buggy ------------------>
ni65 YES YES YES Software(#)
seeq NO NO NO N/A
sgiseek <------------------ Buggy ------------------>
smc-ultra YES YES YES Hardware
sunlance YES YES YES Hardware
tulip YES YES YES Hardware
wavelan YES PROMISC YES Hardware
wd YES YES YES Hardware
xirc2ps_cs YES YES YES Hardware
znet YES YES YES Software
PROMISC = This multicast mode is in fact promiscuous mode. Avoid using
cards who go PROMISC on any multicast in a multicast kernel.
(#) = Hardware multicast support is not used yet.
(*) = Hardware support for Davicom 9132 chipset only.

7
Documentation/networking/netconsole.txt
View File

@ -1,9 +1,10 @@
started by Ingo Molnar <mingo@redhat.com>, 2001.09.17
2.6 port and netpoll api by Matt Mackall <mpm@selenic.com>, Sep 9 2003
IPv6 support by Cong Wang <xiyou.wangcong@gmail.com>, Jan 1 2013
Please send bug reports to Matt Mackall <mpm@selenic.com>
and Satyam Sharma <satyam.sharma@gmail.com>
Satyam Sharma <satyam.sharma@gmail.com>, and Cong Wang <xiyou.wangcong@gmail.com>
Introduction:
=============
@ -41,6 +42,10 @@ Examples:
insmod netconsole netconsole=@/,@10.0.0.2/
or using IPv6
insmod netconsole netconsole=@/,@fd00:1:2:3::1/
It also supports logging to multiple remote agents by specifying
parameters for the multiple agents separated by semicolons and the
complete string enclosed in "quotes", thusly:

176
Documentation/networking/nf_conntrack-sysctl.txt Normal file
View File

@ -0,0 +1,176 @@
/proc/sys/net/netfilter/nf_conntrack_* Variables:
nf_conntrack_acct - BOOLEAN
0 - disabled (default)
not 0 - enabled
Enable connection tracking flow accounting. 64-bit byte and packet
counters per flow are added.
nf_conntrack_buckets - INTEGER (read-only)
Size of hash table. If not specified as parameter during module
loading, the default size is calculated by dividing total memory
by 16384 to determine the number of buckets but the hash table will
never have fewer than 32 or more than 16384 buckets.
nf_conntrack_checksum - BOOLEAN
0 - disabled
not 0 - enabled (default)
Verify checksum of incoming packets. Packets with bad checksums are
in INVALID state. If this is enabled, such packets will not be
considered for connection tracking.
nf_conntrack_count - INTEGER (read-only)
Number of currently allocated flow entries.
nf_conntrack_events - BOOLEAN
0 - disabled
not 0 - enabled (default)
If this option is enabled, the connection tracking code will
provide userspace with connection tracking events via ctnetlink.
nf_conntrack_events_retry_timeout - INTEGER (seconds)
default 15
This option is only relevant when "reliable connection tracking
events" are used. Normally, ctnetlink is "lossy", that is,
events are normally dropped when userspace listeners can't keep up.
Userspace can request "reliable event mode". When this mode is
active, the conntrack will only be destroyed after the event was
delivered. If event delivery fails, the kernel periodically
re-tries to send the event to userspace.
This is the maximum interval the kernel should use when re-trying
to deliver the destroy event.
A higher number means there will be fewer delivery retries and it
will take longer for a backlog to be processed.
nf_conntrack_expect_max - INTEGER
Maximum size of expectation table. Default value is
nf_conntrack_buckets / 256. Minimum is 1.
nf_conntrack_frag6_high_thresh - INTEGER
default 262144
Maximum memory used to reassemble IPv6 fragments. When
nf_conntrack_frag6_high_thresh bytes of memory is allocated for this
purpose, the fragment handler will toss packets until
nf_conntrack_frag6_low_thresh is reached.
nf_conntrack_frag6_low_thresh - INTEGER
default 196608
See nf_conntrack_frag6_low_thresh
nf_conntrack_frag6_timeout - INTEGER (seconds)
default 60
Time to keep an IPv6 fragment in memory.
nf_conntrack_generic_timeout - INTEGER (seconds)
default 600
Default for generic timeout. This refers to layer 4 unknown/unsupported
protocols.
nf_conntrack_helper - BOOLEAN
0 - disabled
not 0 - enabled (default)
Enable automatic conntrack helper assignment.
nf_conntrack_icmp_timeout - INTEGER (seconds)
default 30
Default for ICMP timeout.
nf_conntrack_icmpv6_timeout - INTEGER (seconds)
default 30
Default for ICMP6 timeout.
nf_conntrack_log_invalid - INTEGER
0 - disable (default)
1 - log ICMP packets
6 - log TCP packets
17 - log UDP packets
33 - log DCCP packets
41 - log ICMPv6 packets
136 - log UDPLITE packets
255 - log packets of any protocol
Log invalid packets of a type specified by value.
nf_conntrack_max - INTEGER
Size of connection tracking table. Default value is
nf_conntrack_buckets value * 4.
nf_conntrack_tcp_be_liberal - BOOLEAN
0 - disabled (default)
not 0 - enabled
Be conservative in what you do, be liberal in what you accept from others.
If it's non-zero, we mark only out of window RST segments as INVALID.
nf_conntrack_tcp_loose - BOOLEAN
0 - disabled
not 0 - enabled (default)
If it is set to zero, we disable picking up already established
connections.
nf_conntrack_tcp_max_retrans - INTEGER
default 3
Maximum number of packets that can be retransmitted without
received an (acceptable) ACK from the destination. If this number
is reached, a shorter timer will be started.
nf_conntrack_tcp_timeout_close - INTEGER (seconds)
default 10
nf_conntrack_tcp_timeout_close_wait - INTEGER (seconds)
default 60
nf_conntrack_tcp_timeout_established - INTEGER (seconds)
default 432000 (5 days)
nf_conntrack_tcp_timeout_fin_wait - INTEGER (seconds)
default 120
nf_conntrack_tcp_timeout_last_ack - INTEGER (seconds)
default 30
nf_conntrack_tcp_timeout_max_retrans - INTEGER (seconds)
default 300
nf_conntrack_tcp_timeout_syn_recv - INTEGER (seconds)
default 60
nf_conntrack_tcp_timeout_syn_sent - INTEGER (seconds)
default 120
nf_conntrack_tcp_timeout_time_wait - INTEGER (seconds)
default 120
nf_conntrack_tcp_timeout_unacknowledged - INTEGER (seconds)
default 300
nf_conntrack_timestamp - BOOLEAN
0 - disabled (default)
not 0 - enabled
Enable connection tracking flow timestamping.
nf_conntrack_udp_timeout - INTEGER (seconds)
default 30
nf_conntrack_udp_timeout_stream2 - INTEGER (seconds)
default 180
This extended timeout will be used in case there is an UDP stream
detected.

4
Documentation/networking/operstates.txt
View File

@ -88,6 +88,10 @@ set this flag. On netif_carrier_off(), the scheduler stops sending
packets. The name 'carrier' and the inversion are historical, think of
it as lower layer.
Note that for certain kind of soft-devices, which are not managing any
real hardware, there is possible to set this bit from userpsace.
One should use TVL IFLA_CARRIER to do so.
netif_carrier_ok() can be used to query that bit.
__LINK_STATE_DORMANT, maps to IFF_DORMANT:

11
Documentation/networking/phy.txt
View File

@ -103,7 +103,7 @@ Letting the PHY Abstraction Layer do Everything
Now, to connect, just call this function:
phydev = phy_connect(dev, phy_name, &adjust_link, flags, interface);
phydev = phy_connect(dev, phy_name, &adjust_link, interface);
phydev is a pointer to the phy_device structure which represents the PHY. If
phy_connect is successful, it will return the pointer. dev, here, is the
@ -113,7 +113,9 @@ Letting the PHY Abstraction Layer do Everything
current state, though the PHY will not yet be truly operational at this
point.
flags is a u32 which can optionally contain phy-specific flags.
PHY-specific flags should be set in phydev->dev_flags prior to the call
to phy_connect() such that the underlying PHY driver can check for flags
and perform specific operations based on them.
This is useful if the system has put hardware restrictions on
the PHY/controller, of which the PHY needs to be aware.
@ -185,11 +187,10 @@ Doing it all yourself
start, or disables then frees them for stop.
struct phy_device * phy_attach(struct net_device *dev, const char *phy_id,
u32 flags, phy_interface_t interface);
phy_interface_t interface);
Attaches a network device to a particular PHY, binding the PHY to a generic
driver if none was found during bus initialization. Passes in
any phy-specific flags as needed.
driver if none was found during bus initialization.
int phy_start_aneg(struct phy_device *phydev);

129
Documentation/nfc/nfc-hci.txt
View File

@ -17,10 +17,12 @@ HCI
HCI registers as an nfc device with NFC Core. Requests coming from userspace are
routed through netlink sockets to NFC Core and then to HCI. From this point,
they are translated in a sequence of HCI commands sent to the HCI layer in the
host controller (the chip). The sending context blocks while waiting for the
response to arrive.
host controller (the chip). Commands can be executed synchronously (the sending
context blocks waiting for response) or asynchronously (the response is returned
from HCI Rx context).
HCI events can also be received from the host controller. They will be handled
and a translation will be forwarded to NFC Core as needed.
and a translation will be forwarded to NFC Core as needed. There are hooks to
let the HCI driver handle proprietary events or override standard behavior.
HCI uses 2 execution contexts:
- one for executing commands : nfc_hci_msg_tx_work(). Only one command
can be executing at any given moment.
@ -33,6 +35,8 @@ The Session initialization is an HCI standard which must unfortunately
support proprietary gates. This is the reason why the driver will pass a list
of proprietary gates that must be part of the session. HCI will ensure all
those gates have pipes connected when the hci device is set up.
In case the chip supports pre-opened gates and pseudo-static pipes, the driver
can pass that information to HCI core.
HCI Gates and Pipes
-------------------
@ -46,6 +50,13 @@ without knowing the pipe connected to it.
Driver interface
----------------
A driver is generally written in two parts : the physical link management and
the HCI management. This makes it easier to maintain a driver for a chip that
can be connected using various phy (i2c, spi, ...)
HCI Management
--------------
A driver would normally register itself with HCI and provide the following
entry points:
@ -53,58 +64,113 @@ struct nfc_hci_ops {
int (*open)(struct nfc_hci_dev *hdev);
void (*close)(struct nfc_hci_dev *hdev);
int (*hci_ready) (struct nfc_hci_dev *hdev);
int (*xmit)(struct nfc_hci_dev *hdev, struct sk_buff *skb);
int (*start_poll)(struct nfc_hci_dev *hdev, u32 protocols);
int (*target_from_gate)(struct nfc_hci_dev *hdev, u8 gate,
struct nfc_target *target);
int (*xmit) (struct nfc_hci_dev *hdev, struct sk_buff *skb);
int (*start_poll) (struct nfc_hci_dev *hdev,
u32 im_protocols, u32 tm_protocols);
int (*dep_link_up)(struct nfc_hci_dev *hdev, struct nfc_target *target,
u8 comm_mode, u8 *gb, size_t gb_len);
int (*dep_link_down)(struct nfc_hci_dev *hdev);
int (*target_from_gate) (struct nfc_hci_dev *hdev, u8 gate,
struct nfc_target *target);
int (*complete_target_discovered) (struct nfc_hci_dev *hdev, u8 gate,
struct nfc_target *target);
int (*data_exchange) (struct nfc_hci_dev *hdev,
struct nfc_target *target,
struct sk_buff *skb, struct sk_buff **res_skb);
int (*im_transceive) (struct nfc_hci_dev *hdev,
struct nfc_target *target, struct sk_buff *skb,
data_exchange_cb_t cb, void *cb_context);
int (*tm_send)(struct nfc_hci_dev *hdev, struct sk_buff *skb);
int (*check_presence)(struct nfc_hci_dev *hdev,
struct nfc_target *target);
int (*event_received)(struct nfc_hci_dev *hdev, u8 gate, u8 event,
struct sk_buff *skb);
};
- open() and close() shall turn the hardware on and off.
- hci_ready() is an optional entry point that is called right after the hci
session has been set up. The driver can use it to do additional initialization
that must be performed using HCI commands.
- xmit() shall simply write a frame to the chip.
- xmit() shall simply write a frame to the physical link.
- start_poll() is an optional entrypoint that shall set the hardware in polling
mode. This must be implemented only if the hardware uses proprietary gates or a
mechanism slightly different from the HCI standard.
- dep_link_up() is called after a p2p target has been detected, to finish
the p2p connection setup with hardware parameters that need to be passed back
to nfc core.
- dep_link_down() is called to bring the p2p link down.
- target_from_gate() is an optional entrypoint to return the nfc protocols
corresponding to a proprietary gate.
- complete_target_discovered() is an optional entry point to let the driver
perform additional proprietary processing necessary to auto activate the
discovered target.
- data_exchange() must be implemented by the driver if proprietary HCI commands
- im_transceive() must be implemented by the driver if proprietary HCI commands
are required to send data to the tag. Some tag types will require custom
commands, others can be written to using the standard HCI commands. The driver
can check the tag type and either do proprietary processing, or return 1 to ask
for standard processing.
for standard processing. The data exchange command itself must be sent
asynchronously.
- tm_send() is called to send data in the case of a p2p connection
- check_presence() is an optional entry point that will be called regularly
by the core to check that an activated tag is still in the field. If this is
not implemented, the core will not be able to push tag_lost events to the user
space
- event_received() is called to handle an event coming from the chip. Driver
can handle the event or return 1 to let HCI attempt standard processing.
On the rx path, the driver is responsible to push incoming HCP frames to HCI
using nfc_hci_recv_frame(). HCI will take care of re-aggregation and handling
This must be done from a context that can sleep.
SHDLC
-----
PHY Management
--------------
Most chips use shdlc to ensure integrity and delivery ordering of the HCP
frames between the host controller (the chip) and hosts (entities connected
to the chip, like the cpu). In order to simplify writing the driver, an shdlc
layer is available for use by the driver.
When used, the driver actually registers with shdlc, and shdlc will register
with HCI. HCI sees shdlc as the driver and thus send its HCP frames
through shdlc->xmit.
SHDLC adds a new execution context (nfc_shdlc_sm_work()) to run its state
machine and handle both its rx and tx path.
The physical link (i2c, ...) management is defined by the following struture:
struct nfc_phy_ops {
int (*write)(void *dev_id, struct sk_buff *skb);
int (*enable)(void *dev_id);
void (*disable)(void *dev_id);
};
enable(): turn the phy on (power on), make it ready to transfer data
disable(): turn the phy off
write(): Send a data frame to the chip. Note that to enable higher
layers such as an llc to store the frame for re-emission, this function must
not alter the skb. It must also not return a positive result (return 0 for
success, negative for failure).
Data coming from the chip shall be sent directly to nfc_hci_recv_frame().
LLC
---
Communication between the CPU and the chip often requires some link layer
protocol. Those are isolated as modules managed by the HCI layer. There are
currently two modules : nop (raw transfert) and shdlc.
A new llc must implement the following functions:
struct nfc_llc_ops {
void *(*init) (struct nfc_hci_dev *hdev, xmit_to_drv_t xmit_to_drv,
rcv_to_hci_t rcv_to_hci, int tx_headroom,
int tx_tailroom, int *rx_headroom, int *rx_tailroom,
llc_failure_t llc_failure);
void (*deinit) (struct nfc_llc *llc);
int (*start) (struct nfc_llc *llc);
int (*stop) (struct nfc_llc *llc);
void (*rcv_from_drv) (struct nfc_llc *llc, struct sk_buff *skb);
int (*xmit_from_hci) (struct nfc_llc *llc, struct sk_buff *skb);
};
- init() : allocate and init your private storage
- deinit() : cleanup
- start() : establish the logical connection
- stop () : terminate the logical connection
- rcv_from_drv() : handle data coming from the chip, going to HCI
- xmit_from_hci() : handle data sent by HCI, going to the chip
The llc must be registered with nfc before it can be used. Do that by
calling nfc_llc_register(const char *name, struct nfc_llc_ops *ops);
Again, note that the llc does not handle the physical link. It is thus very
easy to mix any physical link with any llc for a given chip driver.
Included Drivers
----------------
@ -117,10 +183,12 @@ Execution Contexts
The execution contexts are the following:
- IRQ handler (IRQH):
fast, cannot sleep. stores incoming frames into an shdlc rx queue
fast, cannot sleep. sends incoming frames to HCI where they are passed to
the current llc. In case of shdlc, the frame is queued in shdlc rx queue.
- SHDLC State Machine worker (SMW)
handles shdlc rx & tx queues. Dispatches HCI cmd responses.
Only when llc_shdlc is used: handles shdlc rx & tx queues.
Dispatches HCI cmd responses.
- HCI Tx Cmd worker (MSGTXWQ)
Serializes execution of HCI commands. Completes execution in case of response
@ -166,6 +234,15 @@ waiting command execution. Response processing involves invoking the completion
callback that was provided by nfc_hci_msg_tx_work() when it sent the command.
The completion callback will then wake the syscall context.
It is also possible to execute the command asynchronously using this API:
static int nfc_hci_execute_cmd_async(struct nfc_hci_dev *hdev, u8 pipe, u8 cmd,
const u8 *param, size_t param_len,
data_exchange_cb_t cb, void *cb_context)
The workflow is the same, except that the API call returns immediately, and
the callback will be called with the result from the SMW context.
Workflow receiving an HCI event or command
------------------------------------------

84
Documentation/nfc/nfc-pn544.txt
View File

@ -1,32 +1,15 @@
Kernel driver for the NXP Semiconductors PN544 Near Field
Communication chip
Author: Jari Vanhala
Contact: Matti Aaltonen (matti.j.aaltonen at nokia.com)
General
-------
The PN544 is an integrated transmission module for contactless
communication. The driver goes under drives/nfc/ and is compiled as a
module named "pn544". It registers a misc device and creates a device
file named "/dev/pn544".
module named "pn544".
Host Interfaces: I2C, SPI and HSU, this driver supports currently only I2C.
The Interface
-------------
The driver offers a sysfs interface for a hardware test and an IOCTL
interface for selecting between two operating modes. There are read,
write and poll functions for transferring messages. The two operating
modes are the normal (HCI) mode and the firmware update mode.
PN544 is controlled by sending messages from the userspace to the
chip. The main function of the driver is just to pass those messages
without caring about the message content.
Protocols
---------
@ -47,68 +30,3 @@ and third (LSB) bytes of the message. The maximum FW message length is
For the ETSI HCI specification see
http://www.etsi.org/WebSite/Technologies/ProtocolSpecification.aspx
The Hardware Test
-----------------
The idea of the test is that it can performed by reading from the
corresponding sysfs file. The test is implemented in the board file
and it should test that PN544 can be put into the firmware update
mode. If the test is not implemented the sysfs file does not get
created.
Example:
> cat /sys/module/pn544/drivers/i2c\:pn544/3-002b/nfc_test
1
Normal Operation
----------------
PN544 is powered up when the device file is opened, otherwise it's
turned off. Only one instance can use the device at a time.
Userspace applications control PN544 with HCI messages. The hardware
sends an interrupt when data is available for reading. Data is
physically read when the read function is called by a userspace
application. Poll() checks the read interrupt state. Configuration and
self testing are also done from the userspace using read and write.
Example platform data:
static int rx71_pn544_nfc_request_resources(struct i2c_client *client)
{
/* Get and setup the HW resources for the device */
}
static void rx71_pn544_nfc_free_resources(void)
{
/* Release the HW resources */
}
static void rx71_pn544_nfc_enable(int fw)
{
/* Turn the device on */
}
static int rx71_pn544_nfc_test(void)
{
/*
* Put the device into the FW update mode
* and then back to the normal mode.
* Check the behavior and return one on success,
* zero on failure.
*/
}
static void rx71_pn544_nfc_disable(void)
{
/* turn the power off */
}
static struct pn544_nfc_platform_data rx71_nfc_data = {
.request_resources = rx71_pn544_nfc_request_resources,
.free_resources = rx71_pn544_nfc_free_resources,
.enable = rx71_pn544_nfc_enable,
.test = rx71_pn544_nfc_test,
.disable = rx71_pn544_nfc_disable,
};

18
Documentation/pinctrl.txt
View File

@ -972,6 +972,18 @@ pinmux core.
Pin control requests from drivers
=================================
When a device driver is about to probe the device core will automatically
attempt to issue pinctrl_get_select_default() on these devices.
This way driver writers do not need to add any of the boilerplate code
of the type found below. However when doing fine-grained state selection
and not using the "default" state, you may have to do some device driver
handling of the pinctrl handles and states.
So if you just want to put the pins for a certain device into the default
state and be done with it, there is nothing you need to do besides
providing the proper mapping table. The device core will take care of
the rest.
Generally it is discouraged to let individual drivers get and enable pin
control. So if possible, handle the pin control in platform code or some other
place where you have access to all the affected struct device * pointers. In
@ -1097,9 +1109,9 @@ situations that can be electrically unpleasant, you will certainly want to
mux in and bias pins in a certain way before the GPIO subsystems starts to
deal with them.
The above can be hidden: using pinctrl hogs, the pin control driver may be
setting up the config and muxing for the pins when it is probing,
nevertheless orthogonal to the GPIO subsystem.
The above can be hidden: using the device core, the pinctrl core may be
setting up the config and muxing for the pins right before the device is
probing, nevertheless orthogonal to the GPIO subsystem.
But there are also situations where it makes sense for the GPIO subsystem
to communicate directly with with the pinctrl subsystem, using the latter

5
Documentation/power/freezing-of-tasks.txt
View File

@ -223,3 +223,8 @@ since they ask the freezer to skip freezing this task, since it is anyway
only after the entire suspend/hibernation sequence is complete.
So, to summarize, use [un]lock_system_sleep() instead of directly using
mutex_[un]lock(&pm_mutex). That would prevent freezing failures.
V. Miscellaneous
/sys/power/pm_freeze_timeout controls how long it will cost at most to freeze
all user space processes or all freezable kernel threads, in unit of millisecond.
The default value is 20000, with range of unsigned integer.

4
Documentation/power/runtime_pm.txt
View File

@ -426,6 +426,10 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
'power.runtime_error' is set or 'power.disable_depth' is greater than
zero)
bool pm_runtime_active(struct device *dev);
- return true if the device's runtime PM status is 'active' or its
'power.disable_depth' field is not equal to zero, or false otherwise
bool pm_runtime_suspended(struct device *dev);
- return true if the device's runtime PM status is 'suspended' and its
'power.disable_depth' field is equal to zero, or false otherwise

27
Documentation/trace/events-power.txt
View File

@ -17,7 +17,7 @@ Cf. include/trace/events/power.h for the events definitions.
1. Power state switch events
============================
1.1 New trace API
1.1 Trace API
-----------------
A 'cpu' event class gathers the CPU-related events: cpuidle and
@ -41,31 +41,6 @@ The event which has 'state=4294967295' in the trace is very important to the use
space tools which are using it to detect the end of the current state, and so to
correctly draw the states diagrams and to calculate accurate statistics etc.
1.2 DEPRECATED trace API
------------------------
A new Kconfig option CONFIG_EVENT_POWER_TRACING_DEPRECATED with the default value of
'y' has been created. This allows the legacy trace power API to be used conjointly
with the new trace API.
The Kconfig option, the old trace API (in include/trace/events/power.h) and the
old trace points will disappear in a future release (namely 2.6.41).
power_start "type=%lu state=%lu cpu_id=%lu"
power_frequency "type=%lu state=%lu cpu_id=%lu"
power_end "cpu_id=%lu"
The 'type' parameter takes one of those macros:
. POWER_NONE = 0,
. POWER_CSTATE = 1, /* C-State */
. POWER_PSTATE = 2, /* Frequency change or DVFS */
The 'state' parameter is set depending on the type:
. Target C-state for type=POWER_CSTATE,
. Target frequency for type=POWER_PSTATE,
power_end is used to indicate the exit of a state, corresponding to the latest
power_start event.
2. Clocks events
================
The clock events are used for clock enable/disable and for

83
Documentation/trace/ftrace.txt
View File

@ -1842,6 +1842,89 @@ an error.
# cat buffer_size_kb
85
Snapshot
--------
CONFIG_TRACER_SNAPSHOT makes a generic snapshot feature
available to all non latency tracers. (Latency tracers which
record max latency, such as "irqsoff" or "wakeup", can't use
this feature, since those are already using the snapshot
mechanism internally.)
Snapshot preserves a current trace buffer at a particular point
in time without stopping tracing. Ftrace swaps the current
buffer with a spare buffer, and tracing continues in the new
current (=previous spare) buffer.
The following debugfs files in "tracing" are related to this
feature:
snapshot:
This is used to take a snapshot and to read the output
of the snapshot. Echo 1 into this file to allocate a
spare buffer and to take a snapshot (swap), then read
the snapshot from this file in the same format as
"trace" (described above in the section "The File
System"). Both reads snapshot and tracing are executable
in parallel. When the spare buffer is allocated, echoing
0 frees it, and echoing else (positive) values clear the
snapshot contents.
More details are shown in the table below.
status\input | 0 | 1 | else |
--------------+------------+------------+------------+
not allocated |(do nothing)| alloc+swap | EINVAL |
--------------+------------+------------+------------+
allocated | free | swap | clear |
--------------+------------+------------+------------+
Here is an example of using the snapshot feature.
# echo 1 > events/sched/enable
# echo 1 > snapshot
# cat snapshot
# tracer: nop
#
# entries-in-buffer/entries-written: 71/71 #P:8
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
<idle>-0 [005] d... 2440.603828: sched_switch: prev_comm=swapper/5 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=snapshot-test-2 next_pid=2242 next_prio=120
sleep-2242 [005] d... 2440.603846: sched_switch: prev_comm=snapshot-test-2 prev_pid=2242 prev_prio=120 prev_state=R ==> next_comm=kworker/5:1 next_pid=60 next_prio=120
[...]
<idle>-0 [002] d... 2440.707230: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=snapshot-test-2 next_pid=2229 next_prio=120
# cat trace
# tracer: nop
#
# entries-in-buffer/entries-written: 77/77 #P:8
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
<idle>-0 [007] d... 2440.707395: sched_switch: prev_comm=swapper/7 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=snapshot-test-2 next_pid=2243 next_prio=120
snapshot-test-2-2229 [002] d... 2440.707438: sched_switch: prev_comm=snapshot-test-2 prev_pid=2229 prev_prio=120 prev_state=S ==> next_comm=swapper/2 next_pid=0 next_prio=120
[...]
If you try to use this snapshot feature when current tracer is
one of the latency tracers, you will get the following results.
# echo wakeup > current_tracer
# echo 1 > snapshot
bash: echo: write error: Device or resource busy
# cat snapshot
cat: snapshot: Device or resource busy
-----------
More details can be found in the source code, in the

99
Documentation/virtual/kvm/api.txt
View File

@ -293,7 +293,7 @@ kvm_run' (see below).
4.11 KVM_GET_REGS
Capability: basic
Architectures: all
Architectures: all except ARM
Type: vcpu ioctl
Parameters: struct kvm_regs (out)
Returns: 0 on success, -1 on error
@ -314,7 +314,7 @@ struct kvm_regs {
4.12 KVM_SET_REGS
Capability: basic
Architectures: all
Architectures: all except ARM
Type: vcpu ioctl
Parameters: struct kvm_regs (in)
Returns: 0 on success, -1 on error
@ -600,7 +600,7 @@ struct kvm_fpu {
4.24 KVM_CREATE_IRQCHIP
Capability: KVM_CAP_IRQCHIP
Architectures: x86, ia64
Architectures: x86, ia64, ARM
Type: vm ioctl
Parameters: none
Returns: 0 on success, -1 on error
@ -608,21 +608,39 @@ Returns: 0 on success, -1 on error
Creates an interrupt controller model in the kernel. On x86, creates a virtual
ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a
local APIC. IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23
only go to the IOAPIC. On ia64, a IOSAPIC is created.
only go to the IOAPIC. On ia64, a IOSAPIC is created. On ARM, a GIC is
created.
4.25 KVM_IRQ_LINE
Capability: KVM_CAP_IRQCHIP
Architectures: x86, ia64
Architectures: x86, ia64, arm
Type: vm ioctl
Parameters: struct kvm_irq_level
Returns: 0 on success, -1 on error
Sets the level of a GSI input to the interrupt controller model in the kernel.
Requires that an interrupt controller model has been previously created with
KVM_CREATE_IRQCHIP. Note that edge-triggered interrupts require the level
to be set to 1 and then back to 0.
On some architectures it is required that an interrupt controller model has
been previously created with KVM_CREATE_IRQCHIP. Note that edge-triggered
interrupts require the level to be set to 1 and then back to 0.
ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip
(GIC), and for in-kernel irqchip can tell the GIC to use PPIs designated for
specific cpus. The irq field is interpreted like this:
 bits: | 31 ... 24 | 23 ... 16 | 15 ... 0 |
field: | irq_type | vcpu_index | irq_id |
The irq_type field has the following values:
- irq_type[0]: out-of-kernel GIC: irq_id 0 is IRQ, irq_id 1 is FIQ
- irq_type[1]: in-kernel GIC: SPI, irq_id between 32 and 1019 (incl.)
(the vcpu_index field is ignored)
- irq_type[2]: in-kernel GIC: PPI, irq_id between 16 and 31 (incl.)
(The irq_id field thus corresponds nicely to the IRQ ID in the ARM GIC specs)
In both cases, level is used to raise/lower the line.
struct kvm_irq_level {
union {
@ -1775,6 +1793,27 @@ registers, find a list below:
PPC | KVM_REG_PPC_VPA_DTL | 128
PPC | KVM_REG_PPC_EPCR | 32
ARM registers are mapped using the lower 32 bits. The upper 16 of that
is the register group type, or coprocessor number:
ARM core registers have the following id bit patterns:
0x4002 0000 0010 <index into the kvm_regs struct:16>
ARM 32-bit CP15 registers have the following id bit patterns:
0x4002 0000 000F <zero:1> <crn:4> <crm:4> <opc1:4> <opc2:3>
ARM 64-bit CP15 registers have the following id bit patterns:
0x4003 0000 000F <zero:1> <zero:4> <crm:4> <opc1:4> <zero:3>
ARM CCSIDR registers are demultiplexed by CSSELR value:
0x4002 0000 0011 00 <csselr:8>
ARM 32-bit VFP control registers have the following id bit patterns:
0x4002 0000 0012 1 <regno:12>
ARM 64-bit FP registers have the following id bit patterns:
0x4002 0000 0012 0 <regno:12>
4.69 KVM_GET_ONE_REG
Capability: KVM_CAP_ONE_REG
@ -2127,6 +2166,50 @@ written, then `n_invalid' invalid entries, invalidating any previously
valid entries found.
4.77 KVM_ARM_VCPU_INIT
Capability: basic
Architectures: arm
Type: vcpu ioctl
Parameters: struct struct kvm_vcpu_init (in)
Returns: 0 on success; -1 on error
Errors:
 EINVAL:    the target is unknown, or the combination of features is invalid.
 ENOENT:    a features bit specified is unknown.
This tells KVM what type of CPU to present to the guest, and what
optional features it should have.  This will cause a reset of the cpu
registers to their initial values.  If this is not called, KVM_RUN will
return ENOEXEC for that vcpu.
Note that because some registers reflect machine topology, all vcpus
should be created before this ioctl is invoked.
Possible features:
- KVM_ARM_VCPU_POWER_OFF: Starts the CPU in a power-off state.
Depends on KVM_CAP_ARM_PSCI.
4.78 KVM_GET_REG_LIST
Capability: basic
Architectures: arm
Type: vcpu ioctl
Parameters: struct kvm_reg_list (in/out)
Returns: 0 on success; -1 on error
Errors:
 E2BIG:     the reg index list is too big to fit in the array specified by
            the user (the number required will be written into n).
struct kvm_reg_list {
__u64 n; /* number of registers in reg[] */
__u64 reg[0];
};
This ioctl returns the guest registers that are supported for the
KVM_GET_ONE_REG/KVM_SET_ONE_REG calls.
5. The kvm_run structure
------------------------

1
Documentation/x86/boot.txt
View File

@ -390,6 +390,7 @@ Protocol: 2.00+
F Special (0xFF = undefined)
10 Reserved
11 Minimal Linux Bootloader <http://sebastian-plotz.blogspot.de>
12 OVMF UEFI virtualization stack
Please contact <hpa@zytor.com> if you need a bootloader ID
value assigned.

2
Documentation/zh_CN/magic-number.txt
View File

@ -122,7 +122,7 @@ SLAB_C_MAGIC 0x4f17a36d kmem_cache mm/slab.c
COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c
I810_CARD_MAGIC 0x5072696E i810_card sound/oss/i810_audio.c
TRIDENT_CARD_MAGIC 0x5072696E trident_card sound/oss/trident.c
ROUTER_MAGIC 0x524d4157 wan_device include/linux/wanrouter.h
ROUTER_MAGIC 0x524d4157 wan_device [in wanrouter.h pre 3.9]
SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h
SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c
GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h

77
MAINTAINERS
View File

@ -670,8 +670,16 @@ F: drivers/input/serio/ambakmi.*
F: include/linux/amba/kmi.h
ARM PRIMECELL MMCI PL180/1 DRIVER
S: Orphan
M: Russell King <linux@arm.linux.org.uk>
S: Maintained
F: drivers/mmc/host/mmci.*
F: include/linux/amba/mmci.h
ARM PRIMECELL UART PL010 AND PL011 DRIVERS
M: Russell King <linux@arm.linux.org.uk>
S: Maintained
F: drivers/tty/serial/amba-pl01*.c
F: include/linux/amba/serial.h
ARM PRIMECELL BUS SUPPORT
M: Russell King <linux@arm.linux.org.uk>
@ -1303,7 +1311,7 @@ F: include/linux/dmaengine.h
F: include/linux/async_tx.h
AT24 EEPROM DRIVER
M: Wolfram Sang <w.sang@pengutronix.de>
M: Wolfram Sang <wsa@the-dreams.de>
L: linux-i2c@vger.kernel.org
S: Maintained
F: drivers/misc/eeprom/at24.c
@ -2140,10 +2148,10 @@ S: Maintained
F: tools/power/cpupower
CPUSETS
M: Paul Menage <paul@paulmenage.org>
M: Li Zefan <lizefan@huawei.com>
W: http://www.bullopensource.org/cpuset/
W: http://oss.sgi.com/projects/cpusets/
S: Supported
S: Maintained
F: Documentation/cgroups/cpusets.txt
F: include/linux/cpuset.h
F: kernel/cpuset.c
@ -2974,11 +2982,6 @@ S: Maintained
F: include/linux/netfilter_bridge/
F: net/bridge/
ETHERTEAM 16I DRIVER
M: Mika Kuoppala <miku@iki.fi>
S: Maintained
F: drivers/net/ethernet/fujitsu/eth16i.c
EXT2 FILE SYSTEM
M: Jan Kara <jack@suse.cz>
L: linux-ext4@vger.kernel.org
@ -3757,12 +3760,11 @@ S: Maintained
F: drivers/i2c/i2c-stub.c
I2C SUBSYSTEM
M: Wolfram Sang <w.sang@pengutronix.de>
M: Wolfram Sang <wsa@the-dreams.de>
M: "Ben Dooks (embedded platforms)" <ben-linux@fluff.org>
L: linux-i2c@vger.kernel.org
W: http://i2c.wiki.kernel.org/
T: quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/
T: git git://git.pengutronix.de/git/wsa/linux.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
S: Maintained
F: Documentation/i2c/
F: drivers/i2c/
@ -4481,6 +4483,15 @@ F: arch/s390/include/asm/kvm*
F: arch/s390/kvm/
F: drivers/s390/kvm/
KERNEL VIRTUAL MACHINE (KVM) FOR ARM
M: Christoffer Dall <cdall@cs.columbia.edu>
L: kvmarm@lists.cs.columbia.edu
W: http://systems.cs.columbia.edu/projects/kvm-arm
S: Maintained
F: arch/arm/include/uapi/asm/kvm*
F: arch/arm/include/asm/kvm*
F: arch/arm/kvm/
KEXEC
M: Eric Biederman <ebiederm@xmission.com>
W: http://kernel.org/pub/linux/utils/kernel/kexec/
@ -5369,13 +5380,6 @@ F: include/linux/sunrpc/
F: include/uapi/linux/nfs*
F: include/uapi/linux/sunrpc/
NI5010 NETWORK DRIVER
M: Jan-Pascal van Best <janpascal@vanbest.org>
M: Andreas Mohr <andi@lisas.de>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/ethernet/racal/ni5010.*
NILFS2 FILESYSTEM
M: KONISHI Ryusuke <konishi.ryusuke@lab.ntt.co.jp>
L: linux-nilfs@vger.kernel.org
@ -5778,15 +5782,6 @@ L: linux-i2c@vger.kernel.org
S: Maintained
F: drivers/i2c/muxes/i2c-mux-pca9541.c
PCA9564/PCA9665 I2C BUS DRIVER
M: Wolfram Sang <w.sang@pengutronix.de>
L: linux-i2c@vger.kernel.org
S: Maintained
F: drivers/i2c/algos/i2c-algo-pca.c
F: drivers/i2c/busses/i2c-pca-*
F: include/linux/i2c-algo-pca.h
F: include/linux/i2c-pca-platform.h
PCDP - PRIMARY CONSOLE AND DEBUG PORT
M: Khalid Aziz <khalid@gonehiking.org>
S: Maintained
@ -6598,7 +6593,7 @@ F: drivers/dma/dw_dmac_regs.h
F: drivers/dma/dw_dmac.c
TIMEKEEPING, NTP
M: John Stultz <johnstul@us.ibm.com>
M: John Stultz <john.stultz@linaro.org>
M: Thomas Gleixner <tglx@linutronix.de>
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
S: Supported
@ -7178,6 +7173,7 @@ F: drivers/clk/spear/
SPI SUBSYSTEM
M: Grant Likely <grant.likely@secretlab.ca>
M: Mark Brown <broonie@opensource.wolfsonmicro.com>
L: spi-devel-general@lists.sourceforge.net
Q: http://patchwork.kernel.org/project/spi-devel-general/list/
T: git git://git.secretlab.ca/git/linux-2.6.git
@ -7536,13 +7532,18 @@ S: Maintained
F: drivers/media/tuners/tea5767.*
TEAM DRIVER
M: Jiri Pirko <jpirko@redhat.com>
M: Jiri Pirko <jiri@resnulli.us>
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/team/
F: include/linux/if_team.h
F: include/uapi/linux/if_team.h
TECHNOLOGIC SYSTEMS TS-5500 PLATFORM SUPPORT
M: Savoir-faire Linux Inc. <kernel@savoirfairelinux.com>
S: Maintained
F: arch/x86/platform/ts5500/
TECHNOTREND USB IR RECEIVER
M: Sean Young <sean@mess.org>
L: linux-media@vger.kernel.org
@ -7617,6 +7618,22 @@ F: Documentation/backlight/lp855x-driver.txt
F: drivers/video/backlight/lp855x_bl.c
F: include/linux/platform_data/lp855x.h
TI LP8727 CHARGER DRIVER
M: Milo Kim <milo.kim@ti.com>
S: Maintained
F: drivers/power/lp8727_charger.c
F: include/linux/platform_data/lp8727.h
TI LP8788 MFD DRIVER
M: Milo Kim <milo.kim@ti.com>
S: Maintained
F: drivers/iio/adc/lp8788_adc.c
F: drivers/leds/leds-lp8788.c
F: drivers/mfd/lp8788*.c
F: drivers/power/lp8788-charger.c
F: drivers/regulator/lp8788-*.c
F: include/linux/mfd/lp8788*.h
TI TWL4030 SERIES SOC CODEC DRIVER
M: Peter Ujfalusi <peter.ujfalusi@ti.com>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)

5
Makefile
View File

@ -1,7 +1,7 @@
VERSION = 3
PATCHLEVEL = 8
SUBLEVEL = 0
EXTRAVERSION = -rc7
EXTRAVERSION =
NAME = Unicycling Gorilla
# *DOCUMENTATION*
@ -165,7 +165,8 @@ export srctree objtree VPATH
# then ARCH is assigned, getting whatever value it gets normally, and
# SUBARCH is subsequently ignored.
SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
-e s/sun4u/sparc64/ \
-e s/arm.*/arm/ -e s/sa110/arm/ \
-e s/s390x/s390/ -e s/parisc64/parisc/ \
-e s/ppc.*/powerpc/ -e s/mips.*/mips/ \

12
arch/Kconfig
View File

@ -76,6 +76,15 @@ config OPTPROBES
depends on KPROBES && HAVE_OPTPROBES
depends on !PREEMPT
config KPROBES_ON_FTRACE
def_bool y
depends on KPROBES && HAVE_KPROBES_ON_FTRACE
depends on DYNAMIC_FTRACE_WITH_REGS
help
If function tracer is enabled and the arch supports full
passing of pt_regs to function tracing, then kprobes can
optimize on top of function tracing.
config UPROBES
bool "Transparent user-space probes (EXPERIMENTAL)"
depends on UPROBE_EVENT && PERF_EVENTS
@ -158,6 +167,9 @@ config HAVE_KRETPROBES
config HAVE_OPTPROBES
bool
config HAVE_KPROBES_ON_FTRACE
bool
config HAVE_NMI_WATCHDOG
bool
#

1
arch/alpha/Kconfig
View File

@ -5,7 +5,6 @@ config ALPHA
select HAVE_IDE
select HAVE_OPROFILE
select HAVE_SYSCALL_WRAPPERS
select HAVE_IRQ_WORK
select HAVE_PCSPKR_PLATFORM
select HAVE_PERF_EVENTS
select HAVE_DMA_ATTRS

3
arch/alpha/include/uapi/asm/socket.h
View File

@ -19,7 +19,7 @@
#define SO_BROADCAST 0x0020
#define SO_LINGER 0x0080
#define SO_OOBINLINE 0x0100
/* To add :#define SO_REUSEPORT 0x0200 */
#define SO_REUSEPORT 0x0200
#define SO_TYPE 0x1008
#define SO_ERROR 0x1007
@ -77,5 +77,6 @@
/* Instruct lower device to use last 4-bytes of skb data as FCS */
#define SO_NOFCS 43
#define SO_LOCK_FILTER 44
#endif /* _UAPI_ASM_SOCKET_H */

6
arch/alpha/kernel/osf_sys.c
View File

@ -1139,6 +1139,7 @@ struct rusage32 {
SYSCALL_DEFINE2(osf_getrusage, int, who, struct rusage32 __user *, ru)
{
struct rusage32 r;
cputime_t utime, stime;
if (who != RUSAGE_SELF && who != RUSAGE_CHILDREN)
return -EINVAL;
@ -1146,8 +1147,9 @@ SYSCALL_DEFINE2(osf_getrusage, int, who, struct rusage32 __user *, ru)
memset(&r, 0, sizeof(r));
switch (who) {
case RUSAGE_SELF:
jiffies_to_timeval32(current->utime, &r.ru_utime);
jiffies_to_timeval32(current->stime, &r.ru_stime);
task_cputime(current, &utime, &stime);
jiffies_to_timeval32(utime, &r.ru_utime);
jiffies_to_timeval32(stime, &r.ru_stime);
r.ru_minflt = current->min_flt;
r.ru_majflt = current->maj_flt;
break;

18
arch/arm/Kconfig
View File

@ -36,7 +36,6 @@ config ARM
select HAVE_GENERIC_HARDIRQS
select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7))
select HAVE_IDE if PCI || ISA || PCMCIA
select HAVE_IRQ_WORK
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZMA
select HAVE_KERNEL_LZO
@ -1620,6 +1619,16 @@ config HOTPLUG_CPU
Say Y here to experiment with turning CPUs off and on. CPUs
can be controlled through /sys/devices/system/cpu.
config ARM_PSCI
bool "Support for the ARM Power State Coordination Interface (PSCI)"
depends on CPU_V7
help
Say Y here if you want Linux to communicate with system firmware
implementing the PSCI specification for CPU-centric power
management operations described in ARM document number ARM DEN
0022A ("Power State Coordination Interface System Software on
ARM processors").
config LOCAL_TIMERS
bool "Use local timer interrupts"
depends on SMP
@ -1637,7 +1646,7 @@ config ARCH_NR_GPIO
default 355 if ARCH_U8500
default 264 if MACH_H4700
default 512 if SOC_OMAP5
default 288 if ARCH_VT8500
default 288 if ARCH_VT8500 || ARCH_SUNXI
default 0
help
Maximum number of GPIOs in the system.
@ -1655,6 +1664,9 @@ config HZ
default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE
default 100
config SCHED_HRTICK
def_bool HIGH_RES_TIMERS
config THUMB2_KERNEL
bool "Compile the kernel in Thumb-2 mode"
depends on CPU_V7 && !CPU_V6 && !CPU_V6K
@ -2322,3 +2334,5 @@ source "security/Kconfig"
source "crypto/Kconfig"
source "lib/Kconfig"
source "arch/arm/kvm/Kconfig"

1
arch/arm/Makefile
View File

@ -252,6 +252,7 @@ core-$(CONFIG_FPE_NWFPE) += arch/arm/nwfpe/
core-$(CONFIG_FPE_FASTFPE) += $(FASTFPE_OBJ)
core-$(CONFIG_VFP) += arch/arm/vfp/
core-$(CONFIG_XEN) += arch/arm/xen/
core-$(CONFIG_KVM_ARM_HOST) += arch/arm/kvm/
# If we have a machine-specific directory, then include it in the build.
core-y += arch/arm/kernel/ arch/arm/mm/ arch/arm/common/

10
arch/arm/boot/dts/dbx5x0.dtsi
View File

@ -170,10 +170,9 @@ gpio8: gpio@a03fe000 {
gpio-bank = <8>;
};
pinctrl@80157000 {
// This is actually the PRCMU base address
reg = <0x80157000 0x2000>;
compatible = "stericsson,nmk_pinctrl";
pinctrl {
compatible = "stericsson,nmk-pinctrl";
prcm = <&prcmu>;
};
usb@a03e0000 {
@ -190,9 +189,10 @@ dma-controller@801C0000 {
interrupts = <0 25 0x4>;
};
prcmu@80157000 {
prcmu: prcmu@80157000 {
compatible = "stericsson,db8500-prcmu";
reg = <0x80157000 0x1000>;
reg-names = "prcmu";
interrupts = <0 47 0x4>;
#address-cells = <1>;
#size-cells = <1>;

Some files were not shown because too many files have changed in this diff Show More