All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Grant Likely <grant.likely@secretlab.ca>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	Andreas Schallenberg <Andreas.Schallenberg@3alitytechnica.com>,
	Roland Stigge <stigge@antcom.de>,
	Jason Cooper <jason@lakedaemon.net>, Andrew Lunn <andrew@lunn.ch>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/3] gpio: pca953x: add support for pca9505
Date: Fri, 25 Jan 2013 09:36:50 +0100	[thread overview]
Message-ID: <51024422.2060503@free-electrons.com> (raw)
In-Reply-To: <CACRpkda-N0GrKOeaz4Hji0ef9pSRNPCxW_jLGR28iX-sk0-=tg@mail.gmail.com>

On 01/25/2013 09:16 AM, Linus Walleij wrote:
> On Tue, Jan 22, 2013 at 10:10 PM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
> 
>> Now that pca953x driver can handle GPIO expanders with more than 32
>> bits this patch adds the support for the pca9505 which cam with 40
>> GPIOs.
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> 
> Patch applied, thanks.
> 
> But guys, this driver contains some horrific stuff, look at this:
> 
> static int pxa_gpio_nums(void)
> {
>         int count = 0;
> 
> #ifdef CONFIG_ARCH_PXA
>         if (cpu_is_pxa25x()) {
> #ifdef CONFIG_CPU_PXA26x
>                 count = 89;
>                 gpio_type = PXA26X_GPIO;
> #elif defined(CONFIG_PXA25x)
>                 count = 84;
>                 gpio_type = PXA26X_GPIO;
> #endif /* CONFIG_CPU_PXA26x */
>         } else if (cpu_is_pxa27x()) {
>                 count = 120;
>                 gpio_type = PXA27X_GPIO;
>         } else if (cpu_is_pxa93x()) {
>                 count = 191;
>                 gpio_type = PXA93X_GPIO;
>         } else if (cpu_is_pxa3xx()) {
>                 count = 127;
>                 gpio_type = PXA3XX_GPIO;
>         }
> #endif /* CONFIG_ARCH_PXA */
> 
> #ifdef CONFIG_ARCH_MMP
>         if (cpu_is_pxa168() || cpu_is_pxa910()) {
>                 count = 127;
>                 gpio_type = MMP_GPIO;
>         } else if (cpu_is_mmp2()) {
>                 count = 191;
>                 gpio_type = MMP_GPIO;
>         }
> #endif /* CONFIG_ARCH_MMP */
>         return count;
> }
> 
> This is totally killing all attempts at a single kernel for multiple
> machines in this family. The above should not be #ifdef's but instead
> use either platform data or the compatible property to figure out which
> one to use.
> 
> It's fine to introduce new compatible= strings or device names to
> distinguish between these.
> 
> As an example, in pinctrl-nomadik.c we have this:
> 
> static const struct of_device_id nmk_pinctrl_match[] = {
>         {
>                 .compatible = "stericsson,nmk_pinctrl",
>                 .data = (void *)PINCTRL_NMK_DB8500,
>         },
>         {},
> };
> 
> static const struct platform_device_id nmk_pinctrl_id[] = {
>         { "pinctrl-stn8815", PINCTRL_NMK_STN8815 },
>         { "pinctrl-db8500", PINCTRL_NMK_DB8500 },
>         { "pinctrl-db8540", PINCTRL_NMK_DB8540 },
>         { }
> };
> 
> static struct platform_driver nmk_pinctrl_driver = {
>         .driver = {
>                 .owner = THIS_MODULE,
>                 .name = "pinctrl-nomadik",
>                 .of_match_table = nmk_pinctrl_match,
>         },
>         .probe = nmk_pinctrl_probe,
>         .id_table = nmk_pinctrl_id,
> };
> 
> 
> The first match is for DT boot the latter for using the platform
> device name directly.
> 
> Then in the probefunction we do:
> 
> static int nmk_pinctrl_probe(struct platform_device *pdev)
> {
>         const struct platform_device_id *platid = platform_get_device_id(pdev);
> (...)
>         if (platid)
>                 version = platid->driver_data;
>         else if (np) {
>                 const struct of_device_id *match;
> 
>                 match = of_match_device(nmk_pinctrl_match, &pdev->dev);
>                 if (!match)
>                         return -ENODEV;
>                 version = (unsigned int) match->data;
>         }
> (...)
>         if (version == PINCTRL_NMK_STN8815)
>                 nmk_pinctrl_stn8815_init(&npct->soc);
>         if (version == PINCTRL_NMK_DB8500)
>                 nmk_pinctrl_db8500_init(&npct->soc);
>         if (version == PINCTRL_NMK_DB8540)
>                 nmk_pinctrl_db8540_init(&npct->soc);
> }
> 
> Surely a scheme like this must be possible to use to distinguish between
> the different versions at runtime rather than using these #ifdefs?
> 

Well, at the beginning I thought adding support for pca9505 was just a matter
of a couple of lines to add. Then I realized that I need to handle the 40 bits
case, and I ended up refactoring all access to the registers. So now I am on it,
it seems I am volunteer to continue to improve this driver.

However I won't be able to test it, the only PXA based platform I have is a
Zaurus SL-C3100 which embeds a PXA270 if I remember well, but I doubt it come
with gpio expander on i2c.

Gregory

WARNING: multiple messages have this Message-ID (diff)
From: gregory.clement@free-electrons.com (Gregory CLEMENT)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 2/3] gpio: pca953x: add support for pca9505
Date: Fri, 25 Jan 2013 09:36:50 +0100	[thread overview]
Message-ID: <51024422.2060503@free-electrons.com> (raw)
In-Reply-To: <CACRpkda-N0GrKOeaz4Hji0ef9pSRNPCxW_jLGR28iX-sk0-=tg@mail.gmail.com>

On 01/25/2013 09:16 AM, Linus Walleij wrote:
> On Tue, Jan 22, 2013 at 10:10 PM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
> 
>> Now that pca953x driver can handle GPIO expanders with more than 32
>> bits this patch adds the support for the pca9505 which cam with 40
>> GPIOs.
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> 
> Patch applied, thanks.
> 
> But guys, this driver contains some horrific stuff, look at this:
> 
> static int pxa_gpio_nums(void)
> {
>         int count = 0;
> 
> #ifdef CONFIG_ARCH_PXA
>         if (cpu_is_pxa25x()) {
> #ifdef CONFIG_CPU_PXA26x
>                 count = 89;
>                 gpio_type = PXA26X_GPIO;
> #elif defined(CONFIG_PXA25x)
>                 count = 84;
>                 gpio_type = PXA26X_GPIO;
> #endif /* CONFIG_CPU_PXA26x */
>         } else if (cpu_is_pxa27x()) {
>                 count = 120;
>                 gpio_type = PXA27X_GPIO;
>         } else if (cpu_is_pxa93x()) {
>                 count = 191;
>                 gpio_type = PXA93X_GPIO;
>         } else if (cpu_is_pxa3xx()) {
>                 count = 127;
>                 gpio_type = PXA3XX_GPIO;
>         }
> #endif /* CONFIG_ARCH_PXA */
> 
> #ifdef CONFIG_ARCH_MMP
>         if (cpu_is_pxa168() || cpu_is_pxa910()) {
>                 count = 127;
>                 gpio_type = MMP_GPIO;
>         } else if (cpu_is_mmp2()) {
>                 count = 191;
>                 gpio_type = MMP_GPIO;
>         }
> #endif /* CONFIG_ARCH_MMP */
>         return count;
> }
> 
> This is totally killing all attempts at a single kernel for multiple
> machines in this family. The above should not be #ifdef's but instead
> use either platform data or the compatible property to figure out which
> one to use.
> 
> It's fine to introduce new compatible= strings or device names to
> distinguish between these.
> 
> As an example, in pinctrl-nomadik.c we have this:
> 
> static const struct of_device_id nmk_pinctrl_match[] = {
>         {
>                 .compatible = "stericsson,nmk_pinctrl",
>                 .data = (void *)PINCTRL_NMK_DB8500,
>         },
>         {},
> };
> 
> static const struct platform_device_id nmk_pinctrl_id[] = {
>         { "pinctrl-stn8815", PINCTRL_NMK_STN8815 },
>         { "pinctrl-db8500", PINCTRL_NMK_DB8500 },
>         { "pinctrl-db8540", PINCTRL_NMK_DB8540 },
>         { }
> };
> 
> static struct platform_driver nmk_pinctrl_driver = {
>         .driver = {
>                 .owner = THIS_MODULE,
>                 .name = "pinctrl-nomadik",
>                 .of_match_table = nmk_pinctrl_match,
>         },
>         .probe = nmk_pinctrl_probe,
>         .id_table = nmk_pinctrl_id,
> };
> 
> 
> The first match is for DT boot the latter for using the platform
> device name directly.
> 
> Then in the probefunction we do:
> 
> static int nmk_pinctrl_probe(struct platform_device *pdev)
> {
>         const struct platform_device_id *platid = platform_get_device_id(pdev);
> (...)
>         if (platid)
>                 version = platid->driver_data;
>         else if (np) {
>                 const struct of_device_id *match;
> 
>                 match = of_match_device(nmk_pinctrl_match, &pdev->dev);
>                 if (!match)
>                         return -ENODEV;
>                 version = (unsigned int) match->data;
>         }
> (...)
>         if (version == PINCTRL_NMK_STN8815)
>                 nmk_pinctrl_stn8815_init(&npct->soc);
>         if (version == PINCTRL_NMK_DB8500)
>                 nmk_pinctrl_db8500_init(&npct->soc);
>         if (version == PINCTRL_NMK_DB8540)
>                 nmk_pinctrl_db8540_init(&npct->soc);
> }
> 
> Surely a scheme like this must be possible to use to distinguish between
> the different versions at runtime rather than using these #ifdefs?
> 

Well, at the beginning I thought adding support for pca9505 was just a matter
of a couple of lines to add. Then I realized that I need to handle the 40 bits
case, and I ended up refactoring all access to the registers. So now I am on it,
it seems I am volunteer to continue to improve this driver.

However I won't be able to test it, the only PXA based platform I have is a
Zaurus SL-C3100 which embeds a PXA270 if I remember well, but I doubt it come
with gpio expander on i2c.

Gregory

  reply	other threads:[~2013-01-25  8:37 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-22 21:10 [PATCH v3 0/3] Add support for gpio expander pca9505 used on Mirabox Gregory CLEMENT
2013-01-22 21:10 ` Gregory CLEMENT
2013-01-22 21:10 ` [PATCH v3 1/3] gpio: pca953x: make the register access by GPIO bank Gregory CLEMENT
2013-01-22 21:10   ` Gregory CLEMENT
2013-01-25  8:03   ` Linus Walleij
2013-01-25  8:03     ` Linus Walleij
2013-01-22 21:10 ` [PATCH v3 2/3] gpio: pca953x: add support for pca9505 Gregory CLEMENT
2013-01-22 21:10   ` Gregory CLEMENT
2013-01-25  8:16   ` Linus Walleij
2013-01-25  8:16     ` Linus Walleij
2013-01-25  8:36     ` Gregory CLEMENT [this message]
2013-01-25  8:36       ` Gregory CLEMENT
2013-01-25  8:51       ` Linus Walleij
2013-01-25  8:51         ` Linus Walleij
2013-01-26 22:02         ` Gregory CLEMENT
2013-01-26 22:02           ` Gregory CLEMENT
2013-01-28  1:58           ` Haojian Zhuang
2013-01-28  1:58             ` Haojian Zhuang
2013-01-28 10:25           ` Linus Walleij
2013-01-28 10:25             ` Linus Walleij
2013-01-22 21:10 ` [PATCH v3 3/3] arm: mvebu: enable gpio expander over i2c on Mirabox platform Gregory CLEMENT
2013-01-22 21:10   ` Gregory CLEMENT
2013-01-25  8:17   ` Linus Walleij
2013-01-25  8:17     ` Linus Walleij
2013-01-25 12:46     ` Jason Cooper
2013-01-25 12:46       ` Jason Cooper
2013-01-25 12:55       ` Linus Walleij
2013-01-25 12:55         ` Linus Walleij
2013-01-25 12:57         ` Linus Walleij
2013-01-25 12:57           ` Linus Walleij
2013-01-25 13:07           ` Jason Cooper
2013-01-25 13:07             ` Jason Cooper
2013-01-25 13:03         ` Jason Cooper
2013-01-25 13:03           ` Jason Cooper
2013-02-16 18:52   ` Jason Cooper
2013-02-16 18:52     ` Jason Cooper

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=51024422.2060503@free-electrons.com \
    --to=gregory.clement@free-electrons.com \
    --cc=Andreas.Schallenberg@3alitytechnica.com \
    --cc=andrew@lunn.ch \
    --cc=grant.likely@secretlab.ca \
    --cc=jason@lakedaemon.net \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.ripard@free-electrons.com \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=stigge@antcom.de \
    --cc=thomas.petazzoni@free-electrons.com \
    /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.