On Wed, Mar 28, 2012 at 3:14 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> On Wed, 28 Mar 2012 02:36:17 +0800, Daniel Kurtz <djkurtz@xxxxxxxxxxxx> wrote:
>> A common method of probing an i2c bus is trying to do a zero-length write.
>> Handle this case by checking the length first before decrementing it.
>>
>> This is actually important, since attempting a zero-length write is one
>> of the ways that i2cdetect and i2c_new_probed_device detect whether
>> there is device present on the bus with a given address.
>>
>> Signed-off-by: Daniel Kurtz <djkurtz@xxxxxxxxxxxx>
>> ---
>> drivers/gpu/drm/i915/intel_i2c.c | 5 +++--
>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
>> index c12db72..5a94e9b 100644
>> --- a/drivers/gpu/drm/i915/intel_i2c.c
>> +++ b/drivers/gpu/drm/i915/intel_i2c.c
>> @@ -248,9 +248,10 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
>> u32 val, loop;
>>
>> val = loop = 0;
>> - do {
>> + while (len && loop < 4) {
> while (len-- && loop < 4)
>
>> val |= *buf++ << (8 * loop);
>> - } while (--len && ++loop < 4);
>> + len -= 1;
> Otherwise this looks too pythonesque ;-)
Unfortunately there is a bug in both my original patch (it wasn't
incrementing loop), and in your suggested cleanup (it always
decrements len, even when it is already 0... or if the loop test
fails). How about the following; despite its pythonic nature, it
always completes with len holding the number of bytes remaining.
val = loop = 0;
while (len && loop < 4) {
val |= *buf++ << (8 * loop++);
len -= 1;
}
>> + }
>
> --
> Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
