On Thu, Feb 27, 2025 at 07:38:58AM +0100, Jiri Slaby wrote:
On 26. 02. 25, 19:33, Yury Norov wrote:
quoted
quoted
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.
This parity8() is used in just 2 drivers - i3c and hwmon/spd5118. The hwmon
driver looks good. I3C, yeah, makes this implied typecast, which is nasty
regardless.
This is the new code, and I think if we all agree that generic parity()
would be a better API, it's a good time to convert existing users now.
Thanks,
Yury