[PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Stefan Wahren]

This patch series tries to provide backward compatibility for DTB which
lacks the gpio-ranges property.

The commit ("pinctrl: msm: fix gpio-hog related boot issues") by Christian
Lamparter already contains a fallback in case the gpio-ranges property
is missing. But this approach doesn't work on BCM2835 with a gpio-hog
defined for the SoC GPIOs.

Based Christian's on explanation i conclude that the fallback must happen
during the gpiochip_add() call and not afterwards. So the approach is to
call an optional hook, which can be implemented in the platform driver.

This series has been tested on Raspberry Pi 3 B Plus.

Stefan Wahren (2):
  gpiolib: of: Introduce hook for missing gpio-ranges
  pinctrl: bcm2835: implement hook for missing gpio-ranges

 drivers/gpio/gpiolib-of.c             |  5 +++++
 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 18 ++++++++++++++++++
 include/linux/gpio/driver.h           | 12 ++++++++++++
 3 files changed, 35 insertions(+)

-- 
2.7.4

[PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Stefan Wahren]

This patch series tries to provide backward compatibility for DTB which
lacks the gpio-ranges property.

The commit ("pinctrl: msm: fix gpio-hog related boot issues") by Christian
Lamparter already contains a fallback in case the gpio-ranges property
is missing. But this approach doesn't work on BCM2835 with a gpio-hog
defined for the SoC GPIOs.

Based Christian's on explanation i conclude that the fallback must happen
during the gpiochip_add() call and not afterwards. So the approach is to
call an optional hook, which can be implemented in the platform driver.

This series has been tested on Raspberry Pi 3 B Plus.

Stefan Wahren (2):
  gpiolib: of: Introduce hook for missing gpio-ranges
  pinctrl: bcm2835: implement hook for missing gpio-ranges

 drivers/gpio/gpiolib-of.c             |  5 +++++
 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 18 ++++++++++++++++++
 include/linux/gpio/driver.h           | 12 ++++++++++++
 3 files changed, 35 insertions(+)

-- 
2.7.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH RFC 1/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Stefan Wahren]

Since commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
the device tree nodes of GPIO controller need the gpio-ranges property to
handle gpio-hogs. Unfortunately it's impossible to guarantee that every new
kernel is shipped with an updated device tree binary.

In order to provide backward compatibility with those older DTB, we need a
callback within of_gpiochip_add_pin_range() so the relevant platform driver
can handle this case.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 drivers/gpio/gpiolib-of.c   |  5 +++++
 include/linux/gpio/driver.h | 12 ++++++++++++
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 91dcf2c..45b6edb 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -933,6 +933,11 @@ static int of_gpiochip_add_pin_range(struct gpio_chip *chip)
 	if (!np)
 		return 0;
 
+	if (!of_property_read_bool(np, "gpio-ranges") &&
+	    chip->of_gpio_ranges_fallback) {
+		return chip->of_gpio_ranges_fallback(chip, np);
+	}
+
 	group_names = of_find_property(np, group_names_propname, NULL);
 
 	for (;; index++) {
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index b0728c8..47a5ea0 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -489,6 +489,18 @@ struct gpio_chip {
 	 */
 	int (*of_xlate)(struct gpio_chip *gc,
 			const struct of_phandle_args *gpiospec, u32 *flags);
+
+	/**
+	 * @of_gpio_ranges_fallback
+	 *
+	 * Optional hook for the case that no gpio-ranges property is defined
+	 * within the device tree node "np" (usually DT before introduction
+	 * of gpio-ranges). So this callback is helpful to provide the
+	 * necessary backward compatibility for the pin ranges.
+	 */
+	int (*of_gpio_ranges_fallback)(struct gpio_chip *gc,
+				       struct device_node *np);
+
 #endif /* CONFIG_OF_GPIO */
 };
 
-- 
2.7.4

[PATCH RFC 1/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Stefan Wahren]

Since commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
the device tree nodes of GPIO controller need the gpio-ranges property to
handle gpio-hogs. Unfortunately it's impossible to guarantee that every new
kernel is shipped with an updated device tree binary.

In order to provide backward compatibility with those older DTB, we need a
callback within of_gpiochip_add_pin_range() so the relevant platform driver
can handle this case.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 drivers/gpio/gpiolib-of.c   |  5 +++++
 include/linux/gpio/driver.h | 12 ++++++++++++
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 91dcf2c..45b6edb 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -933,6 +933,11 @@ static int of_gpiochip_add_pin_range(struct gpio_chip *chip)
 	if (!np)
 		return 0;
 
+	if (!of_property_read_bool(np, "gpio-ranges") &&
+	    chip->of_gpio_ranges_fallback) {
+		return chip->of_gpio_ranges_fallback(chip, np);
+	}
+
 	group_names = of_find_property(np, group_names_propname, NULL);
 
 	for (;; index++) {
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index b0728c8..47a5ea0 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -489,6 +489,18 @@ struct gpio_chip {
 	 */
 	int (*of_xlate)(struct gpio_chip *gc,
 			const struct of_phandle_args *gpiospec, u32 *flags);
+
+	/**
+	 * @of_gpio_ranges_fallback
+	 *
+	 * Optional hook for the case that no gpio-ranges property is defined
+	 * within the device tree node "np" (usually DT before introduction
+	 * of gpio-ranges). So this callback is helpful to provide the
+	 * necessary backward compatibility for the pin ranges.
+	 */
+	int (*of_gpio_ranges_fallback)(struct gpio_chip *gc,
+				       struct device_node *np);
+
 #endif /* CONFIG_OF_GPIO */
 };
 
-- 
2.7.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH RFC 2/2] pinctrl: bcm2835: implement hook for missing gpio-ranges

[Stefan Wahren]

The commit c8013355ead6 ("ARM: dts: gpio-ranges property is now required")
fixed the GPIO probing issues caused by "pinctrl: bcm2835: Change init
order for gpio hogs". This changed only the DTS files provided by the kernel
tree. Unfortunately it isn't guaranteed that these files are shipped to
all users.

So implement the necessary backward compatibility for BCM2835 and
BCM2711 platform.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 47e433e..dad4530 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -358,6 +358,22 @@ static int bcm2835_gpio_direction_output(struct gpio_chip *chip,
 	return 0;
 }
 
+static int bcm2835_of_gpio_ranges_fallback(struct gpio_chip *gc,
+					   struct device_node *np)
+{
+	struct pinctrl_dev *pctldev = of_pinctrl_get(np);
+
+	of_node_put(np);
+
+	if (!pctldev)
+		return 0;
+
+	gpiochip_add_pin_range(gc, pinctrl_dev_get_devname(pctldev), 0, 0,
+			       gc->ngpio);
+
+	return 0;
+}
+
 static const struct gpio_chip bcm2835_gpio_chip = {
 	.label = MODULE_NAME,
 	.owner = THIS_MODULE,
@@ -372,6 +388,7 @@ static const struct gpio_chip bcm2835_gpio_chip = {
 	.base = -1,
 	.ngpio = BCM2835_NUM_GPIOS,
 	.can_sleep = false,
+	.of_gpio_ranges_fallback = bcm2835_of_gpio_ranges_fallback,
 };
 
 static const struct gpio_chip bcm2711_gpio_chip = {
@@ -388,6 +405,7 @@ static const struct gpio_chip bcm2711_gpio_chip = {
 	.base = -1,
 	.ngpio = BCM2711_NUM_GPIOS,
 	.can_sleep = false,
+	.of_gpio_ranges_fallback = bcm2835_of_gpio_ranges_fallback,
 };
 
 static void bcm2835_gpio_irq_handle_bank(struct bcm2835_pinctrl *pc,
-- 
2.7.4

[PATCH RFC 2/2] pinctrl: bcm2835: implement hook for missing gpio-ranges

[Stefan Wahren]

The commit c8013355ead6 ("ARM: dts: gpio-ranges property is now required")
fixed the GPIO probing issues caused by "pinctrl: bcm2835: Change init
order for gpio hogs". This changed only the DTS files provided by the kernel
tree. Unfortunately it isn't guaranteed that these files are shipped to
all users.

So implement the necessary backward compatibility for BCM2835 and
BCM2711 platform.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 47e433e..dad4530 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -358,6 +358,22 @@ static int bcm2835_gpio_direction_output(struct gpio_chip *chip,
 	return 0;
 }
 
+static int bcm2835_of_gpio_ranges_fallback(struct gpio_chip *gc,
+					   struct device_node *np)
+{
+	struct pinctrl_dev *pctldev = of_pinctrl_get(np);
+
+	of_node_put(np);
+
+	if (!pctldev)
+		return 0;
+
+	gpiochip_add_pin_range(gc, pinctrl_dev_get_devname(pctldev), 0, 0,
+			       gc->ngpio);
+
+	return 0;
+}
+
 static const struct gpio_chip bcm2835_gpio_chip = {
 	.label = MODULE_NAME,
 	.owner = THIS_MODULE,
@@ -372,6 +388,7 @@ static const struct gpio_chip bcm2835_gpio_chip = {
 	.base = -1,
 	.ngpio = BCM2835_NUM_GPIOS,
 	.can_sleep = false,
+	.of_gpio_ranges_fallback = bcm2835_of_gpio_ranges_fallback,
 };
 
 static const struct gpio_chip bcm2711_gpio_chip = {
@@ -388,6 +405,7 @@ static const struct gpio_chip bcm2711_gpio_chip = {
 	.base = -1,
 	.ngpio = BCM2711_NUM_GPIOS,
 	.can_sleep = false,
+	.of_gpio_ranges_fallback = bcm2835_of_gpio_ranges_fallback,
 };
 
 static void bcm2835_gpio_irq_handle_bank(struct bcm2835_pinctrl *pc,
-- 
2.7.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Florian Fainelli]

On 3/9/2022 11:43 AM, Stefan Wahren wrote:
> This patch series tries to provide backward compatibility for DTB which
> lacks the gpio-ranges property.
> 
> The commit ("pinctrl: msm: fix gpio-hog related boot issues") by Christian
> Lamparter already contains a fallback in case the gpio-ranges property
> is missing. But this approach doesn't work on BCM2835 with a gpio-hog
> defined for the SoC GPIOs.
> 
> Based Christian's on explanation i conclude that the fallback must happen
> during the gpiochip_add() call and not afterwards. So the approach is to
> call an optional hook, which can be implemented in the platform driver.
> 
> This series has been tested on Raspberry Pi 3 B Plus.

For both patches, with and without 'gpio-ranges' for pinctrl-bcm2835.c:

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>

Thanks a lot Stefan!
-- 
Florian

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Florian Fainelli]

On 3/9/2022 11:43 AM, Stefan Wahren wrote:
> This patch series tries to provide backward compatibility for DTB which
> lacks the gpio-ranges property.
> 
> The commit ("pinctrl: msm: fix gpio-hog related boot issues") by Christian
> Lamparter already contains a fallback in case the gpio-ranges property
> is missing. But this approach doesn't work on BCM2835 with a gpio-hog
> defined for the SoC GPIOs.
> 
> Based Christian's on explanation i conclude that the fallback must happen
> during the gpiochip_add() call and not afterwards. So the approach is to
> call an optional hook, which can be implemented in the platform driver.
> 
> This series has been tested on Raspberry Pi 3 B Plus.

For both patches, with and without 'gpio-ranges' for pinctrl-bcm2835.c:

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>

Thanks a lot Stefan!
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH RFC 1/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Bartosz Golaszewski]

On Wed, Mar 9, 2022 at 8:44 PM Stefan Wahren <stefan.wahren@i2se.com> wrote:
>
> Since commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
> the device tree nodes of GPIO controller need the gpio-ranges property to
> handle gpio-hogs. Unfortunately it's impossible to guarantee that every new
> kernel is shipped with an updated device tree binary.
>
> In order to provide backward compatibility with those older DTB, we need a
> callback within of_gpiochip_add_pin_range() so the relevant platform driver
> can handle this case.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
>  drivers/gpio/gpiolib-of.c   |  5 +++++
>  include/linux/gpio/driver.h | 12 ++++++++++++
>  2 files changed, 17 insertions(+)
>
> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> index 91dcf2c..45b6edb 100644
> --- a/drivers/gpio/gpiolib-of.c
> +++ b/drivers/gpio/gpiolib-of.c
> @@ -933,6 +933,11 @@ static int of_gpiochip_add_pin_range(struct gpio_chip *chip)
>         if (!np)
>                 return 0;
>
> +       if (!of_property_read_bool(np, "gpio-ranges") &&
> +           chip->of_gpio_ranges_fallback) {
> +               return chip->of_gpio_ranges_fallback(chip, np);
> +       }
> +
>         group_names = of_find_property(np, group_names_propname, NULL);
>
>         for (;; index++) {
> diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
> index b0728c8..47a5ea0 100644
> --- a/include/linux/gpio/driver.h
> +++ b/include/linux/gpio/driver.h
> @@ -489,6 +489,18 @@ struct gpio_chip {
>          */
>         int (*of_xlate)(struct gpio_chip *gc,
>                         const struct of_phandle_args *gpiospec, u32 *flags);
> +
> +       /**
> +        * @of_gpio_ranges_fallback
> +        *
> +        * Optional hook for the case that no gpio-ranges property is defined
> +        * within the device tree node "np" (usually DT before introduction
> +        * of gpio-ranges). So this callback is helpful to provide the
> +        * necessary backward compatibility for the pin ranges.
> +        */
> +       int (*of_gpio_ranges_fallback)(struct gpio_chip *gc,
> +                                      struct device_node *np);
> +
>  #endif /* CONFIG_OF_GPIO */
>  };
>
> --
> 2.7.4
>

Acked-by: Bartosz Golaszewski <brgl@bgdev.pl>

Re: [PATCH RFC 1/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Bartosz Golaszewski]

On Wed, Mar 9, 2022 at 8:44 PM Stefan Wahren <stefan.wahren@i2se.com> wrote:
>
> Since commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
> the device tree nodes of GPIO controller need the gpio-ranges property to
> handle gpio-hogs. Unfortunately it's impossible to guarantee that every new
> kernel is shipped with an updated device tree binary.
>
> In order to provide backward compatibility with those older DTB, we need a
> callback within of_gpiochip_add_pin_range() so the relevant platform driver
> can handle this case.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
>  drivers/gpio/gpiolib-of.c   |  5 +++++
>  include/linux/gpio/driver.h | 12 ++++++++++++
>  2 files changed, 17 insertions(+)
>
> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> index 91dcf2c..45b6edb 100644
> --- a/drivers/gpio/gpiolib-of.c
> +++ b/drivers/gpio/gpiolib-of.c
> @@ -933,6 +933,11 @@ static int of_gpiochip_add_pin_range(struct gpio_chip *chip)
>         if (!np)
>                 return 0;
>
> +       if (!of_property_read_bool(np, "gpio-ranges") &&
> +           chip->of_gpio_ranges_fallback) {
> +               return chip->of_gpio_ranges_fallback(chip, np);
> +       }
> +
>         group_names = of_find_property(np, group_names_propname, NULL);
>
>         for (;; index++) {
> diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
> index b0728c8..47a5ea0 100644
> --- a/include/linux/gpio/driver.h
> +++ b/include/linux/gpio/driver.h
> @@ -489,6 +489,18 @@ struct gpio_chip {
>          */
>         int (*of_xlate)(struct gpio_chip *gc,
>                         const struct of_phandle_args *gpiospec, u32 *flags);
> +
> +       /**
> +        * @of_gpio_ranges_fallback
> +        *
> +        * Optional hook for the case that no gpio-ranges property is defined
> +        * within the device tree node "np" (usually DT before introduction
> +        * of gpio-ranges). So this callback is helpful to provide the
> +        * necessary backward compatibility for the pin ranges.
> +        */
> +       int (*of_gpio_ranges_fallback)(struct gpio_chip *gc,
> +                                      struct device_node *np);
> +
>  #endif /* CONFIG_OF_GPIO */
>  };
>
> --
> 2.7.4
>

Acked-by: Bartosz Golaszewski <brgl@bgdev.pl>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Linus Walleij]

On Wed, Mar 9, 2022 at 8:44 PM Stefan Wahren <stefan.wahren@i2se.com> wrote:

> This patch series tries to provide backward compatibility for DTB which
> lacks the gpio-ranges property.
>
> The commit ("pinctrl: msm: fix gpio-hog related boot issues") by Christian
> Lamparter already contains a fallback in case the gpio-ranges property
> is missing. But this approach doesn't work on BCM2835 with a gpio-hog
> defined for the SoC GPIOs.
>
> Based Christian's on explanation i conclude that the fallback must happen
> during the gpiochip_add() call and not afterwards. So the approach is to
> call an optional hook, which can be implemented in the platform driver.
>
> This series has been tested on Raspberry Pi 3 B Plus.
>
> Stefan Wahren (2):
>   gpiolib: of: Introduce hook for missing gpio-ranges
>   pinctrl: bcm2835: implement hook for missing gpio-ranges

Looks good to me, is this something I should apply to the pinctrl
tree or should I wait for a non-RFC version?

Yours,
Linus Walleij

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Linus Walleij]

On Wed, Mar 9, 2022 at 8:44 PM Stefan Wahren <stefan.wahren@i2se.com> wrote:

> This patch series tries to provide backward compatibility for DTB which
> lacks the gpio-ranges property.
>
> The commit ("pinctrl: msm: fix gpio-hog related boot issues") by Christian
> Lamparter already contains a fallback in case the gpio-ranges property
> is missing. But this approach doesn't work on BCM2835 with a gpio-hog
> defined for the SoC GPIOs.
>
> Based Christian's on explanation i conclude that the fallback must happen
> during the gpiochip_add() call and not afterwards. So the approach is to
> call an optional hook, which can be implemented in the platform driver.
>
> This series has been tested on Raspberry Pi 3 B Plus.
>
> Stefan Wahren (2):
>   gpiolib: of: Introduce hook for missing gpio-ranges
>   pinctrl: bcm2835: implement hook for missing gpio-ranges

Looks good to me, is this something I should apply to the pinctrl
tree or should I wait for a non-RFC version?

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Florian Fainelli]

On 3/16/2022 6:15 PM, Linus Walleij wrote:
> On Wed, Mar 9, 2022 at 8:44 PM Stefan Wahren <stefan.wahren@i2se.com> wrote:
> 
>> This patch series tries to provide backward compatibility for DTB which
>> lacks the gpio-ranges property.
>>
>> The commit ("pinctrl: msm: fix gpio-hog related boot issues") by Christian
>> Lamparter already contains a fallback in case the gpio-ranges property
>> is missing. But this approach doesn't work on BCM2835 with a gpio-hog
>> defined for the SoC GPIOs.
>>
>> Based Christian's on explanation i conclude that the fallback must happen
>> during the gpiochip_add() call and not afterwards. So the approach is to
>> call an optional hook, which can be implemented in the platform driver.
>>
>> This series has been tested on Raspberry Pi 3 B Plus.
>>
>> Stefan Wahren (2):
>>    gpiolib: of: Introduce hook for missing gpio-ranges
>>    pinctrl: bcm2835: implement hook for missing gpio-ranges
> 
> Looks good to me, is this something I should apply to the pinctrl
> tree or should I wait for a non-RFC version?

I would be inclined to slap a couple of different Fixes tag to each 
commit because breaking older DTBs should IMHO be considered a 
regression. So for the first patch I would add:

Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")

and for the second patch:

Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs")

WDYT?
-- 
Florian

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Florian Fainelli]

On 3/16/2022 6:15 PM, Linus Walleij wrote:
> On Wed, Mar 9, 2022 at 8:44 PM Stefan Wahren <stefan.wahren@i2se.com> wrote:
> 
>> This patch series tries to provide backward compatibility for DTB which
>> lacks the gpio-ranges property.
>>
>> The commit ("pinctrl: msm: fix gpio-hog related boot issues") by Christian
>> Lamparter already contains a fallback in case the gpio-ranges property
>> is missing. But this approach doesn't work on BCM2835 with a gpio-hog
>> defined for the SoC GPIOs.
>>
>> Based Christian's on explanation i conclude that the fallback must happen
>> during the gpiochip_add() call and not afterwards. So the approach is to
>> call an optional hook, which can be implemented in the platform driver.
>>
>> This series has been tested on Raspberry Pi 3 B Plus.
>>
>> Stefan Wahren (2):
>>    gpiolib: of: Introduce hook for missing gpio-ranges
>>    pinctrl: bcm2835: implement hook for missing gpio-ranges
> 
> Looks good to me, is this something I should apply to the pinctrl
> tree or should I wait for a non-RFC version?

I would be inclined to slap a couple of different Fixes tag to each 
commit because breaking older DTBs should IMHO be considered a 
regression. So for the first patch I would add:

Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")

and for the second patch:

Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs")

WDYT?
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Stefan Wahren]

Hi,

Am 17.03.22 um 03:02 schrieb Florian Fainelli:
>
>
> On 3/16/2022 6:15 PM, Linus Walleij wrote:
>> On Wed, Mar 9, 2022 at 8:44 PM Stefan Wahren <stefan.wahren@i2se.com> 
>> wrote:
>>
>>> This patch series tries to provide backward compatibility for DTB which
>>> lacks the gpio-ranges property.
>>>
>>> The commit ("pinctrl: msm: fix gpio-hog related boot issues") by 
>>> Christian
>>> Lamparter already contains a fallback in case the gpio-ranges property
>>> is missing. But this approach doesn't work on BCM2835 with a gpio-hog
>>> defined for the SoC GPIOs.
>>>
>>> Based Christian's on explanation i conclude that the fallback must 
>>> happen
>>> during the gpiochip_add() call and not afterwards. So the approach 
>>> is to
>>> call an optional hook, which can be implemented in the platform driver.
>>>
>>> This series has been tested on Raspberry Pi 3 B Plus.
>>>
>>> Stefan Wahren (2):
>>>    gpiolib: of: Introduce hook for missing gpio-ranges
>>>    pinctrl: bcm2835: implement hook for missing gpio-ranges
>>
>> Looks good to me, is this something I should apply to the pinctrl
>> tree or should I wait for a non-RFC version?
>
> I would be inclined to slap a couple of different Fixes tag to each 
> commit because breaking older DTBs should IMHO be considered a 
> regression. So for the first patch I would add:
>
> Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
>
> and for the second patch:
>
> Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs")
>
> WDYT?
so you consider backporting this "feature"?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Stefan Wahren]

Hi,

Am 17.03.22 um 03:02 schrieb Florian Fainelli:
>
>
> On 3/16/2022 6:15 PM, Linus Walleij wrote:
>> On Wed, Mar 9, 2022 at 8:44 PM Stefan Wahren <stefan.wahren@i2se.com> 
>> wrote:
>>
>>> This patch series tries to provide backward compatibility for DTB which
>>> lacks the gpio-ranges property.
>>>
>>> The commit ("pinctrl: msm: fix gpio-hog related boot issues") by 
>>> Christian
>>> Lamparter already contains a fallback in case the gpio-ranges property
>>> is missing. But this approach doesn't work on BCM2835 with a gpio-hog
>>> defined for the SoC GPIOs.
>>>
>>> Based Christian's on explanation i conclude that the fallback must 
>>> happen
>>> during the gpiochip_add() call and not afterwards. So the approach 
>>> is to
>>> call an optional hook, which can be implemented in the platform driver.
>>>
>>> This series has been tested on Raspberry Pi 3 B Plus.
>>>
>>> Stefan Wahren (2):
>>>    gpiolib: of: Introduce hook for missing gpio-ranges
>>>    pinctrl: bcm2835: implement hook for missing gpio-ranges
>>
>> Looks good to me, is this something I should apply to the pinctrl
>> tree or should I wait for a non-RFC version?
>
> I would be inclined to slap a couple of different Fixes tag to each 
> commit because breaking older DTBs should IMHO be considered a 
> regression. So for the first patch I would add:
>
> Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
>
> and for the second patch:
>
> Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs")
>
> WDYT?
so you consider backporting this "feature"?

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Florian Fainelli]

On 3/17/22 4:48 AM, Stefan Wahren wrote:
> Hi,
> 
> Am 17.03.22 um 03:02 schrieb Florian Fainelli:
>>
>>
>> On 3/16/2022 6:15 PM, Linus Walleij wrote:
>>> On Wed, Mar 9, 2022 at 8:44 PM Stefan Wahren <stefan.wahren@i2se.com>
>>> wrote:
>>>
>>>> This patch series tries to provide backward compatibility for DTB which
>>>> lacks the gpio-ranges property.
>>>>
>>>> The commit ("pinctrl: msm: fix gpio-hog related boot issues") by
>>>> Christian
>>>> Lamparter already contains a fallback in case the gpio-ranges property
>>>> is missing. But this approach doesn't work on BCM2835 with a gpio-hog
>>>> defined for the SoC GPIOs.
>>>>
>>>> Based Christian's on explanation i conclude that the fallback must
>>>> happen
>>>> during the gpiochip_add() call and not afterwards. So the approach
>>>> is to
>>>> call an optional hook, which can be implemented in the platform driver.
>>>>
>>>> This series has been tested on Raspberry Pi 3 B Plus.
>>>>
>>>> Stefan Wahren (2):
>>>>    gpiolib: of: Introduce hook for missing gpio-ranges
>>>>    pinctrl: bcm2835: implement hook for missing gpio-ranges
>>>
>>> Looks good to me, is this something I should apply to the pinctrl
>>> tree or should I wait for a non-RFC version?
>>
>> I would be inclined to slap a couple of different Fixes tag to each
>> commit because breaking older DTBs should IMHO be considered a
>> regression. So for the first patch I would add:
>>
>> Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
>>
>> and for the second patch:
>>
>> Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs")
>>
>> WDYT?
> so you consider backporting this "feature"?

Yes, I would consider your changes fixes actually. If I am the only one
deeply concerned about backwards compatibility I suppose I could
backport those into our tree.
-- 
Florian

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Florian Fainelli]

On 3/17/22 4:48 AM, Stefan Wahren wrote:
> Hi,
> 
> Am 17.03.22 um 03:02 schrieb Florian Fainelli:
>>
>>
>> On 3/16/2022 6:15 PM, Linus Walleij wrote:
>>> On Wed, Mar 9, 2022 at 8:44 PM Stefan Wahren <stefan.wahren@i2se.com>
>>> wrote:
>>>
>>>> This patch series tries to provide backward compatibility for DTB which
>>>> lacks the gpio-ranges property.
>>>>
>>>> The commit ("pinctrl: msm: fix gpio-hog related boot issues") by
>>>> Christian
>>>> Lamparter already contains a fallback in case the gpio-ranges property
>>>> is missing. But this approach doesn't work on BCM2835 with a gpio-hog
>>>> defined for the SoC GPIOs.
>>>>
>>>> Based Christian's on explanation i conclude that the fallback must
>>>> happen
>>>> during the gpiochip_add() call and not afterwards. So the approach
>>>> is to
>>>> call an optional hook, which can be implemented in the platform driver.
>>>>
>>>> This series has been tested on Raspberry Pi 3 B Plus.
>>>>
>>>> Stefan Wahren (2):
>>>>    gpiolib: of: Introduce hook for missing gpio-ranges
>>>>    pinctrl: bcm2835: implement hook for missing gpio-ranges
>>>
>>> Looks good to me, is this something I should apply to the pinctrl
>>> tree or should I wait for a non-RFC version?
>>
>> I would be inclined to slap a couple of different Fixes tag to each
>> commit because breaking older DTBs should IMHO be considered a
>> regression. So for the first patch I would add:
>>
>> Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
>>
>> and for the second patch:
>>
>> Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs")
>>
>> WDYT?
> so you consider backporting this "feature"?

Yes, I would consider your changes fixes actually. If I am the only one
deeply concerned about backwards compatibility I suppose I could
backport those into our tree.
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Stefan Wahren]

Hi,

Am 17.03.22 um 18:17 schrieb Florian Fainelli:
> On 3/17/22 4:48 AM, Stefan Wahren wrote:
>> Hi,
>>
>> Am 17.03.22 um 03:02 schrieb Florian Fainelli:
>>>
>>> On 3/16/2022 6:15 PM, Linus Walleij wrote:
>>>> On Wed, Mar 9, 2022 at 8:44 PM Stefan Wahren <stefan.wahren@i2se.com>
>>>> wrote:
>>>>
>>>>> This patch series tries to provide backward compatibility for DTB which
>>>>> lacks the gpio-ranges property.
>>>>>
>>>>> The commit ("pinctrl: msm: fix gpio-hog related boot issues") by
>>>>> Christian
>>>>> Lamparter already contains a fallback in case the gpio-ranges property
>>>>> is missing. But this approach doesn't work on BCM2835 with a gpio-hog
>>>>> defined for the SoC GPIOs.
>>>>>
>>>>> Based Christian's on explanation i conclude that the fallback must
>>>>> happen
>>>>> during the gpiochip_add() call and not afterwards. So the approach
>>>>> is to
>>>>> call an optional hook, which can be implemented in the platform driver.
>>>>>
>>>>> This series has been tested on Raspberry Pi 3 B Plus.
>>>>>
>>>>> Stefan Wahren (2):
>>>>>     gpiolib: of: Introduce hook for missing gpio-ranges
>>>>>     pinctrl: bcm2835: implement hook for missing gpio-ranges
>>>> Looks good to me, is this something I should apply to the pinctrl
>>>> tree or should I wait for a non-RFC version?
>>> I would be inclined to slap a couple of different Fixes tag to each
>>> commit because breaking older DTBs should IMHO be considered a
>>> regression. So for the first patch I would add:
>>>
>>> Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
>>>
>>> and for the second patch:
>>>
>>> Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs")
>>>
>>> WDYT?
>> so you consider backporting this "feature"?
> Yes, I would consider your changes fixes actually. If I am the only one
> deeply concerned about backwards compatibility I suppose I could
> backport those into our tree.
i'm fine with backporting, but i thought these must be single 
independent patches.

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Stefan Wahren]

Hi,

Am 17.03.22 um 18:17 schrieb Florian Fainelli:
> On 3/17/22 4:48 AM, Stefan Wahren wrote:
>> Hi,
>>
>> Am 17.03.22 um 03:02 schrieb Florian Fainelli:
>>>
>>> On 3/16/2022 6:15 PM, Linus Walleij wrote:
>>>> On Wed, Mar 9, 2022 at 8:44 PM Stefan Wahren <stefan.wahren@i2se.com>
>>>> wrote:
>>>>
>>>>> This patch series tries to provide backward compatibility for DTB which
>>>>> lacks the gpio-ranges property.
>>>>>
>>>>> The commit ("pinctrl: msm: fix gpio-hog related boot issues") by
>>>>> Christian
>>>>> Lamparter already contains a fallback in case the gpio-ranges property
>>>>> is missing. But this approach doesn't work on BCM2835 with a gpio-hog
>>>>> defined for the SoC GPIOs.
>>>>>
>>>>> Based Christian's on explanation i conclude that the fallback must
>>>>> happen
>>>>> during the gpiochip_add() call and not afterwards. So the approach
>>>>> is to
>>>>> call an optional hook, which can be implemented in the platform driver.
>>>>>
>>>>> This series has been tested on Raspberry Pi 3 B Plus.
>>>>>
>>>>> Stefan Wahren (2):
>>>>>     gpiolib: of: Introduce hook for missing gpio-ranges
>>>>>     pinctrl: bcm2835: implement hook for missing gpio-ranges
>>>> Looks good to me, is this something I should apply to the pinctrl
>>>> tree or should I wait for a non-RFC version?
>>> I would be inclined to slap a couple of different Fixes tag to each
>>> commit because breaking older DTBs should IMHO be considered a
>>> regression. So for the first patch I would add:
>>>
>>> Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
>>>
>>> and for the second patch:
>>>
>>> Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs")
>>>
>>> WDYT?
>> so you consider backporting this "feature"?
> Yes, I would consider your changes fixes actually. If I am the only one
> deeply concerned about backwards compatibility I suppose I could
> backport those into our tree.
i'm fine with backporting, but i thought these must be single 
independent patches.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Florian Fainelli]

On 3/17/22 12:23, Stefan Wahren wrote:
> Hi,
> 
> Am 17.03.22 um 18:17 schrieb Florian Fainelli:
>> On 3/17/22 4:48 AM, Stefan Wahren wrote:
>>> Hi,
>>>
>>> Am 17.03.22 um 03:02 schrieb Florian Fainelli:
>>>>
>>>> On 3/16/2022 6:15 PM, Linus Walleij wrote:
>>>>> On Wed, Mar 9, 2022 at 8:44 PM Stefan Wahren <stefan.wahren@i2se.com>
>>>>> wrote:
>>>>>
>>>>>> This patch series tries to provide backward compatibility for DTB 
>>>>>> which
>>>>>> lacks the gpio-ranges property.
>>>>>>
>>>>>> The commit ("pinctrl: msm: fix gpio-hog related boot issues") by
>>>>>> Christian
>>>>>> Lamparter already contains a fallback in case the gpio-ranges 
>>>>>> property
>>>>>> is missing. But this approach doesn't work on BCM2835 with a gpio-hog
>>>>>> defined for the SoC GPIOs.
>>>>>>
>>>>>> Based Christian's on explanation i conclude that the fallback must
>>>>>> happen
>>>>>> during the gpiochip_add() call and not afterwards. So the approach
>>>>>> is to
>>>>>> call an optional hook, which can be implemented in the platform 
>>>>>> driver.
>>>>>>
>>>>>> This series has been tested on Raspberry Pi 3 B Plus.
>>>>>>
>>>>>> Stefan Wahren (2):
>>>>>>     gpiolib: of: Introduce hook for missing gpio-ranges
>>>>>>     pinctrl: bcm2835: implement hook for missing gpio-ranges
>>>>> Looks good to me, is this something I should apply to the pinctrl
>>>>> tree or should I wait for a non-RFC version?
>>>> I would be inclined to slap a couple of different Fixes tag to each
>>>> commit because breaking older DTBs should IMHO be considered a
>>>> regression. So for the first patch I would add:
>>>>
>>>> Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without 
>>>> pin-ranges")
>>>>
>>>> and for the second patch:
>>>>
>>>> Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio 
>>>> hogs")
>>>>
>>>> WDYT?
>>> so you consider backporting this "feature"?
>> Yes, I would consider your changes fixes actually. If I am the only one
>> deeply concerned about backwards compatibility I suppose I could
>> backport those into our tree.
> i'm fine with backporting, but i thought these must be single 
> independent patches.

Linus, how are we proceeding with these changes? Any hope to include 
them for 5.18?
-- 
Florian

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Florian Fainelli]

On 3/17/22 12:23, Stefan Wahren wrote:
> Hi,
> 
> Am 17.03.22 um 18:17 schrieb Florian Fainelli:
>> On 3/17/22 4:48 AM, Stefan Wahren wrote:
>>> Hi,
>>>
>>> Am 17.03.22 um 03:02 schrieb Florian Fainelli:
>>>>
>>>> On 3/16/2022 6:15 PM, Linus Walleij wrote:
>>>>> On Wed, Mar 9, 2022 at 8:44 PM Stefan Wahren <stefan.wahren@i2se.com>
>>>>> wrote:
>>>>>
>>>>>> This patch series tries to provide backward compatibility for DTB 
>>>>>> which
>>>>>> lacks the gpio-ranges property.
>>>>>>
>>>>>> The commit ("pinctrl: msm: fix gpio-hog related boot issues") by
>>>>>> Christian
>>>>>> Lamparter already contains a fallback in case the gpio-ranges 
>>>>>> property
>>>>>> is missing. But this approach doesn't work on BCM2835 with a gpio-hog
>>>>>> defined for the SoC GPIOs.
>>>>>>
>>>>>> Based Christian's on explanation i conclude that the fallback must
>>>>>> happen
>>>>>> during the gpiochip_add() call and not afterwards. So the approach
>>>>>> is to
>>>>>> call an optional hook, which can be implemented in the platform 
>>>>>> driver.
>>>>>>
>>>>>> This series has been tested on Raspberry Pi 3 B Plus.
>>>>>>
>>>>>> Stefan Wahren (2):
>>>>>>     gpiolib: of: Introduce hook for missing gpio-ranges
>>>>>>     pinctrl: bcm2835: implement hook for missing gpio-ranges
>>>>> Looks good to me, is this something I should apply to the pinctrl
>>>>> tree or should I wait for a non-RFC version?
>>>> I would be inclined to slap a couple of different Fixes tag to each
>>>> commit because breaking older DTBs should IMHO be considered a
>>>> regression. So for the first patch I would add:
>>>>
>>>> Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without 
>>>> pin-ranges")
>>>>
>>>> and for the second patch:
>>>>
>>>> Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio 
>>>> hogs")
>>>>
>>>> WDYT?
>>> so you consider backporting this "feature"?
>> Yes, I would consider your changes fixes actually. If I am the only one
>> deeply concerned about backwards compatibility I suppose I could
>> backport those into our tree.
> i'm fine with backporting, but i thought these must be single 
> independent patches.

Linus, how are we proceeding with these changes? Any hope to include 
them for 5.18?
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Linus Walleij]

On Mon, Mar 21, 2022 at 7:21 PM Florian Fainelli <f.fainelli@gmail.com> wrote:

> Linus, how are we proceeding with these changes? Any hope to include
> them for 5.18?

Yes if they are finished? These two have RFC prefix but if you say they
should be applied I'll apply them, I trust you!

Yours,
Linus Walleij

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Linus Walleij]

On Mon, Mar 21, 2022 at 7:21 PM Florian Fainelli <f.fainelli@gmail.com> wrote:

> Linus, how are we proceeding with these changes? Any hope to include
> them for 5.18?

Yes if they are finished? These two have RFC prefix but if you say they
should be applied I'll apply them, I trust you!

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Florian Fainelli]

On 3/24/22 12:00, Linus Walleij wrote:
> On Mon, Mar 21, 2022 at 7:21 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> 
>> Linus, how are we proceeding with these changes? Any hope to include
>> them for 5.18?
> 
> Yes if they are finished? These two have RFC prefix but if you say they
> should be applied I'll apply them, I trust you!

I do not really see much room for improvement, unless we wanted to move 
away from the callback approach and make it somewhat mandatory to put 
that code within the core pinctrl code, with the chances of possibly 
regression.

So as far as I can tell, they work as intended and advertised, tested 
them, ship it!
--
Florian

Re: [PATCH RFC 0/2] gpiolib: of: Introduce hook for missing gpio-ranges

[Florian Fainelli]

On 3/24/22 12:00, Linus Walleij wrote:
> On Mon, Mar 21, 2022 at 7:21 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> 
>> Linus, how are we proceeding with these changes? Any hope to include
>> them for 5.18?
> 
> Yes if they are finished? These two have RFC prefix but if you say they
> should be applied I'll apply them, I trust you!

I do not really see much room for improvement, unless we wanted to move 
away from the callback approach and make it somewhat mandatory to put 
that code within the core pinctrl code, with the chances of possibly 
regression.

So as far as I can tell, they work as intended and advertised, tested 
them, ship it!
--
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel