Merge git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial (63589ed0) · Commits · e / devices / android_kernel_oneplus_sm7250

Documentation/DocBook/Makefile

+1 −1

Original line number	Original line	Diff line number	Diff line
	@@ -2,7 +2,7 @@
	# This makefile is used to generate the kernel documentation,		# This makefile is used to generate the kernel documentation,
	# primarily based on in-line comments in various source files.		# primarily based on in-line comments in various source files.
	# See Documentation/kernel-doc-nano-HOWTO.txt for instruction in how		# See Documentation/kernel-doc-nano-HOWTO.txt for instruction in how
	# to ducument the SRC - and how to read it.		# to document the SRC - and how to read it.
	# To add a new book the only step required is to add the book to the		# To add a new book the only step required is to add the book to the
	# list of DOCBOOKS.		# list of DOCBOOKS.

Documentation/DocBook/kernel-api.tmpl

+0 −1

Original line number	Original line	Diff line number	Diff line
	@@ -322,7 +322,6 @@ X!Earch/i386/kernel/mca.c
	<chapter id="sysfs">		<chapter id="sysfs">
	<title>The Filesystem for Exporting Kernel Objects</title>		<title>The Filesystem for Exporting Kernel Objects</title>
	!Efs/sysfs/file.c		!Efs/sysfs/file.c
	!Efs/sysfs/dir.c
	!Efs/sysfs/symlink.c		!Efs/sysfs/symlink.c
	!Efs/sysfs/bin.c		!Efs/sysfs/bin.c
	</chapter>		</chapter>

Documentation/acpi-hotkey.txt

+1 −1

Original line number	Original line	Diff line number	Diff line
	@@ -30,7 +30,7 @@ specific hotkey(event))
	echo "event_num:event_type:event_argument" >		echo "event_num:event_type:event_argument" >
	/proc/acpi/hotkey/action.		/proc/acpi/hotkey/action.
	The result of the execution of this aml method is		The result of the execution of this aml method is
	attached to /proc/acpi/hotkey/poll_method, which is dnyamically		attached to /proc/acpi/hotkey/poll_method, which is dynamically
	created. Please use command "cat /proc/acpi/hotkey/polling_method"		created. Please use command "cat /proc/acpi/hotkey/polling_method"
	to retrieve it.		to retrieve it.

Documentation/fujitsu/frv/kernel-ABI.txt

+110 −82

Original line number	Original line	Diff line number	Diff line
	@@ -2,16 +2,18 @@
	INTERNAL KERNEL ABI FOR FR-V ARCH		INTERNAL KERNEL ABI FOR FR-V ARCH
	=================================		=================================

	The internal FRV kernel ABI is not quite the same as the userspace ABI. A number of the registers		The internal FRV kernel ABI is not quite the same as the userspace ABI. A
	are used for special purposed, and the ABI is not consistent between modules vs core, and MMU vs		number of the registers are used for special purposed, and the ABI is not
	no-MMU.		consistent between modules vs core, and MMU vs no-MMU.

	This partly stems from the fact that FRV CPUs do not have a separate supervisor stack pointer, and		This partly stems from the fact that FRV CPUs do not have a separate
	most of them do not have any scratch registers, thus requiring at least one general purpose		supervisor stack pointer, and most of them do not have any scratch
	register to be clobbered in such an event. Also, within the kernel core, it is possible to simply		registers, thus requiring at least one general purpose register to be
	jump or call directly between functions using a relative offset. This cannot be extended to modules		clobbered in such an event. Also, within the kernel core, it is possible to
	for the displacement is likely to be too far. Thus in modules the address of a function to call		simply jump or call directly between functions using a relative offset.
	must be calculated in a register and then used, requiring two extra instructions.		This cannot be extended to modules for the displacement is likely to be too
			far. Thus in modules the address of a function to call must be calculated
			in a register and then used, requiring two extra instructions.

	This document has the following sections:		This document has the following sections:

	@@ -39,7 +41,8 @@ When a system call is made, the following registers are effective:
	CPU OPERATING MODES		CPU OPERATING MODES
	===================		===================

	The FR-V CPU has three basic operating modes. In order of increasing capability:		The FR-V CPU has three basic operating modes. In order of increasing
			capability:

	(1) User mode.		(1) User mode.

	@@ -47,42 +50,46 @@ The FR-V CPU has three basic operating modes. In order of increasing capability:

	(2) Kernel mode.		(2) Kernel mode.

	Normal kernel mode. There are many additional control registers available that may be		Normal kernel mode. There are many additional control registers
	accessed in this mode, in addition to all the stuff available to user mode. This has two		available that may be accessed in this mode, in addition to all the
	submodes:		stuff available to user mode. This has two submodes:

	(a) Exceptions enabled (PSR.T == 1).		(a) Exceptions enabled (PSR.T == 1).

	Exceptions will invoke the appropriate normal kernel mode handler. On entry to the		Exceptions will invoke the appropriate normal kernel mode
	handler, the PSR.T bit will be cleared.		handler. On entry to the handler, the PSR.T bit will be cleared.

	(b) Exceptions disabled (PSR.T == 0).		(b) Exceptions disabled (PSR.T == 0).

	No exceptions or interrupts may happen. Any mandatory exceptions will cause the CPU to		No exceptions or interrupts may happen. Any mandatory exceptions
	halt unless the CPU is told to jump into debug mode instead.		will cause the CPU to halt unless the CPU is told to jump into
			debug mode instead.

	(3) Debug mode.		(3) Debug mode.

	No exceptions may happen in this mode. Memory protection and management exceptions will be		No exceptions may happen in this mode. Memory protection and
	flagged for later consideration, but the exception handler won't be invoked. Debugging traps		management exceptions will be flagged for later consideration, but
	such as hardware breakpoints and watchpoints will be ignored. This mode is entered only by		the exception handler won't be invoked. Debugging traps such as
	debugging events obtained from the other two modes.		hardware breakpoints and watchpoints will be ignored. This mode is
			entered only by debugging events obtained from the other two modes.

	All kernel mode registers may be accessed, plus a few extra debugging specific registers.		All kernel mode registers may be accessed, plus a few extra debugging
			specific registers.


	=================================		=================================
	INTERNAL KERNEL-MODE REGISTER ABI		INTERNAL KERNEL-MODE REGISTER ABI
	=================================		=================================

	There are a number of permanent register assignments that are set up by entry.S in the exception		There are a number of permanent register assignments that are set up by
	prologue. Note that there is a complete set of exception prologues for each of user->kernel		entry.S in the exception prologue. Note that there is a complete set of
	transition and kernel->kernel transition. There are also user->debug and kernel->debug mode		exception prologues for each of user->kernel transition and kernel->kernel
	transition prologues.		transition. There are also user->debug and kernel->debug mode transition
			prologues.


	REGISTER FLAVOUR USE		REGISTER FLAVOUR USE
	=============== ======= ====================================================		=============== ======= ==============================================
	GR1 Supervisor stack pointer		GR1 Supervisor stack pointer
	GR15 Current thread info pointer		GR15 Current thread info pointer
	GR16 GP-Rel base register for small data		GR16 GP-Rel base register for small data
	@@ -92,10 +99,12 @@ transition prologues.
	GR31 NOMMU Destroyed by debug mode entry		GR31 NOMMU Destroyed by debug mode entry
	GR31 MMU Destroyed by TLB miss kernel mode entry		GR31 MMU Destroyed by TLB miss kernel mode entry
	CCR.ICC2 Virtual interrupt disablement tracking		CCR.ICC2 Virtual interrupt disablement tracking
	CCCR.CC3 Cleared by exception prologue (atomic op emulation)		CCCR.CC3 Cleared by exception prologue
			(atomic op emulation)
	SCR0 MMU See mmu-layout.txt.		SCR0 MMU See mmu-layout.txt.
	SCR1 MMU See mmu-layout.txt.		SCR1 MMU See mmu-layout.txt.
	SCR2 MMU Save for EAR0 (destroyed by icache insns in debug mode)		SCR2 MMU Save for EAR0 (destroyed by icache insns
			in debug mode)
	SCR3 MMU Save for GR31 during debug exceptions		SCR3 MMU Save for GR31 during debug exceptions
	DAMR/IAMR NOMMU Fixed memory protection layout.		DAMR/IAMR NOMMU Fixed memory protection layout.
	DAMR/IAMR MMU See mmu-layout.txt.		DAMR/IAMR MMU See mmu-layout.txt.
	@@ -104,18 +113,21 @@ transition prologues.
	Certain registers are also used or modified across function calls:		Certain registers are also used or modified across function calls:

	REGISTER CALL RETURN		REGISTER CALL RETURN
	=============== =============================== ===============================		=============== =============================== ======================
	GR0 Fixed Zero -		GR0 Fixed Zero -
	GR2 Function call frame pointer		GR2 Function call frame pointer
	GR3 Special Preserved		GR3 Special Preserved
	GR3-GR7 - Clobbered		GR3-GR7 - Clobbered
	GR8 Function call arg #1 Return value (or clobbered)		GR8 Function call arg #1 Return value
	GR9 Function call arg #2 Return value MSW (or clobbered)		(or clobbered)
			GR9 Function call arg #2 Return value MSW
			(or clobbered)
	GR10-GR13 Function call arg #3-#6 Clobbered		GR10-GR13 Function call arg #3-#6 Clobbered
	GR14 - Clobbered		GR14 - Clobbered
	GR15-GR16 Special Preserved		GR15-GR16 Special Preserved
	GR17-GR27 - Preserved		GR17-GR27 - Preserved
	GR28-GR31 Special Only accessed explicitly		GR28-GR31 Special Only accessed
			explicitly
	LR Return address after CALL Clobbered		LR Return address after CALL Clobbered
	CCR/CCCR - Mostly Clobbered		CCR/CCCR - Mostly Clobbered

	@@ -124,46 +136,53 @@ Certain registers are also used or modified across function calls:
	INTERNAL DEBUG-MODE REGISTER ABI		INTERNAL DEBUG-MODE REGISTER ABI
	================================		================================

	This is the same as the kernel-mode register ABI for functions calls. The difference is that in		This is the same as the kernel-mode register ABI for functions calls. The
	debug-mode there's a different stack and a different exception frame. Almost all the global		difference is that in debug-mode there's a different stack and a different
	registers from kernel-mode (including the stack pointer) may be changed.		exception frame. Almost all the global registers from kernel-mode
			(including the stack pointer) may be changed.

	REGISTER FLAVOUR USE		REGISTER FLAVOUR USE
	=============== ======= ====================================================		=============== ======= ==============================================
	GR1 Debug stack pointer		GR1 Debug stack pointer
	GR16 GP-Rel base register for small data		GR16 GP-Rel base register for small data
	GR31 Current debug exception frame pointer (__debug_frame)		GR31 Current debug exception frame pointer
			(__debug_frame)
	SCR3 MMU Saved value of GR31		SCR3 MMU Saved value of GR31


	Note that debug mode is able to interfere with the kernel's emulated atomic ops, so it must be		Note that debug mode is able to interfere with the kernel's emulated atomic
	exceedingly careful not to do any that would interact with the main kernel in this regard. Hence		ops, so it must be exceedingly careful not to do any that would interact
	the debug mode code (gdbstub) is almost completely self-contained. The only external code used is		with the main kernel in this regard. Hence the debug mode code (gdbstub) is
	the sprintf family of functions.		almost completely self-contained. The only external code used is the
			sprintf family of functions.

	Futhermore, break.S is so complicated because single-step mode does not switch off on entry to an		Futhermore, break.S is so complicated because single-step mode does not
	exception. That means unless manually disabled, single-stepping will blithely go on stepping into		switch off on entry to an exception. That means unless manually disabled,
	things like interrupts. See gdbstub.txt for more information.		single-stepping will blithely go on stepping into things like interrupts.
			See gdbstub.txt for more information.


	==========================		==========================
	VIRTUAL INTERRUPT HANDLING		VIRTUAL INTERRUPT HANDLING
	==========================		==========================

	Because accesses to the PSR is so slow, and to disable interrupts we have to access it twice (once		Because accesses to the PSR is so slow, and to disable interrupts we have
	to read and once to write), we don't actually disable interrupts at all if we don't have to. What		to access it twice (once to read and once to write), we don't actually
	we do instead is use the ICC2 condition code flags to note virtual disablement, such that if we		disable interrupts at all if we don't have to. What we do instead is use
	then do take an interrupt, we note the flag, really disable interrupts, set another flag and resume		the ICC2 condition code flags to note virtual disablement, such that if we
	execution at the point the interrupt happened. Setting condition flags as a side effect of an		then do take an interrupt, we note the flag, really disable interrupts, set
	arithmetic or logical instruction is really fast. This use of the ICC2 only occurs within the		another flag and resume execution at the point the interrupt happened.
			Setting condition flags as a side effect of an arithmetic or logical
			instruction is really fast. This use of the ICC2 only occurs within the
	kernel - it does not affect userspace.		kernel - it does not affect userspace.

	The flags we use are:		The flags we use are:

	(*) CCR.ICC2.Z [Zero flag]		(*) CCR.ICC2.Z [Zero flag]

	Set to virtually disable interrupts, clear when interrupts are virtually enabled. Can be		Set to virtually disable interrupts, clear when interrupts are
	modified by logical instructions without affecting the Carry flag.		virtually enabled. Can be modified by logical instructions without
			affecting the Carry flag.

	(*) CCR.ICC2.C [Carry flag]		(*) CCR.ICC2.C [Carry flag]

	@@ -176,8 +195,9 @@ What happens is this:

	ICC2.Z is 0, ICC2.C is 1.		ICC2.Z is 0, ICC2.C is 1.

	(2) An interrupt occurs. The exception prologue examines ICC2.Z and determines that nothing needs		(2) An interrupt occurs. The exception prologue examines ICC2.Z and
	doing. This is done simply with an unlikely BEQ instruction.		determines that nothing needs doing. This is done simply with an
			unlikely BEQ instruction.

	(3) The interrupts are disabled (local_irq_disable)		(3) The interrupts are disabled (local_irq_disable)

	@@ -187,48 +207,56 @@ What happens is this:

	ICC2.Z would be set to 0.		ICC2.Z would be set to 0.

	A TIHI #2 instruction (trap #2 if condition HI - Z==0 && C==0) would be used to trap if		A TIHI #2 instruction (trap #2 if condition HI - Z==0 && C==0) would
	interrupts were now virtually enabled, but physically disabled - which they're not, so the		be used to trap if interrupts were now virtually enabled, but
	trap isn't taken. The kernel would then be back to state (1).		physically disabled - which they're not, so the trap isn't taken. The
			kernel would then be back to state (1).

	(5) An interrupt occurs. The exception prologue examines ICC2.Z and determines that the interrupt		(5) An interrupt occurs. The exception prologue examines ICC2.Z and
	shouldn't actually have happened. It jumps aside, and there disabled interrupts by setting		determines that the interrupt shouldn't actually have happened. It
	PSR.PIL to 14 and then it clears ICC2.C.		jumps aside, and there disabled interrupts by setting PSR.PIL to 14
			and then it clears ICC2.C.

	(6) If interrupts were then saved and disabled again (local_irq_save):		(6) If interrupts were then saved and disabled again (local_irq_save):

	ICC2.Z would be shifted into the save variable and masked off (giving a 1).		ICC2.Z would be shifted into the save variable and masked off
			(giving a 1).

	ICC2.Z would then be set to 1 (thus unchanged), and ICC2.C would be unaffected (ie: 0).		ICC2.Z would then be set to 1 (thus unchanged), and ICC2.C would be
			unaffected (ie: 0).

	(7) If interrupts were then restored from state (6) (local_irq_restore):		(7) If interrupts were then restored from state (6) (local_irq_restore):

	ICC2.Z would be set to indicate the result of XOR'ing the saved value (ie: 1) with 1, which		ICC2.Z would be set to indicate the result of XOR'ing the saved
	gives a result of 0 - thus leaving ICC2.Z set.		value (ie: 1) with 1, which gives a result of 0 - thus leaving
			ICC2.Z set.

	ICC2.C would remain unaffected (ie: 0).		ICC2.C would remain unaffected (ie: 0).

	A TIHI #2 instruction would be used to again assay the current state, but this would do		A TIHI #2 instruction would be used to again assay the current state,
	nothing as Z==1.		but this would do nothing as Z==1.

	(8) If interrupts were then enabled (local_irq_enable):		(8) If interrupts were then enabled (local_irq_enable):

	ICC2.Z would be cleared. ICC2.C would be left unaffected. Both flags would now be 0.		ICC2.Z would be cleared. ICC2.C would be left unaffected. Both
			flags would now be 0.

	A TIHI #2 instruction again issued to assay the current state would then trap as both Z==0		A TIHI #2 instruction again issued to assay the current state would
	[interrupts virtually enabled] and C==0 [interrupts really disabled] would then be true.		then trap as both Z==0 [interrupts virtually enabled] and C==0
			[interrupts really disabled] would then be true.

	(9) The trap #2 handler would simply enable hardware interrupts (set PSR.PIL to 0), set ICC2.C to		(9) The trap #2 handler would simply enable hardware interrupts
	1 and return.		(set PSR.PIL to 0), set ICC2.C to 1 and return.

	(10) Immediately upon returning, the pending interrupt would be taken.		(10) Immediately upon returning, the pending interrupt would be taken.

	(11) The interrupt handler would take the path of actually processing the interrupt (ICC2.Z is		(11) The interrupt handler would take the path of actually processing the
	clear, BEQ fails as per step (2)).		interrupt (ICC2.Z is clear, BEQ fails as per step (2)).

	(12) The interrupt handler would then set ICC2.C to 1 since hardware interrupts are definitely		(12) The interrupt handler would then set ICC2.C to 1 since hardware
	enabled - or else the kernel wouldn't be here.		interrupts are definitely enabled - or else the kernel wouldn't be here.

	(13) On return from the interrupt handler, things would be back to state (1).		(13) On return from the interrupt handler, things would be back to state (1).

	This trap (#2) is only available in kernel mode. In user mode it will result in SIGILL.		This trap (#2) is only available in kernel mode. In user mode it will
			result in SIGILL.

Documentation/kernel-parameters.txt

+14 −20

Original line number	Original line	Diff line number	Diff line
	February 2003 Kernel Parameters v2.5.59		Kernel Parameters
	~~~~~~~~~~~~~~~~~		~~~~~~~~~~~~~~~~~

	The following is a consolidated list of the kernel parameters as implemented		The following is a consolidated list of the kernel parameters as implemented
	@@ -17,9 +17,17 @@ are specified on the kernel command line with the module name plus

	usbcore.blinkenlights=1		usbcore.blinkenlights=1

	The text in square brackets at the beginning of the description states the		This document may not be entirely up to date and comprehensive. The command
	restrictions on the kernel for the said kernel parameter to be valid. The		"modinfo -p ${modulename}" shows a current list of all parameters of a loadable
	restrictions referred to are that the relevant option is valid if:		module. Loadable modules, after being loaded into the running kernel, also
			reveal their parameters in /sys/module/${modulename}/parameters/. Some of these
			parameters may be changed at runtime by the command
			"echo -n ${value} > /sys/module/${modulename}/parameters/${parm}".

			The parameters listed below are only valid if certain kernel build options were
			enabled and if respective hardware is present. The text in square brackets at
			the beginning of each description states the restrictions within which a
			parameter is applicable:

	ACPI ACPI support is enabled.		ACPI ACPI support is enabled.
	ALSA ALSA sound support is enabled.		ALSA ALSA sound support is enabled.
	@@ -1046,10 +1054,10 @@ running once the system is up.
	noltlbs [PPC] Do not use large page/tlb entries for kernel		noltlbs [PPC] Do not use large page/tlb entries for kernel
	lowmem mapping on PPC40x.		lowmem mapping on PPC40x.

	nomce [IA-32] Machine Check Exception

	nomca [IA-64] Disable machine check abort handling		nomca [IA-64] Disable machine check abort handling

			nomce [IA-32] Machine Check Exception

	noresidual [PPC] Don't use residual data on PReP machines.		noresidual [PPC] Don't use residual data on PReP machines.

	noresume [SWSUSP] Disables resume and restores original swap		noresume [SWSUSP] Disables resume and restores original swap
	@@ -1682,20 +1690,6 @@ running once the system is up.


	______________________________________________________________________		______________________________________________________________________
	Changelog:

	2000-06-?? Mr. Unknown
	The last known update (for 2.4.0) - the changelog was not kept before.

	2002-11-24 Petr Baudis <pasky@ucw.cz>
	Randy Dunlap <randy.dunlap@verizon.net>
	Update for 2.5.49, description for most of the options introduced,
	references to other documentation (C files, READMEs, ..), added S390,
	PPC, SPARC, MTD, ALSA and OSS category. Minor corrections and
	reformatting.

	2005-10-19 Randy Dunlap <rdunlap@xenotime.net>
	Lots of typos, whitespace, some reformatting.

	TODO:		TODO: