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. >> How should it work on systems without DTS? > > i2c_board_info? (no offence, sometimes it is hard to tell if you know > all details and still see a valid problem or if you are just missing > details. If the first one is the case, please be a bit more elaborative > on the problem.) I am new in the sense that I jumped in at 2.4 making some non i2c-drivers, rejoind at 2.6.24 for i2c-drivers and a non i2c-driver. Currently I try to catch up to current state to prepare management of all i2c-devices on our next project. Even i2c_board_info needs to be filled in and passed to subsystem via a function call. Which part of kernel is supposed to do that without changing code beside board specific configuration files? (I do really mean this as a question.) -- Kind regards, Michael -- 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
