diff options
| author | Daniel Drake <dsd@laptop.org> | 2012-03-27 16:07:40 +0100 |
|---|---|---|
| committer | Ingo Molnar <mingo@kernel.org> | 2012-03-27 20:54:52 +0200 |
| commit | a3c8121b8724c3d496dc00201ab40e8313edcf0d (patch) | |
| tree | 4e6974368cd9f09a7a881c0f3ece3ccf7b8f5451 /Documentation/ABI | |
| parent | 90e240142bd31ff10aeda5a280a53153f4eff004 (diff) | |
| download | op-kernel-dev-a3c8121b8724c3d496dc00201ab40e8313edcf0d.zip op-kernel-dev-a3c8121b8724c3d496dc00201ab40e8313edcf0d.tar.gz | |
x86/olpc: Add debugfs interface for EC commands
Add a debugfs interface for sending commands to the OLPC
Embedded Controller (EC) and reading the responses. The EC
provides functionality for machine identification, battery and
AC control, wakeup control, etc.
Having a debugfs interface available is useful for EC
development and debugging.
Based on code by Paul Fox (who also approves of the end result).
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Paul Fox <pgf@laptop.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andres Salomon <dilinger@queued.net>
Link: http://lkml.kernel.org/r/20120327150740.667D09D401E@zog.reactivated.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'Documentation/ABI')
| -rw-r--r-- | Documentation/ABI/testing/debugfs-olpc | 16 |
1 files changed, 16 insertions, 0 deletions
diff --git a/Documentation/ABI/testing/debugfs-olpc b/Documentation/ABI/testing/debugfs-olpc new file mode 100644 index 0000000..bd76cc6 --- /dev/null +++ b/Documentation/ABI/testing/debugfs-olpc @@ -0,0 +1,16 @@ +What: /sys/kernel/debug/olpc-ec/cmd +Date: Dec 2011 +KernelVersion: 3.4 +Contact: devel@lists.laptop.org +Description: + +A generic interface for executing OLPC Embedded Controller commands and +reading their responses. + +To execute a command, write data with the format: CC:N A A A A +CC is the (hex) command, N is the count of expected reply bytes, and A A A A +are optional (hex) arguments. + +To read the response (if any), read from the generic node after executing +a command. Hex reply bytes will be returned, *whether or not* they came from +the immediately previous command. |
