AetherDroid/android_kernel_samsung_on5xelte
1
0
Fork 0
mirror of https://github.com/AetherDroid/android_kernel_samsung_on5xelte.git synced 2025-09-05 07:57:45 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Fixed MTP to work with TWRP

Browse source
This commit is contained in:
awab228 2018-06-19 23:16:04 +02:00
commit f6dfaef42e
50820 changed files with 20846062 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

1
Documentation/misc-devices/Makefile Normal file
View file

@ -0,0 +1 @@
subdir-y := mei

57
Documentation/misc-devices/ad525x_dpot.txt Normal file
View file

@ -0,0 +1,57 @@
---------------------------------
AD525x Digital Potentiometers
---------------------------------
The ad525x_dpot driver exports a simple sysfs interface. This allows you to
work with the immediate resistance settings as well as update the saved startup
settings. Access to the factory programmed tolerance is also provided, but
interpretation of this settings is required by the end application according to
the specific part in use.
---------
Files
---------
Each dpot device will have a set of eeprom, rdac, and tolerance files. How
many depends on the actual part you have, as will the range of allowed values.
The eeprom files are used to program the startup value of the device.
The rdac files are used to program the immediate value of the device.
The tolerance files are the read-only factory programmed tolerance settings
and may vary greatly on a part-by-part basis. For exact interpretation of
this field, please consult the datasheet for your part. This is presented
as a hex file for easier parsing.
-----------
Example
-----------
Locate the device in your sysfs tree. This is probably easiest by going into
the common i2c directory and locating the device by the i2c slave address.
# ls /sys/bus/i2c/devices/
0-0022 0-0027 0-002f
So assuming the device in question is on the first i2c bus and has the slave
address of 0x2f, we descend (unrelated sysfs entries have been trimmed).
# ls /sys/bus/i2c/devices/0-002f/
eeprom0 rdac0 tolerance0
You can use simple reads/writes to access these files:
# cd /sys/bus/i2c/devices/0-002f/
# cat eeprom0
0
# echo 10 > eeprom0
# cat eeprom0
10
# cat rdac0
5
# echo 3 > rdac0
# cat rdac0
3

111
Documentation/misc-devices/apds990x.txt Normal file
View file

@ -0,0 +1,111 @@
Kernel driver apds990x
======================
Supported chips:
Avago APDS990X
Data sheet:
Not freely available
Author:
Samu Onkalo <samu.p.onkalo@nokia.com>
Description
-----------
APDS990x is a combined ambient light and proximity sensor. ALS and proximity
functionality are highly connected. ALS measurement path must be running
while the proximity functionality is enabled.
ALS produces raw measurement values for two channels: Clear channel
(infrared + visible light) and IR only. However, threshold comparisons happen
using clear channel only. Lux value and the threshold level on the HW
might vary quite much depending the spectrum of the light source.
Driver makes necessary conversions to both directions so that user handles
only lux values. Lux value is calculated using information from the both
channels. HW threshold level is calculated from the given lux value to match
with current type of the lightning. Sometimes inaccuracy of the estimations
lead to false interrupt, but that doesn't harm.
ALS contains 4 different gain steps. Driver automatically
selects suitable gain step. After each measurement, reliability of the results
is estimated and new measurement is trigged if necessary.
Platform data can provide tuned values to the conversion formulas if
values are known. Otherwise plain sensor default values are used.
Proximity side is little bit simpler. There is no need for complex conversions.
It produces directly usable values.
Driver controls chip operational state using pm_runtime framework.
Voltage regulators are controlled based on chip operational state.
SYSFS
-----
chip_id
RO - shows detected chip type and version
power_state
RW - enable / disable chip. Uses counting logic
1 enables the chip
0 disables the chip
lux0_input
RO - measured lux value
sysfs_notify called when threshold interrupt occurs
lux0_sensor_range
RO - lux0_input max value. Actually never reaches since sensor tends
to saturate much before that. Real max value varies depending
on the light spectrum etc.
lux0_rate
RW - measurement rate in Hz
lux0_rate_avail
RO - supported measurement rates
lux0_calibscale
RW - calibration value. Set to neutral value by default.
Output results are multiplied with calibscale / calibscale_default
value.
lux0_calibscale_default
RO - neutral calibration value
lux0_thresh_above_value
RW - HI level threshold value. All results above the value
trigs an interrupt. 65535 (i.e. sensor_range) disables the above
interrupt.
lux0_thresh_below_value
RW - LO level threshold value. All results below the value
trigs an interrupt. 0 disables the below interrupt.
prox0_raw
RO - measured proximity value
sysfs_notify called when threshold interrupt occurs
prox0_sensor_range
RO - prox0_raw max value (1023)
prox0_raw_en
RW - enable / disable proximity - uses counting logic
1 enables the proximity
0 disables the proximity
prox0_reporting_mode
RW - trigger / periodic. In "trigger" mode the driver tells two possible
values: 0 or prox0_sensor_range value. 0 means no proximity,
1023 means proximity. This causes minimal number of interrupts.
In "periodic" mode the driver reports all values above
prox0_thresh_above. This causes more interrupts, but it can give
_rough_ estimate about the distance.
prox0_reporting_mode_avail
RO - accepted values to prox0_reporting_mode (trigger, periodic)
prox0_thresh_above_value
RW - threshold level which trigs proximity events.

116
Documentation/misc-devices/bh1770glc.txt Normal file
View file

@ -0,0 +1,116 @@
Kernel driver bh1770glc
=======================
Supported chips:
ROHM BH1770GLC
OSRAM SFH7770
Data sheet:
Not freely available
Author:
Samu Onkalo <samu.p.onkalo@nokia.com>
Description
-----------
BH1770GLC and SFH7770 are combined ambient light and proximity sensors.
ALS and proximity parts operates on their own, but they shares common I2C
interface and interrupt logic. In principle they can run on their own,
but ALS side results are used to estimate reliability of the proximity sensor.
ALS produces 16 bit lux values. The chip contains interrupt logic to produce
low and high threshold interrupts.
Proximity part contains IR-led driver up to 3 IR leds. The chip measures
amount of reflected IR light and produces proximity result. Resolution is
8 bit. Driver supports only one channel. Driver uses ALS results to estimate
reliability of the proximity results. Thus ALS is always running while
proximity detection is needed.
Driver uses threshold interrupts to avoid need for polling the values.
Proximity low interrupt doesn't exists in the chip. This is simulated
by using a delayed work. As long as there is proximity threshold above
interrupts the delayed work is pushed forward. So, when proximity level goes
below the threshold value, there is no interrupt and the delayed work will
finally run. This is handled as no proximity indication.
Chip state is controlled via runtime pm framework when enabled in config.
Calibscale factor is used to hide differences between the chips. By default
value set to neutral state meaning factor of 1.00. To get proper values,
calibrated source of light is needed as a reference. Calibscale factor is set
so that measurement produces about the expected lux value.
SYSFS
-----
chip_id
RO - shows detected chip type and version
power_state
RW - enable / disable chip. Uses counting logic
1 enables the chip
0 disables the chip
lux0_input
RO - measured lux value
sysfs_notify called when threshold interrupt occurs
lux0_sensor_range
RO - lux0_input max value
lux0_rate
RW - measurement rate in Hz
lux0_rate_avail
RO - supported measurement rates
lux0_thresh_above_value
RW - HI level threshold value. All results above the value
trigs an interrupt. 65535 (i.e. sensor_range) disables the above
interrupt.
lux0_thresh_below_value
RW - LO level threshold value. All results below the value
trigs an interrupt. 0 disables the below interrupt.
lux0_calibscale
RW - calibration value. Set to neutral value by default.
Output results are multiplied with calibscale / calibscale_default
value.
lux0_calibscale_default
RO - neutral calibration value
prox0_raw
RO - measured proximity value
sysfs_notify called when threshold interrupt occurs
prox0_sensor_range
RO - prox0_raw max value
prox0_raw_en
RW - enable / disable proximity - uses counting logic
1 enables the proximity
0 disables the proximity
prox0_thresh_above_count
RW - number of proximity interrupts needed before triggering the event
prox0_rate_above
RW - Measurement rate (in Hz) when the level is above threshold
i.e. when proximity on has been reported.
prox0_rate_below
RW - Measurement rate (in Hz) when the level is below threshold
i.e. when proximity off has been reported.
prox0_rate_avail
RO - Supported proximity measurement rates in Hz
prox0_thresh_above0_value
RW - threshold level which trigs proximity events.
Filtered by persistence filter (prox0_thresh_above_count)
prox0_thresh_above1_value
RW - threshold level which trigs event immediately

90
Documentation/misc-devices/c2port.txt Normal file
View file

@ -0,0 +1,90 @@
C2 port support
---------------
(C) Copyright 2007 Rodolfo Giometti <giometti@enneenne.com>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
Overview
--------
This driver implements the support for Linux of Silicon Labs (Silabs)
C2 Interface used for in-system programming of micro controllers.
By using this driver you can reprogram the in-system flash without EC2
or EC3 debug adapter. This solution is also useful in those systems
where the micro controller is connected via special GPIOs pins.
References
----------
The C2 Interface main references are at (http://www.silabs.com)
Silicon Laboratories site], see:
- AN127: FLASH Programming via the C2 Interface at
http://www.silabs.com/Support Documents/TechnicalDocs/an127.pdf
- C2 Specification at
http://www.silabs.com/pages/DownloadDoc.aspx?FILEURL=Support%20Documents/TechnicalDocs/an127.pdf&src=SearchResults
however it implements a two wire serial communication protocol (bit
banging) designed to enable in-system programming, debugging, and
boundary-scan testing on low pin-count Silicon Labs devices. Currently
this code supports only flash programming but extensions are easy to
add.
Using the driver
----------------
Once the driver is loaded you can use sysfs support to get C2port's
info or read/write in-system flash.
# ls /sys/class/c2port/c2port0/
access flash_block_size flash_erase rev_id
dev_id flash_blocks_num flash_size subsystem/
flash_access flash_data reset uevent
Initially the C2port access is disabled since you hardware may have
such lines multiplexed with other devices so, to get access to the
C2port, you need the command:
# echo 1 > /sys/class/c2port/c2port0/access
after that you should read the device ID and revision ID of the
connected micro controller:
# cat /sys/class/c2port/c2port0/dev_id
8
# cat /sys/class/c2port/c2port0/rev_id
1
However, for security reasons, the in-system flash access in not
enabled yet, to do so you need the command:
# echo 1 > /sys/class/c2port/c2port0/flash_access
After that you can read the whole flash:
# cat /sys/class/c2port/c2port0/flash_data > image
erase it:
# echo 1 > /sys/class/c2port/c2port0/flash_erase
and write it:
# cat image > /sys/class/c2port/c2port0/flash_data
after writing you have to reset the device to execute the new code:
# echo 1 > /sys/class/c2port/c2port0/reset

96
Documentation/misc-devices/eeprom Normal file
View file

@ -0,0 +1,96 @@
Kernel driver eeprom
====================
Supported chips:
* Any EEPROM chip in the designated address range
Prefix: 'eeprom'
Addresses scanned: I2C 0x50 - 0x57
Datasheets: Publicly available from:
Atmel (www.atmel.com),
Catalyst (www.catsemi.com),
Fairchild (www.fairchildsemi.com),
Microchip (www.microchip.com),
Philips (www.semiconductor.philips.com),
Rohm (www.rohm.com),
ST (www.st.com),
Xicor (www.xicor.com),
and others.
Chip Size (bits) Address
24C01 1K 0x50 (shadows at 0x51 - 0x57)
24C01A 1K 0x50 - 0x57 (Typical device on DIMMs)
24C02 2K 0x50 - 0x57
24C04 4K 0x50, 0x52, 0x54, 0x56
(additional data at 0x51, 0x53, 0x55, 0x57)
24C08 8K 0x50, 0x54 (additional data at 0x51, 0x52,
0x53, 0x55, 0x56, 0x57)
24C16 16K 0x50 (additional data at 0x51 - 0x57)
Sony 2K 0x57
Atmel 34C02B 2K 0x50 - 0x57, SW write protect at 0x30-37
Catalyst 34FC02 2K 0x50 - 0x57, SW write protect at 0x30-37
Catalyst 34RC02 2K 0x50 - 0x57, SW write protect at 0x30-37
Fairchild 34W02 2K 0x50 - 0x57, SW write protect at 0x30-37
Microchip 24AA52 2K 0x50 - 0x57, SW write protect at 0x30-37
ST M34C02 2K 0x50 - 0x57, SW write protect at 0x30-37
Authors:
Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>,
Jean Delvare <jdelvare@suse.de>,
Greg Kroah-Hartman <greg@kroah.com>,
IBM Corp.
Description
-----------
This is a simple EEPROM module meant to enable reading the first 256 bytes
of an EEPROM (on a SDRAM DIMM for example). However, it will access serial
EEPROMs on any I2C adapter. The supported devices are generically called
24Cxx, and are listed above; however the numbering for these
industry-standard devices may vary by manufacturer.
This module was a programming exercise to get used to the new project
organization laid out by Frodo, but it should be at least completely
effective for decoding the contents of EEPROMs on DIMMs.
DIMMS will typically contain a 24C01A or 24C02, or the 34C02 variants.
The other devices will not be found on a DIMM because they respond to more
than one address.
DDC Monitors may contain any device. Often a 24C01, which responds to all 8
addresses, is found.
Recent Sony Vaio laptops have an EEPROM at 0x57. We couldn't get the
specification, so it is guess work and far from being complete.
The Microchip 24AA52/24LCS52, ST M34C02, and others support an additional
software write protect register at 0x30 - 0x37 (0x20 less than the memory
location). The chip responds to "write quick" detection at this address but
does not respond to byte reads. If this register is present, the lower 128
bytes of the memory array are not write protected. Any byte data write to
this address will write protect the memory array permanently, and the
device will no longer respond at the 0x30-37 address. The eeprom driver
does not support this register.
Lacking functionality:
* Full support for larger devices (24C04, 24C08, 24C16). These are not
typically found on a PC. These devices will appear as separate devices at
multiple addresses.
* Support for really large devices (24C32, 24C64, 24C128, 24C256, 24C512).
These devices require two-byte address fields and are not supported.
* Enable Writing. Again, no technical reason why not, but making it easy
to change the contents of the EEPROMs (on DIMMs anyway) also makes it easy
to disable the DIMMs (potentially preventing the computer from booting)
until the values are restored somehow.
Use:
After inserting the module (and any other required SMBus/i2c modules), you
should have some EEPROM directories in /sys/bus/i2c/devices/* of names such
as "0-0050". Inside each of these is a series of files, the eeprom file
contains the binary data from EEPROM.

31
Documentation/misc-devices/ics932s401 Normal file
View file

@ -0,0 +1,31 @@
Kernel driver ics932s401
======================
Supported chips:
* IDT ICS932S401
Prefix: 'ics932s401'
Addresses scanned: I2C 0x69
Datasheet: Publicly available at the IDT website
Author: Darrick J. Wong
Description
-----------
This driver implements support for the IDT ICS932S401 chip family.
This chip has 4 clock outputs--a base clock for the CPU (which is likely
multiplied to get the real CPU clock), a system clock, a PCI clock, a USB
clock, and a reference clock. The driver reports selected and actual
frequency. If spread spectrum mode is enabled, the driver also reports by what
percent the clock signal is being spread, which should be between 0 and -0.5%.
All frequencies are reported in KHz.
The ICS932S401 monitors all inputs continuously. The driver will not read
the registers more often than once every other second.
Special Features
----------------
The clocks could be reprogrammed to increase system speed. I will not help you
do this, as you risk damaging your system!

62
Documentation/misc-devices/isl29003 Normal file
View file

@ -0,0 +1,62 @@
Kernel driver isl29003
=====================
Supported chips:
* Intersil ISL29003
Prefix: 'isl29003'
Addresses scanned: none
Datasheet:
http://www.intersil.com/data/fn/fn7464.pdf
Author: Daniel Mack <daniel@caiaq.de>
Description
-----------
The ISL29003 is an integrated light sensor with a 16-bit integrating type
ADC, I2C user programmable lux range select for optimized counts/lux, and
I2C multi-function control and monitoring capabilities. The internal ADC
provides 16-bit resolution while rejecting 50Hz and 60Hz flicker caused by
artificial light sources.
The driver allows to set the lux range, the bit resolution, the operational
mode (see below) and the power state of device and can read the current lux
value, of course.
Detection
---------
The ISL29003 does not have an ID register which could be used to identify
it, so the detection routine will just try to read from the configured I2C
addess and consider the device to be present as soon as it ACKs the
transfer.
Sysfs entries
-------------
range:
0: 0 lux to 1000 lux (default)
1: 0 lux to 4000 lux
2: 0 lux to 16,000 lux
3: 0 lux to 64,000 lux
resolution:
0: 2^16 cycles (default)
1: 2^12 cycles
2: 2^8 cycles
3: 2^4 cycles
mode:
0: diode1's current (unsigned 16bit) (default)
1: diode1's current (unsigned 16bit)
2: difference between diodes (l1 - l2, signed 15bit)
power_state:
0: device is disabled (default)
1: device is enabled
lux (read only):
returns the value from the last sensor reading

93
Documentation/misc-devices/lis3lv02d Normal file
View file

@ -0,0 +1,93 @@
Kernel driver lis3lv02d
=======================
Supported chips:
* STMicroelectronics LIS3LV02DL, LIS3LV02DQ (12 bits precision)
* STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits) and
LIS331DLH (16 bits)
Authors:
Yan Burman <burman.yan@gmail.com>
Eric Piel <eric.piel@tremplin-utc.net>
Description
-----------
This driver provides support for the accelerometer found in various HP laptops
sporting the feature officially called "HP Mobile Data Protection System 3D" or
"HP 3D DriveGuard". It detects automatically laptops with this sensor. Known
models (full list can be found in drivers/platform/x86/hp_accel.c) will have
their axis automatically oriented on standard way (eg: you can directly play
neverball). The accelerometer data is readable via
/sys/devices/platform/lis3lv02d. Reported values are scaled
to mg values (1/1000th of earth gravity).
Sysfs attributes under /sys/devices/platform/lis3lv02d/:
position - 3D position that the accelerometer reports. Format: "(x,y,z)"
rate - read reports the sampling rate of the accelerometer device in HZ.
write changes sampling rate of the accelerometer device.
Only values which are supported by HW are accepted.
selftest - performs selftest for the chip as specified by chip manufacturer.
This driver also provides an absolute input class device, allowing
the laptop to act as a pinball machine-esque joystick. Joystick device can be
calibrated. Joystick device can be in two different modes.
By default output values are scaled between -32768 .. 32767. In joystick raw
mode, joystick and sysfs position entry have the same scale. There can be
small difference due to input system fuzziness feature.
Events are also available as input event device.
Selftest is meant only for hardware diagnostic purposes. It is not meant to be
used during normal operations. Position data is not corrupted during selftest
but interrupt behaviour is not guaranteed to work reliably. In test mode, the
sensing element is internally moved little bit. Selftest measures difference
between normal mode and test mode. Chip specifications tell the acceptance
limit for each type of the chip. Limits are provided via platform data
to allow adjustment of the limits without a change to the actual driver.
Seltest returns either "OK x y z" or "FAIL x y z" where x, y and z are
measured difference between modes. Axes are not remapped in selftest mode.
Measurement values are provided to help HW diagnostic applications to make
final decision.
On HP laptops, if the led infrastructure is activated, support for a led
indicating disk protection will be provided as /sys/class/leds/hp::hddprotect.
Another feature of the driver is misc device called "freefall" that
acts similar to /dev/rtc and reacts on free-fall interrupts received
from the device. It supports blocking operations, poll/select and
fasync operation modes. You must read 1 bytes from the device. The
result is number of free-fall interrupts since the last successful
read (or 255 if number of interrupts would not fit). See the freefall.c
file for an example on using the device.
Axes orientation
----------------
For better compatibility between the various laptops. The values reported by
the accelerometer are converted into a "standard" organisation of the axes
(aka "can play neverball out of the box"):
* When the laptop is horizontal the position reported is about 0 for X and Y
and a positive value for Z
* If the left side is elevated, X increases (becomes positive)
* If the front side (where the touchpad is) is elevated, Y decreases
(becomes negative)
* If the laptop is put upside-down, Z becomes negative
If your laptop model is not recognized (cf "dmesg"), you can send an
email to the maintainer to add it to the database. When reporting a new
laptop, please include the output of "dmidecode" plus the value of
/sys/devices/platform/lis3lv02d/position in these four cases.
Q&A
---
Q: How do I safely simulate freefall? I have an HP "portable
workstation" which has about 3.5kg and a plastic case, so letting it
fall to the ground is out of question...
A: The sensor is pretty sensitive, so your hands can do it. Lift it
into free space, follow the fall with your hands for like 10
centimeters. That should be enough to trigger the detection.

110
Documentation/misc-devices/max6875 Normal file
View file

@ -0,0 +1,110 @@
Kernel driver max6875
=====================
Supported chips:
* Maxim MAX6874, MAX6875
Prefix: 'max6875'
Addresses scanned: None (see below)
Datasheet:
http://pdfserv.maxim-ic.com/en/ds/MAX6874-MAX6875.pdf
Author: Ben Gardner <bgardner@wabtec.com>
Description
-----------
The Maxim MAX6875 is an EEPROM-programmable power-supply sequencer/supervisor.
It provides timed outputs that can be used as a watchdog, if properly wired.
It also provides 512 bytes of user EEPROM.
At reset, the MAX6875 reads the configuration EEPROM into its configuration
registers. The chip then begins to operate according to the values in the
registers.
The Maxim MAX6874 is a similar, mostly compatible device, with more intputs
and outputs:
vin gpi vout
MAX6874 6 4 8
MAX6875 4 3 5
See the datasheet for more information.
Sysfs entries
-------------
eeprom - 512 bytes of user-defined EEPROM space.
General Remarks
---------------
Valid addresses for the MAX6875 are 0x50 and 0x52.
Valid addresses for the MAX6874 are 0x50, 0x52, 0x54 and 0x56.
The driver does not probe any address, so you explicitly instantiate the
devices.
Example:
$ modprobe max6875
$ echo max6875 0x50 > /sys/bus/i2c/devices/i2c-0/new_device
The MAX6874/MAX6875 ignores address bit 0, so this driver attaches to multiple
addresses. For example, for address 0x50, it also reserves 0x51.
The even-address instance is called 'max6875', the odd one is 'dummy'.
Programming the chip using i2c-dev
----------------------------------
Use the i2c-dev interface to access and program the chips.
Reads and writes are performed differently depending on the address range.
The configuration registers are at addresses 0x00 - 0x45.
Use i2c_smbus_write_byte_data() to write a register and
i2c_smbus_read_byte_data() to read a register.
The command is the register number.
Examples:
To write a 1 to register 0x45:
i2c_smbus_write_byte_data(fd, 0x45, 1);
To read register 0x45:
value = i2c_smbus_read_byte_data(fd, 0x45);
The configuration EEPROM is at addresses 0x8000 - 0x8045.
The user EEPROM is at addresses 0x8100 - 0x82ff.
Use i2c_smbus_write_word_data() to write a byte to EEPROM.
The command is the upper byte of the address: 0x80, 0x81, or 0x82.
The data word is the lower part of the address or'd with data << 8.
cmd = address >> 8;
val = (address & 0xff) | (data << 8);
Example:
To write 0x5a to address 0x8003:
i2c_smbus_write_word_data(fd, 0x80, 0x5a03);
Reading data from the EEPROM is a little more complicated.
Use i2c_smbus_write_byte_data() to set the read address and then
i2c_smbus_read_byte() or i2c_smbus_read_i2c_block_data() to read the data.
Example:
To read data starting at offset 0x8100, first set the address:
i2c_smbus_write_byte_data(fd, 0x81, 0x00);
And then read the data
value = i2c_smbus_read_byte(fd);
or
count = i2c_smbus_read_i2c_block_data(fd, 0x84, 16, buffer);
The block read should read 16 bytes.
0x84 is the block read command.
See the datasheet for more details.

5
Documentation/misc-devices/mei/Makefile Normal file
View file

@ -0,0 +1,5 @@
# List of programs to build
hostprogs-y := mei-amt-version
HOSTCFLAGS_mei-amt-version.o += -I$(objtree)/usr/include
# Tell kbuild to always build the programs
always := $(hostprogs-y)

2
Documentation/misc-devices/mei/TODO Normal file
View file

@ -0,0 +1,2 @@
TODO:
- Cleanup and split the timer function

479
Documentation/misc-devices/mei/mei-amt-version.c Normal file
View file

@ -0,0 +1,479 @@
/******************************************************************************
* Intel Management Engine Interface (Intel MEI) Linux driver
* Intel MEI Interface Header
*
* This file is provided under a dual BSD/GPLv2 license. When using or
* redistributing this file, you may do so under either license.
*
* GPL LICENSE SUMMARY
*
* Copyright(c) 2012 Intel Corporation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of version 2 of the GNU General Public License as
* published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110,
* USA
*
* The full GNU General Public License is included in this distribution
* in the file called LICENSE.GPL.
*
* Contact Information:
* Intel Corporation.
* linux-mei@linux.intel.com
* http://www.intel.com
*
* BSD LICENSE
*
* Copyright(c) 2003 - 2012 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* * Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
* * Neither the name Intel Corporation nor the names of its
* contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
*****************************************************************************/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <unistd.h>
#include <errno.h>
#include <stdint.h>
#include <stdbool.h>
#include <bits/wordsize.h>
#include <linux/mei.h>
/*****************************************************************************
* Intel Management Engine Interface
*****************************************************************************/
#define mei_msg(_me, fmt, ARGS...) do { \
if (_me->verbose) \
fprintf(stderr, fmt, ##ARGS); \
} while (0)
#define mei_err(_me, fmt, ARGS...) do { \
fprintf(stderr, "Error: " fmt, ##ARGS); \
} while (0)
struct mei {
uuid_le guid;
bool initialized;
bool verbose;
unsigned int buf_size;
unsigned char prot_ver;
int fd;
};
static void mei_deinit(struct mei *cl)
{
if (cl->fd != -1)
close(cl->fd);
cl->fd = -1;
cl->buf_size = 0;
cl->prot_ver = 0;
cl->initialized = false;
}
static bool mei_init(struct mei *me, const uuid_le *guid,
unsigned char req_protocol_version, bool verbose)
{
int result;
struct mei_client *cl;
struct mei_connect_client_data data;
me->verbose = verbose;
me->fd = open("/dev/mei", O_RDWR);
if (me->fd == -1) {
mei_err(me, "Cannot establish a handle to the Intel MEI driver\n");
goto err;
}
memcpy(&me->guid, guid, sizeof(*guid));
memset(&data, 0, sizeof(data));
me->initialized = true;
memcpy(&data.in_client_uuid, &me->guid, sizeof(me->guid));
result = ioctl(me->fd, IOCTL_MEI_CONNECT_CLIENT, &data);
if (result) {
mei_err(me, "IOCTL_MEI_CONNECT_CLIENT receive message. err=%d\n", result);
goto err;
}
cl = &data.out_client_properties;
mei_msg(me, "max_message_length %d\n", cl->max_msg_length);
mei_msg(me, "protocol_version %d\n", cl->protocol_version);
if ((req_protocol_version > 0) &&
(cl->protocol_version != req_protocol_version)) {
mei_err(me, "Intel MEI protocol version not supported\n");
goto err;
}
me->buf_size = cl->max_msg_length;
me->prot_ver = cl->protocol_version;
return true;
err:
mei_deinit(me);
return false;
}
static ssize_t mei_recv_msg(struct mei *me, unsigned char *buffer,
ssize_t len, unsigned long timeout)
{
ssize_t rc;
mei_msg(me, "call read length = %zd\n", len);
rc = read(me->fd, buffer, len);
if (rc < 0) {
mei_err(me, "read failed with status %zd %s\n",
rc, strerror(errno));
mei_deinit(me);
} else {
mei_msg(me, "read succeeded with result %zd\n", rc);
}
return rc;
}
static ssize_t mei_send_msg(struct mei *me, const unsigned char *buffer,
ssize_t len, unsigned long timeout)
{
struct timeval tv;
ssize_t written;
ssize_t rc;
fd_set set;
tv.tv_sec = timeout / 1000;
tv.tv_usec = (timeout % 1000) * 1000000;
mei_msg(me, "call write length = %zd\n", len);
written = write(me->fd, buffer, len);
if (written < 0) {
rc = -errno;
mei_err(me, "write failed with status %zd %s\n",
written, strerror(errno));
goto out;
}
FD_ZERO(&set);
FD_SET(me->fd, &set);
rc = select(me->fd + 1 , &set, NULL, NULL, &tv);
if (rc > 0 && FD_ISSET(me->fd, &set)) {
mei_msg(me, "write success\n");
} else if (rc == 0) {
mei_err(me, "write failed on timeout with status\n");
goto out;
} else { /* rc < 0 */
mei_err(me, "write failed on select with status %zd\n", rc);
goto out;
}
rc = written;
out:
if (rc < 0)
mei_deinit(me);
return rc;
}
/***************************************************************************
* Intel Advanced Management Technology ME Client
***************************************************************************/
#define AMT_MAJOR_VERSION 1
#define AMT_MINOR_VERSION 1
#define AMT_STATUS_SUCCESS 0x0
#define AMT_STATUS_INTERNAL_ERROR 0x1
#define AMT_STATUS_NOT_READY 0x2
#define AMT_STATUS_INVALID_AMT_MODE 0x3
#define AMT_STATUS_INVALID_MESSAGE_LENGTH 0x4
#define AMT_STATUS_HOST_IF_EMPTY_RESPONSE 0x4000
#define AMT_STATUS_SDK_RESOURCES 0x1004
#define AMT_BIOS_VERSION_LEN 65
#define AMT_VERSIONS_NUMBER 50
#define AMT_UNICODE_STRING_LEN 20
struct amt_unicode_string {
uint16_t length;
char string[AMT_UNICODE_STRING_LEN];
} __attribute__((packed));
struct amt_version_type {
struct amt_unicode_string description;
struct amt_unicode_string version;
} __attribute__((packed));
struct amt_version {
uint8_t major;
uint8_t minor;
} __attribute__((packed));
struct amt_code_versions {
uint8_t bios[AMT_BIOS_VERSION_LEN];
uint32_t count;
struct amt_version_type versions[AMT_VERSIONS_NUMBER];
} __attribute__((packed));
/***************************************************************************
* Intel Advanced Management Technology Host Interface
***************************************************************************/
struct amt_host_if_msg_header {
struct amt_version version;
uint16_t _reserved;
uint32_t command;
uint32_t length;
} __attribute__((packed));
struct amt_host_if_resp_header {
struct amt_host_if_msg_header header;
uint32_t status;
unsigned char data[0];
} __attribute__((packed));
const uuid_le MEI_IAMTHIF = UUID_LE(0x12f80028, 0xb4b7, 0x4b2d, \
0xac, 0xa8, 0x46, 0xe0, 0xff, 0x65, 0x81, 0x4c);
#define AMT_HOST_IF_CODE_VERSIONS_REQUEST 0x0400001A
#define AMT_HOST_IF_CODE_VERSIONS_RESPONSE 0x0480001A
const struct amt_host_if_msg_header CODE_VERSION_REQ = {
.version = {AMT_MAJOR_VERSION, AMT_MINOR_VERSION},
._reserved = 0,
.command = AMT_HOST_IF_CODE_VERSIONS_REQUEST,
.length = 0
};
struct amt_host_if {
struct mei mei_cl;
unsigned long send_timeout;
bool initialized;
};
static bool amt_host_if_init(struct amt_host_if *acmd,
unsigned long send_timeout, bool verbose)
{
acmd->send_timeout = (send_timeout) ? send_timeout : 20000;
acmd->initialized = mei_init(&acmd->mei_cl, &MEI_IAMTHIF, 0, verbose);
return acmd->initialized;
}
static void amt_host_if_deinit(struct amt_host_if *acmd)
{
mei_deinit(&acmd->mei_cl);
acmd->initialized = false;
}
static uint32_t amt_verify_code_versions(const struct amt_host_if_resp_header *resp)
{
uint32_t status = AMT_STATUS_SUCCESS;
struct amt_code_versions *code_ver;
size_t code_ver_len;
uint32_t ver_type_cnt;
uint32_t len;
uint32_t i;
code_ver = (struct amt_code_versions *)resp->data;
/* length - sizeof(status) */
code_ver_len = resp->header.length - sizeof(uint32_t);
ver_type_cnt = code_ver_len -
sizeof(code_ver->bios) -
sizeof(code_ver->count);
if (code_ver->count != ver_type_cnt / sizeof(struct amt_version_type)) {
status = AMT_STATUS_INTERNAL_ERROR;
goto out;
}
for (i = 0; i < code_ver->count; i++) {
len = code_ver->versions[i].description.length;
if (len > AMT_UNICODE_STRING_LEN) {
status = AMT_STATUS_INTERNAL_ERROR;
goto out;
}
len = code_ver->versions[i].version.length;
if (code_ver->versions[i].version.string[len] != '\0' ||
len != strlen(code_ver->versions[i].version.string)) {
status = AMT_STATUS_INTERNAL_ERROR;
goto out;
}
}
out:
return status;
}
static uint32_t amt_verify_response_header(uint32_t command,
const struct amt_host_if_msg_header *resp_hdr,
uint32_t response_size)
{
if (response_size < sizeof(struct amt_host_if_resp_header)) {
return AMT_STATUS_INTERNAL_ERROR;
} else if (response_size != (resp_hdr->length +
sizeof(struct amt_host_if_msg_header))) {
return AMT_STATUS_INTERNAL_ERROR;
} else if (resp_hdr->command != command) {
return AMT_STATUS_INTERNAL_ERROR;
} else if (resp_hdr->_reserved != 0) {
return AMT_STATUS_INTERNAL_ERROR;
} else if (resp_hdr->version.major != AMT_MAJOR_VERSION ||
resp_hdr->version.minor < AMT_MINOR_VERSION) {
return AMT_STATUS_INTERNAL_ERROR;
}
return AMT_STATUS_SUCCESS;
}
static uint32_t amt_host_if_call(struct amt_host_if *acmd,
const unsigned char *command, ssize_t command_sz,
uint8_t **read_buf, uint32_t rcmd,
unsigned int expected_sz)
{
uint32_t in_buf_sz;
uint32_t out_buf_sz;
ssize_t written;
uint32_t status;
struct amt_host_if_resp_header *msg_hdr;
in_buf_sz = acmd->mei_cl.buf_size;
*read_buf = (uint8_t *)malloc(sizeof(uint8_t) * in_buf_sz);
if (*read_buf == NULL)
return AMT_STATUS_SDK_RESOURCES;
memset(*read_buf, 0, in_buf_sz);
msg_hdr = (struct amt_host_if_resp_header *)*read_buf;
written = mei_send_msg(&acmd->mei_cl,
command, command_sz, acmd->send_timeout);
if (written != command_sz)
return AMT_STATUS_INTERNAL_ERROR;
out_buf_sz = mei_recv_msg(&acmd->mei_cl, *read_buf, in_buf_sz, 2000);
if (out_buf_sz <= 0)
return AMT_STATUS_HOST_IF_EMPTY_RESPONSE;
status = msg_hdr->status;
if (status != AMT_STATUS_SUCCESS)
return status;
status = amt_verify_response_header(rcmd,
&msg_hdr->header, out_buf_sz);
if (status != AMT_STATUS_SUCCESS)
return status;
if (expected_sz && expected_sz != out_buf_sz)
return AMT_STATUS_INTERNAL_ERROR;
return AMT_STATUS_SUCCESS;
}
static uint32_t amt_get_code_versions(struct amt_host_if *cmd,
struct amt_code_versions *versions)
{
struct amt_host_if_resp_header *response = NULL;
uint32_t status;
status = amt_host_if_call(cmd,
(const unsigned char *)&CODE_VERSION_REQ,
sizeof(CODE_VERSION_REQ),
(uint8_t **)&response,
AMT_HOST_IF_CODE_VERSIONS_RESPONSE, 0);
if (status != AMT_STATUS_SUCCESS)
goto out;
status = amt_verify_code_versions(response);
if (status != AMT_STATUS_SUCCESS)
goto out;
memcpy(versions, response->data, sizeof(struct amt_code_versions));
out:
if (response != NULL)
free(response);
return status;
}
/************************** end of amt_host_if_command ***********************/
int main(int argc, char **argv)
{
struct amt_code_versions ver;
struct amt_host_if acmd;
unsigned int i;
uint32_t status;
int ret;
bool verbose;
verbose = (argc > 1 && strcmp(argv[1], "-v") == 0);
if (!amt_host_if_init(&acmd, 5000, verbose)) {
ret = 1;
goto out;
}
status = amt_get_code_versions(&acmd, &ver);
amt_host_if_deinit(&acmd);
switch (status) {
case AMT_STATUS_HOST_IF_EMPTY_RESPONSE:
printf("Intel AMT: DISABLED\n");
ret = 0;
break;
case AMT_STATUS_SUCCESS:
printf("Intel AMT: ENABLED\n");
for (i = 0; i < ver.count; i++) {
printf("%s:\t%s\n", ver.versions[i].description.string,
ver.versions[i].version.string);
}
ret = 0;
break;
default:
printf("An error has occurred\n");
ret = 1;
break;
}
out:
return ret;
}

138
Documentation/misc-devices/mei/mei-client-bus.txt Normal file
View file

@ -0,0 +1,138 @@
Intel(R) Management Engine (ME) Client bus API
===============================================
Rationale
=========
MEI misc character device is useful for dedicated applications to send and receive
data to the many FW appliance found in Intel's ME from the user space.
However for some of the ME functionalities it make sense to leverage existing software
stack and expose them through existing kernel subsystems.
In order to plug seamlessly into the kernel device driver model we add kernel virtual
bus abstraction on top of the MEI driver. This allows implementing linux kernel drivers
for the various MEI features as a stand alone entities found in their respective subsystem.
Existing device drivers can even potentially be re-used by adding an MEI CL bus layer to
the existing code.
MEI CL bus API
===========
A driver implementation for an MEI Client is very similar to existing bus
based device drivers. The driver registers itself as an MEI CL bus driver through
the mei_cl_driver structure:
struct mei_cl_driver {
struct device_driver driver;
const char *name;
const struct mei_cl_device_id *id_table;
int (*probe)(struct mei_cl_device *dev, const struct mei_cl_id *id);
int (*remove)(struct mei_cl_device *dev);
};
struct mei_cl_id {
char name[MEI_NAME_SIZE];
kernel_ulong_t driver_info;
};
The mei_cl_id structure allows the driver to bind itself against a device name.
To actually register a driver on the ME Client bus one must call the mei_cl_add_driver()
API. This is typically called at module init time.
Once registered on the ME Client bus, a driver will typically try to do some I/O on
this bus and this should be done through the mei_cl_send() and mei_cl_recv()
routines. The latter is synchronous (blocks and sleeps until data shows up).
In order for drivers to be notified of pending events waiting for them (e.g.
an Rx event) they can register an event handler through the
mei_cl_register_event_cb() routine. Currently only the MEI_EVENT_RX event
will trigger an event handler call and the driver implementation is supposed
to call mei_recv() from the event handler in order to fetch the pending
received buffers.
Example
=======
As a theoretical example let's pretend the ME comes with a "contact" NFC IP.
The driver init and exit routines for this device would look like:
#define CONTACT_DRIVER_NAME "contact"
static struct mei_cl_device_id contact_mei_cl_tbl[] = {
{ CONTACT_DRIVER_NAME, },
/* required last entry */
{ }
};
MODULE_DEVICE_TABLE(mei_cl, contact_mei_cl_tbl);
static struct mei_cl_driver contact_driver = {
.id_table = contact_mei_tbl,
.name = CONTACT_DRIVER_NAME,
.probe = contact_probe,
.remove = contact_remove,
};
static int contact_init(void)
{
int r;
r = mei_cl_driver_register(&contact_driver);
if (r) {
pr_err(CONTACT_DRIVER_NAME ": driver registration failed\n");
return r;
}
return 0;
}
static void __exit contact_exit(void)
{
mei_cl_driver_unregister(&contact_driver);
}
module_init(contact_init);
module_exit(contact_exit);
And the driver's simplified probe routine would look like that:
int contact_probe(struct mei_cl_device *dev, struct mei_cl_device_id *id)
{
struct contact_driver *contact;
[...]
mei_cl_enable_device(dev);
mei_cl_register_event_cb(dev, contact_event_cb, contact);
return 0;
}
In the probe routine the driver first enable the MEI device and then registers
an ME bus event handler which is as close as it can get to registering a
threaded IRQ handler.
The handler implementation will typically call some I/O routine depending on
the pending events:
#define MAX_NFC_PAYLOAD 128
static void contact_event_cb(struct mei_cl_device *dev, u32 events,
void *context)
{
struct contact_driver *contact = context;
if (events & BIT(MEI_EVENT_RX)) {
u8 payload[MAX_NFC_PAYLOAD];
int payload_size;
payload_size = mei_recv(dev, payload, MAX_NFC_PAYLOAD);
if (payload_size <= 0)
return;
/* Hook to the NFC subsystem */
nfc_hci_recv_frame(contact->hdev, payload, payload_size);
}
}

215
Documentation/misc-devices/mei/mei.txt Normal file
View file

@ -0,0 +1,215 @@
Intel(R) Management Engine Interface (Intel(R) MEI)
=======================
Introduction
=======================
The Intel Management Engine (Intel ME) is an isolated and protected computing
resource (Co-processor) residing inside certain Intel chipsets. The Intel ME
provides support for computer/IT management features. The feature set
depends on the Intel chipset SKU.
The Intel Management Engine Interface (Intel MEI, previously known as HECI)
is the interface between the Host and Intel ME. This interface is exposed
to the host as a PCI device. The Intel MEI Driver is in charge of the
communication channel between a host application and the Intel ME feature.
Each Intel ME feature (Intel ME Client) is addressed by a GUID/UUID and
each client has its own protocol. The protocol is message-based with a
header and payload up to 512 bytes.
Prominent usage of the Intel ME Interface is to communicate with Intel(R)
Active Management Technology (Intel AMT)implemented in firmware running on
the Intel ME.
Intel AMT provides the ability to manage a host remotely out-of-band (OOB)
even when the operating system running on the host processor has crashed or
is in a sleep state.
Some examples of Intel AMT usage are:
- Monitoring hardware state and platform components
- Remote power off/on (useful for green computing or overnight IT
maintenance)
- OS updates
- Storage of useful platform information such as software assets
- Built-in hardware KVM
- Selective network isolation of Ethernet and IP protocol flows based
on policies set by a remote management console
- IDE device redirection from remote management console
Intel AMT (OOB) communication is based on SOAP (deprecated
starting with Release 6.0) over HTTP/S or WS-Management protocol over
HTTP/S that are received from a remote management console application.
For more information about Intel AMT:
http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
Intel MEI Driver
=======================
The driver exposes a misc device called /dev/mei.
An application maintains communication with an Intel ME feature while
/dev/mei is open. The binding to a specific feature is performed by calling
MEI_CONNECT_CLIENT_IOCTL, which passes the desired UUID.
The number of instances of an Intel ME feature that can be opened
at the same time depends on the Intel ME feature, but most of the
features allow only a single instance.
The Intel AMT Host Interface (Intel AMTHI) feature supports multiple
simultaneous user connected applications. The Intel MEI driver
handles this internally by maintaining request queues for the applications.
The driver is transparent to data that are passed between firmware feature
and host application.
Because some of the Intel ME features can change the system
configuration, the driver by default allows only a privileged
user to access it.
A code snippet for an application communicating with Intel AMTHI client:
struct mei_connect_client_data data;
fd = open(MEI_DEVICE);
data.d.in_client_uuid = AMTHI_UUID;
ioctl(fd, IOCTL_MEI_CONNECT_CLIENT, &data);
printf("Ver=%d, MaxLen=%ld\n",
data.d.in_client_uuid.protocol_version,
data.d.in_client_uuid.max_msg_length);
[...]
write(fd, amthi_req_data, amthi_req_data_len);
[...]
read(fd, &amthi_res_data, amthi_res_data_len);
[...]
close(fd);
IOCTL:
======
The Intel MEI Driver supports the following IOCTL command:
IOCTL_MEI_CONNECT_CLIENT Connect to firmware Feature (client).
usage:
struct mei_connect_client_data clientData;
ioctl(fd, IOCTL_MEI_CONNECT_CLIENT, &clientData);
inputs:
mei_connect_client_data struct contain the following
input field:
in_client_uuid - UUID of the FW Feature that needs
to connect to.
outputs:
out_client_properties - Client Properties: MTU and Protocol Version.
error returns:
EINVAL Wrong IOCTL Number
ENODEV Device or Connection is not initialized or ready.
(e.g. Wrong UUID)
ENOMEM Unable to allocate memory to client internal data.
EFAULT Fatal Error (e.g. Unable to access user input data)
EBUSY Connection Already Open
Notes:
max_msg_length (MTU) in client properties describes the maximum
data that can be sent or received. (e.g. if MTU=2K, can send
requests up to bytes 2k and received responses up to 2k bytes).
Intel ME Applications:
==============
1) Intel Local Management Service (Intel LMS)
Applications running locally on the platform communicate with Intel AMT Release
2.0 and later releases in the same way that network applications do via SOAP
over HTTP (deprecated starting with Release 6.0) or with WS-Management over
SOAP over HTTP. This means that some Intel AMT features can be accessed from a
local application using the same network interface as a remote application
communicating with Intel AMT over the network.
When a local application sends a message addressed to the local Intel AMT host
name, the Intel LMS, which listens for traffic directed to the host name,
intercepts the message and routes it to the Intel MEI.
For more information:
http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
Under "About Intel AMT" => "Local Access"
For downloading Intel LMS:
http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/
The Intel LMS opens a connection using the Intel MEI driver to the Intel LMS
firmware feature using a defined UUID and then communicates with the feature
using a protocol called Intel AMT Port Forwarding Protocol(Intel APF protocol).
The protocol is used to maintain multiple sessions with Intel AMT from a
single application.
See the protocol specification in the Intel AMT Software Development Kit(SDK)
http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
Under "SDK Resources" => "Intel(R) vPro(TM) Gateway(MPS)"
=> "Information for Intel(R) vPro(TM) Gateway Developers"
=> "Description of the Intel AMT Port Forwarding (APF)Protocol"
2) Intel AMT Remote configuration using a Local Agent
A Local Agent enables IT personnel to configure Intel AMT out-of-the-box
without requiring installing additional data to enable setup. The remote
configuration process may involve an ISV-developed remote configuration
agent that runs on the host.
For more information:
http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide
Under "Setup and Configuration of Intel AMT" =>
"SDK Tools Supporting Setup and Configuration" =>
"Using the Local Agent Sample"
An open source Intel AMT configuration utility, implementing a local agent
that accesses the Intel MEI driver, can be found here:
http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/
Intel AMT OS Health Watchdog:
=============================
The Intel AMT Watchdog is an OS Health (Hang/Crash) watchdog.
Whenever the OS hangs or crashes, Intel AMT will send an event
to any subscriber to this event. This mechanism means that
IT knows when a platform crashes even when there is a hard failure on the host.
The Intel AMT Watchdog is composed of two parts:
1) Firmware feature - receives the heartbeats
and sends an event when the heartbeats stop.
2) Intel MEI driver - connects to the watchdog feature, configures the
watchdog and sends the heartbeats.
The Intel MEI driver uses the kernel watchdog API to configure the Intel AMT
Watchdog and to send heartbeats to it. The default timeout of the
watchdog is 120 seconds.
If the Intel AMT Watchdog feature does not exist (i.e. the connection failed),
the Intel MEI driver will disable the sending of heartbeats.
Supported Chipsets:
==================
7 Series Chipset Family
6 Series Chipset Family
5 Series Chipset Family
4 Series Chipset Family
Mobile 4 Series Chipset Family
ICH9
82946GZ/GL
82G35 Express
82Q963/Q965
82P965/G965
Mobile PM965/GM965
Mobile GME965/GLE960
82Q35 Express
82G33/G31/P35/P31 Express
82Q33 Express
82X38/X48 Express
---
linux-mei@linux.intel.com

130
Documentation/misc-devices/spear-pcie-gadget.txt Normal file
View file

@ -0,0 +1,130 @@
Spear PCIe Gadget Driver:
Author
=============
Pratyush Anand (pratyush.anand@st.com)
Location
============
driver/misc/spear13xx_pcie_gadget.c
Supported Chip:
===================
SPEAr1300
SPEAr1310
Menuconfig option:
==========================
Device Drivers
Misc devices
PCIe gadget support for SPEAr13XX platform
purpose
===========
This driver has several nodes which can be read/written by configfs interface.
Its main purpose is to configure selected dual mode PCIe controller as device
and then program its various registers to configure it as a particular device
type. This driver can be used to show spear's PCIe device capability.
Description of different nodes:
=================================
read behavior of nodes:
------------------------------
link :gives ltssm status.
int_type :type of supported interrupt
no_of_msi :zero if MSI is not enabled by host. A positive value is the
number of MSI vector granted.
vendor_id :returns programmed vendor id (hex)
device_id :returns programmed device id(hex)
bar0_size: :returns size of bar0 in hex.
bar0_address :returns address of bar0 mapped area in hex.
bar0_rw_offset :returns offset of bar0 for which bar0_data will return value.
bar0_data :returns data at bar0_rw_offset.
write behavior of nodes:
------------------------------
link :write UP to enable ltsmm DOWN to disable
int_type :write interrupt type to be configured and (int_type could be
INTA, MSI or NO_INT). Select MSI only when you have programmed
no_of_msi node.
no_of_msi :number of MSI vector needed.
inta :write 1 to assert INTA and 0 to de-assert.
send_msi :write MSI vector to be sent.
vendor_id :write vendor id(hex) to be programmed.
device_id :write device id(hex) to be programmed.
bar0_size :write size of bar0 in hex. default bar0 size is 1000 (hex)
bytes.
bar0_address :write address of bar0 mapped area in hex. (default mapping of
bar0 is SYSRAM1(E0800000). Always program bar size before bar
address. Kernel might modify bar size and address for alignment, so
read back bar size and address after writing to cross check.
bar0_rw_offset :write offset of bar0 for which bar0_data will write value.
bar0_data :write data to be written at bar0_rw_offset.
Node programming example
===========================
Program all PCIe registers in such a way that when this device is connected
to the PCIe host, then host sees this device as 1MB RAM.
#mount -t configfs none /Config
For nth PCIe Device Controller
# cd /config/pcie_gadget.n/
Now you have all the nodes in this directory.
program vendor id as 0x104a
# echo 104A >> vendor_id
program device id as 0xCD80
# echo CD80 >> device_id
program BAR0 size as 1MB
# echo 100000 >> bar0_size
check for programmed bar0 size
# cat bar0_size
Program BAR0 Address as DDR (0x2100000). This is the physical address of
memory, which is to be made visible to PCIe host. Similarly any other peripheral
can also be made visible to PCIe host. E.g., if you program base address of UART
as BAR0 address then when this device will be connected to a host, it will be
visible as UART.
# echo 2100000 >> bar0_address
program interrupt type : INTA
# echo INTA >> int_type
go for link up now.
# echo UP >> link
It will have to be insured that, once link up is done on gadget, then only host
is initialized and start to search PCIe devices on its port.
/*wait till link is up*/
# cat link
wait till it returns UP.
To assert INTA
# echo 1 >> inta
To de-assert INTA
# echo 0 >> inta
if MSI is to be used as interrupt, program no of msi vector needed (say4)
# echo 4 >> no_of_msi
select MSI as interrupt type
# echo MSI >> int_type
go for link up now
# echo UP >> link
wait till link is up
# cat link
An application can repetitively read this node till link is found UP. It can
sleep between two read.
wait till msi is enabled
# cat no_of_msi
Should return 4 (number of requested MSI vector)
to send msi vector 2
# echo 2 >> send_msi
#cd -