On Wed, Jan 27, 2016 at 09:05:08PM -0800, Guenter Roeck wrote: > ... and thus disable any external chip signals associated with those limits. > > The idea with most if not all temperature sensors is that multiple trip points > would be configured as multiple limits in the chip. Often those limits, > when reached, are tied to pins to cause a specific action (eg to cause > an interrupt, turn on a fan, or shut down the hardware). In effect, you > suggest to re-define this mechanism and, for all practical purposes, > use just one of the limits provided by the chip(s). > > Personally I don't think that would be a good idea, because it would have > impact on hardware design. It would effectively limit the use of the thermal > subsystem with temperature sensor chips to hardware designs which take > the thermal subsystem's expectations and assumptions into account. > At the same time, it would for all practical purposes mandate the use > of the thermal subsystem on such systems, because the hardware would depend > on the thermal subsystem's implementation to control the temperature > in the system. Ah, whoops. That makes a lot of sense. And I think I even saw the poweroff in action once, when I misconfigured the temperature offset register. > While it may be feasible in some situations to have the thermal subsystem > dynamically set free-moving limits, there are many other situations where > those limits are tied to hardware responses, and the limits need to be static. > > Maybe this is just a different world view. The thermal subsystem may see the > world assuming that it always has an unlimited number of trip points available, > and the chip it supports only support lower and upper boundaries (or trip points), > which can be set and changed as needed. This is somewhat different to the > traditional world view, implemented not only in many temperature sensors, > but also in fan controller or Super-IO chips, where a set of temperatures > is programmed into the chip only once. I hope that it is possible to support > both mechanisms. That would be nice. For starters, I think it should be possible for a driver to enable thermal subsystem stuff only if an of_node is present. (Though I haven't checked what that's set to with `status = "disabled"` in the device tree. Hopefully NULL.) So, one option is to, instead of thermal OF telling the driver what the limits are, we simply have thermal OF only notify the driver of trip changes, and the driver does all the work of inspecting defined trips. In the LM90 case, it can set low/high and critical alerts nicely based on trip types (critical or not). But, for example, MAX6696 has an additional 'emergency' alert. Should that just be left untouched? Either way, this means hardcoding thermal trip to sensor alert mapping in the driver. A more elaborate solution would be to define that mapping in the device tree, and have thermal OF handle it, instructing the driver to set specific alerts. (And then the device tree author may choose to leave certain sensor alerts alone.) -- Stéphan Kochen -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
