linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] i2c-stub: Allow increasing the SMBus block write length
@ 2014-07-13  7:23 Jean Delvare
       [not found] ` <20140713092331.67d4f5b3-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
  0 siblings, 1 reply; 2+ messages in thread
From: Jean Delvare @ 2014-07-13  7:23 UTC (permalink / raw)
  To: Linux I2C; +Cc: Wolfram Sang, Guenter Roeck

This is no good reason to not allow SMBus block writes longer than the
first one was. Lift this limitation, this makes the code more simple.

Signed-off-by: Jean Delvare <jdelvare-l3A5Bk7waGM@public.gmane.org>
Reviewed-by: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
---
Changes since v1:
* Sent in a separate thread
* Added Guenter's Reviewed-by
* Fixed subject

 Documentation/i2c/i2c-stub |    5 ++---
 drivers/i2c/i2c-stub.c     |   12 +++---------
 2 files changed, 5 insertions(+), 12 deletions(-)

--- linux-3.16-rc4.orig/Documentation/i2c/i2c-stub	2014-07-12 09:41:26.508195718 +0200
+++ linux-3.16-rc4/Documentation/i2c/i2c-stub	2014-07-12 10:40:05.064578130 +0200
@@ -20,9 +20,8 @@ operations.  This allows for continuous
 EEPROMs, among others.
 
 SMBus block commands must be written to configure an SMBus command for
-SMBus block operations. The first SMBus block write selects the block length.
-Subsequent writes can be partial. Block read commands always return
-the number of bytes selected with the first write.
+SMBus block operations. Writes can be partial. Block read commands always
+return the number of bytes selected with the largest write so far.
 
 The typical use-case is like this:
 	1. load this module
--- linux-3.16-rc4.orig/drivers/i2c/i2c-stub.c	2014-07-12 09:41:26.508195718 +0200
+++ linux-3.16-rc4/drivers/i2c/i2c-stub.c	2014-07-12 11:19:40.908827183 +0200
@@ -254,13 +254,6 @@ static s32 stub_xfer(struct i2c_adapter
 				ret = -EINVAL;
 				break;
 			}
-			if (b && len > b->len) {
-				dev_dbg(&adap->dev,
-					"Attempt to write more data (%d) than with initial SMBus block write (%d)\n",
-					len, b->len);
-				ret = -EINVAL;
-				break;
-			}
 			if (b == NULL) {
 				b = stub_find_block(&adap->dev, chip, command,
 						    true);
@@ -268,9 +261,10 @@ static s32 stub_xfer(struct i2c_adapter
 					ret = -ENOMEM;
 					break;
 				}
-				/* First write sets block length */
-				b->len = len;
 			}
+			/* Largest write sets read block length */
+			if (len > b->len)
+				b->len = len;
 			for (i = 0; i < len; i++)
 				b->block[i] = data->block[i + 1];
 			/* update for byte and word commands */


-- 
Jean Delvare
SUSE L3 Support

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH v2] i2c-stub: Allow increasing the SMBus block write length
       [not found] ` <20140713092331.67d4f5b3-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
@ 2014-07-13 15:09   ` Guenter Roeck
  0 siblings, 0 replies; 2+ messages in thread
From: Guenter Roeck @ 2014-07-13 15:09 UTC (permalink / raw)
  To: Jean Delvare, Linux I2C; +Cc: Wolfram Sang

On 07/13/2014 12:23 AM, Jean Delvare wrote:
> This is no good reason to not allow SMBus block writes longer than the
> first one was. Lift this limitation, this makes the code more simple.
>
> Signed-off-by: Jean Delvare <jdelvare-l3A5Bk7waGM@public.gmane.org>
> Reviewed-by: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>

Applied to my system and working, so you can also add

Tested-by: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>

Guenter

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-07-13 15:09 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-07-13  7:23 [PATCH v2] i2c-stub: Allow increasing the SMBus block write length Jean Delvare
     [not found] ` <20140713092331.67d4f5b3-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2014-07-13 15:09   ` Guenter Roeck

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).