1774fea1aSStewart SmithWhat:		/sys/firmware/opal/elog
2774fea1aSStewart SmithDate:		Feb 2014
3774fea1aSStewart SmithContact:	Stewart Smith <stewart@linux.vnet.ibm.com>
4774fea1aSStewart SmithDescription:
5774fea1aSStewart Smith		This directory exposes error log entries retrieved
6774fea1aSStewart Smith		through the OPAL firmware interface.
7774fea1aSStewart Smith
8774fea1aSStewart Smith		Each error log is identified by a unique ID and will
9774fea1aSStewart Smith		exist until explicitly acknowledged to firmware.
10774fea1aSStewart Smith
11774fea1aSStewart Smith		Each log entry has a directory in /sys/firmware/opal/elog.
12774fea1aSStewart Smith
13774fea1aSStewart Smith		Log entries may be purged by the service processor
14774fea1aSStewart Smith		before retrieved by firmware or retrieved/acknowledged by
15774fea1aSStewart Smith		Linux if there is no room for more log entries.
16774fea1aSStewart Smith
17774fea1aSStewart Smith		In the event that Linux has retrieved the log entries
18774fea1aSStewart Smith		but not explicitly acknowledged them to firmware and
19774fea1aSStewart Smith		the service processor needs more room for log entries,
20774fea1aSStewart Smith		the only remaining copy of a log message may be in
21774fea1aSStewart Smith		Linux.
22774fea1aSStewart Smith
23774fea1aSStewart Smith		Typically, a user space daemon will monitor for new
24774fea1aSStewart Smith		entries, read them out and acknowledge them.
25774fea1aSStewart Smith
26774fea1aSStewart Smith		The service processor may be able to store more log
27774fea1aSStewart Smith		entries than firmware can, so after you acknowledge
28774fea1aSStewart Smith		an event from Linux you may instantly get another one
29774fea1aSStewart Smith		from the queue that was generated some time in the past.
30774fea1aSStewart Smith
31774fea1aSStewart Smith		The raw log format is a binary format. We currently
32774fea1aSStewart Smith		do not parse this at all in kernel, leaving it up to
33774fea1aSStewart Smith		user space to solve the problem. In future, we may
34774fea1aSStewart Smith		do more parsing in kernel and add more files to make
35774fea1aSStewart Smith		it easier for simple user space processes to extract
36774fea1aSStewart Smith		more information.
37774fea1aSStewart Smith
38774fea1aSStewart Smith		For each log entry (directory), there are the following
39774fea1aSStewart Smith		files:
40774fea1aSStewart Smith
4198913408SMauro Carvalho Chehab		==============  ================================================
42774fea1aSStewart Smith		id:		An ASCII representation of the ID of the
43774fea1aSStewart Smith				error log, in hex - e.g. "0x01".
44774fea1aSStewart Smith
45774fea1aSStewart Smith		type:		An ASCII representation of the type id and
46774fea1aSStewart Smith				description of the type of error log.
47774fea1aSStewart Smith				Currently just "0x00 PEL" - platform error log.
48774fea1aSStewart Smith				In the future there may be additional types.
49774fea1aSStewart Smith
50774fea1aSStewart Smith		raw:		A read-only binary file that can be read
51774fea1aSStewart Smith				to get the raw log entry. These are
52774fea1aSStewart Smith				<16kb, often just hundreds of bytes and
53774fea1aSStewart Smith				"average" 2kb.
54774fea1aSStewart Smith
55774fea1aSStewart Smith		acknowledge:	Writing 'ack' to this file will acknowledge
56774fea1aSStewart Smith				the error log to firmware (and in turn
57774fea1aSStewart Smith				the service processor, if applicable).
58774fea1aSStewart Smith				Shortly after acknowledging it, the log
59774fea1aSStewart Smith				entry will be removed from sysfs.
60774fea1aSStewart Smith				Reading this file will list the supported
6183432ef3SMasanari Iida				operations (currently just acknowledge).
6298913408SMauro Carvalho Chehab		==============  ================================================
63