linux-kernel - Re: [PATCH] i2c-omap: always send stop after nack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 16 Jul 2013 16:00:58 +0300
From:	Felipe Balbi <balbi@...com>
To:	Grygorii Strashko <grygorii.strashko@...com>
CC:	<balbi@...com>, Hein Tibosch <hein_tibosch@...oo.es>,
	Tony Lindgren <tony@...mide.com>,
	linux-i2c <linux-i2c@...r.kernel.org>,
	linux-omap <linux-omap@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] i2c-omap: always send stop after nack

Hi,

(when replying, can you add some blank lines around your reply and the
previous mail, it's quite difficult to find your replies with so many
quote marks (>) around)

On Tue, Jul 16, 2013 at 03:08:04PM +0300, Grygorii Strashko wrote:
> Hi Felipe,
> On 07/16/2013 02:27 PM, Felipe Balbi wrote:
> >Hi,
> >
> >On Tue, Jul 16, 2013 at 02:01:11PM +0300, Grygorii Strashko wrote:
> >>>>>>On a OMAP4460, i2c-bus-3:
> >>>>>>
> >>>>>>A driver (lm75) is causing many 'timeout waiting for bus ready' errors.
> >>>>>>SDA remains high (as it should), but SCL remains low after a NACK.
> >>>>>>The bus becomes _unusable for other clients_.
> >>>>>>
> >>>>>>While probing, "lm75" writes a command, followed by a read + stop,
> >>>>>>but the write command is NACK'd. The chip does accept other writes/reads,
> >>>>>>it just refuses to ack invalid commands.
> >>>>>>
> >>>>>>Can you tell me if the patch below would make any sense? Or is it the
> >>>>>>responsibility of the client to reset the i2c_smbus?
> >>>>>patch below breaks repeated start.
> >>Felipe, I'd very appreciate if you'd be able to provide the use case
> >>which will fail with such solution?
> >
> >can't you see how this would fail ?
> >
> >assume omap_i2c_xfer() is called with its last argument (num) being
> >greater than one and you get the NAK before the last transfer.
> That's our case - NACK from slave before last transfer

with one difference, your device requires a STP condition because it's
SMBus, right ? Not all devices act like that :-)

But now I noticed, because of your reply, something I have been
overlooking for quite some time. As you said below, in case of NAK we
break out of the loop and don't even try the following messages.

Which means your original patch starts to make a lot more sense. I
wonder is this is really what we should be doing though - breaking out
of the loop, I mean.

It'd be cool to get an answer from I2C maintainers if we're doing the
right thing here.

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)