Michael Lawnick wrote: > Wolfgang Grandegger said the following: >> Hello, >> >> sorry for jumping in late. I just recently subscribed to this list. >> >> Michael Lawnick wrote: >>> For MPC adapter there is no class assigned as it is done in other >>> adapters. This way no new-style client will ever be instantiated. With >>> this patch class assignment is read from device tree. >>> Necessary entry: >>> class = <1>; /* I2C_CLASS_HWMON (iic.h) */ >> Do we really need that? Probing is dangerous and not necessary. Does it >> not work with a proper DTS entry? But maybe I have missed something? > > Our current and our next system consists of two flavors of the same > board with different devices. To minimize maintenance and testing we use > a reduced kernel and load the needed modules at runtime. Furthermore we > will have to handle hot-plugged I2C-devices. Whether this strategy is > best could be discussed in another thread but is rather OT in this > mailing list. Nevertheless loading modules at runtime is legal and > generally supported by LINUX. > > Defining all possible (I2C-)devices in DTS would give a mess. E.g. on > one board there will be ~30 temperature sensors, on the other none. The legacy device probing has it's limitations and I doubt that it will be able to find 30 DTT devices properly. E.g. the legacy probing algorithm is not able to distinguish between a LM75 and DS75. Let's first try to find out why it does not work as expected with the DTS entry. > As every DTS entry will force a sysFs subdirectory there would be a > bunch of functionless directories - rather ugly. Hopefully not. They will be created when the probing was successful, I assume. I think it is OK to define multiple I2C nodes also for non-existing devices in the DTS file if the I2C address is unique. 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
