All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] What about i2c_smbus_read_block_data() ?
Date: Sun, 08 Apr 2007 08:58:40 +0000	[thread overview]
Message-ID: <20070408105840.53188b16.khali@linux-fr.org> (raw)
In-Reply-To: <200704042149.21264.hjk@linutronix.de>

[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]

Hi Mark, Hans-Jürgen,

On Wed, 4 Apr 2007 22:42:18 -0400, Mark M. Hoffman wrote:
> * Hans-Jürgen Koch <hjk@linutronix.de> [2007-04-04 23:32:34 +0200]:
> > Am Mittwoch, 4. April 2007 21:49 schrieb Hans-Jürgen Koch:
> > > I'm working on a driver for LM93. I've got some code by Mark Hoffman, (c)2004. 
> > > It doesn't compile on a recent kernel, because it heavily uses a function called
> > > i2c_smbus_read_block_data(). Googling for that, I found this old mail in the
> > > archives (October 2005):
> > > 
> > > http://lists.lm-sensors.org/pipermail/lm-sensors/2005-October/013971.html
> > > 
> > > Jean, what do you say to that today? Can we have that function back in
> > > mainline, or do I have to find another solution?
> > > If you agree to add it, I could prepare a patch for it, if you don't have
> > > a recent version handy.
> > 
> > Answering my own question: After looking at i2c-core.c et al., I find it quite
> > obvious that this function should be added, if a driver needs it. 

True.

> > I attached a patch that does this. Would that be acceptable? I can resend it
> > when I have the LM93 patch ready.
> 
> I think if you put it in the same patchset with lm93.c, that will be fine.

I have a different variant of this patch in my local tree, which takes
the i2c-core changes that happened in the meantime into account. I'm
attaching it to this post if someone want to take a look and/or
comment. In fact I think I'll schedule this patch for merge into 2.6.22
regardless of the state of the lm93 driver patch. I'm a bit tired to
have to maintain that patch off-tree and to see people waste their time
wondering where that function has gone, searching the mailing list for
explanations, finding the patch and resubmitting it. We all have better
things to do.

Anyway, the key point for Hans-Jürgen is: you can assume that function
i2c_smbus_read_block_data() will be available to you when your lm93
driver patch is merged upstream.

> Jean: I can do the initial review of this one for you when it's ready.

Great, thanks!

-- 
Jean Delvare

[-- Attachment #2: i2c-add-smbus-block-read.patch --]
[-- Type: text/plain, Size: 1914 bytes --]

Subject: i2c: Restore i2c_smbus_read_block_data

Add back the i2c_smbus_read_block_data function, it is needed by the
upcoming lm93 driver.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
---
 drivers/i2c/i2c-core.c |   16 ++++++++++++++++
 include/linux/i2c.h    |    3 +++
 2 files changed, 19 insertions(+)

--- linux-2.6.21-rc6.orig/drivers/i2c/i2c-core.c	2007-04-08 10:23:22.000000000 +0200
+++ linux-2.6.21-rc6/drivers/i2c/i2c-core.c	2007-04-08 10:48:48.000000000 +0200
@@ -1300,6 +1300,22 @@ s32 i2c_smbus_write_word_data(struct i2c
 }
 EXPORT_SYMBOL(i2c_smbus_write_word_data);
 
+/* Returns the number of read bytes */
+s32 i2c_smbus_read_block_data(struct i2c_client *client, u8 command,
+			      u8 *values)
+{
+	union i2c_smbus_data data;
+
+	if (i2c_smbus_xfer(client->adapter, client->addr, client->flags,
+	                   I2C_SMBUS_READ, command,
+	                   I2C_SMBUS_BLOCK_DATA, &data))
+		return -1;
+
+	memcpy(values, &data.block[1], data.block[0]);
+	return data.block[0];
+}
+EXPORT_SYMBOL(i2c_smbus_read_block_data);
+
 s32 i2c_smbus_write_block_data(struct i2c_client *client, u8 command,
 			       u8 length, const u8 *values)
 {
--- linux-2.6.21-rc6.orig/include/linux/i2c.h	2007-04-08 10:23:22.000000000 +0200
+++ linux-2.6.21-rc6/include/linux/i2c.h	2007-04-08 10:33:45.000000000 +0200
@@ -82,6 +82,9 @@ extern s32 i2c_smbus_write_byte_data(str
 extern s32 i2c_smbus_read_word_data(struct i2c_client * client, u8 command);
 extern s32 i2c_smbus_write_word_data(struct i2c_client * client,
                                      u8 command, u16 value);
+/* Returns the number of read bytes */
+extern s32 i2c_smbus_read_block_data(struct i2c_client *client,
+				     u8 command, u8 *values);
 extern s32 i2c_smbus_write_block_data(struct i2c_client * client,
 				      u8 command, u8 length,
 				      const u8 *values);

[-- Attachment #3: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

  parent reply	other threads:[~2007-04-08  8:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-04 19:49 [lm-sensors] What about i2c_smbus_read_block_data() ? Hans-Jürgen Koch
2007-04-04 21:32 ` Hans-Jürgen Koch
2007-04-05  2:42 ` Mark M. Hoffman
2007-04-08  8:58 ` Jean Delvare [this message]
2007-04-08  9:26 ` Hans-Jürgen Koch

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=20070408105840.53188b16.khali@linux-fr.org \
    --to=khali@linux-fr.org \
    --cc=lm-sensors@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.