[Top][All Lists]

[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: Jean-Christophe DUBOIS
Subject: Re: [Qemu-devel] [PATCH v2 2/4] Add i.MX I2C controller driver.
Date: Sun, 05 May 2013 14:28:37 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5

On 05/05/2013 01:53 PM, Peter Crosthwaite wrote:
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


I will use extract32() for now.


-- PMM

reply via email to

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