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 4.6-rc7 into staging-next
This fixes some merge issues with some iio drivers that were found in linux-next. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
@@ -48,6 +48,9 @@ Felix Kuhling <fxkuehl@gmx.de>
|
||||
Felix Moeller <felix@derklecks.de>
|
||||
Filipe Lautert <filipe@icewall.org>
|
||||
Franck Bui-Huu <vagabon.xyz@gmail.com>
|
||||
Frank Rowand <frowand.list@gmail.com> <frowand@mvista.com>
|
||||
Frank Rowand <frowand.list@gmail.com> <frank.rowand@am.sony.com>
|
||||
Frank Rowand <frowand.list@gmail.com> <frank.rowand@sonymobile.com>
|
||||
Frank Zago <fzago@systemfabricworks.com>
|
||||
Greg Kroah-Hartman <greg@echidna.(none)>
|
||||
Greg Kroah-Hartman <gregkh@suse.de>
|
||||
@@ -66,6 +69,7 @@ Jean Tourrilhes <jt@hpl.hp.com>
|
||||
Jeff Garzik <jgarzik@pretzel.yyz.us>
|
||||
Jens Axboe <axboe@suse.de>
|
||||
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
|
||||
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
|
||||
John Stultz <johnstul@us.ibm.com>
|
||||
<josh@joshtriplett.org> <josh@freedesktop.org>
|
||||
<josh@joshtriplett.org> <josh@kernel.org>
|
||||
@@ -79,6 +83,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.k@gmail.com>
|
||||
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
|
||||
Leonid I Ananiev <leonid.i.ananiev@intel.com>
|
||||
Linas Vepstas <linas@austin.ibm.com>
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
The ARC HS can be configured with a pipeline performance monitor for counting
|
||||
CPU and cache events like cache misses and hits. Like conventional PCT there
|
||||
are 100+ hardware conditions dynamically mapped to upto 32 counters.
|
||||
are 100+ hardware conditions dynamically mapped to up to 32 counters.
|
||||
It also supports overflow interrupts.
|
||||
|
||||
Required properties:
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
The ARC700 can be configured with a pipeline performance monitor for counting
|
||||
CPU and cache events like cache misses and hits. Like conventional PCT there
|
||||
are 100+ hardware conditions dynamically mapped to upto 32 counters
|
||||
are 100+ hardware conditions dynamically mapped to up to 32 counters
|
||||
|
||||
Note that:
|
||||
* The ARC 700 PCT does not support interrupts; although HW events may be
|
||||
|
||||
@@ -192,7 +192,6 @@ nodes to be present and contain the properties described below.
|
||||
can be one of:
|
||||
"allwinner,sun6i-a31"
|
||||
"allwinner,sun8i-a23"
|
||||
"arm,psci"
|
||||
"arm,realview-smp"
|
||||
"brcm,bcm-nsp-smp"
|
||||
"brcm,brahma-b15"
|
||||
|
||||
@@ -32,6 +32,10 @@ Optional properties:
|
||||
- target-supply : regulator for SATA target power
|
||||
- phys : reference to the SATA PHY node
|
||||
- phy-names : must be "sata-phy"
|
||||
- ports-implemented : Mask that indicates which ports that the HBA supports
|
||||
are available for software to use. Useful if PORTS_IMPL
|
||||
is not programmed by the BIOS, which is true with
|
||||
some embedded SOC's.
|
||||
|
||||
Required properties when using sub-nodes:
|
||||
- #address-cells : number of cells to encode an address
|
||||
|
||||
@@ -6,8 +6,8 @@ RK3xxx SoCs.
|
||||
Required properties :
|
||||
|
||||
- reg : Offset and length of the register set for the device
|
||||
- compatible : should be "rockchip,rk3066-i2c", "rockchip,rk3188-i2c" or
|
||||
"rockchip,rk3288-i2c".
|
||||
- compatible : should be "rockchip,rk3066-i2c", "rockchip,rk3188-i2c",
|
||||
"rockchip,rk3228-i2c" or "rockchip,rk3288-i2c".
|
||||
- interrupts : interrupt number
|
||||
- clocks : parent clock
|
||||
|
||||
|
||||
@@ -45,13 +45,13 @@ Required properties:
|
||||
Optional properties:
|
||||
- dual_emac_res_vlan : Specifies VID to be used to segregate the ports
|
||||
- mac-address : See ethernet.txt file in the same directory
|
||||
- phy_id : Specifies slave phy id
|
||||
- phy_id : Specifies slave phy id (deprecated, use phy-handle)
|
||||
- phy-handle : See ethernet.txt file in the same directory
|
||||
|
||||
Slave sub-nodes:
|
||||
- fixed-link : See fixed-link.txt file in the same directory
|
||||
Either the property phy_id, or the sub-node
|
||||
fixed-link can be specified
|
||||
|
||||
Note: Exactly one of phy_id, phy-handle, or fixed-link must be specified.
|
||||
|
||||
Note: "ti,hwmods" field is used to fetch the base address and irq
|
||||
resources from TI, omap hwmod data base during device registration.
|
||||
|
||||
@@ -9,7 +9,8 @@ have dual GMAC each represented by a child node..
|
||||
Required properties:
|
||||
- compatible: Should be "mediatek,mt7623-eth"
|
||||
- reg: Address and length of the register set for the device
|
||||
- interrupts: Should contain the frame engines interrupt
|
||||
- interrupts: Should contain the three frame engines interrupts in numeric
|
||||
order. These are fe_int0, fe_int1 and fe_int2.
|
||||
- clocks: the clock used by the core
|
||||
- clock-names: the names of the clock listed in the clocks property. These are
|
||||
"ethif", "esw", "gp2", "gp1"
|
||||
@@ -42,7 +43,9 @@ eth: ethernet@1b100000 {
|
||||
<ðsys CLK_ETHSYS_GP2>,
|
||||
<ðsys CLK_ETHSYS_GP1>;
|
||||
clock-names = "ethif", "esw", "gp2", "gp1";
|
||||
interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_LOW>;
|
||||
interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_LOW
|
||||
GIC_SPI 199 IRQ_TYPE_LEVEL_LOW
|
||||
GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>;
|
||||
power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
|
||||
resets = <ðsys MT2701_ETHSYS_ETH_RST>;
|
||||
reset-names = "eth";
|
||||
|
||||
@@ -8,15 +8,19 @@ Required properties:
|
||||
of memory mapped region.
|
||||
- clock-names: from common clock binding:
|
||||
Required elements: "24m"
|
||||
- rockchip,grf: phandle to the syscon managing the "general register files"
|
||||
- #phy-cells : from the generic PHY bindings, must be 0;
|
||||
|
||||
Example:
|
||||
|
||||
edp_phy: edp-phy {
|
||||
compatible = "rockchip,rk3288-dp-phy";
|
||||
rockchip,grf = <&grf>;
|
||||
clocks = <&cru SCLK_EDP_24M>;
|
||||
clock-names = "24m";
|
||||
#phy-cells = <0>;
|
||||
grf: syscon@ff770000 {
|
||||
compatible = "rockchip,rk3288-grf", "syscon", "simple-mfd";
|
||||
|
||||
...
|
||||
|
||||
edp_phy: edp-phy {
|
||||
compatible = "rockchip,rk3288-dp-phy";
|
||||
clocks = <&cru SCLK_EDP_24M>;
|
||||
clock-names = "24m";
|
||||
#phy-cells = <0>;
|
||||
};
|
||||
};
|
||||
|
||||
@@ -3,17 +3,23 @@ Rockchip EMMC PHY
|
||||
|
||||
Required properties:
|
||||
- compatible: rockchip,rk3399-emmc-phy
|
||||
- rockchip,grf : phandle to the syscon managing the "general
|
||||
register files"
|
||||
- #phy-cells: must be 0
|
||||
- reg: PHY configure reg address offset in "general
|
||||
- reg: PHY register address offset and length in "general
|
||||
register files"
|
||||
|
||||
Example:
|
||||
|
||||
emmcphy: phy {
|
||||
compatible = "rockchip,rk3399-emmc-phy";
|
||||
rockchip,grf = <&grf>;
|
||||
reg = <0xf780>;
|
||||
#phy-cells = <0>;
|
||||
|
||||
grf: syscon@ff770000 {
|
||||
compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
...
|
||||
|
||||
emmcphy: phy@f780 {
|
||||
compatible = "rockchip,rk3399-emmc-phy";
|
||||
reg = <0xf780 0x20>;
|
||||
#phy-cells = <0>;
|
||||
};
|
||||
};
|
||||
|
||||
@@ -1,13 +1,16 @@
|
||||
== Amlogic Meson pinmux controller ==
|
||||
|
||||
Required properties for the root node:
|
||||
- compatible: "amlogic,meson8-pinctrl" or "amlogic,meson8b-pinctrl"
|
||||
- compatible: one of "amlogic,meson8-cbus-pinctrl"
|
||||
"amlogic,meson8b-cbus-pinctrl"
|
||||
"amlogic,meson8-aobus-pinctrl"
|
||||
"amlogic,meson8b-aobus-pinctrl"
|
||||
- reg: address and size of registers controlling irq functionality
|
||||
|
||||
=== GPIO sub-nodes ===
|
||||
|
||||
The 2 power domains of the controller (regular and always-on) are
|
||||
represented as sub-nodes and each of them acts as a GPIO controller.
|
||||
The GPIO bank for the controller is represented as a sub-node and it acts as a
|
||||
GPIO controller.
|
||||
|
||||
Required properties for sub-nodes are:
|
||||
- reg: should contain address and size for mux, pull-enable, pull and
|
||||
@@ -18,10 +21,6 @@ Required properties for sub-nodes are:
|
||||
- gpio-controller: identifies the node as a gpio controller
|
||||
- #gpio-cells: must be 2
|
||||
|
||||
Valid sub-node names are:
|
||||
- "banks" for the regular domain
|
||||
- "ao-bank" for the always-on domain
|
||||
|
||||
=== Other sub-nodes ===
|
||||
|
||||
Child nodes without the "gpio-controller" represent some desired
|
||||
@@ -45,7 +44,7 @@ pinctrl-bindings.txt
|
||||
=== Example ===
|
||||
|
||||
pinctrl: pinctrl@c1109880 {
|
||||
compatible = "amlogic,meson8-pinctrl";
|
||||
compatible = "amlogic,meson8-cbus-pinctrl";
|
||||
reg = <0xc1109880 0x10>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
@@ -61,15 +60,6 @@ pinctrl-bindings.txt
|
||||
#gpio-cells = <2>;
|
||||
};
|
||||
|
||||
gpio_ao: ao-bank@c1108030 {
|
||||
reg = <0xc8100014 0x4>,
|
||||
<0xc810002c 0x4>,
|
||||
<0xc8100024 0x8>;
|
||||
reg-names = "mux", "pull", "gpio";
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
};
|
||||
|
||||
nand {
|
||||
mux {
|
||||
groups = "nand_io", "nand_io_ce0", "nand_io_ce1",
|
||||
@@ -79,18 +69,4 @@ pinctrl-bindings.txt
|
||||
function = "nand";
|
||||
};
|
||||
};
|
||||
|
||||
uart_ao_a {
|
||||
mux {
|
||||
groups = "uart_tx_ao_a", "uart_rx_ao_a",
|
||||
"uart_cts_ao_a", "uart_rts_ao_a";
|
||||
function = "uart_ao";
|
||||
};
|
||||
|
||||
conf {
|
||||
pins = "GPIOAO_0", "GPIOAO_1",
|
||||
"GPIOAO_2", "GPIOAO_3";
|
||||
bias-disable;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
@@ -15,9 +15,10 @@ Required properties:
|
||||
is the rtc tick interrupt. The number of cells representing a interrupt
|
||||
depends on the parent interrupt controller.
|
||||
- clocks: Must contain a list of phandle and clock specifier for the rtc
|
||||
and source clocks.
|
||||
- clock-names: Must contain "rtc" and "rtc_src" entries sorted in the
|
||||
same order as the clocks property.
|
||||
clock and in the case of a s3c6410 compatible controller, also
|
||||
a source clock.
|
||||
- clock-names: Must contain "rtc" and for a s3c6410 compatible controller,
|
||||
a "rtc_src" sorted in the same order as the clocks property.
|
||||
|
||||
Example:
|
||||
|
||||
|
||||
@@ -173,6 +173,10 @@ A few EV_ABS codes have special meanings:
|
||||
proximity of the device and while the value of the BTN_TOUCH code is 0. If
|
||||
the input device may be used freely in three dimensions, consider ABS_Z
|
||||
instead.
|
||||
- BTN_TOOL_<name> should be set to 1 when the tool comes into detectable
|
||||
proximity and set to 0 when the tool leaves detectable proximity.
|
||||
BTN_TOOL_<name> signals the type of tool that is currently detected by the
|
||||
hardware and is otherwise independent of ABS_DISTANCE and/or BTN_TOUCH.
|
||||
|
||||
* ABS_MT_<name>:
|
||||
- Used to describe multitouch input events. Please see
|
||||
|
||||
@@ -4077,6 +4077,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
sector if the number is odd);
|
||||
i = IGNORE_DEVICE (don't bind to this
|
||||
device);
|
||||
j = NO_REPORT_LUNS (don't use report luns
|
||||
command, uas only);
|
||||
l = NOT_LOCKABLE (don't try to lock and
|
||||
unlock ejectable media);
|
||||
m = MAX_SECTORS_64 (don't transfer more
|
||||
|
||||
@@ -6,7 +6,7 @@ This is the driver for the Altera Triple-Speed Ethernet (TSE) controllers
|
||||
using the SGDMA and MSGDMA soft DMA IP components. The driver uses the
|
||||
platform bus to obtain component resources. The designs used to test this
|
||||
driver were built for a Cyclone(R) V SOC FPGA board, a Cyclone(R) V FPGA board,
|
||||
and tested with ARM and NIOS processor hosts seperately. The anticipated use
|
||||
and tested with ARM and NIOS processor hosts separately. The anticipated use
|
||||
cases are simple communications between an embedded system and an external peer
|
||||
for status and simple configuration of the embedded system.
|
||||
|
||||
@@ -65,14 +65,14 @@ Driver parameters can be also passed in command line by using:
|
||||
4.1) Transmit process
|
||||
When the driver's transmit routine is called by the kernel, it sets up a
|
||||
transmit descriptor by calling the underlying DMA transmit routine (SGDMA or
|
||||
MSGDMA), and initites a transmit operation. Once the transmit is complete, an
|
||||
MSGDMA), and initiates a transmit operation. Once the transmit is complete, an
|
||||
interrupt is driven by the transmit DMA logic. The driver handles the transmit
|
||||
completion in the context of the interrupt handling chain by recycling
|
||||
resource required to send and track the requested transmit operation.
|
||||
|
||||
4.2) Receive process
|
||||
The driver will post receive buffers to the receive DMA logic during driver
|
||||
intialization. Receive buffers may or may not be queued depending upon the
|
||||
initialization. Receive buffers may or may not be queued depending upon the
|
||||
underlying DMA logic (MSGDMA is able queue receive buffers, SGDMA is not able
|
||||
to queue receive buffers to the SGDMA receive logic). When a packet is
|
||||
received, the DMA logic generates an interrupt. The driver handles a receive
|
||||
|
||||
@@ -8,7 +8,7 @@ Initial Release:
|
||||
This is conceptually very similar to the macvlan driver with one major
|
||||
exception of using L3 for mux-ing /demux-ing among slaves. This property makes
|
||||
the master device share the L2 with it's slave devices. I have developed this
|
||||
driver in conjuntion with network namespaces and not sure if there is use case
|
||||
driver in conjunction with network namespaces and not sure if there is use case
|
||||
outside of it.
|
||||
|
||||
|
||||
@@ -42,7 +42,7 @@ out. In this mode the slaves will RX/TX multicast and broadcast (if applicable)
|
||||
as well.
|
||||
|
||||
4.2 L3 mode:
|
||||
In this mode TX processing upto L3 happens on the stack instance attached
|
||||
In this mode TX processing up to L3 happens on the stack instance attached
|
||||
to the slave device and packets are switched to the stack instance of the
|
||||
master device for the L2 processing and routing from that instance will be
|
||||
used before packets are queued on the outbound device. In this mode the slaves
|
||||
@@ -56,7 +56,7 @@ situations defines your use case then you can choose to use ipvlan -
|
||||
(a) The Linux host that is connected to the external switch / router has
|
||||
policy configured that allows only one mac per port.
|
||||
(b) No of virtual devices created on a master exceed the mac capacity and
|
||||
puts the NIC in promiscous mode and degraded performance is a concern.
|
||||
puts the NIC in promiscuous mode and degraded performance is a concern.
|
||||
(c) If the slave device is to be put into the hostile / untrusted network
|
||||
namespace where L2 on the slave could be changed / misused.
|
||||
|
||||
|
||||
@@ -67,12 +67,12 @@ The two basic thread commands are:
|
||||
* add_device DEVICE@NAME -- adds a single device
|
||||
* rem_device_all -- remove all associated devices
|
||||
|
||||
When adding a device to a thread, a corrosponding procfile is created
|
||||
When adding a device to a thread, a corresponding procfile is created
|
||||
which is used for configuring this device. Thus, device names need to
|
||||
be unique.
|
||||
|
||||
To support adding the same device to multiple threads, which is useful
|
||||
with multi queue NICs, a the device naming scheme is extended with "@":
|
||||
with multi queue NICs, the device naming scheme is extended with "@":
|
||||
device@something
|
||||
|
||||
The part after "@" can be anything, but it is custom to use the thread
|
||||
@@ -221,7 +221,7 @@ Sample scripts
|
||||
|
||||
A collection of tutorial scripts and helpers for pktgen is in the
|
||||
samples/pktgen directory. The helper parameters.sh file support easy
|
||||
and consistant parameter parsing across the sample scripts.
|
||||
and consistent parameter parsing across the sample scripts.
|
||||
|
||||
Usage example and help:
|
||||
./pktgen_sample01_simple.sh -i eth4 -m 00:1B:21:3C:9D:F8 -d 192.168.8.2
|
||||
|
||||
@@ -41,7 +41,7 @@ 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
|
||||
VRF as a whole.[1] Similarly, 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
|
||||
|
||||
@@ -4,7 +4,7 @@ Krisztian <hidden@balabit.hu> and others and additional patches
|
||||
from Jamal <hadi@cyberus.ca>.
|
||||
|
||||
The end goal for syncing is to be able to insert attributes + generate
|
||||
events so that the an SA can be safely moved from one machine to another
|
||||
events so that the SA can be safely moved from one machine to another
|
||||
for HA purposes.
|
||||
The idea is to synchronize the SA so that the takeover machine can do
|
||||
the processing of the SA as accurate as possible if it has access to it.
|
||||
@@ -13,7 +13,7 @@ We already have the ability to generate SA add/del/upd events.
|
||||
These patches add ability to sync and have accurate lifetime byte (to
|
||||
ensure proper decay of SAs) and replay counters to avoid replay attacks
|
||||
with as minimal loss at failover time.
|
||||
This way a backup stays as closely uptodate as an active member.
|
||||
This way a backup stays as closely up-to-date as an active member.
|
||||
|
||||
Because the above items change for every packet the SA receives,
|
||||
it is possible for a lot of the events to be generated.
|
||||
@@ -163,7 +163,7 @@ If you have an SA that is getting hit by traffic in bursts such that
|
||||
there is a period where the timer threshold expires with no packets
|
||||
seen, then an odd behavior is seen as follows:
|
||||
The first packet arrival after a timer expiry will trigger a timeout
|
||||
aevent; i.e we dont wait for a timeout period or a packet threshold
|
||||
event; i.e we don't wait for a timeout period or a packet threshold
|
||||
to be reached. This is done for simplicity and efficiency reasons.
|
||||
|
||||
-JHS
|
||||
|
||||
@@ -581,15 +581,16 @@ Specify "[Nn]ode" for node order
|
||||
"Zone Order" orders the zonelists by zone type, then by node within each
|
||||
zone. Specify "[Zz]one" for zone order.
|
||||
|
||||
Specify "[Dd]efault" to request automatic configuration. Autoconfiguration
|
||||
will select "node" order in following case.
|
||||
(1) if the DMA zone does not exist or
|
||||
(2) if the DMA zone comprises greater than 50% of the available memory or
|
||||
(3) if any node's DMA zone comprises greater than 70% of its local memory and
|
||||
the amount of local memory is big enough.
|
||||
Specify "[Dd]efault" to request automatic configuration.
|
||||
|
||||
Otherwise, "zone" order will be selected. Default order is recommended unless
|
||||
this is causing problems for your system/application.
|
||||
On 32-bit, the Normal zone needs to be preserved for allocations accessible
|
||||
by the kernel, so "zone" order will be selected.
|
||||
|
||||
On 64-bit, devices that require DMA32/DMA are relatively rare, so "node"
|
||||
order will be selected.
|
||||
|
||||
Default order is recommended unless this is causing problems for your
|
||||
system/application.
|
||||
|
||||
==============================================================
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user