[PATCH 0/4] Trivial GPIO/pinctrl documentation fixes

[PATCH 0/4] Trivial GPIO/pinctrl documentation fixes

[Andrew Jeffery]

Hi all,

The patches fix some file paths and minor grammatical issues in the
GPIO/pinctrl documentation. Patches 3 and 4 are separate to ease review.

Cheers,

Andrew

Andrew Jeffery (4):
  drivers-on-gpio.txt: Fix paths to GPIO driver source files
  pinctrl.txt: Fix grammar in pinmux request list
  pinctrl.txt: s/have/has/ in GPIO driver interaction description
  pinctrl.txt: Reflow/wrap paragraph describing GPIO interaction

 Documentation/gpio/drivers-on-gpio.txt | 13 +++++++------
 Documentation/pinctrl.txt              | 22 +++++++++++-----------
 2 files changed, 18 insertions(+), 17 deletions(-)

-- 
2.7.4

[PATCH 1/4] drivers-on-gpio.txt: Fix paths to GPIO driver source files

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
 Documentation/gpio/drivers-on-gpio.txt | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/gpio/drivers-on-gpio.txt b/Documentation/gpio/drivers-on-gpio.txt
index 14bf95a13bae..306513251713 100644
--- a/Documentation/gpio/drivers-on-gpio.txt
+++ b/Documentation/gpio/drivers-on-gpio.txt
@@ -37,15 +37,16 @@ hardware descriptions such as device tree or ACPI:
   external connector status, such as a headset line for an audio driver or an
   HDMI connector. It will provide a better userspace sysfs interface than GPIO.
 
-- restart-gpio: drivers/power/gpio-restart.c is used to restart/reboot the
-  system by pulling a GPIO line and will register a restart handler so
+- restart-gpio: drivers/power/reset/gpio-restart.c is used to restart/reboot
+  the system by pulling a GPIO line and will register a restart handler so
   userspace can issue the right system call to restart the system.
 
-- poweroff-gpio: drivers/power/gpio-poweroff.c is used to power the system down
-  by pulling a GPIO line and will register a pm_power_off() callback so that
-  userspace can issue the right system call to power down the system.
+- poweroff-gpio: drivers/power/reset/gpio-poweroff.c is used to power the
+  system down by pulling a GPIO line and will register a pm_power_off()
+  callback so that userspace can issue the right system call to power down the
+  system.
 
-- gpio-gate-clock: drivers/clk/clk-gpio-gate.c is used to control a gated clock
+- gpio-gate-clock: drivers/clk/clk-gpio.c is used to control a gated clock
   (off/on) that uses a GPIO, and integrated with the clock subsystem.
 
 - i2c-gpio: drivers/i2c/busses/i2c-gpio.c is used to drive an I2C bus
-- 
2.7.4

[PATCH 2/4] pinctrl.txt: Fix grammar in pinmux request list

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
 Documentation/pinctrl.txt | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index 4976389e432d..cefcf5d88a1c 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -493,12 +493,12 @@ Definitions:
 - The combination of a FUNCTION and a PIN GROUP determine a certain function
   for a certain set of pins. The knowledge of the functions and pin groups
   and their machine-specific particulars are kept inside the pinmux driver,
-  from the outside only the enumerators are known, and the driver core can:
+  from the outside only the enumerators are known, and the driver core can
+  request:
 
-  - Request the name of a function with a certain selector (>= 0)
+  - The name of a function with a certain selector (>= 0)
   - A list of groups associated with a certain function
-  - Request that a certain group in that list to be activated for a certain
-    function
+  - That a certain group in that list to be activated for a certain function
 
   As already described above, pin groups are in turn self-descriptive, so
   the core will retrieve the actual pin range in a certain group from the
-- 
2.7.4

[PATCH 3/4] pinctrl.txt: s/have/has/ in GPIO driver interaction description

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
 Documentation/pinctrl.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index cefcf5d88a1c..07d102c3d05a 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -286,7 +286,7 @@ see the section named "pin control requests from drivers" and
 "drivers needing both pin control and GPIOs" below for details. But in some
 situations a cross-subsystem mapping between pins and GPIOs is needed.
 
-Since the pin controller subsystem have its pinspace local to the pin
+Since the pin controller subsystem has its pinspace local to the pin
 controller we need a mapping so that the pin control subsystem can figure out
 which pin controller handles control of a certain GPIO pin. Since a single
 pin controller may be muxing several GPIO ranges (typically SoCs that have
-- 
2.7.4

[PATCH 4/4] pinctrl.txt: Reflow/wrap paragraph describing GPIO interaction

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
 Documentation/pinctrl.txt | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index 07d102c3d05a..6414a613cb8a 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -286,13 +286,13 @@ see the section named "pin control requests from drivers" and
 "drivers needing both pin control and GPIOs" below for details. But in some
 situations a cross-subsystem mapping between pins and GPIOs is needed.
 
-Since the pin controller subsystem has its pinspace local to the pin
-controller we need a mapping so that the pin control subsystem can figure out
-which pin controller handles control of a certain GPIO pin. Since a single
-pin controller may be muxing several GPIO ranges (typically SoCs that have
-one set of pins, but internally several GPIO silicon blocks, each modelled as
-a struct gpio_chip) any number of GPIO ranges can be added to a pin controller
-instance like this:
+Since the pin controller subsystem has its pinspace local to the pin controller
+we need a mapping so that the pin control subsystem can figure out which pin
+controller handles control of a certain GPIO pin. Since a single pin controller
+may be muxing several GPIO ranges (typically SoCs that have one set of pins,
+but internally several GPIO silicon blocks, each modelled as a struct
+gpio_chip) any number of GPIO ranges can be added to a pin controller instance
+like this:
 
 struct gpio_chip chip_a;
 struct gpio_chip chip_b;
-- 
2.7.4

Re: [PATCH 1/4] drivers-on-gpio.txt: Fix paths to GPIO driver source files

[Linus Walleij]

On Fri, Jun 10, 2016 at 9:16 AM, Andrew Jeffery <andrew@aj.id.au> wrote:

> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

Patch applied.

Yours,
Linus Walleij

Re: [PATCH 2/4] pinctrl.txt: Fix grammar in pinmux request list

[Linus Walleij]

On Fri, Jun 10, 2016 at 9:16 AM, Andrew Jeffery <andrew@aj.id.au> wrote:

> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

Patch applied.

Yours,
Linus Walleij

Re: [PATCH 3/4] pinctrl.txt: s/have/has/ in GPIO driver interaction description

[Linus Walleij]

On Fri, Jun 10, 2016 at 9:16 AM, Andrew Jeffery <andrew@aj.id.au> wrote:

> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

Patch applied.

Yours,
Linus Walleij

Re: [PATCH 4/4] pinctrl.txt: Reflow/wrap paragraph describing GPIO interaction

[Linus Walleij]

On Fri, Jun 10, 2016 at 9:16 AM, Andrew Jeffery <andrew@aj.id.au> wrote:

> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

Patch applied.

Yours,
Linus Walleij