From owner-svn-src-all@freebsd.org Tue Oct 10 16:21:24 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 BF332E36684; Tue, 10 Oct 2017 16:21:24 +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 74F0038E1; Tue, 10 Oct 2017 16:21:22 +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 TAA02726; Tue, 10 Oct 2017 19:21:21 +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 1e1xHU-0001ia-V5; Tue, 10 Oct 2017 19:21:20 +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> From: Andriy Gapon Message-ID: Date: Tue, 10 Oct 2017 19:20:25 +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: <1507651963.84167.37.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 16:21:24 -0000 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). -- Andriy Gapon