All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Jianqun Xu <jay.xu@rock-chips.com>
Cc: linus.walleij@linaro.org, linux-rockchip@lists.infradead.org,
	linux-gpio@vger.kernel.org, Jianqun Xu <jay.xu@rock-chips.com>
Subject: Re: [PATCH 2/2] gpio: rockchip: get pinctrl node from 'gpio-ranges' property
Date: Thu, 03 Mar 2022 12:40:30 +0100	[thread overview]
Message-ID: <2004737.KQk8vJUODO@diego> (raw)
In-Reply-To: <20220303062211.1378883-3-jay.xu@rock-chips.com>

Hi Jianqun,

Am Donnerstag, 3. März 2022, 07:22:11 CET schrieb Jianqun Xu:
> The dt nodes for rockchip soc designes as
> 
> 	pinctrl: pinctrl {
> 		gpio {
> 			gpio-ranges = <&pinctrl xxx>;
> 		};
> 	};
> 
> Currently, we get the pinctrl dt node from parent of gpio, this patch
> try to get pinctrl dt node from 'gpio-ranges' property.
> 
> After this patch, the dt nodes possible to be
> 
> 	gpio {
> 		gpio-ranges = <&pinctrl xxx>;
> 	};
> 
> 	pinctrl: pinctrl {
> 
> 	};
> 
> then the gpio driver could register as platform device itself, but not
> populate from pinctrl driver.

The change looks interesting, as it would solve that long-standing
design-issue I "created" back in 2013 ;-) .

Though you need to keep some things in mind:

(1) Such a change should be reflected in the devicetree binding
    as it involves a different form of nodes and introduces.

    Looking at the binding description, using gpio-ranges to map
    to specific pinctrl pins really seems to be a valid use for this.


(2) Keep things backwards compatible.
    Old devicetrees should stay working with new kernel versions

    A common pattern is to try the new approach and if that fails
    try the "deprecated" method, which should be nicely doable
    when looking at the code change below.


Heiko

> Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
> ---
>  drivers/gpio/gpio-rockchip.c | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-rockchip.c b/drivers/gpio/gpio-rockchip.c
> index 1da0324445cc..46c54dff92db 100644
> --- a/drivers/gpio/gpio-rockchip.c
> +++ b/drivers/gpio/gpio-rockchip.c
> @@ -690,6 +690,9 @@ rockchip_gpio_find_bank(struct pinctrl_dev *pctldev, int id)
>  	int i, found = 0;
>  
>  	info = pinctrl_dev_get_drvdata(pctldev);
> +	if (!info)
> +		return NULL;
> +
>  	bank = info->ctrl->pin_banks;
>  	for (i = 0; i < info->ctrl->nr_banks; i++, bank++) {
>  		if (bank->bank_num == id) {
> @@ -705,15 +708,16 @@ static int rockchip_gpio_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
>  	struct device_node *np = dev->of_node;
> -	struct device_node *pctlnp = of_get_parent(np);
> +	struct device_node *pctlnp = NULL;
>  	struct pinctrl_dev *pctldev = NULL;
>  	struct rockchip_pin_bank *bank = NULL;
>  	struct rockchip_pin_output_deferred *cfg;
>  	static int gpio;
>  	int id, ret;
>  
> -	if (!np || !pctlnp)
> -		return -ENODEV;
> +	pctlnp = of_parse_phandle(np, "gpio-ranges", 0);
> +	if (!pctlnp)
> +		pctlnp = of_get_parent(np);
>  
>  	pctldev = of_pinctrl_get(pctlnp);
>  	if (!pctldev)
> 





WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: Jianqun Xu <jay.xu@rock-chips.com>
Cc: linus.walleij@linaro.org, linux-rockchip@lists.infradead.org,
	linux-gpio@vger.kernel.org, Jianqun Xu <jay.xu@rock-chips.com>
Subject: Re: [PATCH 2/2] gpio: rockchip: get pinctrl node from 'gpio-ranges' property
Date: Thu, 03 Mar 2022 12:40:30 +0100	[thread overview]
Message-ID: <2004737.KQk8vJUODO@diego> (raw)
In-Reply-To: <20220303062211.1378883-3-jay.xu@rock-chips.com>

Hi Jianqun,

Am Donnerstag, 3. März 2022, 07:22:11 CET schrieb Jianqun Xu:
> The dt nodes for rockchip soc designes as
> 
> 	pinctrl: pinctrl {
> 		gpio {
> 			gpio-ranges = <&pinctrl xxx>;
> 		};
> 	};
> 
> Currently, we get the pinctrl dt node from parent of gpio, this patch
> try to get pinctrl dt node from 'gpio-ranges' property.
> 
> After this patch, the dt nodes possible to be
> 
> 	gpio {
> 		gpio-ranges = <&pinctrl xxx>;
> 	};
> 
> 	pinctrl: pinctrl {
> 
> 	};
> 
> then the gpio driver could register as platform device itself, but not
> populate from pinctrl driver.

The change looks interesting, as it would solve that long-standing
design-issue I "created" back in 2013 ;-) .

Though you need to keep some things in mind:

(1) Such a change should be reflected in the devicetree binding
    as it involves a different form of nodes and introduces.

    Looking at the binding description, using gpio-ranges to map
    to specific pinctrl pins really seems to be a valid use for this.


(2) Keep things backwards compatible.
    Old devicetrees should stay working with new kernel versions

    A common pattern is to try the new approach and if that fails
    try the "deprecated" method, which should be nicely doable
    when looking at the code change below.


Heiko

> Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
> ---
>  drivers/gpio/gpio-rockchip.c | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-rockchip.c b/drivers/gpio/gpio-rockchip.c
> index 1da0324445cc..46c54dff92db 100644
> --- a/drivers/gpio/gpio-rockchip.c
> +++ b/drivers/gpio/gpio-rockchip.c
> @@ -690,6 +690,9 @@ rockchip_gpio_find_bank(struct pinctrl_dev *pctldev, int id)
>  	int i, found = 0;
>  
>  	info = pinctrl_dev_get_drvdata(pctldev);
> +	if (!info)
> +		return NULL;
> +
>  	bank = info->ctrl->pin_banks;
>  	for (i = 0; i < info->ctrl->nr_banks; i++, bank++) {
>  		if (bank->bank_num == id) {
> @@ -705,15 +708,16 @@ static int rockchip_gpio_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
>  	struct device_node *np = dev->of_node;
> -	struct device_node *pctlnp = of_get_parent(np);
> +	struct device_node *pctlnp = NULL;
>  	struct pinctrl_dev *pctldev = NULL;
>  	struct rockchip_pin_bank *bank = NULL;
>  	struct rockchip_pin_output_deferred *cfg;
>  	static int gpio;
>  	int id, ret;
>  
> -	if (!np || !pctlnp)
> -		return -ENODEV;
> +	pctlnp = of_parse_phandle(np, "gpio-ranges", 0);
> +	if (!pctlnp)
> +		pctlnp = of_get_parent(np);
>  
>  	pctldev = of_pinctrl_get(pctlnp);
>  	if (!pctldev)
> 





_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2022-03-03 11:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-03  6:22 [PATCH 0/2] gpio-rochchip Jianqun Xu
2022-03-03  6:22 ` Jianqun Xu
2022-03-03  6:22 ` [PATCH 1/2] gpio: rockchip: make gpio work without cru module Jianqun Xu
2022-03-03  6:22   ` Jianqun Xu
2022-03-03 11:28   ` Heiko Stübner
2022-03-03 11:28     ` Heiko Stübner
2022-03-04  3:00     ` jay.xu
2022-03-03  6:22 ` [PATCH 2/2] gpio: rockchip: get pinctrl node from 'gpio-ranges' property Jianqun Xu
2022-03-03  6:22   ` Jianqun Xu
2022-03-03 11:40   ` Heiko Stübner [this message]
2022-03-03 11:40     ` Heiko Stübner
2022-03-04  3:02     ` jay.xu
2022-03-07  8:08     ` jay.xu
2022-03-15  1:15   ` Linus Walleij
2022-03-15  1:15     ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2004737.KQk8vJUODO@diego \
    --to=heiko@sntech.de \
    --cc=jay.xu@rock-chips.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.