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. It's possible to get to the i2c bus from user space. You could write a user space app that polls in your controlled environment. When you detect the new devices you can load the appropriate modules. Now you need to instantiate these new devices. Jean, is it still possible to instantiate i2c devices from the module command line? > >>> 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 > -- Jon Smirl jonsmirl@xxxxxxxxx -- 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
