[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <eetu2jkcnaqvxyvto2vvslmducsecewtcnoktuxczjeaohqm3i@khc33hutl7ac>
Date: Tue, 29 Apr 2025 13:29:41 +0200
From: Andi Shyti <andi.shyti@...nel.org>
To: Akhil R <akhilrajeev@...dia.com>
Cc: Wolfram Sang <wsa+renesas@...g-engineering.com>,
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,
On Tue, Apr 29, 2025 at 09:51:14AM +0000, Akhil R wrote:
> > > 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.
I took it anyway into i2c/i2c-host. Better redundant than sorry.
Other drivers are doing the same check, so for now there is no
point in being picky.
I might try to clean things up later.
Thanks,
Andi
Powered by blists - more mailing lists