Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
Conflicts: drivers/net/ethernet/emulex/benet/be_main.c net/core/sysctl_net_core.c net/ipv4/inet_diag.c The be_main.c conflict resolution was really tricky. The conflict hunks generated by GIT were very unhelpful, to say the least. It split functions in half and moved them around, when the real actual conflict only existed solely inside of one function, that being be_map_pci_bars(). So instead, to resolve this, I checked out be_main.c from the top of net-next, then I applied the be_main.c changes from 'net' since the last time I merged. And this worked beautifully. The inet_diag.c and sysctl_net_core.c conflicts were simple overlapping changes, and were easily to resolve. Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
@@ -22,6 +22,8 @@ Optional Properties:
|
||||
- pclkN, clkN: Pairs of parent of input clock and input clock to the
|
||||
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
|
||||
are supported currently.
|
||||
- power-domains: phandle pointing to the parent power domain, for more details
|
||||
see Documentation/devicetree/bindings/power/power_domain.txt
|
||||
|
||||
Node of a device using power domains must have a power-domains property
|
||||
defined with a phandle to respective power domain.
|
||||
|
@@ -13,6 +13,10 @@ Boards with the ST STiH407 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,stih407";
|
||||
|
||||
Boards with the ST STiH410 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,stih410";
|
||||
|
||||
Boards with the ST STiH418 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible = "st,stih418";
|
||||
|
@@ -19,6 +19,16 @@ Required properties:
|
||||
providing multiple PM domains (e.g. power controllers), but can be any value
|
||||
as specified by device tree binding documentation of particular provider.
|
||||
|
||||
Optional properties:
|
||||
- power-domains : A phandle and PM domain specifier as defined by bindings of
|
||||
the power controller specified by phandle.
|
||||
Some power domains might be powered from another power domain (or have
|
||||
other hardware specific dependencies). For representing such dependency
|
||||
a standard PM domain consumer binding is used. When provided, all domains
|
||||
created by the given provider should be subdomains of the domain
|
||||
specified by this binding. More details about power domain specifier are
|
||||
available in the next section.
|
||||
|
||||
Example:
|
||||
|
||||
power: power-controller@12340000 {
|
||||
@@ -30,6 +40,25 @@ Example:
|
||||
The node above defines a power controller that is a PM domain provider and
|
||||
expects one cell as its phandle argument.
|
||||
|
||||
Example 2:
|
||||
|
||||
parent: power-controller@12340000 {
|
||||
compatible = "foo,power-controller";
|
||||
reg = <0x12340000 0x1000>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
child: power-controller@12340000 {
|
||||
compatible = "foo,power-controller";
|
||||
reg = <0x12341000 0x1000>;
|
||||
power-domains = <&parent 0>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
The nodes above define two power controllers: 'parent' and 'child'.
|
||||
Domains created by the 'child' power controller are subdomains of '0' power
|
||||
domain provided by the 'parent' power controller.
|
||||
|
||||
==PM domain consumers==
|
||||
|
||||
Required properties:
|
||||
|
@@ -0,0 +1,19 @@
|
||||
ETRAX FS UART
|
||||
|
||||
Required properties:
|
||||
- compatible : "axis,etraxfs-uart"
|
||||
- reg: offset and length of the register set for the device.
|
||||
- interrupts: device interrupt
|
||||
|
||||
Optional properties:
|
||||
- {dtr,dsr,ri,cd}-gpios: specify a GPIO for DTR/DSR/RI/CD
|
||||
line respectively.
|
||||
|
||||
Example:
|
||||
|
||||
serial@b00260000 {
|
||||
compatible = "axis,etraxfs-uart";
|
||||
reg = <0xb0026000 0x1000>;
|
||||
interrupts = <68>;
|
||||
status = "disabled";
|
||||
};
|
@@ -12,6 +12,9 @@ I. For patch submitters
|
||||
|
||||
devicetree@vger.kernel.org
|
||||
|
||||
and Cc: the DT maintainers. Use scripts/get_maintainer.pl to identify
|
||||
all of the DT maintainers.
|
||||
|
||||
3) The Documentation/ portion of the patch should come in the series before
|
||||
the code implementing the binding.
|
||||
|
||||
|
@@ -20,6 +20,7 @@ amlogic Amlogic, Inc.
|
||||
ams AMS AG
|
||||
amstaos AMS-Taos Inc.
|
||||
apm Applied Micro Circuits Corporation (APM)
|
||||
arasan Arasan Chip Systems
|
||||
arm ARM Ltd.
|
||||
armadeus ARMadeus Systems SARL
|
||||
asahi-kasei Asahi Kasei Corp.
|
||||
@@ -27,6 +28,7 @@ atmel Atmel Corporation
|
||||
auo AU Optronics Corporation
|
||||
avago Avago Technologies
|
||||
avic Shanghai AVIC Optoelectronics Co., Ltd.
|
||||
axis Axis Communications AB
|
||||
bosch Bosch Sensortec GmbH
|
||||
brcm Broadcom Corporation
|
||||
buffalo Buffalo, Inc.
|
||||
|
@@ -26,6 +26,11 @@ Optional properties:
|
||||
- atmel,disable : Should be present if you want to disable the watchdog.
|
||||
- atmel,idle-halt : Should be present if you want to stop the watchdog when
|
||||
entering idle state.
|
||||
CAUTION: This property should be used with care, it actually makes the
|
||||
watchdog not counting when the CPU is in idle state, therefore the
|
||||
watchdog reset time depends on mean CPU usage and will not reset at all
|
||||
if the CPU stop working while it is in idle state, which is probably
|
||||
not what you want.
|
||||
- atmel,dbg-halt : Should be present if you want to stop the watchdog when
|
||||
entering debug state.
|
||||
|
||||
|
Reference in New Issue
Block a user