> mailing list. Nevertheless loading modules at runtime is legal and > generally supported by LINUX. Ack. And it does so... > 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. > As every DTS entry will force a sysFs subdirectory there would be a > bunch of functionless directories - rather ugly. Well, you should have a DTS for every flavour; that is what DTS are about. You do know that, do you? Even if not, there would be a slighty messed directory on one specific device with how many units? Let's take the latest example of extending the DTS file with OS-specific information - this one is ugly, too, but has impact _for everyone using dts_ files. Think about the number of affected systems and you will hopefully understand why such patches are handled with extreme caution. > Because of the situation above I try to keep the ability of dynamic > instantiation. Jean hesitates, I feel because he sees I2C solely in > static manner. He is taking care for every I2C communication on every Linux machine out there. He can't please everyone. On the other hand, you are free to modify the kernel as you please. It doesn't really have to be in mainline, does it? BTW, I hope you saw that the "linux,i2c-class" property is considered deprecated. Thus, expect a patch from me removing it entirely as soon as the old binding model went away (there aren't even any users). -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ |
Attachment:
signature.asc
Description: Digital signature
