From owner-svn-src-all@freebsd.org Tue Oct 10 17:01:56 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 876BFE378B0; Tue, 10 Oct 2017 17:01:56 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 385F06431C; Tue, 10 Oct 2017 17:01:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA02806; Tue, 10 Oct 2017 20:01:53 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1e1xuj-0001kH-7d; Tue, 10 Oct 2017 20:01:53 +0300 Subject: Re: svn commit: r323465 - head/usr.sbin/i2c To: Ian Lepore , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org References: <201709112149.v8BLncAs049328@repo.freebsd.org> <4c4a916f-9960-6d7f-3389-37b998ba980b@FreeBSD.org> <1507651963.84167.37.camel@freebsd.org> <1507653746.84167.40.camel@freebsd.org> From: Andriy Gapon Message-ID: <736553e2-050b-a444-d52e-5526e03c0ae8@FreeBSD.org> Date: Tue, 10 Oct 2017 20:00:32 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1507653746.84167.40.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 17:01:56 -0000 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