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 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "[email protected]"
