On Tue, 21 Apr 2009 12:35:49 +0200, Wolfgang Grandegger wrote: > Michael Lawnick wrote: > > Wolfgang Grandegger said the following: > >> 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. No, device creation is unconditional. It is assumed that the DTS file author knew what he/she was doing. There was a discussion about adding a flag to state the "may not be present" nature of devices, which would result in a probe before instantiating the device (on success), but it wasn't implemented yet. I have no objection is this mechanism is deemed useful. > 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. -- Jean Delvare -- 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
