[PATCH v2 0/3] gpio/pinctrl: imx: let IOMUX controller know about on-SoC GPIOs

[PATCH v2 0/3] gpio/pinctrl: imx: let IOMUX controller know about on-SoC GPIOs

[Vladimir Zapolskiy]

The change establishes a connection between on-SoC IOMUX controller(s)
and GPIO controllers found on some SoC from Freescale/NXP iMX series,
if a GPIO controller device node contains common gpio-ranges information.

The change is backward compatible with respect to potentially not updated
outdated DTB data without gpio-ranges propery, for such boards the only
functional change is lowered initcall priority of GPIO controller driver,
which in general anyway is exected to be used only after pinctrl/pinmux
controller.

If this change is applied the next interesting applications may be done
as a follow-up work, for example switching pad function to GPIO on gpiod
request, converting iomux controller driver to strict type and so on.

For actual values of gpio-ranges properties please reference series
"ARM: dts: imx: add gpio-ranges properties to some iMX GPIO controllers"
http://www.spinics.net/lists/arm-kernel/msg525258.html

Changes from v1 to v2:
* replaced 2/3 by an own change providing a better commit description
  and which moves gpio_mxc_init() call to subsys_initcall() instead of
  apparently too late device_initcall(), this mitigates Shawn's
  expressed concern about the change.

Vladimir Zapolskiy (3):
  pinctrl: imx: accept gpio request/free from pinctrl
  gpio: mxc: shift gpio_mxc_init() to subsys_initcall level
  gpio: mxc: add generic gpio request/free callbacks to pinctrl

 drivers/gpio/gpio-mxc.c                 | 7 ++++++-
 drivers/pinctrl/freescale/pinctrl-imx.c | 4 ++--
 2 files changed, 8 insertions(+), 3 deletions(-)

-- 
2.8.1

[PATCH v2 0/3] gpio/pinctrl: imx: let IOMUX controller know about on-SoC GPIOs

[Vladimir Zapolskiy]

The change establishes a connection between on-SoC IOMUX controller(s)
and GPIO controllers found on some SoC from Freescale/NXP iMX series,
if a GPIO controller device node contains common gpio-ranges information.

The change is backward compatible with respect to potentially not updated
outdated DTB data without gpio-ranges propery, for such boards the only
functional change is lowered initcall priority of GPIO controller driver,
which in general anyway is exected to be used only after pinctrl/pinmux
controller.

If this change is applied the next interesting applications may be done
as a follow-up work, for example switching pad function to GPIO on gpiod
request, converting iomux controller driver to strict type and so on.

For actual values of gpio-ranges properties please reference series
"ARM: dts: imx: add gpio-ranges properties to some iMX GPIO controllers"
http://www.spinics.net/lists/arm-kernel/msg525258.html

Changes from v1 to v2:
* replaced 2/3 by an own change providing a better commit description
  and which moves gpio_mxc_init() call to subsys_initcall() instead of
  apparently too late device_initcall(), this mitigates Shawn's
  expressed concern about the change.

Vladimir Zapolskiy (3):
  pinctrl: imx: accept gpio request/free from pinctrl
  gpio: mxc: shift gpio_mxc_init() to subsys_initcall level
  gpio: mxc: add generic gpio request/free callbacks to pinctrl

 drivers/gpio/gpio-mxc.c                 | 7 ++++++-
 drivers/pinctrl/freescale/pinctrl-imx.c | 4 ++--
 2 files changed, 8 insertions(+), 3 deletions(-)

-- 
2.8.1

[PATCH v2 1/3] pinctrl: imx: accept gpio request/free from pinctrl

[Vladimir Zapolskiy]

While only Freescale Vybrid SoC has settings of GPIO capabilities done
by iomux controller, it is only a matter of GPIO controller driver
implementation for the rest of Freescale/NXP SoCs from iMX series.

As a practical example on GPIO request a pad function should be
switched to GPIO, but because this requires updates to all particular
iMX pinctrl drivers, for simplicity at the moment add only a proper
connection between shared pinctrl-imx and pinctrl/pinmux core, namely
.gpio_request_enable/.gpio_disable_free/.gpio_set_direction callbacks
should return success to a caller. This change allows to progress by
adding request/free callbacks into gpio-mxc.c driver.

Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
---
Changes from v1 to v2:
* none

 drivers/pinctrl/freescale/pinctrl-imx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c b/drivers/pinctrl/freescale/pinctrl-imx.c
index 71391757938b..6e248ca10169 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -315,7 +315,7 @@ static int imx_pmx_gpio_request_enable(struct pinctrl_dev *pctldev,
 
 	/* Currently implementation only for shared mux/conf register */
 	if (!(info->flags & SHARE_MUX_CONF_REG))
-		return -EINVAL;
+		return 0;
 
 	pin_reg = &info->pin_regs[offset];
 	if (pin_reg->mux_reg == -1)
@@ -380,7 +380,7 @@ static int imx_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
 	 * They are part of the shared mux/conf register.
 	 */
 	if (!(info->flags & SHARE_MUX_CONF_REG))
-		return -EINVAL;
+		return 0;
 
 	pin_reg = &info->pin_regs[offset];
 	if (pin_reg->mux_reg == -1)
-- 
2.8.1

[PATCH v2 1/3] pinctrl: imx: accept gpio request/free from pinctrl

[Vladimir Zapolskiy]

While only Freescale Vybrid SoC has settings of GPIO capabilities done
by iomux controller, it is only a matter of GPIO controller driver
implementation for the rest of Freescale/NXP SoCs from iMX series.

As a practical example on GPIO request a pad function should be
switched to GPIO, but because this requires updates to all particular
iMX pinctrl drivers, for simplicity at the moment add only a proper
connection between shared pinctrl-imx and pinctrl/pinmux core, namely
.gpio_request_enable/.gpio_disable_free/.gpio_set_direction callbacks
should return success to a caller. This change allows to progress by
adding request/free callbacks into gpio-mxc.c driver.

Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
---
Changes from v1 to v2:
* none

 drivers/pinctrl/freescale/pinctrl-imx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c b/drivers/pinctrl/freescale/pinctrl-imx.c
index 71391757938b..6e248ca10169 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -315,7 +315,7 @@ static int imx_pmx_gpio_request_enable(struct pinctrl_dev *pctldev,
 
 	/* Currently implementation only for shared mux/conf register */
 	if (!(info->flags & SHARE_MUX_CONF_REG))
-		return -EINVAL;
+		return 0;
 
 	pin_reg = &info->pin_regs[offset];
 	if (pin_reg->mux_reg == -1)
@@ -380,7 +380,7 @@ static int imx_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
 	 * They are part of the shared mux/conf register.
 	 */
 	if (!(info->flags & SHARE_MUX_CONF_REG))
-		return -EINVAL;
+		return 0;
 
 	pin_reg = &info->pin_regs[offset];
 	if (pin_reg->mux_reg == -1)
-- 
2.8.1

[PATCH v2 2/3] gpio: mxc: shift gpio_mxc_init() to subsys_initcall level

[Vladimir Zapolskiy]

In general situation on-SoC GPIO controller drivers should be probed
after pinctrl/pinmux controller driver, because on-SoC GPIOs utilize a
pin/pad as a resource provided and controlled by pinctrl subsystem.

This is stated in multiple places, e.g. from drivers/Makefile:

  GPIO must come after pinctrl as gpios may need to mux pins etc

Looking at Freescale iMX SoC series specifics, imx*_pinctrl_init()
functions are called at arch_initcall and postcore_initcall init
levels, so the change of initcall level for gpio-mxc driver from
postcore_initcall to subsys_initcall level is sufficient. Also note
that the most of GPIO controller drivers settled at subsys_initcall
level.

If pinctrl subsystem manages pads with GPIO functions, the change is
needed to avoid unwanted driver probe deferrals during kernel boot.

Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
---
Changes from v1 to v2:
* replaced by a change with better commit description and which
  moves gpio_mxc_init() call to subsys_initcall() instead of
  apparently too late device_initcall(), this mitigates Shawn's
  expressed concern about the change.

 drivers/gpio/gpio-mxc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
index 1b342a3842c8..1fdd5d804b5b 100644
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@ -510,7 +510,7 @@ static int __init gpio_mxc_init(void)
 {
 	return platform_driver_register(&mxc_gpio_driver);
 }
-postcore_initcall(gpio_mxc_init);
+subsys_initcall(gpio_mxc_init);
 
 MODULE_AUTHOR("Freescale Semiconductor, "
 	      "Daniel Mack <danielncaiaq.de>, "
-- 
2.8.1

[PATCH v2 2/3] gpio: mxc: shift gpio_mxc_init() to subsys_initcall level

[Vladimir Zapolskiy]

In general situation on-SoC GPIO controller drivers should be probed
after pinctrl/pinmux controller driver, because on-SoC GPIOs utilize a
pin/pad as a resource provided and controlled by pinctrl subsystem.

This is stated in multiple places, e.g. from drivers/Makefile:

  GPIO must come after pinctrl as gpios may need to mux pins etc

Looking at Freescale iMX SoC series specifics, imx*_pinctrl_init()
functions are called at arch_initcall and postcore_initcall init
levels, so the change of initcall level for gpio-mxc driver from
postcore_initcall to subsys_initcall level is sufficient. Also note
that the most of GPIO controller drivers settled at subsys_initcall
level.

If pinctrl subsystem manages pads with GPIO functions, the change is
needed to avoid unwanted driver probe deferrals during kernel boot.

Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
---
Changes from v1 to v2:
* replaced by a change with better commit description and which
  moves gpio_mxc_init() call to subsys_initcall() instead of
  apparently too late device_initcall(), this mitigates Shawn's
  expressed concern about the change.

 drivers/gpio/gpio-mxc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
index 1b342a3842c8..1fdd5d804b5b 100644
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@ -510,7 +510,7 @@ static int __init gpio_mxc_init(void)
 {
 	return platform_driver_register(&mxc_gpio_driver);
 }
-postcore_initcall(gpio_mxc_init);
+subsys_initcall(gpio_mxc_init);
 
 MODULE_AUTHOR("Freescale Semiconductor, "
 	      "Daniel Mack <danielncaiaq.de>, "
-- 
2.8.1

[PATCH v2 3/3] gpio: mxc: add generic gpio request/free callbacks to pinctrl

[Vladimir Zapolskiy]

If a GPIO controller description in board DTB contains information
about mappings between GPIOs and pads under IOMUX control use it to
request and free GPIOs with respect to pinctrl/pinmux subsystems.

One of immediate positive functional changes is inability to
request non-existing GPIOs, i.e. if there is no pad such. Also
pinctrl/pinmux may now properly account pads occupied by requested
GPIOs.

The change has no effect, if "gpio-ranges" property is not found
including the case if a board has no DTB firmware.

Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
---
Changes from v1 to v2:
* none

 drivers/gpio/gpio-mxc.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
index 1fdd5d804b5b..e38989a4fa0c 100644
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@ -458,6 +458,11 @@ static int mxc_gpio_probe(struct platform_device *pdev)
 	if (err)
 		goto out_bgio;
 
+	if (of_property_read_bool(np, "gpio-ranges")) {
+		port->gc.request = gpiochip_generic_request;
+		port->gc.free = gpiochip_generic_free;
+	}
+
 	port->gc.to_irq = mxc_gpio_to_irq;
 	port->gc.base = (pdev->id < 0) ? of_alias_get_id(np, "gpio") * 32 :
 					     pdev->id * 32;
-- 
2.8.1

[PATCH v2 3/3] gpio: mxc: add generic gpio request/free callbacks to pinctrl

[Vladimir Zapolskiy]

If a GPIO controller description in board DTB contains information
about mappings between GPIOs and pads under IOMUX control use it to
request and free GPIOs with respect to pinctrl/pinmux subsystems.

One of immediate positive functional changes is inability to
request non-existing GPIOs, i.e. if there is no pad such. Also
pinctrl/pinmux may now properly account pads occupied by requested
GPIOs.

The change has no effect, if "gpio-ranges" property is not found
including the case if a board has no DTB firmware.

Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
---
Changes from v1 to v2:
* none

 drivers/gpio/gpio-mxc.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
index 1fdd5d804b5b..e38989a4fa0c 100644
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@ -458,6 +458,11 @@ static int mxc_gpio_probe(struct platform_device *pdev)
 	if (err)
 		goto out_bgio;
 
+	if (of_property_read_bool(np, "gpio-ranges")) {
+		port->gc.request = gpiochip_generic_request;
+		port->gc.free = gpiochip_generic_free;
+	}
+
 	port->gc.to_irq = mxc_gpio_to_irq;
 	port->gc.base = (pdev->id < 0) ? of_alias_get_id(np, "gpio") * 32 :
 					     pdev->id * 32;
-- 
2.8.1

Re: [PATCH v2 0/3] gpio/pinctrl: imx: let IOMUX controller know about on-SoC GPIOs

[Shawn Guo]

On Thu, Sep 08, 2016 at 04:48:13AM +0300, Vladimir Zapolskiy wrote:
> The change establishes a connection between on-SoC IOMUX controller(s)
> and GPIO controllers found on some SoC from Freescale/NXP iMX series,
> if a GPIO controller device node contains common gpio-ranges information.
> 
> The change is backward compatible with respect to potentially not updated
> outdated DTB data without gpio-ranges propery, for such boards the only
> functional change is lowered initcall priority of GPIO controller driver,
> which in general anyway is exected to be used only after pinctrl/pinmux
> controller.
> 
> If this change is applied the next interesting applications may be done
> as a follow-up work, for example switching pad function to GPIO on gpiod
> request, converting iomux controller driver to strict type and so on.
> 
> For actual values of gpio-ranges properties please reference series
> "ARM: dts: imx: add gpio-ranges properties to some iMX GPIO controllers"
> http://www.spinics.net/lists/arm-kernel/msg525258.html
> 
> Changes from v1 to v2:
> * replaced 2/3 by an own change providing a better commit description
>   and which moves gpio_mxc_init() call to subsys_initcall() instead of
>   apparently too late device_initcall(), this mitigates Shawn's
>   expressed concern about the change.

Yes, this is more conservative and stands less chance to cause regression.

> 
> Vladimir Zapolskiy (3):
>   pinctrl: imx: accept gpio request/free from pinctrl
>   gpio: mxc: shift gpio_mxc_init() to subsys_initcall level
>   gpio: mxc: add generic gpio request/free callbacks to pinctrl

For the series,

Acked-by: Shawn Guo <shawnguo@kernel.org>

[PATCH v2 0/3] gpio/pinctrl: imx: let IOMUX controller know about on-SoC GPIOs

[Shawn Guo]

On Thu, Sep 08, 2016 at 04:48:13AM +0300, Vladimir Zapolskiy wrote:
> The change establishes a connection between on-SoC IOMUX controller(s)
> and GPIO controllers found on some SoC from Freescale/NXP iMX series,
> if a GPIO controller device node contains common gpio-ranges information.
> 
> The change is backward compatible with respect to potentially not updated
> outdated DTB data without gpio-ranges propery, for such boards the only
> functional change is lowered initcall priority of GPIO controller driver,
> which in general anyway is exected to be used only after pinctrl/pinmux
> controller.
> 
> If this change is applied the next interesting applications may be done
> as a follow-up work, for example switching pad function to GPIO on gpiod
> request, converting iomux controller driver to strict type and so on.
> 
> For actual values of gpio-ranges properties please reference series
> "ARM: dts: imx: add gpio-ranges properties to some iMX GPIO controllers"
> http://www.spinics.net/lists/arm-kernel/msg525258.html
> 
> Changes from v1 to v2:
> * replaced 2/3 by an own change providing a better commit description
>   and which moves gpio_mxc_init() call to subsys_initcall() instead of
>   apparently too late device_initcall(), this mitigates Shawn's
>   expressed concern about the change.

Yes, this is more conservative and stands less chance to cause regression.

> 
> Vladimir Zapolskiy (3):
>   pinctrl: imx: accept gpio request/free from pinctrl
>   gpio: mxc: shift gpio_mxc_init() to subsys_initcall level
>   gpio: mxc: add generic gpio request/free callbacks to pinctrl

For the series,

Acked-by: Shawn Guo <shawnguo@kernel.org>

Re: [PATCH v2 1/3] pinctrl: imx: accept gpio request/free from pinctrl

[Linus Walleij]

On Thu, Sep 8, 2016 at 3:48 AM, Vladimir Zapolskiy
<vladimir_zapolskiy@mentor.com> wrote:

> While only Freescale Vybrid SoC has settings of GPIO capabilities done
> by iomux controller, it is only a matter of GPIO controller driver
> implementation for the rest of Freescale/NXP SoCs from iMX series.
>
> As a practical example on GPIO request a pad function should be
> switched to GPIO, but because this requires updates to all particular
> iMX pinctrl drivers, for simplicity at the moment add only a proper
> connection between shared pinctrl-imx and pinctrl/pinmux core, namely
> .gpio_request_enable/.gpio_disable_free/.gpio_set_direction callbacks
> should return success to a caller. This change allows to progress by
> adding request/free callbacks into gpio-mxc.c driver.
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> ---
> Changes from v1 to v2:
> * none

Patch applied with Shawn's ACK.

Yours,
Linus Walleij

[PATCH v2 1/3] pinctrl: imx: accept gpio request/free from pinctrl

[Linus Walleij]

On Thu, Sep 8, 2016 at 3:48 AM, Vladimir Zapolskiy
<vladimir_zapolskiy@mentor.com> wrote:

> While only Freescale Vybrid SoC has settings of GPIO capabilities done
> by iomux controller, it is only a matter of GPIO controller driver
> implementation for the rest of Freescale/NXP SoCs from iMX series.
>
> As a practical example on GPIO request a pad function should be
> switched to GPIO, but because this requires updates to all particular
> iMX pinctrl drivers, for simplicity at the moment add only a proper
> connection between shared pinctrl-imx and pinctrl/pinmux core, namely
> .gpio_request_enable/.gpio_disable_free/.gpio_set_direction callbacks
> should return success to a caller. This change allows to progress by
> adding request/free callbacks into gpio-mxc.c driver.
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> ---
> Changes from v1 to v2:
> * none

Patch applied with Shawn's ACK.

Yours,
Linus Walleij

Re: [PATCH v2 2/3] gpio: mxc: shift gpio_mxc_init() to subsys_initcall level

[Linus Walleij]

On Thu, Sep 8, 2016 at 3:48 AM, Vladimir Zapolskiy
<vladimir_zapolskiy@mentor.com> wrote:

> In general situation on-SoC GPIO controller drivers should be probed
> after pinctrl/pinmux controller driver, because on-SoC GPIOs utilize a
> pin/pad as a resource provided and controlled by pinctrl subsystem.
>
> This is stated in multiple places, e.g. from drivers/Makefile:
>
>   GPIO must come after pinctrl as gpios may need to mux pins etc
>
> Looking at Freescale iMX SoC series specifics, imx*_pinctrl_init()
> functions are called at arch_initcall and postcore_initcall init
> levels, so the change of initcall level for gpio-mxc driver from
> postcore_initcall to subsys_initcall level is sufficient. Also note
> that the most of GPIO controller drivers settled at subsys_initcall
> level.
>
> If pinctrl subsystem manages pads with GPIO functions, the change is
> needed to avoid unwanted driver probe deferrals during kernel boot.
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> ---
> Changes from v1 to v2:
> * replaced by a change with better commit description and which
>   moves gpio_mxc_init() call to subsys_initcall() instead of
>   apparently too late device_initcall(), this mitigates Shawn's
>   expressed concern about the change.

Patch applied with Shawn's ACK.

Yours,
Linus Walleij

[PATCH v2 2/3] gpio: mxc: shift gpio_mxc_init() to subsys_initcall level

[Linus Walleij]

On Thu, Sep 8, 2016 at 3:48 AM, Vladimir Zapolskiy
<vladimir_zapolskiy@mentor.com> wrote:

> In general situation on-SoC GPIO controller drivers should be probed
> after pinctrl/pinmux controller driver, because on-SoC GPIOs utilize a
> pin/pad as a resource provided and controlled by pinctrl subsystem.
>
> This is stated in multiple places, e.g. from drivers/Makefile:
>
>   GPIO must come after pinctrl as gpios may need to mux pins etc
>
> Looking at Freescale iMX SoC series specifics, imx*_pinctrl_init()
> functions are called at arch_initcall and postcore_initcall init
> levels, so the change of initcall level for gpio-mxc driver from
> postcore_initcall to subsys_initcall level is sufficient. Also note
> that the most of GPIO controller drivers settled at subsys_initcall
> level.
>
> If pinctrl subsystem manages pads with GPIO functions, the change is
> needed to avoid unwanted driver probe deferrals during kernel boot.
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> ---
> Changes from v1 to v2:
> * replaced by a change with better commit description and which
>   moves gpio_mxc_init() call to subsys_initcall() instead of
>   apparently too late device_initcall(), this mitigates Shawn's
>   expressed concern about the change.

Patch applied with Shawn's ACK.

Yours,
Linus Walleij

Re: [PATCH v2 3/3] gpio: mxc: add generic gpio request/free callbacks to pinctrl

[Linus Walleij]

On Thu, Sep 8, 2016 at 3:48 AM, Vladimir Zapolskiy
<vladimir_zapolskiy@mentor.com> wrote:

> If a GPIO controller description in board DTB contains information
> about mappings between GPIOs and pads under IOMUX control use it to
> request and free GPIOs with respect to pinctrl/pinmux subsystems.
>
> One of immediate positive functional changes is inability to
> request non-existing GPIOs, i.e. if there is no pad such. Also
> pinctrl/pinmux may now properly account pads occupied by requested
> GPIOs.
>
> The change has no effect, if "gpio-ranges" property is not found
> including the case if a board has no DTB firmware.
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> ---
> Changes from v1 to v2:
> * none

Patch applied with Shawn's ACK.

Yours,
Linus Walleij

[PATCH v2 3/3] gpio: mxc: add generic gpio request/free callbacks to pinctrl

[Linus Walleij]

On Thu, Sep 8, 2016 at 3:48 AM, Vladimir Zapolskiy
<vladimir_zapolskiy@mentor.com> wrote:

> If a GPIO controller description in board DTB contains information
> about mappings between GPIOs and pads under IOMUX control use it to
> request and free GPIOs with respect to pinctrl/pinmux subsystems.
>
> One of immediate positive functional changes is inability to
> request non-existing GPIOs, i.e. if there is no pad such. Also
> pinctrl/pinmux may now properly account pads occupied by requested
> GPIOs.
>
> The change has no effect, if "gpio-ranges" property is not found
> including the case if a board has no DTB firmware.
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> ---
> Changes from v1 to v2:
> * none

Patch applied with Shawn's ACK.

Yours,
Linus Walleij