On 12/01/2012 07:58 AM, Thierry Reding wrote:
On Sat, Dec 01, 2012 at 01:31:02PM +0200, Terje Bergström wrote:
...
I was thinking of definitions like this:
static inline u32 host1x_sync_cfpeek_ctrl_cfpeek_addr_f(u32 v) { return (v & 0x1ff) << 0; }
versus
#define host1x_sync_cfpeek_ctrl_cfpeek_addr_f(v) ((v) >> 16) & 0x3ff
Both of these produce the same machine code and have same usage, but the latter has type checking and code coverage analysis and the former is (in my eyes) clearer. In both of these cases the usage is like this:
writel(host1x_sync_cfpeek_ctrl_cfpeek_ena_f(1) | host1x_sync_cfpeek_ctrl_cfpeek_channr_f(chid) | host1x_sync_cfpeek_ctrl_cfpeek_addr_f(rd_ptr), m->sync_aperture + host1x_sync_cfpeek_ctrl_r());
Again there's no precedent for doing this with static inline functions. You can do the same with macros. Type checking isn't an issue in these cases since we're talking about bitfields for which no proper type exists.
I suspect the inline functions could encode signed-vs-unsigned fields, perhaps catch u8 variables when they should have been u32, etc.?