Hello Ahmad, Thanks for maintenance of the Barebox EFI. On Wed, Aug 14, 2024 at 11:24:23AM +0200, Ahmad Fatoum wrote: > I2C message length is 16 bit, so doing a 64-bit division is overkill. > Let's remove the cast and just rely on the usual integer promotion > to 32-bit. > > Cc: Tomas Marek <tomas.marek@xxxxxxxxx> > Signed-off-by: Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> > --- > drivers/i2c/busses/i2c-efi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/i2c/busses/i2c-efi.c b/drivers/i2c/busses/i2c-efi.c > index 5f6cc0eed28e..a666a28fab51 100644 > --- a/drivers/i2c/busses/i2c-efi.c > +++ b/drivers/i2c/busses/i2c-efi.c > @@ -114,7 +114,7 @@ static unsigned int efi_i2c_msg_op_cnt(const struct efi_i2c_priv *i2c_priv, > > max_len = efi_i2c_max_len(i2c_priv, msg); > > - return ((u64)msg->len + max_len - 1) / max_len; > + return (msg->len + max_len - 1) / max_len; The issue here is that max_len, which represents the MaximumReceiveBytes or MaximumTransmitBytes in EFI I2C capabilities, is 32-bit. In some EFI implementations (including the one I use), the EFI I2C MaximumReceiveBytes and MaximumTransmitBytes are set to the maximum value (0xFFFFFFFF). This causes msg->len + max_len - 1 to overflow, leading to an incorrect number of returned operations. To address this, the msg->len is extended to 64 bits. Best regards Tomas > } > > static unsigned int efi_i2c_req_op_cnt( > -- > 2.39.2 >
