On Thu, 12 Jan 2006, Diana Eichert wrote: > I've been following all the i2c work lately and have a question. I have > some blade servers that use i2c as a control path between a master blade > and the child blades. This is in addition to sensor info. > > Has there been any thought towards supporting i2c control channel stuff, > or am I ahead of the development work, or perhaps I'm talking about a > corner case with limited usefulness?
Right now the i2c work has been focussed on monitoring only - controlling stuff is a fair bit more scary. The big problem with i2c is figuring out what devices live on the bus - Theo has been writing heaps of delicate code to probe and identify i2c sensors. This has to be done very carefully as some devices will crash (or worse: corrupt themselves) if they are prodded in the wrong way. This is tricky for passive sensor devices, but it is very much worse for control devices: typically these have a bunch of GPIO pins that could be hooked up to anything: an output could be hooked up to something as harmless as a LED or something far more scary and there is often no way to perform a software probe that identifies what is attached. To make matters worse, different vendors or models are likely to hook stuff up to these pins in completely different ways. There are probably some easier cases buried in the difficult ones though, adjusting fan speeds may be possible for instance. > FWIW they're RLX blade servers and they are no longer in the blade > server business. At one point they had support for their control s/w for > FreeBSD, I think I even have a copy of it laying around. If the code is under a free license, then it will probably be useful (even if only as documentation). -d
