* [lm-sensors] What about i2c_smbus_read_block_data() ?
@ 2007-04-04 19:49 Hans-Jürgen Koch
2007-04-04 21:32 ` Hans-Jürgen Koch
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: Hans-Jürgen Koch @ 2007-04-04 19:49 UTC (permalink / raw)
To: lm-sensors
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.
Thanks,
Hans
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [lm-sensors] What about i2c_smbus_read_block_data() ?
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
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Hans-Jürgen Koch @ 2007-04-04 21:32 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1: Type: text/plain, Size: 932 bytes --]
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.
I attached a patch that does this. Would that be acceptable? I can resend it
when I have the LM93 patch ready.
Thanks,
Hans
[-- Attachment #2: add-i2c_smbus_read_block_data.patch --]
[-- Type: text/x-diff, Size: 1921 bytes --]
Index: linux-2.6.21-rc/drivers/i2c/i2c-core.c
===================================================================
--- linux-2.6.21-rc.orig/drivers/i2c/i2c-core.c 2007-04-04 22:40:55.000000000 +0200
+++ linux-2.6.21-rc/drivers/i2c/i2c-core.c 2007-04-04 23:01:40.000000000 +0200
@@ -994,6 +994,22 @@
I2C_SMBUS_WORD_DATA,&data);
}
+s32 i2c_smbus_read_block_data(struct i2c_client *client, u8 command,
+ u8 *values)
+{
+ union i2c_smbus_data data;
+ int i;
+ if (i2c_smbus_xfer(client->adapter, client->addr, client->flags,
+ I2C_SMBUS_READ, command,
+ I2C_SMBUS_BLOCK_DATA, &data))
+ return -1;
+ else {
+ for (i = 1; i <= data.block[0]; i++)
+ values[i-1] = data.block[i];
+ return data.block[0];
+ }
+}
+
s32 i2c_smbus_write_block_data(struct i2c_client *client, u8 command,
u8 length, const u8 *values)
{
@@ -1238,6 +1254,7 @@
EXPORT_SYMBOL(i2c_smbus_write_byte_data);
EXPORT_SYMBOL(i2c_smbus_read_word_data);
EXPORT_SYMBOL(i2c_smbus_write_word_data);
+EXPORT_SYMBOL(i2c_smbus_read_block_data);
EXPORT_SYMBOL(i2c_smbus_write_block_data);
EXPORT_SYMBOL(i2c_smbus_read_i2c_block_data);
EXPORT_SYMBOL(i2c_smbus_write_i2c_block_data);
Index: linux-2.6.21-rc/include/linux/i2c.h
===================================================================
--- linux-2.6.21-rc.orig/include/linux/i2c.h 2007-04-04 22:46:15.000000000 +0200
+++ linux-2.6.21-rc/include/linux/i2c.h 2007-04-04 22:47:19.000000000 +0200
@@ -87,6 +87,8 @@
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);
+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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [lm-sensors] What about i2c_smbus_read_block_data() ?
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
2007-04-08 9:26 ` Hans-Jürgen Koch
3 siblings, 0 replies; 5+ messages in thread
From: Mark M. Hoffman @ 2007-04-05 2:42 UTC (permalink / raw)
To: lm-sensors
Hello:
* 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.
>
> 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.
Jean: I can do the initial review of this one for you when it's ready.
Regards,
--
Mark M. Hoffman
mhoffman@lightlink.com
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [lm-sensors] What about i2c_smbus_read_block_data() ?
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
2007-04-08 9:26 ` Hans-Jürgen Koch
3 siblings, 0 replies; 5+ messages in thread
From: Jean Delvare @ 2007-04-08 8:58 UTC (permalink / raw)
To: lm-sensors
[-- 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [lm-sensors] What about i2c_smbus_read_block_data() ?
2007-04-04 19:49 [lm-sensors] What about i2c_smbus_read_block_data() ? Hans-Jürgen Koch
` (2 preceding siblings ...)
2007-04-08 8:58 ` Jean Delvare
@ 2007-04-08 9:26 ` Hans-Jürgen Koch
3 siblings, 0 replies; 5+ messages in thread
From: Hans-Jürgen Koch @ 2007-04-08 9:26 UTC (permalink / raw)
To: lm-sensors
Am Sonntag 08 April 2007 10:58 schrieb Jean Delvare:
>
> 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.
Looks allright to me.
> In fact I think I'll schedule this patch for merge into 2.6.22
> regardless of the state of the lm93 driver patch.
Good idea. I will submit a first version of the LM93 patch next Thursday
or Friday. It's ready, but I cannot test it until then.
> 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.
I second that.
>
> 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.
Fine.
Thanks,
Hans
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-04-08 9:26 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2007-04-08 9:26 ` Hans-Jürgen Koch
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.