On 26. 02. 25, 19:33, Yury Norov wrote:
Not in cases where macros are inevitable. I mean, do we need parityXX() for
XX in (8, 16, 32, 64) at all? Isn't the parity() above enough for everybody?
The existing codebase has something like:
int ret;
ret = i3c_master_get_free_addr(m, last_addr + 1);
ret |= parity8(ret) ? 0 : BIT(7)
So if we'll switch it to a macro like one above, it will become a
32-bit parity. It wouldn't be an error because i3c_master_get_free_addr()
returns an u8 or -ENOMEM, and the error code is checked explicitly.
But if we decide to go with parity() only, some users will have to
call it like parity((u8)val) explicitly. Which is not bad actually.
That cast looks ugly -- we apparently need parityXX(). (In this
particular case we could do parity8(last_addr), but I assume there are
more cases like this.) Thanks for looking up the case for this.
And if not, you can have all those parityXX() as inlines as you suggest, but
also provide a macro such as the above to call (optimized) parityXX() as per
datatype len.
Yes, if we need fixed-type parity's, they should all be one-liners
calling the same macro. Macros or inline functions - no preference for
me.
--
js
suse labs
