LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Håvard Skinnemoen" <hskinnemoen@gmail.com>
To: Thomas Chou <thomas@wytron.com.tw>
Cc: Grant Likely <grant.likely@secretlab.ca>,
	Ben Dooks <ben-linux@fluff.org>,
	linux-kernel@vger.kernel.org, nios2-dev@sopc.et.ntust.edu.tw,
	devicetree-discuss@lists.ozlabs.org, linux-i2c@vger.kernel.org,
	Jean Delvare <khali@linux-fr.org>,
	Albert Herranz <albert_herranz@yahoo.es>
Subject: Re: [PATCH] i2c-gpio: add devicetree support
Date: Sun, 30 Jan 2011 19:26:24 -0800	[thread overview]
Message-ID: <AANLkTi=5Uik+EwBRfYs_Pa77+qHngY03ezC63RC0WLQ8@mail.gmail.com> (raw)
In-Reply-To: <1296403013-6058-1-git-send-email-thomas@wytron.com.tw>

Hi,

On Sun, Jan 30, 2011 at 7:56 AM, Thomas Chou <thomas@wytron.com.tw> wrote:
> From: Albert Herranz <albert_herranz@yahoo.es>
>
> This patch is based on an earlier patch from Albert Herranz,
> http://git.infradead.org/users/herraa1/gc-linux-2.6.git/commit/
> 9854eb78607c641ab5ae85bcbe3c9d14ac113733

That commit has a single-line description of which I don't understand
a single word (unless "wii" is what I think it is, which seems
likely). Could you please explain how that commit relates to this
patch?

> The dts binding is modified as Grant suggested. The of probing
> is merged inline instead of a separate file. It uses the newer
> of gpio probe.

It seems like a terrible idea to merge firmware-specific code into the
driver. Is there are reason why of-based platforms can't just pass the
data they need in pdata like everyone else?

Not saying that it necessarily _is_ a terrible idea, but I think the
reasoning behind it needs to be included in the patch description.

> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
> Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
> ---
>  Documentation/devicetree/bindings/gpio/i2c.txt |   39 ++++++++++++++
>  drivers/i2c/busses/i2c-gpio.c                  |   67 ++++++++++++++++++++++-
>  2 files changed, 103 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/gpio/i2c.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/i2c.txt b/Documentation/devicetree/bindings/gpio/i2c.txt
> new file mode 100644
> index 0000000..402569e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/i2c.txt

This looks a bit backwards. i2c-gpio is a i2c driver which happens to
utilize the gpio framework, not the other way around.

> @@ -0,0 +1,39 @@
> +GPIO-based I2C
> +
> +Required properties:
> +- compatible : should be "i2c-gpio".
> +- gpios : should specify GPIOs used for SDA and SCL lines, in that order.
> +Optional properties:
> +- sda-is-open-drain : present if SDA gpio is open-drain.
> +- scl-is-open-drain : present if SCL gpio is open-drain.
> +- scl-is-output-only : present if SCL is an output gpio only.

I think "present if the output driver for SCL cannot be turned off" is
more accurate. Might also be worth mentioning that this will prevent
clock stretching from working.

> --- a/drivers/i2c/busses/i2c-gpio.c
> +++ b/drivers/i2c/busses/i2c-gpio.c
> @@ -14,6 +14,9 @@
>  #include <linux/module.h>
>  #include <linux/slab.h>
>  #include <linux/platform_device.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_gpio.h>
> +#include <linux/of_i2c.h>

Do these headers provide stubs so non-of platforms won't break?

> @@ -83,11 +86,52 @@ static int __devinit i2c_gpio_probe(struct platform_device *pdev)
>        struct i2c_gpio_platform_data *pdata;
>        struct i2c_algo_bit_data *bit_data;
>        struct i2c_adapter *adap;
> +       struct device_node *np = pdev->dev.of_node;

Would be nice if this could be eliminated on non-of platforms.

>        int ret;
>
>        pdata = pdev->dev.platform_data;
> -       if (!pdata)
> -               return -ENXIO;
> +       if (!pdata) {
> +               if (np && of_gpio_count(np) >= 2) {

If that expression somehow always evaluates to false on non-of
platforms, this might be ok. But please confirm if this is the case;
otherwise, it looks like a pretty large addition to an otherwise very
small driver.

How about a tiny bit of restructuring: Move the block below into a
separate function, which is only called if some constant expression
says that of is enabled. Then you can move the declaration above
either into the if block or into the function, depending on where you
want to do the conditional above.

>  static struct platform_driver i2c_gpio_driver = {
>        .driver         = {
>                .name   = "i2c-gpio",
>                .owner  = THIS_MODULE,
> +               .of_match_table = i2c_gpio_match,

Is this field always present even when of is disabled?

Havard

  reply	other threads:[~2011-01-31  3:26 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-30 15:56 Thomas Chou
2011-01-31  3:26 ` Håvard Skinnemoen [this message]
2011-01-31  8:09   ` Grant Likely
2011-01-31 13:55     ` Jon Loeliger
2011-01-31 15:25     ` [PATCH 1/3] of: define dummy of_get_property if not CONFIG_OF Thomas Chou
2011-01-31 22:10       ` Grant Likely
2011-01-31 15:25     ` [PATCH 2/3] of: of_gpiochip_add is needed only for gpiolib Thomas Chou
2011-01-31 22:16       ` Grant Likely
2011-01-31 15:25     ` [PATCH 3/3 v2] i2c-gpio: add devicetree support Thomas Chou
2011-01-31 21:14       ` [3/3,v2] " Milton Miller
2011-01-31 21:29         ` Grant Likely
2011-02-03  2:26           ` [PATCH] " Thomas Chou
2011-02-03  4:24             ` Håvard Skinnemoen
2011-02-03 18:07             ` Grant Likely
2011-02-10  2:29               ` [PATCH v4] " Thomas Chou
2011-02-14  2:30                 ` [PATCH v5] " Thomas Chou
2011-02-16  5:49                   ` Grant Likely
2011-02-16  6:13                     ` Thomas Chou
2011-02-23  1:12                   ` Ben Dooks
2011-02-23 13:18                     ` Thomas Chou
2011-02-24  4:00                     ` [PATCH v6] " Thomas Chou
2011-02-24 16:22                       ` Grant Likely
2011-02-25  2:04                         ` Thomas Chou
2011-01-31 22:35     ` [PATCH] " Håvard Skinnemoen
2011-01-31 23:01       ` Grant Likely

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='AANLkTi=5Uik+EwBRfYs_Pa77+qHngY03ezC63RC0WLQ8@mail.gmail.com' \
    --to=hskinnemoen@gmail.com \
    --cc=albert_herranz@yahoo.es \
    --cc=ben-linux@fluff.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=khali@linux-fr.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nios2-dev@sopc.et.ntust.edu.tw \
    --cc=thomas@wytron.com.tw \
    --subject='Re: [PATCH] i2c-gpio: add devicetree support' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).