All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@cam.ac.uk>
To: Bryan Freed <bfreed@chromium.org>
Cc: linux-kernel@vger.kernel.org, jbrenner@taosinc.com,
	gregkh@suse.de, arnd@arndb.de,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	Jean Delvare <khali@linux-fr.org>,
	Amit Kucheria <amit.kucheria@verdurent.com>
Subject: Re: [PATCH 1/3] light sensor: Add SMBUS support to the tsl2563 driver.
Date: Wed, 22 Jun 2011 10:05:44 +0100	[thread overview]
Message-ID: <4E01B068.3090102@cam.ac.uk> (raw)
In-Reply-To: <1308696897-25161-1-git-send-email-bfreed@chromium.org>

On 06/21/11 23:54, Bryan Freed wrote:
> This is so we can support it on x86 SMBUS adapters.
Hi Brian,

Please cc linux-iio@vger.kernel.org for iio patches.  Also this driver has fairly
clear authorship at the top, so more for your cc list. (added)
> 
> Signed-off-by: Bryan Freed <bfreed@chromium.org>
> ---
>  drivers/staging/iio/light/tsl2563.c |   29 ++++++++++++++++++++++++++++-
>  1 files changed, 28 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/staging/iio/light/tsl2563.c b/drivers/staging/iio/light/tsl2563.c
> index 9cffa2e..04aa155 100644
> --- a/drivers/staging/iio/light/tsl2563.c
> +++ b/drivers/staging/iio/light/tsl2563.c
> @@ -137,6 +137,8 @@ struct tsl2563_chip {
>  	u32			data1;
>  };
>  
> +static int use_smbus;
> +
>  static int tsl2563_write(struct i2c_client *client, u8 reg, u8 value)
>  {
>  	int ret;
> @@ -145,15 +147,35 @@ static int tsl2563_write(struct i2c_client *client, u8 reg, u8 value)
>  	buf[0] = TSL2563_CMD | reg;
>  	buf[1] = value;
>  
> +	if (use_smbus) {
> +		ret = i2c_smbus_write_byte_data(client, buf[0], value);
> +		return ret;
> +	}
> +
Here I'd prefer to see this in an else block to make the program flow clear. Same with the others.
Actually, is there any reason we can't use the smbus_write_byte_data for all cases?  I 'think'
it's emulated via i2c if that is available and smbus is not? (cc'd Jean to confirm this - though
a quick code browse of i2c-core.c looks promising.)

If smbus_xfer is not supplied by the adapter, i2c_smbus_xfer_emulated is called. 

The only possible issue I can think of is that a device supports full i2c + a partial smbus
support. (rather odd!)
>  	ret = i2c_master_send(client, buf, sizeof(buf));
>  	return (ret == sizeof(buf)) ? 0 : ret;
>  }
>  
> -static int tsl2563_read(struct i2c_client *client, u8 reg, void *buf, int len)
> +static int tsl2563_read(struct i2c_client *client, u8 reg, u8 *buf, int len)
>  {
>  	int ret;
>  	u8 cmd = TSL2563_CMD | reg;
>  
> +	if (use_smbus) {
> +		if (len == 1) {
> +			ret = i2c_smbus_read_byte_data(client, cmd);
> +			buf[0] = ret & 0xff;
> +		} else if (len == 2) {
> +			ret = i2c_smbus_read_word_data(client, cmd);
> +			buf[0] = ret & 0xff;
> +			buf[1] = (ret >> 8) & 0xff;
> +		} else
> +			ret = -1;
If we hit this something has gone hideously wrong.  Hence please
audit the driver to be sure this doesn't happen and don't bother
with this extra option.
> +		if (ret < 0)
> +			return 0; /* failure */
Please return the error, not 0 in event of failure.
> +		return len; /* success */
> +	}
> +
>  	ret = i2c_master_send(client, &cmd, sizeof(cmd));
>  	if (ret != sizeof(cmd))
>  		return ret;
> @@ -712,6 +734,11 @@ static int __devinit tsl2563_probe(struct i2c_client *client,
>  	int err = 0;
>  	int ret;
>  	u8 id;
> +	u32 smbus_func = I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA;
Can this be const?  Oddly, the answer looks to be no.  Given its an inline
in i2c.h, can't see why this one isn't const.  Jean, am I missing something
or wouldn't:
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index a6c652e..be5515d 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -458,7 +458,7 @@ static inline u32 i2c_get_functionality(struct i2c_adapter *adap)
 }
 
 /* Return 1 if adapter supports everything we need, 0 if not. */
-static inline int i2c_check_functionality(struct i2c_adapter *adap, u32 func)
+static inline int i2c_check_functionality(struct i2c_adapter *adap, const u32 func)
 {
        return (func & i2c_get_functionality(adap)) == func;
 }

Be a sensible change?  For that matter, this code should probably just have that
value inline in the function call as it isn't used anywhere else.

> +	/* We support both I2C and SMBUS adapter interfaces. */
> +	if (i2c_check_functionality(client->adapter, smbus_func))
> +		use_smbus = 1;
>  
>  	indio_dev = iio_allocate_device(sizeof(*chip));
>  	if (!indio_dev)


  parent reply	other threads:[~2011-06-22  8:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-21 22:54 [PATCH 1/3] light sensor: Add SMBUS support to the tsl2563 driver Bryan Freed
2011-06-21 22:54 ` [PATCH 2/3] light sensor: Fix a panic in " Bryan Freed
2011-06-22  9:07   ` Jonathan Cameron
2011-06-21 22:54 ` [PATCH 3/3] " Bryan Freed
2011-06-22  9:09   ` Jonathan Cameron
2011-06-22  9:05 ` Jonathan Cameron [this message]
2011-06-22 14:10   ` [PATCH 1/3] light sensor: Add SMBUS support to " Jean Delvare
2011-06-22 15:53     ` Jonathan Cameron
2011-06-22 16:16       ` Jean Delvare

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=4E01B068.3090102@cam.ac.uk \
    --to=jic23@cam.ac.uk \
    --cc=amit.kucheria@verdurent.com \
    --cc=arnd@arndb.de \
    --cc=bfreed@chromium.org \
    --cc=gregkh@suse.de \
    --cc=jbrenner@taosinc.com \
    --cc=khali@linux-fr.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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.