Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 8ace5c46 authored by Paul Mundt's avatar Paul Mundt
Browse files

Merge branch 'master' of... 

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 into sh-latest
parents a375b151 71a86384

Documentation/00-INDEX

+0 −2
Original line number Diff line number Diff line
@@ -328,8 +328,6 @@ sysrq.txt 
	- info on the magic SysRq key.

telephony/

	- directory with info on telephony (e.g. voice over IP) support.

uml/

	- directory with information about User Mode Linux.

unicode.txt

	- info on the Unicode character/font mapping used in Linux.

unshare.txt

Documentation/ABI/testing/sysfs-bus-bcma

0 → 100644
+31 −0
Original line number Diff line number Diff line 
What:		/sys/bus/bcma/devices/.../manuf

Date:		May 2011

KernelVersion:	2.6.40

Contact:	Rafał Miłecki <zajec5@gmail.com>

Description:

		Each BCMA core has it's manufacturer id. See

		include/linux/bcma/bcma.h for possible values.



What:		/sys/bus/bcma/devices/.../id

Date:		May 2011

KernelVersion:	2.6.40

Contact:	Rafał Miłecki <zajec5@gmail.com>

Description:

		There are a few types of BCMA cores, they can be identified by

		id field.



What:		/sys/bus/bcma/devices/.../rev

Date:		May 2011

KernelVersion:	2.6.40

Contact:	Rafał Miłecki <zajec5@gmail.com>

Description:

		BCMA cores of the same type can still slightly differ depending

		on their revision. Use it for detailed programming.



What:		/sys/bus/bcma/devices/.../class

Date:		May 2011

KernelVersion:	2.6.40

Contact:	Rafał Miłecki <zajec5@gmail.com>

Description:

		Each BCMA core is identified by few fields, including class it

		belongs to. See include/linux/bcma/bcma.h for possible values.

Documentation/ABI/testing/sysfs-devices-system-cpu

+17 −17
Original line number Diff line number Diff line
@@ -183,21 +183,21 @@ Description: Discover and change clock speed of CPUs 
		to learn how to control the knobs.





What:      /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X

What:		/sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1}

Date:		August 2008

KernelVersion:	2.6.27

Contact:	mark.langsdorf@amd.com

Description:	These files exist in every cpu's cache index directories.

		There are currently 2 cache_disable_# files in each

		directory.  Reading from these files on a supported

		processor will return that cache disable index value

		for that processor and node.  Writing to one of these

		files will cause the specificed cache index to be disabled.



		Currently, only AMD Family 10h Processors support cache index

		disable, and only for their L3 caches.  See the BIOS and

		Kernel Developer's Guide at

		http://support.amd.com/us/Embedded_TechDocs/31116-Public-GH-BKDG_3-28_5-28-09.pdf	

		for formatting information and other details on the

		cache index disable.

Users:    joachim.deguara@amd.com
 
Contact:	discuss@x86-64.org

Description:	Disable L3 cache indices



		These files exist in every CPU's cache/index3 directory. Each

		cache_disable_{0,1} file corresponds to one disable slot which

		can be used to disable a cache index. Reading from these files

		on a processor with this functionality will return the currently

		disabled index for that node. There is one L3 structure per

		node, or per internal node on MCM machines. Writing a valid

		index to one of these files will cause the specificed cache

		index to be disabled.



		All AMD processors with L3 caches provide this functionality.

		For details, see BKDGs at

		http://developer.amd.com/documentation/guides/Pages/default.aspx

Documentation/ABI/testing/sysfs-firmware-dmi

+9 −9
Original line number Diff line number Diff line
@@ -14,14 +14,15 @@ Description: 


		DMI is structured as a large table of entries, where

		each entry has a common header indicating the type and

		length of the entry, as well as 'handle' that is

		supposed to be unique amongst all entries.

		length of the entry, as well as a firmware-provided

		'handle' that is supposed to be unique amongst all

		entries.



		Some entries are required by the specification, but many

		others are optional.  In general though, users should

		never expect to find a specific entry type on their

		system unless they know for certain what their firmware

		is doing.  Machine to machine will vary.

		is doing.  Machine to machine experiences will vary.



		Multiple entries of the same type are allowed.  In order

		to handle these duplicate entry types, each entry is
@@ -67,25 +68,24 @@ Description: 
			  and the two terminating nul characters.

		type	: The type of the entry.  This value is the same

			  as found in the directory name.  It indicates

			  how the rest of the entry should be

			  interpreted.

			  how the rest of the entry should be interpreted.

		instance: The instance ordinal of the entry for the

			  given type.  This value is the same as found

			  in the parent directory name.

		position: The position of the entry within the entirety

			  of the entirety.

		position: The ordinal position (zero-based) of the entry

			  within the entirety of the DMI entry table.



		=== Entry Specialization ===



		Some entry types may have other information available in

		sysfs.

		sysfs.  Not all types are specialized.



		--- Type 15 - System Event Log ---



		This entry allows the firmware to export a log of

		events the system has taken.  This information is

		typically backed by nvram, but the implementation

		details are abstracted by this table.  This entries data

		details are abstracted by this table.  This entry's data

		is exported in the directory:



		/sys/firmware/dmi/entries/15-0/system_event_log

Documentation/ABI/testing/sysfs-firmware-gsmi

0 → 100644
+58 −0
Original line number Diff line number Diff line 
What:		/sys/firmware/gsmi

Date:		March 2011

Contact:	Mike Waychison <mikew@google.com>

Description:

		Some servers used internally at Google have firmware

		that provides callback functionality via explicit SMI

		triggers.  Some of the callbacks are similar to those

		provided by the EFI runtime services page, but due to

		historical reasons this different entry-point has been

		used.



		The gsmi driver implements the kernel's abstraction for

		these firmware callbacks.  Currently, this functionality

		is limited to handling the system event log and getting

		access to EFI-style variables stored in nvram.



		Layout:



		/sys/firmware/gsmi/vars:



			This directory has the same layout (and

			underlying implementation as /sys/firmware/efi/vars.

			See Documentation/ABI/*/sysfs-firmware-efi-vars

			for more information on how to interact with

			this structure.



		/sys/firmware/gsmi/append_to_eventlog - write-only:



			This file takes a binary blob and passes it onto

			the firmware to be timestamped and appended to

			the system eventlog.  The binary format is

			interpreted by the firmware and may change from

			platform to platform.  The only kernel-enforced

			requirement is that the blob be prefixed with a

			32bit host-endian type used as part of the

			firmware call.



		/sys/firmware/gsmi/clear_config - write-only:



			Writing any value to this file will cause the

			entire firmware configuration to be reset to

			"factory defaults".  Callers should assume that

			a reboot is required for the configuration to be

			cleared.



		/sys/firmware/gsmi/clear_eventlog - write-only:



			This file is used to clear out a portion/the

			whole of the system event log.  Values written

			should be values between 1 and 100 inclusive (in

			ASCII) representing the fraction of the log to

			clear.  Not all platforms support fractional

			clearing though, and this writes to this file

			will error out if the firmware doesn't like your

			submitted fraction.



			Callers should assume that a reboot is needed

			for this operation to complete.