Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Oct 2017 20:00:32 +0300
From:      Andriy Gapon <avg@FreeBSD.org>
To:        Ian Lepore <ian@FreeBSD.org>, src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org
Subject:   Re: svn commit: r323465 - head/usr.sbin/i2c
Message-ID:  <736553e2-050b-a444-d52e-5526e03c0ae8@FreeBSD.org>
In-Reply-To: <1507653746.84167.40.camel@freebsd.org>
References:  <201709112149.v8BLncAs049328@repo.freebsd.org> <4c4a916f-9960-6d7f-3389-37b998ba980b@FreeBSD.org> <1507651963.84167.37.camel@freebsd.org> <f451de74-554c-6782-d954-4964683775db@FreeBSD.org> <1507653746.84167.40.camel@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 10/10/2017 19:42, Ian Lepore wrote:
> On Tue, 2017-10-10 at 19:20 +0300, Andriy Gapon wrote:
>> On 10/10/2017 19:12, Ian Lepore wrote:
>>>
>>> i2c -s is not a thing that's done routinely in a production system or
>>> normal system operations... it's something a person does manually when
>>> trying to configure or debug a system.  In that situation, there is
>>> more harm in being told there are no working devices on the bus when in
>>> fact everything is fine, than there is some some hypothetical device
>>> doing some hypothetical "bad thing" in response to a read command.  In
>>> all my years of working with i2c stuff I've never seen a device doing
>>> anything more harmful than hanging the bus, requiring a reset (and even
>>> causing that requires worse behavior than an unexpected read).  On the
>>> other hand, I've seen a lot of people frustrated that i2c -s on freebsd
>>> says there are no devices, while the equivelent command on linux shows
>>> that everything is fine.
>> Okay.
>>
>> However, I will just mention that in the past I used to own a system where
>> scanning the bus would make a slave that controlled CPU frequency to change it
>> to some garbage.  The system "just" crashed, but theoretically the damage could
>> have been worse.
>> Also, I own a system right now where scanning the bus results in something like
>> what you mentioned, but a little bit worse, the hanging bus that can be brought
>> back only by a power cycle (not even a warm reset).
>>
> 
> These systems didn't used to hang on i2c -s, and now they do?

Sorry, I failed to clarify that I talked about smbus and smbmsg -p.
I imagine that pure i2c slaves can be as fragile.

-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?736553e2-050b-a444-d52e-5526e03c0ae8>