qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 2/4] Add i.MX I2C controller driver.


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH v2 2/4] Add i.MX I2C controller driver.
Date: Sun, 5 May 2013 21:53:17 +1000

Hi Peter,

On Sun, May 5, 2013 at 9:41 PM, Peter Maydell <address@hidden> wrote:
> On 5 May 2013 11:53, Peter Crosthwaite <address@hidden> wrote:
>> On Sun, May 5, 2013 at 8:47 PM, Peter Maydell <address@hidden> wrote:
>>> On 5 May 2013 04:58, Jean-Christophe DUBOIS <address@hidden> wrote:
>>>> no extract16() macro spotted.
>>>> Should one be added?
>>>
>>> There's no need for one -- just use extract32. The only
>>> reason for having a separate extract64 is to avoid doing
>>> 64 bit arithmetic when we don't have to, I think.
>>>
>>
>> perhaps a quick:
>>
>> #define extract16(a, b, c) (uint16_t)extract32((uint16_t)(a), (b), (c))
>>
>> would keep the 16bit device code explicit and clean? Save on
>> dummy casts in certain situations as well (but not this one).
>
> Hmm, what situations would ever require a cast of the result
> or the input of extract32?
>

The one off the top of my head:

fprintf(stderr, "your 16 field is :%" PRIx16 "\n", extract16(foo, bar, baz));

Otherwise you would have to match PRIx32 to extract 16 which is clumsy.

But aren't there there some other varargs situations that may require
casts as well?

As for the input cast, I got nothin, I just put it in there for
completeness. Meet you half way and drop the input cast and keep the
output?

Regards,
Peter

> -- PMM
>



reply via email to

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