Jon Smirl wrote: > On Fri, Apr 24, 2009 at 6:53 AM, Michael Lawnick <ml.lawnick@xxxxxx> wrote: >> Wolfram Sang said the following: >> ... >>>> Allowing only clients that are mentioned in DTS? >>> For now, yes. This is still the common case (=avoid probing). Until a >>> mainline solution comes up (which is needed, I agree on that), not so >>> common cases could simply patch the driver to add a .class field. >>> >> Especially it is ugly that devices which are mentioned in DTS but are >> not present (because the component isn't plugged in or powered) get an >> directory entry in /sys/bus/i2c/devices with bind, unbind, ... >> This is my 'problem': I search for a clean way to instantiate on demand >> with no zombies in case of missing H/W. I know there are problems in >> identification of devices, but to remove all possibilities to try it >> seems not a good way for me. > > You might want to ask about this on the linux-ppc mailing list. > > You're stuck because i2c hardware does not support hotplug. Since the > hardware doesn't support hotplug there's no software support for it in > the kernel. So you want to fall back to polled probing. > > But probing is bad because it isn't standardized and coordinated, one > device's probe can cause another device to destroy things (like set a > voltage too high on a motherboard). Because of this probing can't be > turned on in general. To decide if a device exists and responds at a specified I2C address, it would be sufficient to just read some data without causing trouble. Is that assumption correct or have I missed something? Trying to identify the device is a different issue and should be avoided. Wolfgang. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
