qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] i2c: Fix SMBus read transactions to avoid do


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v2] i2c: Fix SMBus read transactions to avoid double events
Date: Mon, 24 Oct 2016 15:14:35 +0100

On 23 October 2016 at 22:38, Corey Minyard <address@hidden> wrote:
> On 10/22/2016 04:20 AM, Peter Maydell wrote:
>>>>
>>>> I got here because Coverity complains that the
>>>> i2c_start_transfer() calls in smbus.c don't check their
>>>> return value. That suggests to me that we'd be better off
>>>> having a different function (i2c_restart_transfer() ??)
>>>> for the "I know we already did this once, so don't try to
>>>> re-determine who to send this to" case, rather than trying to
>>>> handle both cases in the same function.
>>>
>>>
>>> Perhaps so.  Or maybe i2c_continue_transfer().  That would
>>> be more clear.  The second operation can't fail, but relying
>>> on that is frail.
>>
>> i2c_continue_transfer() sounds like a better name, yes.
>> Would you like to write a patch that takes that approach?
>> If you cc me I'll review it and put it through the
>> target-arm tree.
>
>
> I was working on this and looking at old information, and realized that
> this won't work.  The same problem exists in I2C devices when
> doing SMBus emulation, the device driver in the OS will cause a
> i2c_start_transfer() to be done twice without an intervening
> i2c_end_transfer().  Though a continue function would fix the smbus
> case, it won't fix the i2c case.
>
> I can't think of a better way to do it than I have done.

OK, thanks for looking into this. I'll apply this patch to
target-arm.next, and we can think about something else for
the coverity issue. (Perhaps just assert() that i2c_start_transfer()
returns success? The bus contents shouldn't be able to change
I think...)

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]