Skip to content
This repository has been archived by the owner on Nov 1, 2022. It is now read-only.

Commit

Permalink
Merge tag 'v4.8-rc7' into capsicum
Browse files Browse the repository at this point in the history
Linux 4.8-rc7

Conflicts:
	Makefile
	security/Kconfig
  • Loading branch information
daviddrysdale committed Sep 20, 2016
2 parents 0f0f63b + 3be7988 commit fef76b9
Show file tree
Hide file tree
Showing 1,154 changed files with 12,459 additions and 6,833 deletions.
3 changes: 3 additions & 0 deletions .mailmap
Expand Up @@ -88,6 +88,7 @@ Kay Sievers <kay.sievers@vrfy.org>
Kenneth W Chen <kenneth.w.chen@intel.com>
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
Koushik <raghavendra.koushik@neterion.com>
Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski@samsung.com>
Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski.k@gmail.com>
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Leonid I Ananiev <leonid.i.ananiev@intel.com>
Expand Down Expand Up @@ -158,6 +159,8 @@ Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Viresh Kumar <vireshk@kernel.org> <viresh.kumar@st.com>
Viresh Kumar <vireshk@kernel.org> <viresh.linux@gmail.com>
Viresh Kumar <vireshk@kernel.org> <viresh.kumar2@arm.com>
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@virtuozzo.com>
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@parallels.com>
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
Yusuke Goda <goda.yusuke@renesas.com>
Gustavo Padovan <gustavo@las.ic.unicamp.br>
Expand Down
2 changes: 1 addition & 1 deletion Documentation/ABI/stable/sysfs-devices
@@ -1,7 +1,7 @@
# Note: This documents additional properties of any device beyond what
# is documented in Documentation/sysfs-rules.txt

What: /sys/devices/*/of_path
What: /sys/devices/*/of_node
Date: February 2015
Contact: Device Tree mailing list <devicetree@vger.kernel.org>
Description:
Expand Down
24 changes: 10 additions & 14 deletions Documentation/PCI/MSI-HOWTO.txt
Expand Up @@ -94,14 +94,11 @@ has a requirements for a minimum number of vectors the driver can pass a
min_vecs argument set to this limit, and the PCI core will return -ENOSPC
if it can't meet the minimum number of vectors.

The flags argument should normally be set to 0, but can be used to pass the
PCI_IRQ_NOMSI and PCI_IRQ_NOMSIX flag in case a device claims to support
MSI or MSI-X, but the support is broken, or to pass PCI_IRQ_NOLEGACY in
case the device does not support legacy interrupt lines.

By default this function will spread the interrupts around the available
CPUs, but this feature can be disabled by passing the PCI_IRQ_NOAFFINITY
flag.
The flags argument is used to specify which type of interrupt can be used
by the device and the driver (PCI_IRQ_LEGACY, PCI_IRQ_MSI, PCI_IRQ_MSIX).
A convenient short-hand (PCI_IRQ_ALL_TYPES) is also available to ask for
any possible kind of interrupt. If the PCI_IRQ_AFFINITY flag is set,
pci_alloc_irq_vectors() will spread the interrupts around the available CPUs.

To get the Linux IRQ numbers passed to request_irq() and free_irq() and the
vectors, use the following function:
Expand Down Expand Up @@ -131,7 +128,7 @@ larger than the number supported by the device it will automatically be
capped to the supported limit, so there is no need to query the number of
vectors supported beforehand:

nvec = pci_alloc_irq_vectors(pdev, 1, nvec, 0);
nvec = pci_alloc_irq_vectors(pdev, 1, nvec, PCI_IRQ_ALL_TYPES)
if (nvec < 0)
goto out_err;

Expand All @@ -140,23 +137,22 @@ interrupts it can request a particular number of interrupts by passing that
number to pci_alloc_irq_vectors() function as both 'min_vecs' and
'max_vecs' parameters:

ret = pci_alloc_irq_vectors(pdev, nvec, nvec, 0);
ret = pci_alloc_irq_vectors(pdev, nvec, nvec, PCI_IRQ_ALL_TYPES);
if (ret < 0)
goto out_err;

The most notorious example of the request type described above is enabling
the single MSI mode for a device. It could be done by passing two 1s as
'min_vecs' and 'max_vecs':

ret = pci_alloc_irq_vectors(pdev, 1, 1, 0);
ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES);
if (ret < 0)
goto out_err;

Some devices might not support using legacy line interrupts, in which case
the PCI_IRQ_NOLEGACY flag can be used to fail the request if the platform
can't provide MSI or MSI-X interrupts:
the driver can specify that only MSI or MSI-X is acceptable:

nvec = pci_alloc_irq_vectors(pdev, 1, nvec, PCI_IRQ_NOLEGACY);
nvec = pci_alloc_irq_vectors(pdev, 1, nvec, PCI_IRQ_MSI | PCI_IRQ_MSIX);
if (nvec < 0)
goto out_err;

Expand Down
1 change: 0 additions & 1 deletion Documentation/PCI/pci.txt
Expand Up @@ -124,7 +124,6 @@ initialization with a pointer to a structure describing the driver

The ID table is an array of struct pci_device_id entries ending with an
all-zero entry. Definitions with static const are generally preferred.
Use of the deprecated macro DEFINE_PCI_DEVICE_TABLE should be avoided.

Each entry consists of:

Expand Down
16 changes: 10 additions & 6 deletions Documentation/arm/CCN.txt
Expand Up @@ -18,13 +18,17 @@ and config2 fields of the perf_event_attr structure. The "events"
directory provides configuration templates for all documented
events, that can be used with perf tool. For example "xp_valid_flit"
is an equivalent of "type=0x8,event=0x4". Other parameters must be
explicitly specified. For events originating from device, "node"
defines its index. All crosspoint events require "xp" (index),
"port" (device port number) and "vc" (virtual channel ID) and
"dir" (direction). Watchpoints (special "event" value 0xfe) also
require comparator values ("cmp_l" and "cmp_h") and "mask", being
index of the comparator mask.
explicitly specified.

For events originating from device, "node" defines its index.

Crosspoint PMU events require "xp" (index), "bus" (bus number)
and "vc" (virtual channel ID).

Crosspoint watchpoint-based events (special "event" value 0xfe)
require "xp" and "vc" as as above plus "port" (device port index),
"dir" (transmit/receive direction), comparator values ("cmp_l"
and "cmp_h") and "mask", being index of the comparator mask.
Masks are defined separately from the event description
(due to limited number of the config values) in the "cmp_mask"
directory, with first 8 configurable by user and additional
Expand Down
1 change: 1 addition & 0 deletions Documentation/arm64/silicon-errata.txt
Expand Up @@ -53,6 +53,7 @@ stable kernels.
| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
| ARM | Cortex-A57 | #852523 | N/A |
| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
| ARM | Cortex-A72 | #853709 | N/A |
| ARM | MMU-500 | #841119,#826419 | N/A |
| | | | |
| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
Expand Down
2 changes: 1 addition & 1 deletion Documentation/conf.py
Expand Up @@ -131,7 +131,7 @@
todo_include_todos = False

primary_domain = 'C'
highlight_language = 'C'
highlight_language = 'guess'

# -- Options for HTML output ----------------------------------------------

Expand Down
2 changes: 1 addition & 1 deletion Documentation/cpu-freq/cpufreq-stats.txt
Expand Up @@ -103,7 +103,7 @@ Config Main Menu
Power management options (ACPI, APM) --->
CPU Frequency scaling --->
[*] CPU Frequency scaling
<*> CPU frequency translation statistics
[*] CPU frequency translation statistics
[*] CPU frequency translation statistics details


Expand Down
7 changes: 7 additions & 0 deletions Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt
Expand Up @@ -16,13 +16,20 @@ Required properties:
- vref-supply: The regulator supply ADC reference voltage.
- #io-channel-cells: Should be 1, see ../iio-bindings.txt

Optional properties:
- resets: Must contain an entry for each entry in reset-names if need support
this option. See ../reset/reset.txt for details.
- reset-names: Must include the name "saradc-apb".

Example:
saradc: saradc@2006c000 {
compatible = "rockchip,saradc";
reg = <0x2006c000 0x100>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru SCLK_SARADC>, <&cru PCLK_SARADC>;
clock-names = "saradc", "apb_pclk";
resets = <&cru SRST_SARADC>;
reset-names = "saradc-apb";
#io-channel-cells = <1>;
vref-supply = <&vcc18>;
};
2 changes: 1 addition & 1 deletion Documentation/devicetree/bindings/mmc/sdhci-st.txt
Expand Up @@ -10,7 +10,7 @@ Required properties:
subsystem (mmcss) inside the FlashSS (available in STiH407 SoC
family).

- clock-names: Should be "mmc".
- clock-names: Should be "mmc" and "icn". (NB: The latter is not compulsory)
See: Documentation/devicetree/bindings/resource-names.txt
- clocks: Phandle to the clock.
See: Documentation/devicetree/bindings/clock/clock-bindings.txt
Expand Down
19 changes: 0 additions & 19 deletions Documentation/devicetree/bindings/serial/8250.txt
Expand Up @@ -42,9 +42,6 @@ Optional properties:
- auto-flow-control: one way to enable automatic flow control support. The
driver is allowed to detect support for the capability even without this
property.
- {rts,cts,dtr,dsr,rng,dcd}-gpios: specify a GPIO for RTS/CTS/DTR/DSR/RI/DCD
line respectively. It will use specified GPIO instead of the peripheral
function pin for the UART feature. If unsure, don't specify this property.

Note:
* fsl,ns16550:
Expand All @@ -66,19 +63,3 @@ Example:
interrupts = <10>;
reg-shift = <2>;
};

Example for OMAP UART using GPIO-based modem control signals:

uart4: serial@49042000 {
compatible = "ti,omap3-uart";
reg = <0x49042000 0x400>;
interrupts = <80>;
ti,hwmods = "uart4";
clock-frequency = <48000000>;
cts-gpios = <&gpio3 5 GPIO_ACTIVE_LOW>;
rts-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>;
dtr-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
dsr-gpios = <&gpio1 13 GPIO_ACTIVE_LOW>;
dcd-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>;
rng-gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
};
10 changes: 0 additions & 10 deletions Documentation/devicetree/bindings/sound/omap-mcpdm.txt
Expand Up @@ -8,8 +8,6 @@ Required properties:
- interrupts: Interrupt number for McPDM
- interrupt-parent: The parent interrupt controller
- ti,hwmods: Name of the hwmod associated to the McPDM
- clocks: phandle for the pdmclk provider, likely <&twl6040>
- clock-names: Must be "pdmclk"

Example:

Expand All @@ -21,11 +19,3 @@ mcpdm: mcpdm@40132000 {
interrupt-parent = <&gic>;
ti,hwmods = "mcpdm";
};

In board DTS file the pdmclk needs to be added:

&mcpdm {
clocks = <&twl6040>;
clock-names = "pdmclk";
status = "okay";
};
10 changes: 5 additions & 5 deletions Documentation/devicetree/bindings/thermal/thermal.txt
Expand Up @@ -62,7 +62,7 @@ For more examples of cooling devices, refer to the example sections below.
Required properties:
- #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
Size: one cell to specify minimum and maximum cooling state used
in the reference. The first cell is the minimum
cooling state requested and the second cell is
the maximum cooling state requested in the reference.
Expand Down Expand Up @@ -119,7 +119,7 @@ Required properties:
Optional property:
- contribution: The cooling contribution to the thermal zone of the
Type: unsigned referred cooling device at the referred trip point.
Size: one cell The contribution is a ratio of the sum
Size: one cell The contribution is a ratio of the sum
of all cooling contributions within a thermal zone.

Note: Using the THERMAL_NO_LIMIT (-1UL) constant in the cooling-device phandle
Expand All @@ -145,7 +145,7 @@ Required properties:
Size: one cell

- thermal-sensors: A list of thermal sensor phandles and sensor specifier
Type: list of used while monitoring the thermal zone.
Type: list of used while monitoring the thermal zone.
phandles + sensor
specifier

Expand Down Expand Up @@ -473,7 +473,7 @@ thermal-zones {
<&adc>; /* pcb north */

/* hotspot = 100 * bandgap - 120 * adc + 484 */
coefficients = <100 -120 484>;
coefficients = <100 -120 484>;

trips {
...
Expand Down Expand Up @@ -502,7 +502,7 @@ from the ADC sensor. The binding would be then:
thermal-sensors = <&adc>;

/* hotspot = 1 * adc + 6000 */
coefficients = <1 6000>;
coefficients = <1 6000>;

(d) - Board thermal

Expand Down
8 changes: 3 additions & 5 deletions Documentation/filesystems/overlayfs.txt
Expand Up @@ -183,12 +183,10 @@ The copy_up operation essentially creates a new, identical file and
moves it over to the old name. The new file may be on a different
filesystem, so both st_dev and st_ino of the file may change.

Any open files referring to this inode will access the old data and
metadata. Similarly any file locks obtained before copy_up will not
apply to the copied up file.
Any open files referring to this inode will access the old data.

On a file opened with O_RDONLY fchmod(2), fchown(2), futimesat(2) and
fsetxattr(2) will fail with EROFS.
Any file locks (and leases) obtained before copy_up will not apply
to the copied up file.

If a file with multiple hard links is copied up, then this will
"break" the link. Changes will not be propagated to other names
Expand Down
4 changes: 2 additions & 2 deletions Documentation/hwmon/ftsteutates
Expand Up @@ -19,5 +19,5 @@ enhancements. It can monitor up to 4 voltages, 16 temperatures and
implemented in this driver.

Specification of the chip can be found here:
ftp:///pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/BMC-Teutates_Specification_V1.21.pdf
ftp:///pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/Fujitsu_mainboards-1-Sensors_HowTo-en-US.pdf
ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/BMC-Teutates_Specification_V1.21.pdf
ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/Fujitsu_mainboards-1-Sensors_HowTo-en-US.pdf
5 changes: 5 additions & 0 deletions Documentation/i2c/slave-interface
Expand Up @@ -145,6 +145,11 @@ If you want to add slave support to the bus driver:

* Catch the slave interrupts and send appropriate i2c_slave_events to the backend.

Note that most hardware supports being master _and_ slave on the same bus. So,
if you extend a bus driver, please make sure that the driver supports that as
well. In almost all cases, slave support does not need to disable the master
functionality.

Check the i2c-rcar driver as an example.


Expand Down
6 changes: 0 additions & 6 deletions Documentation/kernel-documentation.rst
Expand Up @@ -366,8 +366,6 @@ Domain`_ references.
Cross-referencing from reStructuredText
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. highlight:: none

To cross-reference the functions and types defined in the kernel-doc comments
from reStructuredText documents, please use the `Sphinx C Domain`_
references. For example::
Expand All @@ -390,8 +388,6 @@ For further details, please refer to the `Sphinx C Domain`_ documentation.
Function documentation
----------------------

.. highlight:: c

The general format of a function and function-like macro kernel-doc comment is::

/**
Expand Down Expand Up @@ -572,8 +568,6 @@ DocBook XML [DEPRECATED]
Converting DocBook to Sphinx
----------------------------

.. highlight:: none

Over time, we expect all of the documents under ``Documentation/DocBook`` to be
converted to Sphinx and reStructuredText. For most DocBook XML documents, a good
enough solution is to use the simple ``Documentation/sphinx/tmplcvt`` script,
Expand Down
4 changes: 4 additions & 0 deletions Documentation/kernel-parameters.txt
Expand Up @@ -3032,6 +3032,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
PAGE_SIZE is used as alignment.
PCI-PCI bridge can be specified, if resource
windows need to be expanded.
To specify the alignment for several
instances of a device, the PCI vendor,
device, subvendor, and subdevice may be
specified, e.g., 4096@pci:8086:9c22:103c:198f
ecrc= Enable/disable PCIe ECRC (transaction layer
end-to-end CRC checking).
bios: Use BIOS/firmware settings. This is the
Expand Down
20 changes: 0 additions & 20 deletions Documentation/networking/dsa/dsa.txt
Expand Up @@ -587,26 +587,6 @@ of DSA, would be the its port-based VLAN, used by the associated bridge device.
TODO
====

The platform device problem
---------------------------
DSA is currently implemented as a platform device driver which is far from ideal
as was discussed in this thread:

http://permalink.gmane.org/gmane.linux.network/329848

This basically prevents the device driver model to be properly used and applied,
and support non-MDIO, non-MMIO Ethernet connected switches.

Another problem with the platform device driver approach is that it prevents the
use of a modular switch drivers build due to a circular dependency, illustrated
here:

http://comments.gmane.org/gmane.linux.network/345803

Attempts of reworking this has been done here:

https://lwn.net/Articles/643149/

Making SWITCHDEV and DSA converge towards an unified codebase
-------------------------------------------------------------

Expand Down

0 comments on commit fef76b9

Please sign in to comment.