---

yaml
---
r: 48652
b: refs/heads/master
c: b60f16e
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: f8abea8f8c24ecdad6d6861bffb912f23f2741cd
+refs/heads/master: b60f16eb56ff872a86c55c11bcfd430ce8cec340

trunk/Documentation/gpio.txt

@@ -78,8 +78,7 @@ Identifying GPIOs
 -----------------
 GPIOs are identified by unsigned integers in the range 0..MAX_INT.  That
 reserves "negative" numbers for other purposes like marking signals as
-"not available on this board", or indicating faults.  Code that doesn't
-touch the underlying hardware treats these integers as opaque cookies.
+"not available on this board", or indicating faults.
 
 Platforms define how they use those integers, and usually #define symbols
 for the GPIO lines so that board-specific setup code directly corresponds
@@ -140,10 +139,10 @@ issues including wire-OR and output latencies.
 The get/set calls have no error returns because "invalid GPIO" should have
 been reported earlier in gpio_set_direction().  However, note that not all
 platforms can read the value of output pins; those that can't should always
-return zero.  Also, using these calls for GPIOs that can't safely be accessed
-without sleeping (see below) is an error.
+return zero.  Also, these calls will be ignored for GPIOs that can't safely
+be accessed wihtout sleeping (see below).
 
-Platform-specific implementations are encouraged to optimize the two
+Platform-specific implementations are encouraged to optimise the two
 calls to access the GPIO value in cases where the GPIO number (and for
 output, value) are constant.  It's normal for them to need only a couple
 of instructions in such cases (reading or writing a hardware register),
@@ -240,8 +239,7 @@ options are part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are
 system wakeup capabilities.
 
 Non-error values returned from irq_to_gpio() would most commonly be used
-with gpio_get_value(), for example to initialize or update driver state
-when the IRQ is edge-triggered.
+with gpio_get_value().
 
 
 
@@ -262,10 +260,9 @@ pullups (or pulldowns) so that the on-chip ones should not be used.
 There are other system-specific mechanisms that are not specified here,
 like the aforementioned options for input de-glitching and wire-OR output.
 Hardware may support reading or writing GPIOs in gangs, but that's usually
-configuration dependent:  for GPIOs sharing the same bank.  (GPIOs are
+configuration dependednt:  for GPIOs sharing the same bank.  (GPIOs are
 commonly grouped in banks of 16 or 32, with a given SOC having several such
-banks.)  Some systems can trigger IRQs from output GPIOs.  Code relying on
-such mechanisms will necessarily be nonportable.
+banks.)  Code relying on such mechanisms will necessarily be nonportable.
 
 Dynamic definition of GPIOs is not currently supported; for example, as
 a side effect of configuring an add-on board with some GPIO expanders.

trunk/Documentation/kernel-parameters.txt

@@ -609,10 +609,6 @@ and is between 256 and 4096 characters. It is defined in the file
 			highmem otherwise. This also works to reduce highmem
 			size on bigger boxes.
 
-	highres=	[KNL] Enable/disable high resolution timer mode.
-			Valid parameters: "on", "off"
-			Default: "on"
-
 	hisax=		[HW,ISDN]
 			See Documentation/isdn/README.HiSax.
 
@@ -1082,10 +1078,6 @@ and is between 256 and 4096 characters. It is defined in the file
 			in certain environments such as networked servers or
 			real-time systems.
 
-	nohz=		[KNL] Boottime enable/disable dynamic ticks
-			Valid arguments: on, off
-			Default: on
-
 	noirqbalance	[IA-32,SMP,KNL] Disable kernel irq balancing
 
 	noirqdebug	[IA-32] Disables the code which attempts to detect and