[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<PH7PR12MB8178A35A3D51F6BE3D1E6888C0802@PH7PR12MB8178.namprd12.prod.outlook.com>
Date: Tue, 29 Apr 2025 09:51:14 +0000
From: Akhil R <akhilrajeev@...dia.com>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>
CC: Andi Shyti <andi.shyti@...nel.org>, Laxman Dewangan
<ldewangan@...dia.com>, "digetx@...il.com" <digetx@...il.com>,
"thierry.reding@...il.com" <thierry.reding@...il.com>, Jon Hunter
<jonathanh@...dia.com>, "wsa@...nel.org" <wsa@...nel.org>,
"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Thierry Reding
<treding@...dia.com>
Subject: RE: [PATCH v2 RESEND] i2c: tegra: check msg length in SMBUS block
read
> Hi Akhil,
>
> > Yes. We have had issues where the client device sends '0' as length if
> > the
>
> Can you reveal which client that is?
The issue came from a downstream change in the file
drivers/char/ipmi/ssif_bmc.c in the OpenBMC Linux tree.
>
> > transfer is terminated abruptly at the client's side. The actual fix
> > is in the client's driver, but this check here would ensure that the
> > master does not run into trouble either.
>
> Correct.
>
> Happy hacking!
Regards,
Akhil
Powered by blists - more mailing lists