Loading .mailmap +1 −0 Original line number Diff line number Diff line Loading @@ -99,6 +99,7 @@ Sachin P Sant <ssant@in.ibm.com> Sam Ravnborg <sam@mars.ravnborg.org> Sascha Hauer <s.hauer@pengutronix.de> S.Çağlar Onur <caglar@pardus.org.tr> Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com> Simon Kelley <simon@thekelleys.org.uk> Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr> Stephen Hemminger <shemminger@osdl.org> Loading CREDITS +16 −2 Original line number Diff line number Diff line Loading @@ -630,6 +630,13 @@ N: Michael Elizabeth Chastain E: mec@shout.net D: Configure, Menuconfig, xconfig N: Mauro Carvalho Chehab E: m.chehab@samsung.org E: mchehab@infradead.org D: Media subsystem (V4L/DVB) drivers and core D: EDAC drivers and EDAC 3.0 core rework S: Brazil N: Raymond Chen E: raymondc@microsoft.com D: Author of Configure script Loading Loading @@ -2560,10 +2567,14 @@ S: 22 Seaview St S: Fullarton 5063 S: South Australia N. Wolfgang Muees N: Wolfgang Muees E: wolfgang@iksw-muees.de D: Auerswald USB driver N: Paul Mundt E: paul.mundt@gmail.com D: SuperH maintainer N: Ian A. Murdock E: imurdock@gnu.ai.mit.edu D: Creator of Debian distribution Loading Loading @@ -2707,6 +2718,9 @@ N: Greg Page E: gpage@sovereign.org D: IPX development and support N: Venkatesh Pallipadi (Venki) D: x86/HPET N: David Parsons E: orc@pell.chi.il.us D: improved memory detection code. Loading Documentation/00-INDEX +0 −2 Original line number Diff line number Diff line Loading @@ -413,8 +413,6 @@ serial-console.txt - how to set up Linux with a serial line console as the default. sgi-ioc4.txt - description of the SGI IOC4 PCI (multi function) device. sgi-visws.txt - short blurb on the SGI Visual Workstations. sh/ - directory with info on porting Linux to a new architecture. smsc_ece1099.txt Loading Documentation/ABI/stable/sysfs-firmware-opal-dump 0 → 100644 +41 −0 Original line number Diff line number Diff line 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. Documentation/ABI/stable/sysfs-firmware-opal-elog 0 → 100644 +60 −0 Original line number Diff line number Diff line What: /sys/firmware/opal/elog Date: Feb 2014 Contact: Stewart Smith <stewart@linux.vnet.ibm.com> Description: This directory exposes error log entries retrieved through the OPAL firmware interface. Each error log is identified by a unique ID and will exist until explicitly acknowledged to firmware. Each log entry has a directory in /sys/firmware/opal/elog. Log entries may be purged by the service processor before retrieved by firmware or retrieved/acknowledged by Linux if there is no room for more log entries. In the event that Linux has retrieved the log entries but not explicitly acknowledged them to firmware and the service processor needs more room for log entries, the only remaining copy of a log message may be in Linux. Typically, a user space daemon will monitor for new entries, read them out and acknowledge them. The service processor may be able to store more log entries than firmware can, so after you acknowledge an event from Linux you may instantly get another one from the queue that was generated some time in the past. The raw log format is a binary format. We currently do not parse this at all in kernel, leaving it up to user space to solve the problem. In future, we may do more parsing in kernel and add more files to make it easier for simple user space processes to extract more information. For each log entry (directory), there are the following files: id: An ASCII representation of the ID of the error log, in hex - e.g. "0x01". type: An ASCII representation of the type id and description of the type of error log. Currently just "0x00 PEL" - platform error log. In the future there may be additional types. raw: A read-only binary file that can be read to get the raw log entry. These are <16kb, often just hundreds of bytes and "average" 2kb. acknowledge: Writing 'ack' to this file will acknowledge the error log to firmware (and in turn the service processor, if applicable). Shortly after acknowledging it, the log entry will be removed from sysfs. Reading this file will list the supported operations (curently just acknowledge). No newline at end of file Loading
.mailmap +1 −0 Original line number Diff line number Diff line Loading @@ -99,6 +99,7 @@ Sachin P Sant <ssant@in.ibm.com> Sam Ravnborg <sam@mars.ravnborg.org> Sascha Hauer <s.hauer@pengutronix.de> S.Çağlar Onur <caglar@pardus.org.tr> Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com> Simon Kelley <simon@thekelleys.org.uk> Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr> Stephen Hemminger <shemminger@osdl.org> Loading
CREDITS +16 −2 Original line number Diff line number Diff line Loading @@ -630,6 +630,13 @@ N: Michael Elizabeth Chastain E: mec@shout.net D: Configure, Menuconfig, xconfig N: Mauro Carvalho Chehab E: m.chehab@samsung.org E: mchehab@infradead.org D: Media subsystem (V4L/DVB) drivers and core D: EDAC drivers and EDAC 3.0 core rework S: Brazil N: Raymond Chen E: raymondc@microsoft.com D: Author of Configure script Loading Loading @@ -2560,10 +2567,14 @@ S: 22 Seaview St S: Fullarton 5063 S: South Australia N. Wolfgang Muees N: Wolfgang Muees E: wolfgang@iksw-muees.de D: Auerswald USB driver N: Paul Mundt E: paul.mundt@gmail.com D: SuperH maintainer N: Ian A. Murdock E: imurdock@gnu.ai.mit.edu D: Creator of Debian distribution Loading Loading @@ -2707,6 +2718,9 @@ N: Greg Page E: gpage@sovereign.org D: IPX development and support N: Venkatesh Pallipadi (Venki) D: x86/HPET N: David Parsons E: orc@pell.chi.il.us D: improved memory detection code. Loading
Documentation/00-INDEX +0 −2 Original line number Diff line number Diff line Loading @@ -413,8 +413,6 @@ serial-console.txt - how to set up Linux with a serial line console as the default. sgi-ioc4.txt - description of the SGI IOC4 PCI (multi function) device. sgi-visws.txt - short blurb on the SGI Visual Workstations. sh/ - directory with info on porting Linux to a new architecture. smsc_ece1099.txt Loading
Documentation/ABI/stable/sysfs-firmware-opal-dump 0 → 100644 +41 −0 Original line number Diff line number Diff line 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.
Documentation/ABI/stable/sysfs-firmware-opal-elog 0 → 100644 +60 −0 Original line number Diff line number Diff line What: /sys/firmware/opal/elog Date: Feb 2014 Contact: Stewart Smith <stewart@linux.vnet.ibm.com> Description: This directory exposes error log entries retrieved through the OPAL firmware interface. Each error log is identified by a unique ID and will exist until explicitly acknowledged to firmware. Each log entry has a directory in /sys/firmware/opal/elog. Log entries may be purged by the service processor before retrieved by firmware or retrieved/acknowledged by Linux if there is no room for more log entries. In the event that Linux has retrieved the log entries but not explicitly acknowledged them to firmware and the service processor needs more room for log entries, the only remaining copy of a log message may be in Linux. Typically, a user space daemon will monitor for new entries, read them out and acknowledge them. The service processor may be able to store more log entries than firmware can, so after you acknowledge an event from Linux you may instantly get another one from the queue that was generated some time in the past. The raw log format is a binary format. We currently do not parse this at all in kernel, leaving it up to user space to solve the problem. In future, we may do more parsing in kernel and add more files to make it easier for simple user space processes to extract more information. For each log entry (directory), there are the following files: id: An ASCII representation of the ID of the error log, in hex - e.g. "0x01". type: An ASCII representation of the type id and description of the type of error log. Currently just "0x00 PEL" - platform error log. In the future there may be additional types. raw: A read-only binary file that can be read to get the raw log entry. These are <16kb, often just hundreds of bytes and "average" 2kb. acknowledge: Writing 'ack' to this file will acknowledge the error log to firmware (and in turn the service processor, if applicable). Shortly after acknowledging it, the log entry will be removed from sysfs. Reading this file will list the supported operations (curently just acknowledge). No newline at end of file
