summaryrefslogtreecommitdiffstats
path: root/Documentation/misc-devices
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/misc-devices')
-rw-r--r--Documentation/misc-devices/ad525x_dpot.txt57
-rw-r--r--Documentation/misc-devices/apds990x.txt111
-rw-r--r--Documentation/misc-devices/bh1770glc.txt116
-rw-r--r--Documentation/misc-devices/c2port.txt90
-rw-r--r--Documentation/misc-devices/eeprom96
-rw-r--r--Documentation/misc-devices/ics932s40131
-rw-r--r--Documentation/misc-devices/isl2900362
-rw-r--r--Documentation/misc-devices/lis3lv02d92
-rw-r--r--Documentation/misc-devices/max6875110
-rw-r--r--Documentation/misc-devices/mei/.gitignore1
-rw-r--r--Documentation/misc-devices/mei/Makefile8
-rw-r--r--Documentation/misc-devices/mei/TODO2
-rw-r--r--Documentation/misc-devices/mei/mei-amt-version.c481
-rw-r--r--Documentation/misc-devices/mei/mei.txt215
-rw-r--r--Documentation/misc-devices/spear-pcie-gadget.txt130
15 files changed, 0 insertions, 1602 deletions
diff --git a/Documentation/misc-devices/ad525x_dpot.txt b/Documentation/misc-devices/ad525x_dpot.txt
deleted file mode 100644
index 0c9413b1cbf..00000000000
--- a/Documentation/misc-devices/ad525x_dpot.txt
+++ /dev/null
@@ -1,57 +0,0 @@
----------------------------------
- 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
diff --git a/Documentation/misc-devices/apds990x.txt b/Documentation/misc-devices/apds990x.txt
deleted file mode 100644
index d5408cade32..00000000000
--- a/Documentation/misc-devices/apds990x.txt
+++ /dev/null
@@ -1,111 +0,0 @@
-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.
diff --git a/Documentation/misc-devices/bh1770glc.txt b/Documentation/misc-devices/bh1770glc.txt
deleted file mode 100644
index 7d64c014dc7..00000000000
--- a/Documentation/misc-devices/bh1770glc.txt
+++ /dev/null
@@ -1,116 +0,0 @@
-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
diff --git a/Documentation/misc-devices/c2port.txt b/Documentation/misc-devices/c2port.txt
deleted file mode 100644
index ea734446561..00000000000
--- a/Documentation/misc-devices/c2port.txt
+++ /dev/null
@@ -1,90 +0,0 @@
- 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
diff --git a/Documentation/misc-devices/eeprom b/Documentation/misc-devices/eeprom
deleted file mode 100644
index f7e8104b576..00000000000
--- a/Documentation/misc-devices/eeprom
+++ /dev/null
@@ -1,96 +0,0 @@
-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 <khali@linux-fr.org>,
- 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.
diff --git a/Documentation/misc-devices/ics932s401 b/Documentation/misc-devices/ics932s401
deleted file mode 100644
index bdac67ff6e3..00000000000
--- a/Documentation/misc-devices/ics932s401
+++ /dev/null
@@ -1,31 +0,0 @@
-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!
diff --git a/Documentation/misc-devices/isl29003 b/Documentation/misc-devices/isl29003
deleted file mode 100644
index c4ff5f38e01..00000000000
--- a/Documentation/misc-devices/isl29003
+++ /dev/null
@@ -1,62 +0,0 @@
-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
-
diff --git a/Documentation/misc-devices/lis3lv02d b/Documentation/misc-devices/lis3lv02d
deleted file mode 100644
index f1a4ec840f8..00000000000
--- a/Documentation/misc-devices/lis3lv02d
+++ /dev/null
@@ -1,92 +0,0 @@
-Kernel driver lis3lv02d
-=======================
-
-Supported chips:
-
- * STMicroelectronics LIS3LV02DL, LIS3LV02DQ (12 bits precision)
- * STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 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 hpfall.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.
diff --git a/Documentation/misc-devices/max6875 b/Documentation/misc-devices/max6875
deleted file mode 100644
index 1e89ee3ccc1..00000000000
--- a/Documentation/misc-devices/max6875
+++ /dev/null
@@ -1,110 +0,0 @@
-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.
-
diff --git a/Documentation/misc-devices/mei/.gitignore b/Documentation/misc-devices/mei/.gitignore
deleted file mode 100644
index f356b81ca1e..00000000000
--- a/Documentation/misc-devices/mei/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-mei-amt-version
diff --git a/Documentation/misc-devices/mei/Makefile b/Documentation/misc-devices/mei/Makefile
deleted file mode 100644
index 00e8c3e836f..00000000000
--- a/Documentation/misc-devices/mei/Makefile
+++ /dev/null
@@ -1,8 +0,0 @@
-# kbuild trick to avoid linker error. Can be omitted if a module is built.
-obj- := dummy.o
-
-# 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)
diff --git a/Documentation/misc-devices/mei/TODO b/Documentation/misc-devices/mei/TODO
deleted file mode 100644
index 6b3625d3058..00000000000
--- a/Documentation/misc-devices/mei/TODO
+++ /dev/null
@@ -1,2 +0,0 @@
-TODO:
- - Cleanup and split the timer function
diff --git a/Documentation/misc-devices/mei/mei-amt-version.c b/Documentation/misc-devices/mei/mei-amt-version.c
deleted file mode 100644
index 01804f21631..00000000000
--- a/Documentation/misc-devices/mei/mei-amt-version.c
+++ /dev/null
@@ -1,481 +0,0 @@
-/******************************************************************************
- * 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;
-
- mei_deinit(me);
-
- 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 Technolgy 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 Technolgy 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;
-}
diff --git a/Documentation/misc-devices/mei/mei.txt b/Documentation/misc-devices/mei/mei.txt
deleted file mode 100644
index 2785697da59..00000000000
--- a/Documentation/misc-devices/mei/mei.txt
+++ /dev/null
@@ -1,215 +0,0 @@
-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 features 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 applications. Therefore, the Intel MEI driver handles
-this internally by maintaining request queues for the applications.
-
-The driver is oblivious to data that is 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 upto 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 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
diff --git a/Documentation/misc-devices/spear-pcie-gadget.txt b/Documentation/misc-devices/spear-pcie-gadget.txt
deleted file mode 100644
index 02c13ef5e90..00000000000
--- a/Documentation/misc-devices/spear-pcie-gadget.txt
+++ /dev/null
@@ -1,130 +0,0 @@
-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 -