forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
Conflicts: arch/arm/boot/dts/imx6sx-sdb.dts net/sched/cls_bpf.c Two simple sets of overlapping changes. Signed-off-by: David S. Miller <[email protected]>
- Loading branch information
Showing
457 changed files
with
4,418 additions
and
3,193 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,3 +14,18 @@ Description: | |
The /sys/class/mei/meiN directory is created for | ||
each probed mei device | ||
|
||
What: /sys/class/mei/meiN/fw_status | ||
Date: Nov 2014 | ||
KernelVersion: 3.19 | ||
Contact: Tomas Winkler <[email protected]> | ||
Description: Display fw status registers content | ||
|
||
The ME FW writes its status information into fw status | ||
registers for BIOS and OS to monitor fw health. | ||
|
||
The register contains running state, power management | ||
state, error codes, and others. The way the registers | ||
are decoded depends on PCH or SoC generation. | ||
Also number of registers varies between 1 and 6 | ||
depending on generation. | ||
|
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,72 @@ | ||
* QEMU Firmware Configuration bindings for ARM | ||
|
||
QEMU's arm-softmmu and aarch64-softmmu emulation / virtualization targets | ||
provide the following Firmware Configuration interface on the "virt" machine | ||
type: | ||
|
||
- A write-only, 16-bit wide selector (or control) register, | ||
- a read-write, 64-bit wide data register. | ||
|
||
QEMU exposes the control and data register to ARM guests as memory mapped | ||
registers; their location is communicated to the guest's UEFI firmware in the | ||
DTB that QEMU places at the bottom of the guest's DRAM. | ||
|
||
The guest writes a selector value (a key) to the selector register, and then | ||
can read the corresponding data (produced by QEMU) via the data register. If | ||
the selected entry is writable, the guest can rewrite it through the data | ||
register. | ||
|
||
The selector register takes keys in big endian byte order. | ||
|
||
The data register allows accesses with 8, 16, 32 and 64-bit width (only at | ||
offset 0 of the register). Accesses larger than a byte are interpreted as | ||
arrays, bundled together only for better performance. The bytes constituting | ||
such a word, in increasing address order, correspond to the bytes that would | ||
have been transferred by byte-wide accesses in chronological order. | ||
|
||
The interface allows guest firmware to download various parameters and blobs | ||
that affect how the firmware works and what tables it installs for the guest | ||
OS. For example, boot order of devices, ACPI tables, SMBIOS tables, kernel and | ||
initrd images for direct kernel booting, virtual machine UUID, SMP information, | ||
virtual NUMA topology, and so on. | ||
|
||
The authoritative registry of the valid selector values and their meanings is | ||
the QEMU source code; the structure of the data blobs corresponding to the | ||
individual key values is also defined in the QEMU source code. | ||
|
||
The presence of the registers can be verified by selecting the "signature" blob | ||
with key 0x0000, and reading four bytes from the data register. The returned | ||
signature is "QEMU". | ||
|
||
The outermost protocol (involving the write / read sequences of the control and | ||
data registers) is expected to be versioned, and/or described by feature bits. | ||
The interface revision / feature bitmap can be retrieved with key 0x0001. The | ||
blob to be read from the data register has size 4, and it is to be interpreted | ||
as a uint32_t value in little endian byte order. The current value | ||
(corresponding to the above outer protocol) is zero. | ||
|
||
The guest kernel is not expected to use these registers (although it is | ||
certainly allowed to); the device tree bindings are documented here because | ||
this is where device tree bindings reside in general. | ||
|
||
Required properties: | ||
|
||
- compatible: "qemu,fw-cfg-mmio". | ||
|
||
- reg: the MMIO region used by the device. | ||
* Bytes 0x0 to 0x7 cover the data register. | ||
* Bytes 0x8 to 0x9 cover the selector register. | ||
* Further registers may be appended to the region in case of future interface | ||
revisions / feature bits. | ||
|
||
Example: | ||
|
||
/ { | ||
#size-cells = <0x2>; | ||
#address-cells = <0x2>; | ||
|
||
fw-cfg@9020000 { | ||
compatible = "qemu,fw-cfg-mmio"; | ||
reg = <0x0 0x9020000 0x0 0xa>; | ||
}; | ||
}; |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3,7 +3,7 @@ CPU cooling APIs How To | |
|
||
Written by Amit Daniel Kachhap <[email protected]> | ||
|
||
Updated: 12 May 2012 | ||
Updated: 6 Jan 2015 | ||
|
||
Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) | ||
|
||
|
@@ -25,7 +25,18 @@ the user. The registration APIs returns the cooling device pointer. | |
|
||
clip_cpus: cpumask of cpus where the frequency constraints will happen. | ||
|
||
1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) | ||
1.1.2 struct thermal_cooling_device *of_cpufreq_cooling_register( | ||
struct device_node *np, const struct cpumask *clip_cpus) | ||
|
||
This interface function registers the cpufreq cooling device with | ||
the name "thermal-cpufreq-%x" linking it with a device tree node, in | ||
order to bind it via the thermal DT code. This api can support multiple | ||
instances of cpufreq cooling devices. | ||
|
||
np: pointer to the cooling device device tree node | ||
clip_cpus: cpumask of cpus where the frequency constraints will happen. | ||
|
||
1.1.3 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) | ||
|
||
This interface function unregisters the "thermal-cpufreq-%x" cooling device. | ||
|
||
|
Oops, something went wrong.