You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'for-4.4/core' into for-4.4/drivers
Signed-off-by: Jens Axboe <axboe@fb.com>
This commit is contained in:
Jens Axboe
@@ -43,7 +43,7 @@ o udev 081 # udevd --version
|
||||
o grub 0.93 # grub --version || grub-install --version
|
||||
o mcelog 0.6 # mcelog --version
|
||||
o iptables 1.4.2 # iptables -V
|
||||
o openssl & libcrypto 1.0.1k # openssl version
|
||||
o openssl & libcrypto 1.0.0 # openssl version
|
||||
|
||||
|
||||
Kernel compilation
|
||||
|
||||
@@ -57,6 +57,8 @@ used to route Message Signalled Interrupts (MSI) to the CPUs.
|
||||
These nodes must have the following properties:
|
||||
- compatible : Should at least contain "arm,gic-v3-its".
|
||||
- msi-controller : Boolean property. Identifies the node as an MSI controller
|
||||
- #msi-cells: Must be <1>. The single msi-cell is the DeviceID of the device
|
||||
which will generate the MSI.
|
||||
- reg: Specifies the base physical address and size of the ITS
|
||||
registers.
|
||||
|
||||
@@ -83,6 +85,7 @@ Examples:
|
||||
gic-its@2c200000 {
|
||||
compatible = "arm,gic-v3-its";
|
||||
msi-controller;
|
||||
#msi-cells = <1>;
|
||||
reg = <0x0 0x2c200000 0 0x200000>;
|
||||
};
|
||||
};
|
||||
@@ -107,12 +110,14 @@ Examples:
|
||||
gic-its@2c200000 {
|
||||
compatible = "arm,gic-v3-its";
|
||||
msi-controller;
|
||||
#msi-cells = <1>;
|
||||
reg = <0x0 0x2c200000 0 0x200000>;
|
||||
};
|
||||
|
||||
gic-its@2c400000 {
|
||||
compatible = "arm,gic-v3-its";
|
||||
msi-controller;
|
||||
#msi-cells = <1>;
|
||||
reg = <0x0 0x2c400000 0 0x200000>;
|
||||
};
|
||||
};
|
||||
|
||||
@@ -497,7 +497,7 @@ cpus {
|
||||
};
|
||||
|
||||
idle-states {
|
||||
entry-method = "arm,psci";
|
||||
entry-method = "psci";
|
||||
|
||||
CPU_RETENTION_0_0: cpu-retention-0-0 {
|
||||
compatible = "arm,idle-state";
|
||||
|
||||
@@ -16,7 +16,9 @@ properties, each containing a 'gpio-list':
|
||||
GPIO properties should be named "[<name>-]gpios", with <name> being the purpose
|
||||
of this GPIO for the device. While a non-existent <name> is considered valid
|
||||
for compatibility reasons (resolving to the "gpios" property), it is not allowed
|
||||
for new bindings.
|
||||
for new bindings. Also, GPIO properties named "[<name>-]gpio" are valid and old
|
||||
bindings use it, but are only supported for compatibility reasons and should not
|
||||
be used for newer bindings since it has been deprecated.
|
||||
|
||||
GPIO properties can contain one or more GPIO phandles, but only in exceptional
|
||||
cases should they contain more than one. If your device uses several GPIOs with
|
||||
|
||||
@@ -1,10 +1,11 @@
|
||||
* Bosch BMA180 triaxial acceleration sensor
|
||||
* Bosch BMA180 / BMA250 triaxial acceleration sensor
|
||||
|
||||
http://omapworld.com/BMA180_111_1002839.pdf
|
||||
http://ae-bst.resource.bosch.com/media/products/dokumente/bma250/bst-bma250-ds002-05.pdf
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "bosch,bma180"
|
||||
- compatible : should be "bosch,bma180" or "bosch,bma250"
|
||||
- reg : the I2C address of the sensor
|
||||
|
||||
Optional properties:
|
||||
@@ -13,6 +14,9 @@ Optional properties:
|
||||
|
||||
- interrupts : interrupt mapping for GPIO IRQ, it should by configured with
|
||||
flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
|
||||
For the bma250 the first interrupt listed must be the one
|
||||
connected to the INT1 pin, the second (optional) interrupt
|
||||
listed must be the one connected to the INT2 pin.
|
||||
|
||||
Example:
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ Example:
|
||||
/* Cypress Gen3 touchpad */
|
||||
touchpad@67 {
|
||||
compatible = "cypress,cyapa";
|
||||
reg = <0x24>;
|
||||
reg = <0x67>;
|
||||
interrupt-parent = <&gpio>;
|
||||
interrupts = <2 IRQ_TYPE_EDGE_FALLING>; /* GPIO 2 */
|
||||
wakeup-source;
|
||||
|
||||
@@ -4,8 +4,8 @@ The MISC interrupt controller is a secondary controller for lower priority
|
||||
interrupt.
|
||||
|
||||
Required Properties:
|
||||
- compatible: has to be "qca,<soctype>-cpu-intc", "qca,ar7100-misc-intc"
|
||||
as fallback
|
||||
- compatible: has to be "qca,<soctype>-cpu-intc", "qca,ar7100-misc-intc" or
|
||||
"qca,<soctype>-cpu-intc", "qca,ar7240-misc-intc"
|
||||
- reg: Base address and size of the controllers memory area
|
||||
- interrupt-parent: phandle of the parent interrupt controller.
|
||||
- interrupts: Interrupt specifier for the controllers interrupt.
|
||||
@@ -13,6 +13,9 @@ Required Properties:
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode interrupt
|
||||
source, should be 1
|
||||
|
||||
Compatible fallback depends on the SoC. Use ar7100 for ar71xx and ar913x,
|
||||
use ar7240 for all other SoCs.
|
||||
|
||||
Please refer to interrupts.txt in this directory for details of the common
|
||||
Interrupt Controllers bindings used by client devices.
|
||||
|
||||
@@ -28,3 +31,16 @@ Example:
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
};
|
||||
|
||||
Another example:
|
||||
|
||||
interrupt-controller@18060010 {
|
||||
compatible = "qca,ar9331-misc-intc", qca,ar7240-misc-intc";
|
||||
reg = <0x18060010 0x4>;
|
||||
|
||||
interrupt-parent = <&cpuintc>;
|
||||
interrupts = <6>;
|
||||
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
};
|
||||
|
||||
@@ -7,7 +7,8 @@ OHCI and EHCI controllers.
|
||||
|
||||
Required properties:
|
||||
- compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
|
||||
"renesas,pci-r8a7791" for the R8A7791 SoC.
|
||||
"renesas,pci-r8a7791" for the R8A7791 SoC;
|
||||
"renesas,pci-r8a7794" for the R8A7794 SoC.
|
||||
- reg: A list of physical regions to access the device: the first is
|
||||
the operational registers for the OHCI/EHCI controllers and the
|
||||
second is for the bridge configuration and control registers.
|
||||
|
||||
@@ -2,7 +2,12 @@ PBIAS internal regulator for SD card dual voltage i/o pads on OMAP SoCs.
|
||||
|
||||
Required properties:
|
||||
- compatible:
|
||||
- "ti,pbias-omap" for OMAP2, OMAP3, OMAP4, OMAP5, DRA7.
|
||||
- should be "ti,pbias-dra7" for DRA7
|
||||
- should be "ti,pbias-omap2" for OMAP2
|
||||
- should be "ti,pbias-omap3" for OMAP3
|
||||
- should be "ti,pbias-omap4" for OMAP4
|
||||
- should be "ti,pbias-omap5" for OMAP5
|
||||
- "ti,pbias-omap" is deprecated
|
||||
- reg: pbias register offset from syscon base and size of pbias register.
|
||||
- syscon : phandle of the system control module
|
||||
- regulator-name : should be
|
||||
|
||||
@@ -15,17 +15,18 @@ Required properties:
|
||||
- interrupts: Should contain spi interrupt
|
||||
|
||||
- clocks: phandles to input clocks.
|
||||
The first should be <&topckgen CLK_TOP_SPI_SEL>.
|
||||
The second should be one of the following.
|
||||
The first should be one of the following. It's PLL.
|
||||
- <&clk26m>: specify parent clock 26MHZ.
|
||||
- <&topckgen CLK_TOP_SYSPLL3_D2>: specify parent clock 109MHZ.
|
||||
It's the default one.
|
||||
- <&topckgen CLK_TOP_SYSPLL4_D2>: specify parent clock 78MHZ.
|
||||
- <&topckgen CLK_TOP_UNIVPLL2_D4>: specify parent clock 104MHZ.
|
||||
- <&topckgen CLK_TOP_UNIVPLL1_D8>: specify parent clock 78MHZ.
|
||||
The second should be <&topckgen CLK_TOP_SPI_SEL>. It's clock mux.
|
||||
The third is <&pericfg CLK_PERI_SPI0>. It's clock gate.
|
||||
|
||||
- clock-names: shall be "spi-clk" for the controller clock, and
|
||||
"parent-clk" for the parent clock.
|
||||
- clock-names: shall be "parent-clk" for the parent clock, "sel-clk" for the
|
||||
muxes clock, and "spi-clk" for the clock gate.
|
||||
|
||||
Optional properties:
|
||||
- mediatek,pad-select: specify which pins group(ck/mi/mo/cs) spi
|
||||
@@ -44,8 +45,11 @@ spi: spi@1100a000 {
|
||||
#size-cells = <0>;
|
||||
reg = <0 0x1100a000 0 0x1000>;
|
||||
interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_LOW>;
|
||||
clocks = <&topckgen CLK_TOP_SPI_SEL>, <&topckgen CLK_TOP_SYSPLL3_D2>;
|
||||
clock-names = "spi-clk", "parent-clk";
|
||||
clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
|
||||
<&topckgen CLK_TOP_SPI_SEL>,
|
||||
<&pericfg CLK_PERI_SPI0>;
|
||||
clock-names = "parent-clk", "sel-clk", "spi-clk";
|
||||
|
||||
mediatek,pad-select = <0>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
@@ -55,19 +55,11 @@ of heat dissipation). For example a fan's cooling states correspond to
|
||||
the different fan speeds possible. Cooling states are referred to by
|
||||
single unsigned integers, where larger numbers mean greater heat
|
||||
dissipation. The precise set of cooling states associated with a device
|
||||
(as referred to be the cooling-min-state and cooling-max-state
|
||||
(as referred to by the cooling-min-level and cooling-max-level
|
||||
properties) should be defined in a particular device's binding.
|
||||
For more examples of cooling devices, refer to the example sections below.
|
||||
|
||||
Required properties:
|
||||
- cooling-min-state: An integer indicating the smallest
|
||||
Type: unsigned cooling state accepted. Typically 0.
|
||||
Size: one cell
|
||||
|
||||
- cooling-max-state: An integer indicating the largest
|
||||
Type: unsigned cooling state accepted.
|
||||
Size: one cell
|
||||
|
||||
- #cooling-cells: Used to provide cooling device specific information
|
||||
Type: unsigned while referring to it. Must be at least 2, in order
|
||||
Size: one cell to specify minimum and maximum cooling state used
|
||||
@@ -77,6 +69,15 @@ Required properties:
|
||||
See Cooling device maps section below for more details
|
||||
on how consumers refer to cooling devices.
|
||||
|
||||
Optional properties:
|
||||
- cooling-min-level: An integer indicating the smallest
|
||||
Type: unsigned cooling state accepted. Typically 0.
|
||||
Size: one cell
|
||||
|
||||
- cooling-max-level: An integer indicating the largest
|
||||
Type: unsigned cooling state accepted.
|
||||
Size: one cell
|
||||
|
||||
* Trip points
|
||||
|
||||
The trip node is a node to describe a point in the temperature domain
|
||||
@@ -225,8 +226,8 @@ cpus {
|
||||
396000 950000
|
||||
198000 850000
|
||||
>;
|
||||
cooling-min-state = <0>;
|
||||
cooling-max-state = <3>;
|
||||
cooling-min-level = <0>;
|
||||
cooling-max-level = <3>;
|
||||
#cooling-cells = <2>; /* min followed by max */
|
||||
};
|
||||
...
|
||||
@@ -240,8 +241,8 @@ cpus {
|
||||
*/
|
||||
fan0: fan@0x48 {
|
||||
...
|
||||
cooling-min-state = <0>;
|
||||
cooling-max-state = <9>;
|
||||
cooling-min-level = <0>;
|
||||
cooling-max-level = <9>;
|
||||
#cooling-cells = <2>; /* min followed by max */
|
||||
};
|
||||
};
|
||||
|
||||
@@ -6,6 +6,7 @@ Required properties:
|
||||
"lsi,zevio-usb"
|
||||
"qcom,ci-hdrc"
|
||||
"chipidea,usb2"
|
||||
"xlnx,zynq-usb-2.20a"
|
||||
- reg: base address and length of the registers
|
||||
- interrupts: interrupt for the USB controller
|
||||
|
||||
|
||||
@@ -203,6 +203,7 @@ sitronix Sitronix Technology Corporation
|
||||
skyworks Skyworks Solutions, Inc.
|
||||
smsc Standard Microsystems Corporation
|
||||
snps Synopsys, Inc.
|
||||
socionext Socionext Inc.
|
||||
solidrun SolidRun
|
||||
solomon Solomon Systech Limited
|
||||
sony Sony Corporation
|
||||
|
||||
@@ -361,7 +361,7 @@ For win8 devices with both T and C coordinates, the position mapping is
|
||||
ABS_MT_POSITION_X := T_X
|
||||
ABS_MT_POSITION_Y := T_Y
|
||||
ABS_MT_TOOL_X := C_X
|
||||
ABS_MT_TOOL_X := C_Y
|
||||
ABS_MT_TOOL_Y := C_Y
|
||||
|
||||
Unfortunately, there is not enough information to specify both the touching
|
||||
ellipse and the tool ellipse, so one has to resort to approximations. One
|
||||
|
||||
@@ -0,0 +1,96 @@
|
||||
Virtual Routing and Forwarding (VRF)
|
||||
====================================
|
||||
The VRF device combined with ip rules provides the ability to create virtual
|
||||
routing and forwarding domains (aka VRFs, VRF-lite to be specific) in the
|
||||
Linux network stack. One use case is the multi-tenancy problem where each
|
||||
tenant has their own unique routing tables and in the very least need
|
||||
different default gateways.
|
||||
|
||||
Processes can be "VRF aware" by binding a socket to the VRF device. Packets
|
||||
through the socket then use the routing table associated with the VRF
|
||||
device. An important feature of the VRF device implementation is that it
|
||||
impacts only Layer 3 and above so L2 tools (e.g., LLDP) are not affected
|
||||
(ie., they do not need to be run in each VRF). The design also allows
|
||||
the use of higher priority ip rules (Policy Based Routing, PBR) to take
|
||||
precedence over the VRF device rules directing specific traffic as desired.
|
||||
|
||||
In addition, VRF devices allow VRFs to be nested within namespaces. For
|
||||
example network namespaces provide separation of network interfaces at L1
|
||||
(Layer 1 separation), VLANs on the interfaces within a namespace provide
|
||||
L2 separation and then VRF devices provide L3 separation.
|
||||
|
||||
Design
|
||||
------
|
||||
A VRF device is created with an associated route table. Network interfaces
|
||||
are then enslaved to a VRF device:
|
||||
|
||||
+-----------------------------+
|
||||
| vrf-blue | ===> route table 10
|
||||
+-----------------------------+
|
||||
| | |
|
||||
+------+ +------+ +-------------+
|
||||
| eth1 | | eth2 | ... | bond1 |
|
||||
+------+ +------+ +-------------+
|
||||
| |
|
||||
+------+ +------+
|
||||
| eth8 | | eth9 |
|
||||
+------+ +------+
|
||||
|
||||
Packets received on an enslaved device and are switched to the VRF device
|
||||
using an rx_handler which gives the impression that packets flow through
|
||||
the VRF device. Similarly on egress routing rules are used to send packets
|
||||
to the VRF device driver before getting sent out the actual interface. This
|
||||
allows tcpdump on a VRF device to capture all packets into and out of the
|
||||
VRF as a whole.[1] Similiarly, netfilter [2] and tc rules can be applied
|
||||
using the VRF device to specify rules that apply to the VRF domain as a whole.
|
||||
|
||||
[1] Packets in the forwarded state do not flow through the device, so those
|
||||
packets are not seen by tcpdump. Will revisit this limitation in a
|
||||
future release.
|
||||
|
||||
[2] Iptables on ingress is limited to NF_INET_PRE_ROUTING only with skb->dev
|
||||
set to real ingress device and egress is limited to NF_INET_POST_ROUTING.
|
||||
Will revisit this limitation in a future release.
|
||||
|
||||
|
||||
Setup
|
||||
-----
|
||||
1. VRF device is created with an association to a FIB table.
|
||||
e.g, ip link add vrf-blue type vrf table 10
|
||||
ip link set dev vrf-blue up
|
||||
|
||||
2. Rules are added that send lookups to the associated FIB table when the
|
||||
iif or oif is the VRF device. e.g.,
|
||||
ip ru add oif vrf-blue table 10
|
||||
ip ru add iif vrf-blue table 10
|
||||
|
||||
Set the default route for the table (and hence default route for the VRF).
|
||||
e.g, ip route add table 10 prohibit default
|
||||
|
||||
3. Enslave L3 interfaces to a VRF device.
|
||||
e.g, ip link set dev eth1 master vrf-blue
|
||||
|
||||
Local and connected routes for enslaved devices are automatically moved to
|
||||
the table associated with VRF device. Any additional routes depending on
|
||||
the enslaved device will need to be reinserted following the enslavement.
|
||||
|
||||
4. Additional VRF routes are added to associated table.
|
||||
e.g., ip route add table 10 ...
|
||||
|
||||
|
||||
Applications
|
||||
------------
|
||||
Applications that are to work within a VRF need to bind their socket to the
|
||||
VRF device:
|
||||
|
||||
setsockopt(sd, SOL_SOCKET, SO_BINDTODEVICE, dev, strlen(dev)+1);
|
||||
|
||||
or to specify the output device using cmsg and IP_PKTINFO.
|
||||
|
||||
|
||||
Limitations
|
||||
-----------
|
||||
VRF device currently only works for IPv4. Support for IPv6 is under development.
|
||||
|
||||
Index of original ingress interface is not available via cmsg. Will address
|
||||
soon.
|
||||
+38
-13
@@ -979,20 +979,45 @@ every time right after the runtime_resume() callback has returned
|
||||
(alternatively, the runtime_suspend() callback will have to check if the
|
||||
device should really be suspended and return -EAGAIN if that is not the case).
|
||||
|
||||
The runtime PM of PCI devices is disabled by default. It is also blocked by
|
||||
pci_pm_init() that runs the pm_runtime_forbid() helper function. If a PCI
|
||||
driver implements the runtime PM callbacks and intends to use the runtime PM
|
||||
framework provided by the PM core and the PCI subsystem, it should enable this
|
||||
feature by executing the pm_runtime_enable() helper function. However, the
|
||||
driver should not call the pm_runtime_allow() helper function unblocking
|
||||
the runtime PM of the device. Instead, it should allow user space or some
|
||||
platform-specific code to do that (user space can do it via sysfs), although
|
||||
once it has called pm_runtime_enable(), it must be prepared to handle the
|
||||
The runtime PM of PCI devices is enabled by default by the PCI core. PCI
|
||||
device drivers do not need to enable it and should not attempt to do so.
|
||||
However, it is blocked by pci_pm_init() that runs the pm_runtime_forbid()
|
||||
helper function. In addition to that, the runtime PM usage counter of
|
||||
each PCI device is incremented by local_pci_probe() before executing the
|
||||
probe callback provided by the device's driver.
|
||||
|
||||
If a PCI driver implements the runtime PM callbacks and intends to use the
|
||||
runtime PM framework provided by the PM core and the PCI subsystem, it needs
|
||||
to decrement the device's runtime PM usage counter in its probe callback
|
||||
function. If it doesn't do that, the counter will always be different from
|
||||
zero for the device and it will never be runtime-suspended. The simplest
|
||||
way to do that is by calling pm_runtime_put_noidle(), but if the driver
|
||||
wants to schedule an autosuspend right away, for example, it may call
|
||||
pm_runtime_put_autosuspend() instead for this purpose. Generally, it
|
||||
just needs to call a function that decrements the devices usage counter
|
||||
from its probe routine to make runtime PM work for the device.
|
||||
|
||||
It is important to remember that the driver's runtime_suspend() callback
|
||||
may be executed right after the usage counter has been decremented, because
|
||||
user space may already have cuased the pm_runtime_allow() helper function
|
||||
unblocking the runtime PM of the device to run via sysfs, so the driver must
|
||||
be prepared to cope with that.
|
||||
|
||||
The driver itself should not call pm_runtime_allow(), though. Instead, it
|
||||
should let user space or some platform-specific code do that (user space can
|
||||
do it via sysfs as stated above), but it must be prepared to handle the
|
||||
runtime PM of the device correctly as soon as pm_runtime_allow() is called
|
||||
(which may happen at any time). [It also is possible that user space causes
|
||||
pm_runtime_allow() to be called via sysfs before the driver is loaded, so in
|
||||
fact the driver has to be prepared to handle the runtime PM of the device as
|
||||
soon as it calls pm_runtime_enable().]
|
||||
(which may happen at any time, even before the driver is loaded).
|
||||
|
||||
When the driver's remove callback runs, it has to balance the decrementation
|
||||
of the device's runtime PM usage counter at the probe time. For this reason,
|
||||
if it has decremented the counter in its probe callback, it must run
|
||||
pm_runtime_get_noresume() in its remove callback. [Since the core carries
|
||||
out a runtime resume of the device and bumps up the device's usage counter
|
||||
before running the driver's remove callback, the runtime PM of the device
|
||||
is effectively disabled for the duration of the remove execution and all
|
||||
runtime PM helper functions incrementing the device's usage counter are
|
||||
then effectively equivalent to pm_runtime_get_noresume().]
|
||||
|
||||
The runtime PM framework works by processing requests to suspend or resume
|
||||
devices, or to check if they are idle (in which cases it is reasonable to
|
||||
|
||||
@@ -18,6 +18,7 @@
|
||||
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
||||
*/
|
||||
#define _GNU_SOURCE
|
||||
#define __SANE_USERSPACE_TYPES__ /* For PPC64, to get LL64 types */
|
||||
#include <errno.h>
|
||||
#include <fcntl.h>
|
||||
#include <inttypes.h>
|
||||
|
||||
@@ -54,13 +54,15 @@ default_qdisc
|
||||
--------------
|
||||
|
||||
The default queuing discipline to use for network devices. This allows
|
||||
overriding the default queue discipline of pfifo_fast with an
|
||||
alternative. Since the default queuing discipline is created with the
|
||||
no additional parameters so is best suited to queuing disciplines that
|
||||
work well without configuration like stochastic fair queue (sfq),
|
||||
CoDel (codel) or fair queue CoDel (fq_codel). Don't use queuing disciplines
|
||||
like Hierarchical Token Bucket or Deficit Round Robin which require setting
|
||||
up classes and bandwidths.
|
||||
overriding the default of pfifo_fast with an alternative. Since the default
|
||||
queuing discipline is created without additional parameters so is best suited
|
||||
to queuing disciplines that work well without configuration like stochastic
|
||||
fair queue (sfq), CoDel (codel) or fair queue CoDel (fq_codel). Don't use
|
||||
queuing disciplines like Hierarchical Token Bucket or Deficit Round Robin
|
||||
which require setting up classes and bandwidths. Note that physical multiqueue
|
||||
interfaces still use mq as root qdisc, which in turn uses this default for its
|
||||
leaves. Virtual devices (like e.g. lo or veth) ignore this setting and instead
|
||||
default to noqueue.
|
||||
Default: pfifo_fast
|
||||
|
||||
busy_read
|
||||
|
||||
@@ -4,7 +4,7 @@ Power allocator governor tunables
|
||||
Trip points
|
||||
-----------
|
||||
|
||||
The governor requires the following two passive trip points:
|
||||
The governor works optimally with the following two passive trip points:
|
||||
|
||||
1. "switch on" trip point: temperature above which the governor
|
||||
control loop starts operating. This is the first passive trip
|
||||
|
||||
+27
-15
@@ -615,9 +615,8 @@ F: Documentation/hwmon/fam15h_power
|
||||
F: drivers/hwmon/fam15h_power.c
|
||||
|
||||
AMD GEODE CS5536 USB DEVICE CONTROLLER DRIVER
|
||||
M: Thomas Dahlmann <dahlmann.thomas@arcor.de>
|
||||
L: linux-geode@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Supported
|
||||
S: Orphan
|
||||
F: drivers/usb/gadget/udc/amd5536udc.*
|
||||
|
||||
AMD GEODE PROCESSOR/CHIPSET SUPPORT
|
||||
@@ -808,6 +807,13 @@ S: Maintained
|
||||
F: drivers/video/fbdev/arcfb.c
|
||||
F: drivers/video/fbdev/core/fb_defio.c
|
||||
|
||||
ARCNET NETWORK LAYER
|
||||
M: Michael Grzeschik <m.grzeschik@pengutronix.de>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/arcnet/
|
||||
F: include/uapi/linux/if_arcnet.h
|
||||
|
||||
ARM MFM AND FLOPPY DRIVERS
|
||||
M: Ian Molton <spyro@f2s.com>
|
||||
S: Maintained
|
||||
@@ -3394,7 +3400,6 @@ F: drivers/staging/dgnc/
|
||||
|
||||
DIGI EPCA PCI PRODUCTS
|
||||
M: Lidza Louina <lidza.louina@gmail.com>
|
||||
M: Mark Hounschell <markh@compro.net>
|
||||
M: Daeseok Youn <daeseok.youn@gmail.com>
|
||||
L: driverdev-devel@linuxdriverproject.org
|
||||
S: Maintained
|
||||
@@ -5952,7 +5957,7 @@ F: virt/kvm/
|
||||
KERNEL VIRTUAL MACHINE (KVM) FOR AMD-V
|
||||
M: Joerg Roedel <joro@8bytes.org>
|
||||
L: kvm@vger.kernel.org
|
||||
W: http://kvm.qumranet.com
|
||||
W: http://www.linux-kvm.org/
|
||||
S: Maintained
|
||||
F: arch/x86/include/asm/svm.h
|
||||
F: arch/x86/kvm/svm.c
|
||||
@@ -5960,7 +5965,7 @@ F: arch/x86/kvm/svm.c
|
||||
KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC
|
||||
M: Alexander Graf <agraf@suse.com>
|
||||
L: kvm-ppc@vger.kernel.org
|
||||
W: http://kvm.qumranet.com
|
||||
W: http://www.linux-kvm.org/
|
||||
T: git git://github.com/agraf/linux-2.6.git
|
||||
S: Supported
|
||||
F: arch/powerpc/include/asm/kvm*
|
||||
@@ -8500,7 +8505,6 @@ F: Documentation/networking/LICENSE.qla3xxx
|
||||
F: drivers/net/ethernet/qlogic/qla3xxx.*
|
||||
|
||||
QLOGIC QLCNIC (1/10)Gb ETHERNET DRIVER
|
||||
M: Shahed Shaikh <shahed.shaikh@qlogic.com>
|
||||
M: Dept-GELinuxNICDev@qlogic.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
@@ -9904,8 +9908,8 @@ F: drivers/staging/media/lirc/
|
||||
STAGING - LUSTRE PARALLEL FILESYSTEM
|
||||
M: Oleg Drokin <oleg.drokin@intel.com>
|
||||
M: Andreas Dilger <andreas.dilger@intel.com>
|
||||
L: HPDD-discuss@lists.01.org (moderated for non-subscribers)
|
||||
W: http://lustre.opensfs.org/
|
||||
L: lustre-devel@lists.lustre.org (moderated for non-subscribers)
|
||||
W: http://wiki.lustre.org/
|
||||
S: Maintained
|
||||
F: drivers/staging/lustre
|
||||
|
||||
@@ -10338,6 +10342,16 @@ F: include/uapi/linux/thermal.h
|
||||
F: include/linux/cpu_cooling.h
|
||||
F: Documentation/devicetree/bindings/thermal/
|
||||
|
||||
THERMAL/CPU_COOLING
|
||||
M: Amit Daniel Kachhap <amit.kachhap@gmail.com>
|
||||
M: Viresh Kumar <viresh.kumar@linaro.org>
|
||||
M: Javi Merino <javi.merino@arm.com>
|
||||
L: linux-pm@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/thermal/cpu-cooling-api.txt
|
||||
F: drivers/thermal/cpu_cooling.c
|
||||
F: include/linux/cpu_cooling.h
|
||||
|
||||
THINGM BLINK(1) USB RGB LED DRIVER
|
||||
M: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
|
||||
S: Maintained
|
||||
@@ -11187,7 +11201,7 @@ F: drivers/vlynq/vlynq.c
|
||||
F: include/linux/vlynq.h
|
||||
|
||||
VME SUBSYSTEM
|
||||
M: Martyn Welch <martyn.welch@ge.com>
|
||||
M: Martyn Welch <martyn@welchs.me.uk>
|
||||
M: Manohar Vanga <manohar.vanga@gmail.com>
|
||||
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
L: devel@driverdev.osuosl.org
|
||||
@@ -11239,7 +11253,6 @@ VOLTAGE AND CURRENT REGULATOR FRAMEWORK
|
||||
M: Liam Girdwood <lgirdwood@gmail.com>
|
||||
M: Mark Brown <broonie@kernel.org>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
W: http://opensource.wolfsonmicro.com/node/15
|
||||
W: http://www.slimlogic.co.uk/?p=48
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
|
||||
S: Supported
|
||||
@@ -11253,6 +11266,7 @@ L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/vrf.c
|
||||
F: include/net/vrf.h
|
||||
F: Documentation/networking/vrf.txt
|
||||
|
||||
VT1211 HARDWARE MONITOR DRIVER
|
||||
M: Juerg Haefliger <juergh@gmail.com>
|
||||
@@ -11368,17 +11382,15 @@ WM97XX TOUCHSCREEN DRIVERS
|
||||
M: Mark Brown <broonie@kernel.org>
|
||||
M: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||
L: linux-input@vger.kernel.org
|
||||
T: git git://opensource.wolfsonmicro.com/linux-2.6-touch
|
||||
W: http://opensource.wolfsonmicro.com/node/7
|
||||
W: https://github.com/CirrusLogic/linux-drivers/wiki
|
||||
S: Supported
|
||||
F: drivers/input/touchscreen/*wm97*
|
||||
F: include/linux/wm97xx.h
|
||||
|
||||
WOLFSON MICROELECTRONICS DRIVERS
|
||||
L: patches@opensource.wolfsonmicro.com
|
||||
T: git git://opensource.wolfsonmicro.com/linux-2.6-asoc
|
||||
T: git git://opensource.wolfsonmicro.com/linux-2.6-audioplus
|
||||
W: http://opensource.wolfsonmicro.com/content/linux-drivers-wolfson-devices
|
||||
T: git https://github.com/CirrusLogic/linux-drivers.git
|
||||
W: https://github.com/CirrusLogic/linux-drivers/wiki
|
||||
S: Supported
|
||||
F: Documentation/hwmon/wm83??
|
||||
F: arch/arm/mach-s3c64xx/mach-crag6410*
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user