On Oct 29, 2008, at 4:58 AM, Jochen Kunz wrote:
Probing is a bad idea. I remember back in the NetBSD 1.3 to 1.4 days, when booting NetBSD on a VAXstation 4000/90 caused permanent damage to the hardware: A probe routine for a device, that can't exist on a VAXstation 4000/90, accidently issued the right sequence of read /write commands to overwrite part of the FLASH boot ROM. Fortunately themachine was still functional with the damaged FALSH ROM. But it complained at every POST about a PROM checksum mismatch and disabledauto-boot. It took years until someone dug out a FLASH ROM update image out of the reminders of DEC, as reflashing the firmware was the only wayto repair the damage. If the firmware _knows_ where devices are located, by all means, usethis information instead fscking the hardware and _guess_ the existenceof devices.
For stuff like I2C chips, I agree 100%. Speaking as an embedded systems designer who uses I2C all the time, I can tell you that probing for stuff like this is a VERY bad idea. These are not video cards and network interfaces on a user-accessible bus; they are chips on a board integrated into a subsystem. We KNOW what is where if we have proper documentation for the system; their presence or absence isn't optional or user-configurable. Poking around for hardware at this level is reckless and dangerous.
Michael wrote:
Well, some (many?) i2c devices, especially temperature monitors, have chip ID registers these days, many even in standardized places. So all it takes are a couple reads.
Actually, almost none have ID registers; they are quite rare. We're just lucky that the designers of systems we're currently working with have used some that have such registers, this time.
Also, most i2c chips have hardwired addresses ( some can switch between two or four different ones by wiring some pins to ground or not ) so no i2c driver would have to probe all over the place. To screw things up you'd need to have a screwy chip that's allergic to register reads at an address where your driver expects its own.
This is the only saving grace here.
No i2c chip I know of would do anything funny when you try to read its ID registers, even if it doesn't have any. They'd either return bogus or nothing but that's it.
Perhaps the ones you/we have experience with so far, sure, but this behavior is not guaranteed by the I2C standard. I2C (and SPI, etc) chips tend to be very dumb, with a simple shift register and some latches implementing the I2C interface. An I2C-addressed I/O port (frequently referred to as an "I/O expander") could certainly generate read strobe pulses when registers are read.
-Dave
--
Dave McGuire
Port Charlotte, FL