[PATCH v2 0/6] ARM: shmobile: Move gpio ranges from C code to DT

[PATCH v2 0/6] ARM: shmobile: Move gpio ranges from C code to DT

[Geert Uytterhoeven]

	Hi Simon, Magnus,

This patch series moves the setup of the GPIO-PFC pin mapping for
Renesas PFC/GPIO combos from C code to DT, and does some cleanups.
The move to DT is needed to make the GPIO hogging mechanism work, cfr.
the discussion following "[PATCH] [RFC] gpio: Retry deferred GPIO
hogging on pin range change" (https://lkml.org/lkml/2015/6/16/455).

The series consists of 3 parts:
  a. Patches 1-3 add the missing "gpio-ranges" properties to the dtsi
     files for all affected SoCs,
  b. Patch 4 disables the C code to set up the mapping on DT platforms
     (it's still needed on SH or ARM-legacy),
  c. Patches 5-6 do a few more cleanups in the sh-pfc gpio code.

Changes compared to v1 ("[PATCH 0/7] ARM: shmobile: Move gpio ranges
from C code to DT",
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/353124.html):
  - Add check for CONFIG_OF and pfc->dev->of_node,
  - #ifdef out the code instead of introducing helper and dummy
    functions,
  - Drop "pinctrl: sh-pfc: Move sh_pfc_add_gpiochip() up", as it's no
    longer needed due to the #ifdefs,
  - Add Acked-by.

Dependencies:
  - This series applies against renesas-devel-20150803-v4.2-rc5,
  - Part a must go in first, to avoid regressions,
  - While I didn't notice any bad behavior by having part a only, part b
    should go in immediately after part a. Hence I think it's best if
    Simon can take this one, too.
  - Part c is independent (it doesn't touch the same code), so it can go
    in before or after the other parts, or in parallel.

Given this fixes the LCD on r8a7740/armadillo, which is a regression
introduced by the removal of armadillo-legacy support, I think at least
patch 2 should be queued for v4.3.

Thanks for applying!

Geert Uytterhoeven (6):
  ARM: shmobile: r8a73a4 dtsi: Add missing "gpio-ranges" to gpio node
  ARM: shmobile: r8a7740 dtsi: Add missing "gpio-ranges" to gpio node
  ARM: shmobile: sh73a0 dtsi: Add missing "gpio-ranges" to gpio node
  pinctrl: sh-pfc: Stop calling gpiochip_add_pin_range() on DT platforms
  pinctrl: sh-pfc: Remove empty gpio_function_free()
  pinctrl: sh-pfc: Confine legacy function GPIOs to SH

 arch/arm/boot/dts/r8a73a4.dtsi  |  7 ++++++
 arch/arm/boot/dts/r8a7740.dtsi  |  1 +
 arch/arm/boot/dts/sh73a0.dtsi   |  3 +++
 drivers/pinctrl/sh-pfc/core.h   |  2 ++
 drivers/pinctrl/sh-pfc/gpio.c   | 49 +++++++++++++++++++++++------------------
 drivers/pinctrl/sh-pfc/sh_pfc.h |  2 ++
 6 files changed, 43 insertions(+), 21 deletions(-)

-- 
1.9.1

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[PATCH v2 1/6] ARM: shmobile: r8a73a4 dtsi: Add missing "gpio-ranges" to gpio node

[Geert Uytterhoeven]

If a GPIO driver uses gpiochip_add_pin_range() (which is usually the
case for GPIO/PFC combos), the GPIO hogging mechanism configured from DT
doesn't work:

    requesting hog GPIO led1-high (chip r8a73a4_pfc, offset 28) failed

The actual error code is -517 == -EPROBE_DEFER.

The problem is that PFC+GPIO registration is handled in multiple steps:
  1. pinctrl_register(),
  2. gpiochip_add(),
  3. gpiochip_add_pin_range().

Configuration of the hogs is handled in gpiochip_add():

    gpiochip_add
        of_gpiochip_add
            of_gpiochip_scan_hogs
                gpiod_hog
                    gpiochip_request_own_desc
                        __gpiod_request
                            chip->request
                                pinctrl_request_gpio
                                    pinctrl_get_device_gpio_range

However, at this point the GPIO controller hasn't been added to
pinctrldev_list yet, so the range can't be found, and the operation fails
with -EPROBE_DEFER.

To fix this, add a "gpio-ranges" property to the gpio device node, so
the ranges are added by of_gpiochip_add_pin_range(), which is called by
of_gpiochip_add() before the call to of_gpiochip_scan_hogs().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
v2:
  - Add Acked-by.
---
 arch/arm/boot/dts/r8a73a4.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 5090d1a8f652e8be..cb4f7b2798fe23be 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -207,6 +207,13 @@
 		reg = <0 0xe6050000 0 0x9000>;
 		gpio-controller;
 		#gpio-cells = <2>;
+		gpio-ranges =
+			<&pfc 0 0 31>, <&pfc 32 32 9>,
+			<&pfc 64 64 22>, <&pfc 96 96 31>,
+			<&pfc 128 128 7>, <&pfc 160 160 19>,
+			<&pfc 192 192 31>, <&pfc 224 224 27>,
+			<&pfc 256 256 28>, <&pfc 288 288 21>,
+			<&pfc 320 320 10>;
 		interrupts-extended =
 			<&irqc0  0 0>, <&irqc0  1 0>, <&irqc0  2 0>, <&irqc0  3 0>,
 			<&irqc0  4 0>, <&irqc0  5 0>, <&irqc0  6 0>, <&irqc0  7 0>,
-- 
1.9.1

[PATCH v2 2/6] ARM: shmobile: r8a7740 dtsi: Add missing "gpio-ranges" to gpio node

[Geert Uytterhoeven]

If a GPIO driver uses gpiochip_add_pin_range() (which is usually the
case for GPIO/PFC combos), the GPIO hogging mechanism configured from DT
doesn't work:

    requesting hog GPIO lcd0 (chip r8a7740_pfc, offset 176) failed

The actual error code is -517 == -EPROBE_DEFER.

The problem is that PFC+GPIO registration is handled in multiple steps:
  1. pinctrl_register(),
  2. gpiochip_add(),
  3. gpiochip_add_pin_range().

Configuration of the hogs is handled in gpiochip_add():

    gpiochip_add
        of_gpiochip_add
            of_gpiochip_scan_hogs
                gpiod_hog
                    gpiochip_request_own_desc
                        __gpiod_request
                            chip->request
                                pinctrl_request_gpio
                                    pinctrl_get_device_gpio_range

However, at this point the GPIO controller hasn't been added to
pinctrldev_list yet, so the range can't be found, and the operation fails
with -EPROBE_DEFER.

To fix this, add a "gpio-ranges" property to the gpio device node, so
the range is added by of_gpiochip_add_pin_range(), which is called by
of_gpiochip_add() before the call to of_gpiochip_scan_hogs().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
v2:
  - Add Acked-by.
---
 arch/arm/boot/dts/r8a7740.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index d84714468cce18df..e14cb1438216e8df 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -291,6 +291,7 @@
 		      <0xe605800c 0x20>;
 		gpio-controller;
 		#gpio-cells = <2>;
+		gpio-ranges = <&pfc 0 0 212>;
 		interrupts-extended =
 			<&irqpin0 0 0>, <&irqpin0 1 0>, <&irqpin0 2 0>, <&irqpin0 3 0>,
 			<&irqpin0 4 0>, <&irqpin0 5 0>, <&irqpin0 6 0>, <&irqpin0 7 0>,
-- 
1.9.1

[PATCH v2 3/6] ARM: shmobile: sh73a0 dtsi: Add missing "gpio-ranges" to gpio node

[Geert Uytterhoeven]

If a GPIO driver uses gpiochip_add_pin_range() (which is usually the
case for GPIO/PFC combos), the GPIO hogging mechanism configured from DT
doesn't work:

    requesting hog GPIO led1-high (chip sh73a0_pfc, offset 20) failed

The actual error code is -517 == -EPROBE_DEFER.

The problem is that PFC+GPIO registration is handled in multiple steps:
  1. pinctrl_register(),
  2. gpiochip_add(),
  3. gpiochip_add_pin_range().

Configuration of the hogs is handled in gpiochip_add():

    gpiochip_add
        of_gpiochip_add
            of_gpiochip_scan_hogs
                gpiod_hog
                    gpiochip_request_own_desc
                        __gpiod_request
                            chip->request
                                pinctrl_request_gpio
                                    pinctrl_get_device_gpio_range

However, at this point the GPIO controller hasn't been added to
pinctrldev_list yet, so the range can't be found, and the operation fails
with -EPROBE_DEFER.

To fix this, add a "gpio-ranges" property to the gpio device node, so
the ranges are added by of_gpiochip_add_pin_range(), which is called by
of_gpiochip_add() before the call to of_gpiochip_scan_hogs().

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
v2:
  - Add Acked-by.
---
 arch/arm/boot/dts/sh73a0.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index 11e17c5f26e2cae2..ff7c8f298f30a58d 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -392,6 +392,9 @@
 		      <0xe605801c 0x1c>;
 		gpio-controller;
 		#gpio-cells = <2>;
+		gpio-ranges =
+			<&pfc 0 0 119>, <&pfc 128 128 37>, <&pfc 192 192 91>,
+			<&pfc 288 288 22>;
 		interrupts-extended =
 			<&irqpin0 0 0>, <&irqpin0 1 0>, <&irqpin0 2 0>, <&irqpin0 3 0>,
 			<&irqpin0 4 0>, <&irqpin0 5 0>, <&irqpin0 6 0>, <&irqpin0 7 0>,
-- 
1.9.1

[PATCH v2 4/6] pinctrl: sh-pfc: Stop calling gpiochip_add_pin_range() on DT platforms

[Geert Uytterhoeven]

On platforms where the PFC/GPIO controller is instantiated from DT, the
mapping between GPIOs and pins is set up using the "gpio-ranges"
property in DT.

Hence stop setting up the mapping from C code on DT platforms.
This code is still used for SH or ARM-legacy platforms.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
v2:
  - Add Acked-by,
  - Add check for CONFIG_OF and pfc->dev->of_node.
---
 drivers/pinctrl/sh-pfc/gpio.c | 37 ++++++++++++++++++++++---------------
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/gpio.c b/drivers/pinctrl/sh-pfc/gpio.c
index ba353735ecf2be9a..b380e3f17b121bbb 100644
--- a/drivers/pinctrl/sh-pfc/gpio.c
+++ b/drivers/pinctrl/sh-pfc/gpio.c
@@ -379,22 +379,29 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
 
 	pfc->gpio = chip;
 
-	/* Register the GPIO to pin mappings. As pins with GPIO ports must come
-	 * first in the ranges, skip the pins without GPIO ports by stopping at
-	 * the first range that contains such a pin.
-	 */
-	for (i = 0; i < pfc->nr_ranges; ++i) {
-		const struct sh_pfc_pin_range *range = &pfc->ranges[i];
-
-		if (range->start >= pfc->nr_gpio_pins)
-			break;
+	if (IS_ENABLED(CONFIG_OF) && pfc->dev->of_node)
+		return 0;
 
-		ret = gpiochip_add_pin_range(&chip->gpio_chip,
-					     dev_name(pfc->dev),
-					     range->start, range->start,
-					     range->end - range->start + 1);
-		if (ret < 0)
-			return ret;
+	if (IS_ENABLED(CONFIG_SUPERH) ||
+	    IS_ENABLED(CONFIG_ARCH_SHMOBILE_LEGACY)) {
+		/*
+		 * Register the GPIO to pin mappings. As pins with GPIO ports
+		 * must come first in the ranges, skip the pins without GPIO
+		 * ports by stopping at the first range that contains such a
+		 * pin.
+		 */
+		for (i = 0; i < pfc->nr_ranges; ++i) {
+			const struct sh_pfc_pin_range *range = &pfc->ranges[i];
+
+			if (range->start >= pfc->nr_gpio_pins)
+				break;
+
+			ret = gpiochip_add_pin_range(&chip->gpio_chip,
+				dev_name(pfc->dev), range->start, range->start,
+				range->end - range->start + 1);
+			if (ret < 0)
+				return ret;
+		}
 	}
 
 	/* Register the function GPIOs chip. */
-- 
1.9.1

Re: [PATCH v2 4/6] pinctrl: sh-pfc: Stop calling gpiochip_add_pin_range() on DT platforms

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Tuesday 04 August 2015 15:55:17 Geert Uytterhoeven wrote:
> On platforms where the PFC/GPIO controller is instantiated from DT, the
> mapping between GPIOs and pins is set up using the "gpio-ranges"
> property in DT.
> 
> Hence stop setting up the mapping from C code on DT platforms.
> This code is still used for SH or ARM-legacy platforms.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>

Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> ---
> v2:
>   - Add Acked-by,
>   - Add check for CONFIG_OF and pfc->dev->of_node.
> ---
>  drivers/pinctrl/sh-pfc/gpio.c | 37 ++++++++++++++++++++++---------------
>  1 file changed, 22 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/pinctrl/sh-pfc/gpio.c b/drivers/pinctrl/sh-pfc/gpio.c
> index ba353735ecf2be9a..b380e3f17b121bbb 100644
> --- a/drivers/pinctrl/sh-pfc/gpio.c
> +++ b/drivers/pinctrl/sh-pfc/gpio.c
> @@ -379,22 +379,29 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
> 
>  	pfc->gpio = chip;
> 
> -	/* Register the GPIO to pin mappings. As pins with GPIO ports must come
> -	 * first in the ranges, skip the pins without GPIO ports by stopping at
> -	 * the first range that contains such a pin.
> -	 */
> -	for (i = 0; i < pfc->nr_ranges; ++i) {
> -		const struct sh_pfc_pin_range *range = &pfc->ranges[i];
> -
> -		if (range->start >= pfc->nr_gpio_pins)
> -			break;
> +	if (IS_ENABLED(CONFIG_OF) && pfc->dev->of_node)
> +		return 0;
> 
> -		ret = gpiochip_add_pin_range(&chip->gpio_chip,
> -					     dev_name(pfc->dev),
> -					     range->start, range->start,
> -					     range->end - range->start + 1);
> -		if (ret < 0)
> -			return ret;
> +	if (IS_ENABLED(CONFIG_SUPERH) ||
> +	    IS_ENABLED(CONFIG_ARCH_SHMOBILE_LEGACY)) {
> +		/*
> +		 * Register the GPIO to pin mappings. As pins with GPIO ports
> +		 * must come first in the ranges, skip the pins without GPIO
> +		 * ports by stopping at the first range that contains such a
> +		 * pin.
> +		 */
> +		for (i = 0; i < pfc->nr_ranges; ++i) {
> +			const struct sh_pfc_pin_range *range = &pfc->ranges[i];
> +
> +			if (range->start >= pfc->nr_gpio_pins)
> +				break;
> +
> +			ret = gpiochip_add_pin_range(&chip->gpio_chip,
> +				dev_name(pfc->dev), range->start, range->start,
> +				range->end - range->start + 1);
> +			if (ret < 0)
> +				return ret;
> +		}
>  	}
> 
>  	/* Register the function GPIOs chip. */

-- 
Regards,

Laurent Pinchart

[PATCH v2 5/6] pinctrl: sh-pfc: Remove empty gpio_function_free()

[Geert Uytterhoeven]

gpio_chip.free() is optional, and can just be left unimplemented.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
Untested due to lack of hardware (used on sh only).

v2:
  - Add Acked-by.
---
 drivers/pinctrl/sh-pfc/gpio.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/gpio.c b/drivers/pinctrl/sh-pfc/gpio.c
index b380e3f17b121bbb..e46439030914ad13 100644
--- a/drivers/pinctrl/sh-pfc/gpio.c
+++ b/drivers/pinctrl/sh-pfc/gpio.c
@@ -286,17 +286,12 @@ static int gpio_function_request(struct gpio_chip *gc, unsigned offset)
 	return ret;
 }
 
-static void gpio_function_free(struct gpio_chip *gc, unsigned offset)
-{
-}
-
 static int gpio_function_setup(struct sh_pfc_chip *chip)
 {
 	struct sh_pfc *pfc = chip->pfc;
 	struct gpio_chip *gc = &chip->gpio_chip;
 
 	gc->request = gpio_function_request;
-	gc->free = gpio_function_free;
 
 	gc->label = pfc->info->name;
 	gc->owner = THIS_MODULE;
-- 
1.9.1

[PATCH v2 6/6] pinctrl: sh-pfc: Confine legacy function GPIOs to SH

[Geert Uytterhoeven]

Legacy function GPIOs are no longer used on ARM since commit
a27c5cd1a08cc95c ("sh-pfc: sh73a0: Remove function GPIOs").
Extract its setup code into a separate function, and make all function
GPIO related code and data depend on CONFIG_SUPERH.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
Compile-tested on sh using se7724_defconfig.

v2:
  - Add Acked-by,
  - #ifdef out the code instead of introducing helper and dummy
    functions.
---
 drivers/pinctrl/sh-pfc/core.h   | 2 ++
 drivers/pinctrl/sh-pfc/gpio.c   | 7 ++++++-
 drivers/pinctrl/sh-pfc/sh_pfc.h | 2 ++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/sh-pfc/core.h b/drivers/pinctrl/sh-pfc/core.h
index 4c3c37bf7161804d..c38ace46d7111b0d 100644
--- a/drivers/pinctrl/sh-pfc/core.h
+++ b/drivers/pinctrl/sh-pfc/core.h
@@ -46,7 +46,9 @@ struct sh_pfc {
 	unsigned int nr_gpio_pins;
 
 	struct sh_pfc_chip *gpio;
+#ifdef CONFIG_SUPERH
 	struct sh_pfc_chip *func;
+#endif
 
 	struct sh_pfc_pinctrl *pinctrl;
 };
diff --git a/drivers/pinctrl/sh-pfc/gpio.c b/drivers/pinctrl/sh-pfc/gpio.c
index e46439030914ad13..685b3c24627daf03 100644
--- a/drivers/pinctrl/sh-pfc/gpio.c
+++ b/drivers/pinctrl/sh-pfc/gpio.c
@@ -261,6 +261,7 @@ static int gpio_pin_setup(struct sh_pfc_chip *chip)
  * Function GPIOs
  */
 
+#ifdef CONFIG_SUPERH
 static int gpio_function_request(struct gpio_chip *gc, unsigned offset)
 {
 	static bool __print_once;
@@ -300,6 +301,7 @@ static int gpio_function_setup(struct sh_pfc_chip *chip)
 
 	return 0;
 }
+#endif
 
 /* -----------------------------------------------------------------------------
  * Register/unregister
@@ -399,6 +401,7 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
 		}
 	}
 
+#ifdef CONFIG_SUPERH
 	/* Register the function GPIOs chip. */
 	if (pfc->info->nr_func_gpios == 0)
 		return 0;
@@ -408,6 +411,7 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
 		return PTR_ERR(chip);
 
 	pfc->func = chip;
+#endif /* CONFIG_SUPERH */
 
 	return 0;
 }
@@ -415,7 +419,8 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
 int sh_pfc_unregister_gpiochip(struct sh_pfc *pfc)
 {
 	gpiochip_remove(&pfc->gpio->gpio_chip);
+#ifdef CONFIG_SUPERH
 	gpiochip_remove(&pfc->func->gpio_chip);
-
+#endif
 	return 0;
 }
diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h b/drivers/pinctrl/sh-pfc/sh_pfc.h
index 0874cfee6889afa1..1f43bae56065e659 100644
--- a/drivers/pinctrl/sh-pfc/sh_pfc.h
+++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
@@ -138,8 +138,10 @@ struct sh_pfc_soc_info {
 	const struct sh_pfc_function *functions;
 	unsigned int nr_functions;
 
+#ifdef CONFIG_SUPERH
 	const struct pinmux_func *func_gpios;
 	unsigned int nr_func_gpios;
+#endif
 
 	const struct pinmux_cfg_reg *cfg_regs;
 	const struct pinmux_data_reg *data_regs;
-- 
1.9.1

Re: [PATCH v2 6/6] pinctrl: sh-pfc: Confine legacy function GPIOs to SH

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Tuesday 04 August 2015 15:55:19 Geert Uytterhoeven wrote:
> Legacy function GPIOs are no longer used on ARM since commit
> a27c5cd1a08cc95c ("sh-pfc: sh73a0: Remove function GPIOs").
> Extract its setup code into a separate function, and make all function
> GPIO related code and data depend on CONFIG_SUPERH.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>

Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

We now need a volunteer to port SH to proper pinctrl to remove the function 
GPIOs completely :-)

> ---
> Compile-tested on sh using se7724_defconfig.
> 
> v2:
>   - Add Acked-by,
>   - #ifdef out the code instead of introducing helper and dummy
>     functions.
> ---
>  drivers/pinctrl/sh-pfc/core.h   | 2 ++
>  drivers/pinctrl/sh-pfc/gpio.c   | 7 ++++++-
>  drivers/pinctrl/sh-pfc/sh_pfc.h | 2 ++
>  3 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/sh-pfc/core.h b/drivers/pinctrl/sh-pfc/core.h
> index 4c3c37bf7161804d..c38ace46d7111b0d 100644
> --- a/drivers/pinctrl/sh-pfc/core.h
> +++ b/drivers/pinctrl/sh-pfc/core.h
> @@ -46,7 +46,9 @@ struct sh_pfc {
>  	unsigned int nr_gpio_pins;
> 
>  	struct sh_pfc_chip *gpio;
> +#ifdef CONFIG_SUPERH
>  	struct sh_pfc_chip *func;
> +#endif
> 
>  	struct sh_pfc_pinctrl *pinctrl;
>  };
> diff --git a/drivers/pinctrl/sh-pfc/gpio.c b/drivers/pinctrl/sh-pfc/gpio.c
> index e46439030914ad13..685b3c24627daf03 100644
> --- a/drivers/pinctrl/sh-pfc/gpio.c
> +++ b/drivers/pinctrl/sh-pfc/gpio.c
> @@ -261,6 +261,7 @@ static int gpio_pin_setup(struct sh_pfc_chip *chip)
>   * Function GPIOs
>   */
> 
> +#ifdef CONFIG_SUPERH
>  static int gpio_function_request(struct gpio_chip *gc, unsigned offset)
>  {
>  	static bool __print_once;
> @@ -300,6 +301,7 @@ static int gpio_function_setup(struct sh_pfc_chip *chip)
> 
>  	return 0;
>  }
> +#endif
> 
>  /*
> ---------------------------------------------------------------------------
> -- * Register/unregister
> @@ -399,6 +401,7 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
>  		}
>  	}
> 
> +#ifdef CONFIG_SUPERH
>  	/* Register the function GPIOs chip. */
>  	if (pfc->info->nr_func_gpios == 0)
>  		return 0;
> @@ -408,6 +411,7 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
>  		return PTR_ERR(chip);
> 
>  	pfc->func = chip;
> +#endif /* CONFIG_SUPERH */
> 
>  	return 0;
>  }
> @@ -415,7 +419,8 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
>  int sh_pfc_unregister_gpiochip(struct sh_pfc *pfc)
>  {
>  	gpiochip_remove(&pfc->gpio->gpio_chip);
> +#ifdef CONFIG_SUPERH
>  	gpiochip_remove(&pfc->func->gpio_chip);
> -
> +#endif
>  	return 0;
>  }
> diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h
> b/drivers/pinctrl/sh-pfc/sh_pfc.h index 0874cfee6889afa1..1f43bae56065e659
> 100644
> --- a/drivers/pinctrl/sh-pfc/sh_pfc.h
> +++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
> @@ -138,8 +138,10 @@ struct sh_pfc_soc_info {
>  	const struct sh_pfc_function *functions;
>  	unsigned int nr_functions;
> 
> +#ifdef CONFIG_SUPERH
>  	const struct pinmux_func *func_gpios;
>  	unsigned int nr_func_gpios;
> +#endif
> 
>  	const struct pinmux_cfg_reg *cfg_regs;
>  	const struct pinmux_data_reg *data_regs;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 0/6] ARM: shmobile: Move gpio ranges from C code to DT

[Simon Horman]

Hi Geert,

On Tue, Aug 04, 2015 at 03:55:13PM +0200, Geert Uytterhoeven wrote:
> 	Hi Simon, Magnus,
> 
> This patch series moves the setup of the GPIO-PFC pin mapping for
> Renesas PFC/GPIO combos from C code to DT, and does some cleanups.
> The move to DT is needed to make the GPIO hogging mechanism work, cfr.
> the discussion following "[PATCH] [RFC] gpio: Retry deferred GPIO
> hogging on pin range change" (https://lkml.org/lkml/2015/6/16/455).
> 
> The series consists of 3 parts:
>   a. Patches 1-3 add the missing "gpio-ranges" properties to the dtsi
>      files for all affected SoCs,
>   b. Patch 4 disables the C code to set up the mapping on DT platforms
>      (it's still needed on SH or ARM-legacy),
>   c. Patches 5-6 do a few more cleanups in the sh-pfc gpio code.
> 
> Changes compared to v1 ("[PATCH 0/7] ARM: shmobile: Move gpio ranges
> from C code to DT",
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/353124.html):
>   - Add check for CONFIG_OF and pfc->dev->of_node,
>   - #ifdef out the code instead of introducing helper and dummy
>     functions,
>   - Drop "pinctrl: sh-pfc: Move sh_pfc_add_gpiochip() up", as it's no
>     longer needed due to the #ifdefs,
>   - Add Acked-by.
> 
> Dependencies:
>   - This series applies against renesas-devel-20150803-v4.2-rc5,
>   - Part a must go in first, to avoid regressions,
>   - While I didn't notice any bad behavior by having part a only, part b
>     should go in immediately after part a. Hence I think it's best if
>     Simon can take this one, too.
>   - Part c is independent (it doesn't touch the same code), so it can go
>     in before or after the other parts, or in parallel.
> 
> Given this fixes the LCD on r8a7740/armadillo, which is a regression
> introduced by the removal of armadillo-legacy support, I think at least
> patch 2 should be queued for v4.3.
> 
> Thanks for applying!
> 
> Geert Uytterhoeven (6):
>   ARM: shmobile: r8a73a4 dtsi: Add missing "gpio-ranges" to gpio node
>   ARM: shmobile: r8a7740 dtsi: Add missing "gpio-ranges" to gpio node
>   ARM: shmobile: sh73a0 dtsi: Add missing "gpio-ranges" to gpio node
>   pinctrl: sh-pfc: Stop calling gpiochip_add_pin_range() on DT platforms
>   pinctrl: sh-pfc: Remove empty gpio_function_free()
>   pinctrl: sh-pfc: Confine legacy function GPIOs to SH

Where possible I prefer not to apply non-DTS/DTSI patches on top of
DTS/DTSI patches, I believe this is in keeping with how the ARM SoC
maintainers like things handled.  With this in mind I have done the following:

1. Queued up the DTSI patches (patches 1 - 3) for v4.3 in my dt branch.
   I intend for this to turn up in next soon.
2. Queued up for pinctrl patches (patches 4 - 6) for v4.4 in a pinctrl patch.
   I intend for these to be present in the renesas devel branch but
   not in next until after the release of v4.3-rc1. I would also be
   happy to drop them and let Linus Walleij take these patches for v4.4,
   assuming patches 1 - 3 are accepted for v4.3.

Re: [PATCH v2 0/6] ARM: shmobile: Move gpio ranges from C code to DT

[Geert Uytterhoeven]

Hi Simon,

On Wed, Aug 5, 2015 at 2:55 AM, Simon Horman <horms@verge.net.au> wrote:
> On Tue, Aug 04, 2015 at 03:55:13PM +0200, Geert Uytterhoeven wrote:
>> This patch series moves the setup of the GPIO-PFC pin mapping for
>> Renesas PFC/GPIO combos from C code to DT, and does some cleanups.
>> The move to DT is needed to make the GPIO hogging mechanism work, cfr.
>> the discussion following "[PATCH] [RFC] gpio: Retry deferred GPIO
>> hogging on pin range change" (https://lkml.org/lkml/2015/6/16/455).
>>
>> The series consists of 3 parts:
>>   a. Patches 1-3 add the missing "gpio-ranges" properties to the dtsi
>>      files for all affected SoCs,
>>   b. Patch 4 disables the C code to set up the mapping on DT platforms
>>      (it's still needed on SH or ARM-legacy),
>>   c. Patches 5-6 do a few more cleanups in the sh-pfc gpio code.
>>
>> Changes compared to v1 ("[PATCH 0/7] ARM: shmobile: Move gpio ranges
>> from C code to DT",
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/353124.html):
>>   - Add check for CONFIG_OF and pfc->dev->of_node,
>>   - #ifdef out the code instead of introducing helper and dummy
>>     functions,
>>   - Drop "pinctrl: sh-pfc: Move sh_pfc_add_gpiochip() up", as it's no
>>     longer needed due to the #ifdefs,
>>   - Add Acked-by.
>>
>> Dependencies:
>>   - This series applies against renesas-devel-20150803-v4.2-rc5,
>>   - Part a must go in first, to avoid regressions,
>>   - While I didn't notice any bad behavior by having part a only, part b
>>     should go in immediately after part a. Hence I think it's best if
>>     Simon can take this one, too.
>>   - Part c is independent (it doesn't touch the same code), so it can go
>>     in before or after the other parts, or in parallel.
>>
>> Given this fixes the LCD on r8a7740/armadillo, which is a regression
>> introduced by the removal of armadillo-legacy support, I think at least
>> patch 2 should be queued for v4.3.
>>
>> Thanks for applying!
>>
>> Geert Uytterhoeven (6):
>>   ARM: shmobile: r8a73a4 dtsi: Add missing "gpio-ranges" to gpio node
>>   ARM: shmobile: r8a7740 dtsi: Add missing "gpio-ranges" to gpio node
>>   ARM: shmobile: sh73a0 dtsi: Add missing "gpio-ranges" to gpio node
>>   pinctrl: sh-pfc: Stop calling gpiochip_add_pin_range() on DT platforms
>>   pinctrl: sh-pfc: Remove empty gpio_function_free()
>>   pinctrl: sh-pfc: Confine legacy function GPIOs to SH
>
> Where possible I prefer not to apply non-DTS/DTSI patches on top of
> DTS/DTSI patches, I believe this is in keeping with how the ARM SoC

Ugh, that means I have to put a few more DT patches in my queue on the
fast track...

> maintainers like things handled.  With this in mind I have done the following:
>
> 1. Queued up the DTSI patches (patches 1 - 3) for v4.3 in my dt branch.
>    I intend for this to turn up in next soon.
> 2. Queued up for pinctrl patches (patches 4 - 6) for v4.4 in a pinctrl patch.
>    I intend for these to be present in the renesas devel branch but
>    not in next until after the release of v4.3-rc1. I would also be
>    happy to drop them and let Linus Walleij take these patches for v4.4,
>    assuming patches 1 - 3 are accepted for v4.3.

Thanks, that sounds fine to me!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 0/6] ARM: shmobile: Move gpio ranges from C code to DT

[Linus Walleij]

On Wed, Aug 5, 2015 at 2:55 AM, Simon Horman <horms@verge.net.au> wrote:

> Where possible I prefer not to apply non-DTS/DTSI patches on top of
> DTS/DTSI patches, I believe this is in keeping with how the ARM SoC
> maintainers like things handled.  With this in mind I have done the following:
>
> 1. Queued up the DTSI patches (patches 1 - 3) for v4.3 in my dt branch.
>    I intend for this to turn up in next soon.
> 2. Queued up for pinctrl patches (patches 4 - 6) for v4.4 in a pinctrl patch.
>    I intend for these to be present in the renesas devel branch but
>    not in next until after the release of v4.3-rc1. I would also be
>    happy to drop them and let Linus Walleij take these patches for v4.4,
>    assuming patches 1 - 3 are accepted for v4.3.

OK.

Will the world explode if I try to queue the pinctrl patches 4-6 in my
tree now for v4.3? Then I prefer to defer to v4.4. Else I can merge
it in parallel?

Yours,
Linus Walleij

Re: [PATCH v2 0/6] ARM: shmobile: Move gpio ranges from C code to DT

[Geert Uytterhoeven]

Hi Linus,

On Thu, Aug 13, 2015 at 2:29 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Aug 5, 2015 at 2:55 AM, Simon Horman <horms@verge.net.au> wrote:
>> Where possible I prefer not to apply non-DTS/DTSI patches on top of
>> DTS/DTSI patches, I believe this is in keeping with how the ARM SoC
>> maintainers like things handled.  With this in mind I have done the following:
>>
>> 1. Queued up the DTSI patches (patches 1 - 3) for v4.3 in my dt branch.
>>    I intend for this to turn up in next soon.
>> 2. Queued up for pinctrl patches (patches 4 - 6) for v4.4 in a pinctrl patch.
>>    I intend for these to be present in the renesas devel branch but
>>    not in next until after the release of v4.3-rc1. I would also be
>>    happy to drop them and let Linus Walleij take these patches for v4.4,
>>    assuming patches 1 - 3 are accepted for v4.3.
>
> OK.
>
> Will the world explode if I try to queue the pinctrl patches 4-6 in my
> tree now for v4.3? Then I prefer to defer to v4.4. Else I can merge
> it in parallel?

There won't be a mapping between gpio and pins in any branch having the
pinctrl changes but not the dtsi changes.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 0/6] ARM: shmobile: Move gpio ranges from C code to DT

[Simon Horman]

On Thu, Aug 13, 2015 at 02:45:55PM +0200, Geert Uytterhoeven wrote:
> Hi Linus,
> 
> On Thu, Aug 13, 2015 at 2:29 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Wed, Aug 5, 2015 at 2:55 AM, Simon Horman <horms@verge.net.au> wrote:
> >> Where possible I prefer not to apply non-DTS/DTSI patches on top of
> >> DTS/DTSI patches, I believe this is in keeping with how the ARM SoC
> >> maintainers like things handled.  With this in mind I have done the following:
> >>
> >> 1. Queued up the DTSI patches (patches 1 - 3) for v4.3 in my dt branch.
> >>    I intend for this to turn up in next soon.
> >> 2. Queued up for pinctrl patches (patches 4 - 6) for v4.4 in a pinctrl patch.
> >>    I intend for these to be present in the renesas devel branch but
> >>    not in next until after the release of v4.3-rc1. I would also be
> >>    happy to drop them and let Linus Walleij take these patches for v4.4,
> >>    assuming patches 1 - 3 are accepted for v4.3.
> >
> > OK.
> >
> > Will the world explode if I try to queue the pinctrl patches 4-6 in my
> > tree now for v4.3? Then I prefer to defer to v4.4. Else I can merge
> > it in parallel?
> 
> There won't be a mapping between gpio and pins in any branch having the
> pinctrl changes but not the dtsi changes.

It sounds to me that Linus should take his option 2; defer to v4.4.
In which case I should drop the changes from my tree (they are not in next
anyway). Please let me know if thats the way we will move this forwards.

Re: [PATCH v2 0/6] ARM: shmobile: Move gpio ranges from C code to DT

[Geert Uytterhoeven]

On Fri, Aug 14, 2015 at 2:30 AM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, Aug 13, 2015 at 02:45:55PM +0200, Geert Uytterhoeven wrote:
>> On Thu, Aug 13, 2015 at 2:29 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> > On Wed, Aug 5, 2015 at 2:55 AM, Simon Horman <horms@verge.net.au> wrote:
>> >> Where possible I prefer not to apply non-DTS/DTSI patches on top of
>> >> DTS/DTSI patches, I believe this is in keeping with how the ARM SoC
>> >> maintainers like things handled.  With this in mind I have done the following:
>> >>
>> >> 1. Queued up the DTSI patches (patches 1 - 3) for v4.3 in my dt branch.
>> >>    I intend for this to turn up in next soon.
>> >> 2. Queued up for pinctrl patches (patches 4 - 6) for v4.4 in a pinctrl patch.
>> >>    I intend for these to be present in the renesas devel branch but
>> >>    not in next until after the release of v4.3-rc1. I would also be
>> >>    happy to drop them and let Linus Walleij take these patches for v4.4,
>> >>    assuming patches 1 - 3 are accepted for v4.3.
>> >
>> > OK.
>> >
>> > Will the world explode if I try to queue the pinctrl patches 4-6 in my
>> > tree now for v4.3? Then I prefer to defer to v4.4. Else I can merge
>> > it in parallel?
>>
>> There won't be a mapping between gpio and pins in any branch having the
>> pinctrl changes but not the dtsi changes.
>
> It sounds to me that Linus should take his option 2; defer to v4.4.
> In which case I should drop the changes from my tree (they are not in next
> anyway). Please let me know if thats the way we will move this forwards.

Sounds fine to me.

And in the unlikely event we discover regressions in v4.3-rc1 due to having
the dtsi changes without the pinctrl changes, we can still fast-track them
into v4.3-rc2.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2 0/6] ARM: shmobile: Move gpio ranges from C code to DT

[Linus Walleij]

On Fri, Aug 14, 2015 at 9:46 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Fri, Aug 14, 2015 at 2:30 AM, Simon Horman <horms@verge.net.au> wrote:
>> On Thu, Aug 13, 2015 at 02:45:55PM +0200, Geert Uytterhoeven wrote:
>>> On Thu, Aug 13, 2015 at 2:29 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>> > On Wed, Aug 5, 2015 at 2:55 AM, Simon Horman <horms@verge.net.au> wrote:
>>> >> Where possible I prefer not to apply non-DTS/DTSI patches on top of
>>> >> DTS/DTSI patches, I believe this is in keeping with how the ARM SoC
>>> >> maintainers like things handled.  With this in mind I have done the following:
>>> >>
>>> >> 1. Queued up the DTSI patches (patches 1 - 3) for v4.3 in my dt branch.
>>> >>    I intend for this to turn up in next soon.
>>> >> 2. Queued up for pinctrl patches (patches 4 - 6) for v4.4 in a pinctrl patch.
>>> >>    I intend for these to be present in the renesas devel branch but
>>> >>    not in next until after the release of v4.3-rc1. I would also be
>>> >>    happy to drop them and let Linus Walleij take these patches for v4.4,
>>> >>    assuming patches 1 - 3 are accepted for v4.3.
>>> >
>>> > OK.
>>> >
>>> > Will the world explode if I try to queue the pinctrl patches 4-6 in my
>>> > tree now for v4.3? Then I prefer to defer to v4.4. Else I can merge
>>> > it in parallel?
>>>
>>> There won't be a mapping between gpio and pins in any branch having the
>>> pinctrl changes but not the dtsi changes.
>>
>> It sounds to me that Linus should take his option 2; defer to v4.4.
>> In which case I should drop the changes from my tree (they are not in next
>> anyway). Please let me know if thats the way we will move this forwards.
>
> Sounds fine to me.
>
> And in the unlikely event we discover regressions in v4.3-rc1 due to having
> the dtsi changes without the pinctrl changes, we can still fast-track them
> into v4.3-rc2.

Sounds like a plan.

Hit me on the head about this once v4.3-rc1 is out!

Yours,
Linus Walleij

Re: [PATCH v2 0/6] ARM: shmobile: Move gpio ranges from C code to DT

[Simon Horman]

On Fri, Aug 14, 2015 at 12:34:33PM +0200, Linus Walleij wrote:
> On Fri, Aug 14, 2015 at 9:46 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Fri, Aug 14, 2015 at 2:30 AM, Simon Horman <horms@verge.net.au> wrote:
> >> On Thu, Aug 13, 2015 at 02:45:55PM +0200, Geert Uytterhoeven wrote:
> >>> On Thu, Aug 13, 2015 at 2:29 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> >>> > On Wed, Aug 5, 2015 at 2:55 AM, Simon Horman <horms@verge.net.au> wrote:
> >>> >> Where possible I prefer not to apply non-DTS/DTSI patches on top of
> >>> >> DTS/DTSI patches, I believe this is in keeping with how the ARM SoC
> >>> >> maintainers like things handled.  With this in mind I have done the following:
> >>> >>
> >>> >> 1. Queued up the DTSI patches (patches 1 - 3) for v4.3 in my dt branch.
> >>> >>    I intend for this to turn up in next soon.
> >>> >> 2. Queued up for pinctrl patches (patches 4 - 6) for v4.4 in a pinctrl patch.
> >>> >>    I intend for these to be present in the renesas devel branch but
> >>> >>    not in next until after the release of v4.3-rc1. I would also be
> >>> >>    happy to drop them and let Linus Walleij take these patches for v4.4,
> >>> >>    assuming patches 1 - 3 are accepted for v4.3.
> >>> >
> >>> > OK.
> >>> >
> >>> > Will the world explode if I try to queue the pinctrl patches 4-6 in my
> >>> > tree now for v4.3? Then I prefer to defer to v4.4. Else I can merge
> >>> > it in parallel?
> >>>
> >>> There won't be a mapping between gpio and pins in any branch having the
> >>> pinctrl changes but not the dtsi changes.
> >>
> >> It sounds to me that Linus should take his option 2; defer to v4.4.
> >> In which case I should drop the changes from my tree (they are not in next
> >> anyway). Please let me know if thats the way we will move this forwards.
> >
> > Sounds fine to me.
> >
> > And in the unlikely event we discover regressions in v4.3-rc1 due to having
> > the dtsi changes without the pinctrl changes, we can still fast-track them
> > into v4.3-rc2.
> 
> Sounds like a plan.
> 
> Hit me on the head about this once v4.3-rc1 is out!

Thanks, I will drop the patches from my tree.