LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Thomas Chou <thomas@wytron.com.tw>
To: Ben Dooks <ben-i2c@fluff.org>
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,
	Albert Herranz <albert_herranz@yahoo.es>
Subject: Re: [PATCH v5] i2c-gpio: add devicetree support
Date: Wed, 23 Feb 2011 21:18:15 +0800	[thread overview]
Message-ID: <4D650917.8000201@wytron.com.tw> (raw)
In-Reply-To: <20110223011232.GC15795@trinity.fluff.org>

Hi Ben,

On 02/23/2011 09:12 AM, Ben Dooks wrote:
> On Mon, Feb 14, 2011 at 10:30:10AM +0800, Thomas Chou wrote:
>> From: Albert Herranz<albert_herranz@yahoo.es>
>>
>> This patch adds devicetree support to i2c-gpio driver. The allocation
>> of local data is integrated to a private structure, and use devm_*
>> helper for easy cleanup.
>>
>> It is base on an earlier patch for gc-linux from
>> Albert Herranz<albert_herranz@yahoo.es>.
>>
>> Signed-off-by: Thomas Chou<thomas@wytron.com.tw>
>> CC: Albert Herranz<albert_herranz@yahoo.es>
>> Acked-by: Haavard Skinnemoen<hskinnemoen@gmail.com>
>> ---
>> for v2.6.39
>> v2 move of nodes probing to a hook, which will be optimized out
>>       when devicetree is not used.
>>     use linux/gpio.h.
>>     move binding doc to i2c/i2c-gpio.txt.
>> v3 use speed-hz instead of udelay in dts binding.
>>     condition the devicetree probe.
>> v4 simplify private allocation.
>> v5 condition module device table export for of.
>>

>> +/* Check if devicetree nodes exist and build platform data */
>> +static int i2c_gpio_of_probe(struct platform_device *pdev,
>> +			     struct i2c_gpio_platform_data *pdata)
>> +{
>> +	struct device_node *np = pdev->dev.of_node;
>> +	const __be32 *prop;
>> +	int sda_pin, scl_pin;
>> +	int len;
>> +
>> +	if (!np || of_gpio_count(np)<  2)
>> +		return -ENXIO;
>
> Would prefer to see different return code, most bus probe functions
> tend to drop these without signalling to the user as they assume the
> device was either never there or totally faulty.
>
>> +	sda_pin = of_get_gpio_flags(np, 0, NULL);
>> +	scl_pin = of_get_gpio_flags(np, 1, NULL);
>> +	if (sda_pin<  0 || scl_pin<  0) {
>> +		pr_err("%s: invalid GPIO pins, sda=%d/scl=%d\n",
>> +		       np->full_name, sda_pin, scl_pin);
>> +		return -ENXIO;
>> +	}
>
> see same as above.
>
>> +	pdata->sda_pin = sda_pin;
>> +	pdata->scl_pin = scl_pin;
>> +	prop = of_get_property(np, "sda-is-open-drain", NULL);
>> +	if (prop)
>> +		pdata->sda_is_open_drain = 1;
>> +	prop = of_get_property(np, "scl-is-open-drain", NULL);
>> +	if (prop)
>> +		pdata->scl_is_open_drain = 1;
>> +	prop = of_get_property(np, "scl-is-output-only", NULL);
>> +	if (prop)
>> +		pdata->scl_is_output_only = 1;
>> +	prop = of_get_property(np, "speed-hz",&len);
>> +	if (prop&&  len>= sizeof(__be32))
>> +		pdata->udelay = DIV_ROUND_UP(1000000, be32_to_cpup(prop) * 2);
>> +	prop = of_get_property(np, "timeout",&len);
>> +	if (prop&&  len>= sizeof(__be32))
>> +		pdata->timeout = msecs_to_jiffies(be32_to_cpup(prop));
>> +
>> +	return 0;
>> +}
>> +#else
>> +static int i2c_gpio_of_probe(struct platform_device *pdev,
>> +			     struct i2c_gpio_platform_data *pdata)
>> +{
>> +	return -ENXIO;
>> +}
>
> might be valid here, however can we make this NULL if no support?
>

Thanks. How about return NULL if no support, and return pdata if support?

- Thomas

  reply	other threads:[~2011-02-23 13:18 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-30 15:56 [PATCH] " Thomas Chou
2011-01-31  3:26 ` Håvard Skinnemoen
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 [this message]
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=4D650917.8000201@wytron.com.tw \
    --to=thomas@wytron.com.tw \
    --cc=albert_herranz@yahoo.es \
    --cc=ben-i2c@fluff.org \
    --cc=ben-linux@fluff.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nios2-dev@sopc.et.ntust.edu.tw \
    --subject='Re: [PATCH v5] 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).