mirror of
https://github.com/armbian/linux.git
synced 2026-01-06 10:13:00 -08:00
Merge with upstream to accommodate with thermal changes
This merge is performed to take commit c56f5c0342 ("Thermal: Make
Thermal trip points writeable") out of Linus' tree and then fixup power
supply class. This is needed since thermal stuff added a new argument:
CC drivers/power/power_supply_core.o
drivers/power/power_supply_core.c: In function ‘psy_register_thermal’:
drivers/power/power_supply_core.c:204:6: warning: passing argument 3 of ‘thermal_zone_device_register’ makes integer from pointer without a cast [enabled by default]
include/linux/thermal.h:154:29: note: expected ‘int’ but argument is of type ‘struct power_supply *’
drivers/power/power_supply_core.c:204:6: error: too few arguments to function ‘thermal_zone_device_register’
include/linux/thermal.h:154:29: note: declared here
make[1]: *** [drivers/power/power_supply_core.o] Error 1
make: *** [drivers/power/] Error 2
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
This commit is contained in:
Anton Vorontsov
1
.mailmap
1
.mailmap
@@ -111,6 +111,7 @@ Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
|
||||
Uwe Kleine-König <ukl@pengutronix.de>
|
||||
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
|
||||
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
|
||||
Viresh Kumar <viresh.linux@gmail.com> <viresh.kumar@st.com>
|
||||
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
|
||||
Yusuke Goda <goda.yusuke@renesas.com>
|
||||
Gustavo Padovan <gustavo@las.ic.unicamp.br>
|
||||
|
||||
@@ -1,26 +1,5 @@
|
||||
What: /sys/block/rssd*/registers
|
||||
Date: March 2012
|
||||
KernelVersion: 3.3
|
||||
Contact: Asai Thambi S P <asamymuthupa@micron.com>
|
||||
Description: This is a read-only file. Dumps below driver information and
|
||||
hardware registers.
|
||||
- S ACTive
|
||||
- Command Issue
|
||||
- Completed
|
||||
- PORT IRQ STAT
|
||||
- HOST IRQ STAT
|
||||
- Allocated
|
||||
- Commands in Q
|
||||
|
||||
What: /sys/block/rssd*/status
|
||||
Date: April 2012
|
||||
KernelVersion: 3.4
|
||||
Contact: Asai Thambi S P <asamymuthupa@micron.com>
|
||||
Description: This is a read-only file. Indicates the status of the device.
|
||||
|
||||
What: /sys/block/rssd*/flags
|
||||
Date: May 2012
|
||||
KernelVersion: 3.5
|
||||
Contact: Asai Thambi S P <asamymuthupa@micron.com>
|
||||
Description: This is a read-only file. Dumps the flags in port and driver
|
||||
data structure
|
||||
|
||||
@@ -219,6 +219,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_peak_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_scale
|
||||
@@ -273,6 +274,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_accel_scale_available
|
||||
What: /sys/.../iio:deviceX/in_voltageX_scale_available
|
||||
What: /sys/.../iio:deviceX/in_voltage-voltage_scale_available
|
||||
What: /sys/.../iio:deviceX/out_voltageX_scale_available
|
||||
What: /sys/.../iio:deviceX/out_altvoltageX_scale_available
|
||||
What: /sys/.../iio:deviceX/in_capacitance_scale_available
|
||||
KernelVersion: 2.635
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
@@ -298,14 +300,19 @@ Description:
|
||||
gives the 3dB frequency of the filter in Hz.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_raw
|
||||
KernelVersion: 2.6.37
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Raw (unscaled, no bias etc.) output voltage for
|
||||
channel Y. The number must always be specified and
|
||||
unique if the output corresponds to a single channel.
|
||||
While DAC like devices typically use out_voltage,
|
||||
a continuous frequency generating device, such as
|
||||
a DDS or PLL should use out_altvoltage.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY&Z_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY&Z_raw
|
||||
KernelVersion: 2.6.37
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
@@ -316,6 +323,8 @@ Description:
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_powerdown_mode
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_voltage_powerdown_mode
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_powerdown_mode
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltage_powerdown_mode
|
||||
KernelVersion: 2.6.38
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
@@ -330,6 +339,8 @@ Description:
|
||||
|
||||
What: /sys/.../iio:deviceX/out_votlageY_powerdown_mode_available
|
||||
What: /sys/.../iio:deviceX/out_voltage_powerdown_mode_available
|
||||
What: /sys/.../iio:deviceX/out_altvotlageY_powerdown_mode_available
|
||||
What: /sys/.../iio:deviceX/out_altvoltage_powerdown_mode_available
|
||||
KernelVersion: 2.6.38
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
@@ -338,6 +349,8 @@ Description:
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_powerdown
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_voltage_powerdown
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_powerdown
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltage_powerdown
|
||||
KernelVersion: 2.6.38
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
@@ -346,6 +359,24 @@ Description:
|
||||
normal operation. Y may be suppressed if all outputs are
|
||||
controlled together.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency
|
||||
KernelVersion: 3.4.0
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Output frequency for channel Y in Hz. The number must always be
|
||||
specified and unique if the output corresponds to a single
|
||||
channel.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_phase
|
||||
KernelVersion: 3.4.0
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Phase in radians of one frequency/clock output Y
|
||||
(out_altvoltageY) relative to another frequency/clock output
|
||||
(out_altvoltageZ) of the device X. The number must always be
|
||||
specified and unique if the output corresponds to a single
|
||||
channel.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/events
|
||||
KernelVersion: 2.6.35
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
|
||||
@@ -142,13 +142,14 @@ KernelVersion: 3.4
|
||||
Contact: linux-mtd@lists.infradead.org
|
||||
Description:
|
||||
This allows the user to examine and adjust the criteria by which
|
||||
mtd returns -EUCLEAN from mtd_read(). If the maximum number of
|
||||
bit errors that were corrected on any single region comprising
|
||||
an ecc step (as reported by the driver) equals or exceeds this
|
||||
value, -EUCLEAN is returned. Otherwise, absent an error, 0 is
|
||||
returned. Higher layers (e.g., UBI) use this return code as an
|
||||
indication that an erase block may be degrading and should be
|
||||
scrutinized as a candidate for being marked as bad.
|
||||
mtd returns -EUCLEAN from mtd_read() and mtd_read_oob(). If the
|
||||
maximum number of bit errors that were corrected on any single
|
||||
region comprising an ecc step (as reported by the driver) equals
|
||||
or exceeds this value, -EUCLEAN is returned. Otherwise, absent
|
||||
an error, 0 is returned. Higher layers (e.g., UBI) use this
|
||||
return code as an indication that an erase block may be
|
||||
degrading and should be scrutinized as a candidate for being
|
||||
marked as bad.
|
||||
|
||||
The initial value may be specified by the flash device driver.
|
||||
If not, then the default value is ecc_strength.
|
||||
@@ -167,7 +168,7 @@ Description:
|
||||
block degradation, but high enough to avoid the consequences of
|
||||
a persistent return value of -EUCLEAN on devices where sticky
|
||||
bitflips occur. Note that if bitflip_threshold exceeds
|
||||
ecc_strength, -EUCLEAN is never returned by mtd_read().
|
||||
ecc_strength, -EUCLEAN is never returned by the read operations.
|
||||
Conversely, if bitflip_threshold is zero, -EUCLEAN is always
|
||||
returned, absent a hard error.
|
||||
|
||||
|
||||
@@ -3988,7 +3988,7 @@ interface and may change in the future.</para>
|
||||
from RGB to Y'CbCr color space.
|
||||
</entry>
|
||||
</row>
|
||||
<row id = "v4l2-jpeg-chroma-subsampling">
|
||||
<row>
|
||||
<entrytbl spanname="descr" cols="2">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
|
||||
@@ -986,13 +986,13 @@ http://www.thedirks.org/winnov/</ulink></para></entry>
|
||||
<row id="V4L2-PIX-FMT-Y4">
|
||||
<entry><constant>V4L2_PIX_FMT_Y4</constant></entry>
|
||||
<entry>'Y04 '</entry>
|
||||
<entry>Old 4-bit greyscale format. Only the least significant 4 bits of each byte are used,
|
||||
<entry>Old 4-bit greyscale format. Only the most significant 4 bits of each byte are used,
|
||||
the other bits are set to 0.</entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-Y6">
|
||||
<entry><constant>V4L2_PIX_FMT_Y6</constant></entry>
|
||||
<entry>'Y06 '</entry>
|
||||
<entry>Old 6-bit greyscale format. Only the least significant 6 bits of each byte are used,
|
||||
<entry>Old 6-bit greyscale format. Only the most significant 6 bits of each byte are used,
|
||||
the other bits are set to 0.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
|
||||
@@ -560,6 +560,7 @@ and discussions on the V4L mailing list.</revremark>
|
||||
&sub-g-tuner;
|
||||
&sub-log-status;
|
||||
&sub-overlay;
|
||||
&sub-prepare-buf;
|
||||
&sub-qbuf;
|
||||
&sub-querybuf;
|
||||
&sub-querycap;
|
||||
@@ -567,7 +568,6 @@ and discussions on the V4L mailing list.</revremark>
|
||||
&sub-query-dv-preset;
|
||||
&sub-query-dv-timings;
|
||||
&sub-querystd;
|
||||
&sub-prepare-buf;
|
||||
&sub-reqbufs;
|
||||
&sub-s-hw-freq-seek;
|
||||
&sub-streamon;
|
||||
|
||||
@@ -108,10 +108,9 @@ information.</para>
|
||||
/></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry>struct v4l2_format</entry>
|
||||
<entry><structfield>format</structfield></entry>
|
||||
<entry>Filled in by the application, preserved by the driver.
|
||||
See <xref linkend="v4l2-format" />.</entry>
|
||||
<entry>Filled in by the application, preserved by the driver.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
||||
@@ -89,7 +89,7 @@
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>&v4l2-event-frame-sync;</entry>
|
||||
<entry><structfield>frame</structfield></entry>
|
||||
<entry><structfield>frame_sync</structfield></entry>
|
||||
<entry>Event data for event V4L2_EVENT_FRAME_SYNC.</entry>
|
||||
</row>
|
||||
<row>
|
||||
|
||||
@@ -284,13 +284,6 @@ These controls are described in <xref
|
||||
processing controls. These controls are described in <xref
|
||||
linkend="image-process-controls" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CTRL_CLASS_JPEG</constant></entry>
|
||||
<entry>0x9d0000</entry>
|
||||
<entry>The class containing JPEG compression controls.
|
||||
These controls are described in <xref
|
||||
linkend="jpeg-controls" />.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
@@ -60,4 +60,4 @@ Introduction
|
||||
Document Author
|
||||
---------------
|
||||
|
||||
Viresh Kumar <viresh.kumar@st.com>, (c) 2010-2012 ST Microelectronics
|
||||
Viresh Kumar <viresh.linux@gmail.com>, (c) 2010-2012 ST Microelectronics
|
||||
|
||||
@@ -7,39 +7,39 @@ This target is read-only.
|
||||
|
||||
Construction Parameters
|
||||
=======================
|
||||
<version> <dev> <hash_dev> <hash_start>
|
||||
<version> <dev> <hash_dev>
|
||||
<data_block_size> <hash_block_size>
|
||||
<num_data_blocks> <hash_start_block>
|
||||
<algorithm> <digest> <salt>
|
||||
|
||||
<version>
|
||||
This is the version number of the on-disk format.
|
||||
This is the type of the on-disk hash format.
|
||||
|
||||
0 is the original format used in the Chromium OS.
|
||||
The salt is appended when hashing, digests are stored continuously and
|
||||
the rest of the block is padded with zeros.
|
||||
The salt is appended when hashing, digests are stored continuously and
|
||||
the rest of the block is padded with zeros.
|
||||
|
||||
1 is the current format that should be used for new devices.
|
||||
The salt is prepended when hashing and each digest is
|
||||
padded with zeros to the power of two.
|
||||
The salt is prepended when hashing and each digest is
|
||||
padded with zeros to the power of two.
|
||||
|
||||
<dev>
|
||||
This is the device containing the data the integrity of which needs to be
|
||||
This is the device containing data, the integrity of which needs to be
|
||||
checked. It may be specified as a path, like /dev/sdaX, or a device number,
|
||||
<major>:<minor>.
|
||||
|
||||
<hash_dev>
|
||||
This is the device that that supplies the hash tree data. It may be
|
||||
This is the device that supplies the hash tree data. It may be
|
||||
specified similarly to the device path and may be the same device. If the
|
||||
same device is used, the hash_start should be outside of the dm-verity
|
||||
configured device size.
|
||||
same device is used, the hash_start should be outside the configured
|
||||
dm-verity device.
|
||||
|
||||
<data_block_size>
|
||||
The block size on a data device. Each block corresponds to one digest on
|
||||
the hash device.
|
||||
The block size on a data device in bytes.
|
||||
Each block corresponds to one digest on the hash device.
|
||||
|
||||
<hash_block_size>
|
||||
The size of a hash block.
|
||||
The size of a hash block in bytes.
|
||||
|
||||
<num_data_blocks>
|
||||
The number of data blocks on the data device. Additional blocks are
|
||||
@@ -65,7 +65,7 @@ Construction Parameters
|
||||
Theory of operation
|
||||
===================
|
||||
|
||||
dm-verity is meant to be setup as part of a verified boot path. This
|
||||
dm-verity is meant to be set up as part of a verified boot path. This
|
||||
may be anything ranging from a boot using tboot or trustedgrub to just
|
||||
booting from a known-good device (like a USB drive or CD).
|
||||
|
||||
@@ -73,20 +73,20 @@ When a dm-verity device is configured, it is expected that the caller
|
||||
has been authenticated in some way (cryptographic signatures, etc).
|
||||
After instantiation, all hashes will be verified on-demand during
|
||||
disk access. If they cannot be verified up to the root node of the
|
||||
tree, the root hash, then the I/O will fail. This should identify
|
||||
tree, the root hash, then the I/O will fail. This should detect
|
||||
tampering with any data on the device and the hash data.
|
||||
|
||||
Cryptographic hashes are used to assert the integrity of the device on a
|
||||
per-block basis. This allows for a lightweight hash computation on first read
|
||||
into the page cache. Block hashes are stored linearly-aligned to the nearest
|
||||
block the size of a page.
|
||||
per-block basis. This allows for a lightweight hash computation on first read
|
||||
into the page cache. Block hashes are stored linearly, aligned to the nearest
|
||||
block size.
|
||||
|
||||
Hash Tree
|
||||
---------
|
||||
|
||||
Each node in the tree is a cryptographic hash. If it is a leaf node, the hash
|
||||
is of some block data on disk. If it is an intermediary node, then the hash is
|
||||
of a number of child nodes.
|
||||
of some data block on disk is calculated. If it is an intermediary node,
|
||||
the hash of a number of child nodes is calculated.
|
||||
|
||||
Each entry in the tree is a collection of neighboring nodes that fit in one
|
||||
block. The number is determined based on block_size and the size of the
|
||||
@@ -110,63 +110,23 @@ alg = sha256, num_blocks = 32768, block_size = 4096
|
||||
On-disk format
|
||||
==============
|
||||
|
||||
Below is the recommended on-disk format. The verity kernel code does not
|
||||
read the on-disk header. It only reads the hash blocks which directly
|
||||
follow the header. It is expected that a user-space tool will verify the
|
||||
integrity of the verity_header and then call dmsetup with the correct
|
||||
parameters. Alternatively, the header can be omitted and the dmsetup
|
||||
parameters can be passed via the kernel command-line in a rooted chain
|
||||
of trust where the command-line is verified.
|
||||
The verity kernel code does not read the verity metadata on-disk header.
|
||||
It only reads the hash blocks which directly follow the header.
|
||||
It is expected that a user-space tool will verify the integrity of the
|
||||
verity header.
|
||||
|
||||
The on-disk format is especially useful in cases where the hash blocks
|
||||
are on a separate partition. The magic number allows easy identification
|
||||
of the partition contents. Alternatively, the hash blocks can be stored
|
||||
in the same partition as the data to be verified. In such a configuration
|
||||
the filesystem on the partition would be sized a little smaller than
|
||||
the full-partition, leaving room for the hash blocks.
|
||||
|
||||
struct superblock {
|
||||
uint8_t signature[8]
|
||||
"verity\0\0";
|
||||
|
||||
uint8_t version;
|
||||
1 - current format
|
||||
|
||||
uint8_t data_block_bits;
|
||||
log2(data block size)
|
||||
|
||||
uint8_t hash_block_bits;
|
||||
log2(hash block size)
|
||||
|
||||
uint8_t pad1[1];
|
||||
zero padding
|
||||
|
||||
uint16_t salt_size;
|
||||
big-endian salt size
|
||||
|
||||
uint8_t pad2[2];
|
||||
zero padding
|
||||
|
||||
uint32_t data_blocks_hi;
|
||||
big-endian high 32 bits of the 64-bit number of data blocks
|
||||
|
||||
uint32_t data_blocks_lo;
|
||||
big-endian low 32 bits of the 64-bit number of data blocks
|
||||
|
||||
uint8_t algorithm[16];
|
||||
cryptographic algorithm
|
||||
|
||||
uint8_t salt[384];
|
||||
salt (the salt size is specified above)
|
||||
|
||||
uint8_t pad3[88];
|
||||
zero padding to 512-byte boundary
|
||||
}
|
||||
Alternatively, the header can be omitted and the dmsetup parameters can
|
||||
be passed via the kernel command-line in a rooted chain of trust where
|
||||
the command-line is verified.
|
||||
|
||||
Directly following the header (and with sector number padded to the next hash
|
||||
block boundary) are the hash blocks which are stored a depth at a time
|
||||
(starting from the root), sorted in order of increasing index.
|
||||
|
||||
The full specification of kernel parameters and on-disk metadata format
|
||||
is available at the cryptsetup project's wiki page
|
||||
http://code.google.com/p/cryptsetup/wiki/DMVerity
|
||||
|
||||
Status
|
||||
======
|
||||
V (for Valid) is returned if every check performed so far was valid.
|
||||
@@ -174,21 +134,22 @@ If any check failed, C (for Corruption) is returned.
|
||||
|
||||
Example
|
||||
=======
|
||||
|
||||
Setup a device:
|
||||
dmsetup create vroot --table \
|
||||
"0 2097152 "\
|
||||
"verity 1 /dev/sda1 /dev/sda2 4096 4096 2097152 1 "\
|
||||
Set up a device:
|
||||
# dmsetup create vroot --readonly --table \
|
||||
"0 2097152 verity 1 /dev/sda1 /dev/sda2 4096 4096 262144 1 sha256 "\
|
||||
"4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 "\
|
||||
"1234000000000000000000000000000000000000000000000000000000000000"
|
||||
|
||||
A command line tool veritysetup is available to compute or verify
|
||||
the hash tree or activate the kernel driver. This is available from
|
||||
the LVM2 upstream repository and may be supplied as a package called
|
||||
device-mapper-verity-tools:
|
||||
git://sources.redhat.com/git/lvm2
|
||||
http://sourceware.org/git/?p=lvm2.git
|
||||
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/verity?cvsroot=lvm2
|
||||
the hash tree or activate the kernel device. This is available from
|
||||
the cryptsetup upstream repository http://code.google.com/p/cryptsetup/
|
||||
(as a libcryptsetup extension).
|
||||
|
||||
veritysetup -a vroot /dev/sda1 /dev/sda2 \
|
||||
4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
|
||||
Create hash on the device:
|
||||
# veritysetup format /dev/sda1 /dev/sda2
|
||||
...
|
||||
Root hash: 4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
|
||||
|
||||
Activate the device:
|
||||
# veritysetup create vroot /dev/sda1 /dev/sda2 \
|
||||
4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
|
||||
|
||||
@@ -2,6 +2,7 @@
|
||||
|
||||
Required properties:
|
||||
- compatible : "fsl,mma8450".
|
||||
- reg: the I2C address of MMA8450
|
||||
|
||||
Example:
|
||||
|
||||
|
||||
@@ -46,8 +46,8 @@ Examples:
|
||||
|
||||
ecspi@70010000 { /* ECSPI1 */
|
||||
fsl,spi-num-chipselects = <2>;
|
||||
cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
|
||||
<&gpio3 25 0>; /* GPIO4_25 */
|
||||
cs-gpios = <&gpio4 24 0>, /* GPIO4_24 */
|
||||
<&gpio4 25 0>; /* GPIO4_25 */
|
||||
status = "okay";
|
||||
|
||||
pmic: mc13892@0 {
|
||||
|
||||
@@ -29,6 +29,6 @@ esdhc@70008000 {
|
||||
compatible = "fsl,imx51-esdhc";
|
||||
reg = <0x70008000 0x4000>;
|
||||
interrupts = <2>;
|
||||
cd-gpios = <&gpio0 6 0>; /* GPIO1_6 */
|
||||
wp-gpios = <&gpio0 5 0>; /* GPIO1_5 */
|
||||
cd-gpios = <&gpio1 6 0>; /* GPIO1_6 */
|
||||
wp-gpios = <&gpio1 5 0>; /* GPIO1_5 */
|
||||
};
|
||||
|
||||
@@ -19,6 +19,6 @@ ethernet@83fec000 {
|
||||
reg = <0x83fec000 0x4000>;
|
||||
interrupts = <87>;
|
||||
phy-mode = "mii";
|
||||
phy-reset-gpios = <&gpio1 14 0>; /* GPIO2_14 */
|
||||
phy-reset-gpios = <&gpio2 14 0>; /* GPIO2_14 */
|
||||
local-mac-address = [00 04 9F 01 1B B9];
|
||||
};
|
||||
|
||||
@@ -1626,3 +1626,5 @@ MX6Q_PAD_SD2_DAT3__PCIE_CTRL_MUX_11 1587
|
||||
MX6Q_PAD_SD2_DAT3__GPIO_1_12 1588
|
||||
MX6Q_PAD_SD2_DAT3__SJC_DONE 1589
|
||||
MX6Q_PAD_SD2_DAT3__ANATOP_TESTO_3 1590
|
||||
MX6Q_PAD_ENET_RX_ER__ANATOP_USBOTG_ID 1591
|
||||
MX6Q_PAD_GPIO_1__ANATOP_USBOTG_ID 1592
|
||||
|
||||
@@ -17,6 +17,6 @@ ecspi@70010000 {
|
||||
reg = <0x70010000 0x4000>;
|
||||
interrupts = <36>;
|
||||
fsl,spi-num-chipselects = <2>;
|
||||
cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
|
||||
<&gpio3 25 0>; /* GPIO4_25 */
|
||||
cs-gpios = <&gpio3 24 0>, /* GPIO3_24 */
|
||||
<&gpio3 25 0>; /* GPIO3_25 */
|
||||
};
|
||||
|
||||
@@ -3,6 +3,7 @@ Device tree binding vendor prefix registry. Keep list in alphabetical order.
|
||||
This isn't an exhaustive list, but you should add new prefixes to it before
|
||||
using them to avoid name-space collisions.
|
||||
|
||||
ad Avionic Design GmbH
|
||||
adi Analog Devices, Inc.
|
||||
amcc Applied Micro Circuits Corporation (APM, formally AMCC)
|
||||
apm Applied Micro Circuits Corporation (APM)
|
||||
|
||||
@@ -6,7 +6,9 @@ Supported chips:
|
||||
Prefix: 'coretemp'
|
||||
CPUID: family 0x6, models 0xe (Pentium M DC), 0xf (Core 2 DC 65nm),
|
||||
0x16 (Core 2 SC 65nm), 0x17 (Penryn 45nm),
|
||||
0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield)
|
||||
0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield),
|
||||
0x26 (Tunnel Creek Atom), 0x27 (Medfield Atom),
|
||||
0x36 (Cedar Trail Atom)
|
||||
Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual
|
||||
Volume 3A: System Programming Guide
|
||||
http://softwarecommunity.intel.com/Wiki/Mobility/720.htm
|
||||
@@ -52,6 +54,17 @@ Some information comes from ark.intel.com
|
||||
|
||||
Process Processor TjMax(C)
|
||||
|
||||
22nm Core i5/i7 Processors
|
||||
i7 3920XM, 3820QM, 3720QM, 3667U, 3520M 105
|
||||
i5 3427U, 3360M/3320M 105
|
||||
i7 3770/3770K 105
|
||||
i5 3570/3570K, 3550, 3470/3450 105
|
||||
i7 3770S 103
|
||||
i5 3570S/3550S, 3475S/3470S/3450S 103
|
||||
i7 3770T 94
|
||||
i5 3570T 94
|
||||
i5 3470T 91
|
||||
|
||||
32nm Core i3/i5/i7 Processors
|
||||
i7 660UM/640/620, 640LM/620, 620M, 610E 105
|
||||
i5 540UM/520/430, 540M/520/450/430 105
|
||||
@@ -65,6 +78,11 @@ Process Processor TjMax(C)
|
||||
U3400 105
|
||||
P4505/P4500 90
|
||||
|
||||
32nm Atom Processors
|
||||
Z2460 90
|
||||
D2700/2550/2500 100
|
||||
N2850/2800/2650/2600 100
|
||||
|
||||
45nm Xeon Processors 5400 Quad-Core
|
||||
X5492, X5482, X5472, X5470, X5460, X5450 85
|
||||
E5472, E5462, E5450/40/30/20/10/05 85
|
||||
@@ -85,6 +103,8 @@ Process Processor TjMax(C)
|
||||
N475/470/455/450 100
|
||||
N280/270 90
|
||||
330/230 125
|
||||
E680/660/640/620 90
|
||||
E680T/660T/640T/620T 110
|
||||
|
||||
45nm Core2 Processors
|
||||
Solo ULV SU3500/3300 100
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user