linux-yocto/sysfs-firmware-opal-dump at 00fec2a10b51a071ec92da256ccd30f6b13fc55b

mirror of git://git.yoctoproject.org/linux-yocto.git synced 2025-07-07 22:35:42 +02:00

Stewart Smith c7e64b9ce0 powerpc/powernv Platform dump interface

This enables support for userspace to fetch and initiate FSP and
Platform dumps from the service processor (via firmware) through sysfs.

Based on original patch from Vasant Hegde <hegdevasant@linux.vnet.ibm.com>

Flow:
  - We register for OPAL notification events.
  - OPAL sends new dump available notification.
  - We make information on dump available via sysfs
  - Userspace requests dump contents
  - We retrieve the dump via OPAL interface
  - User copies the dump data
  - userspace sends ack for dump
  - We send ACK to OPAL.

sysfs files:
  - We add the /sys/firmware/opal/dump directory
  - echoing 1 (well, anything, but in future we may support
    different dump types) to /sys/firmware/opal/dump/initiate_dump
    will initiate a dump.
  - Each dump that we've been notified of gets a directory
    in /sys/firmware/opal/dump/ with a name of the dump type and ID (in hex,
    as this is what's used elsewhere to identify the dump).
  - Each dump has files: id, type, dump and acknowledge
    dump is binary and is the dump itself.
    echoing 'ack' to acknowledge (currently any string will do) will
    acknowledge the dump and it will soon after disappear from sysfs.

OPAL APIs:
  - opal_dump_init()
  - opal_dump_info()
  - opal_dump_read()
  - opal_dump_ack()
  - opal_dump_resend_notification()

Currently we are only ever notified for one dump at a time (until
the user explicitly acks the current dump, then we get a notification
of the next dump), but this kernel code should "just work" when OPAL
starts notifying us of all the dumps present.

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

2014-03-07 16:19:10 +11:00

1.5 KiB

Raw Blame History

What: /sys/firmware/opal/dump Date: Feb 2014 Contact: Stewart Smith stewart@linux.vnet.ibm.com Description: This directory exposes interfaces for interacting with the FSP and platform dumps through OPAL firmware interface.

	This is only for the powerpc/powernv platform.

	initiate_dump:	When '1' is written to it,
			we will initiate a dump.
			Read this file for supported commands.

	0xXX-0xYYYY:	A directory for dump of type 0xXX and
			id 0xYYYY (in hex). The name of this
			directory should not be relied upon to
			be in this format, only that it's unique
			among all dumps. For determining the type
			and ID of the dump, use the id and type files.
			Do not rely on any particular size of dump
			type or dump id.

	Each dump has the following files:
	id:		An ASCII representation of the dump ID
			in hex (e.g. '0x01')
	type:		An ASCII representation of the type of
			dump in the format "0x%x %s" with the ID
			in hex and a description of the dump type
			(or 'unknown').
			Type '0xffffffff unknown' is used when
			we could not get the type from firmware.
			e.g. '0x02 System/Platform Dump'
	dump:		A binary file containing the dump.
			The size of the dump is the size of this file.
	acknowledge:	When 'ack' is written to this, we will
			acknowledge that we've retrieved the
			dump to the service processor. It will
			then remove it, making the dump
			inaccessible.
			Reading this file will get a list of
			supported actions.

1.5 KiB Raw Blame History

1.5 KiB

Raw Blame History