1.\" $NetBSD: envsys.4,v 1.6 2000/07/04 08:57:44 enami Exp $ 2.\" 3.\" 4.\" Copyright (c) 2000 The NetBSD Foundation, Inc. 5.\" All rights reserved. 6.\" 7.\" This code is derived from software contributed to The NetBSD Foundation 8.\" by Tim Rightnour and Bill Squier 9.\" 10.\" Redistribution and use in source and binary forms, with or without 11.\" modification, are permitted provided that the following conditions 12.\" are met: 13.\" 1. Redistributions of source code must retain the above copyright 14.\" notice, this list of conditions and the following disclaimer. 15.\" 2. Redistributions in binary form must reproduce the above copyright 16.\" notice, this list of conditions and the following disclaimer in the 17.\" documentation and/or other materials provided with the distribution. 18.\" 3. All advertising materials mentioning features or use of this software 19.\" must display the following acknowledgement: 20.\" This product includes software developed by the NetBSD 21.\" Foundation, Inc. and its contributors. 22.\" 4. Neither the name of The NetBSD Foundation nor the names of its 23.\" contributors may be used to endorse or promote products derived 24.\" from this software without specific prior written permission. 25.\" 26.\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS 27.\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED 28.\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 29.\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS 30.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 31.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 32.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 33.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN 34.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 35.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 36.\" POSSIBILITY OF SUCH DAMAGE. 37.\" 38.Dd February 26, 2000 39.Dt ENVSYS 4 40.Os 41.Sh NAME 42.Nm envsys 43.Nd Environmental Systems API 44.Sh SYNOPSIS 45.Fd #include <sys/envsys.h> 46.Sh DESCRIPTION 47.Pp 48.Bd -offset center 49.Em This API is experimental and may be deprecated at 50.Em any time 51.Ed 52.Pp 53There are a number of considerations: 54.Bl -enum 55.It 56This API is designed to support various environmental sensor ICs 57available on modern motherboards. Initially it supports three 58distinct sensor types; fan speed, temperature, and voltage. 59Additional sensor types can be added with new ioctl's without 60disrupting the current API. 61.It 62Many sensor ICs have no fixed assignment of registers to 63physical phenomena. Thus, some userland mechanism of 64assigning meanings to the registers is required to allow 65userland utilities to produce reasonable output. 66.It 67The number of registers for each class of sensor varies 68among devices. Therefore a way to enumerate all data of 69a particular sensor type is required. Fixed limits on the 70number of sensors per type is not desirable. 71.It 72Some ICs provide useful statistical information. 73Collecting reliable statistical information in userland 74from a polled device is problematic. We would like to use 75the on-chip information when it is available. 76.It 77A useful balance between complexity of use and amount 78of available information is desired. While it may be 79possible to allow for an unlimited number of statistical 80measures to be returned by a device, we have chosen only 81four common ones: current, minimum, maximum, and average. 82Even with this limited set, it may be impractical or 83impossible for devices to produce them all. Thus, a 84mechanism to determine which statistics are valid is required. 85.It 86The API is designed in a way that can be used to monitor 87both system-internal, and system-external environmental 88sensors. 89.El 90.Pp 91For the purposes of this API, all devices must number the sensors 92sequentially, beginning with 0. Moreover, all sensors of the same 93type must occupy a sub-interval of [0..n-1]. This arrangement 94allows easy iteration over the entire collection of sensors or over 95sensors of a particular type. 96.Pp 97The following 98.Xr ioctl 2 's 99must be supported by any device claiming to 100be compliant with version 1.0 of 101.Nm 102.Pp 103.Bl -tag -width indent 104.It Dv ENVSYS_VERSION (int) 105Returns API version * 1000. A userland application could use 106this command to determine further supported ioctl's of the 107device. 108.It Dv ENVSYS_GRANGE (envsys_range_t) 109The caller fills in the 110.Va units 111member of: 112.Bd -literal 113typedef struct envsys_range { 114 u_int low; 115 u_int high; 116 117 u_int units; /* see GTREDATA */ 118} envsys_range_t; 119.Ed 120.Pp 121The driver fills in the 122.Va low 123and 124.Va high 125values such that 126sensor numbers from 127.Va low 128to 129.Va high , 130inclusive, contain sensors of type 131.Va units . 132.Pp 133NOTE: 134.Va high 135< 136.Va low 137implies no sensors of the unit type specified exist. 138.It Dv ENVSYS_GTREDATA (envsys_tre_data) 139This command makes use of: 140.Bd -literal 141typedef struct envsys_tre_data { 142 u_int sensor; 143 union { /* all data is given */ 144 u_int32_t data_us; /* in microKelvins, */ 145 int32_t data_s; /* rpms, volts, amps, */ 146 } cur, min, max, avg; /* ohms, watts, etc */ 147 /* see units below */ 148 149 u_int32_t warnflags; /* warning flags */ 150 u_int32_t validflags; /* sensor valid flags */ 151 u_int units; /* type of sensor */ 152} envsys_tre_data_t; 153.Ed 154.Pp 155At request time, the caller of this command fills only the 156.Va sensor 157member with the sensor number for which data is being 158requested. The structure is returned with available data 159filled in by the driver. 160.Pp 161Zero or more of the following bits may be set in 162.Va validflags : 163.Pp 164.Bl -tag -width indent -compact -offset indent 165.It Dv ENVSYS_FVALID 166Not set implies an illegal sensor number was requested. 167.Pp 168.It Dv ENVSYS_FCURVALID 169.It Dv ENVSYS_FMINVALID 170.It Dv ENVSYS_FMAXVALID 171.It Dv ENVSYS_FAVGVALID 172Set if these fields are filled with valid data 173.Pp 174Although 175.Dv !ENVSYS_FVALID 176might be implied from the absence of 177all other *VALID flags, it is conceivable that some ICs have 178a period during which valid sensors contain invalid data. 179.El 180.Pp 181Valid 182.Va warnflags 183are: 184.Pp 185.Bl -tag -width indent -compact -offset indent 186.It Dv ENVSYS_WARN_OK 187.It Dv ENVSYS_WARN_UNDER 188.It Dv ENVSYS_WARN_CRITUNDER 189.It Dv ENVSYS_WARN_OVER 190.It Dv ENVSYS_WARN_CRITOVER 191.El 192.Pp 193The driver may return 194.Dv ENVSYS_WARN_OK 195at all times if the hardware or driver does not support warning flags. 196.Pp 197Valid 198.Va units 199are: 200.Pp 201.Bl -tag -width indent -compact -offset indent 202.It Dv ENVSYS_STEMP 203.It Dv ENVSYS_SFANRPM 204.It Dv ENVSYS_SVOLTS_AC 205.It Dv ENVSYS_SVOLTS_DC 206.It Dv ENVSYS_SOHMS 207.It Dv ENVSYS_SWATTS 208.Ir Dv ENVSYS_SAMPS 209.El 210.It Dv ENVSYS_STREINFO (envsys_basic_info_t) 211.It Dv ENVSYS_GTREINFO (envsys_basic_info_t) 212These commands make use of: 213.Bd -literal 214typedef struct envsys_basic_info { 215 u_int sensor; /* sensor number */ 216 u_int units; /* type of sensor */ 217 char desc[33]; /* sensor description */ 218 u_int rpms; /* for fans */ 219 u_int rfact; /* for volts, (factor x 10^4) */ 220 u_int32_t validflags; /* sensor valid flags */ 221} envsys_basic_info_t; 222.Ed 223.Pp 224.Dv ENVSYS_STREINFO is for setting this information in the driver, 225while 226.DV ENVSYS_GTREINFO is for retrieving this information. 227.Pp 228To retrieve information, simply fill in the 229.Va sensor 230member. 231.Pp 232All environmental sensor types read the supplied 233.Va desc 234field and store the contents for subsequent requests. The 235driver is expected to supply a default 236.Dv NULL 237terminated string for 238.Va desc . 239.Pp 240RPM sensor types additionally read the nominal RPM value from 241.Va rpms . 242Voltage sensors read 243.Va rfact . 244Drivers are expected to multiply DC voltage values by this factor before 245returning them to the user. 246.Pp 247The driver will fill in the 248.Va flags 249value, indicating to the user that he has successfully programmed or 250retrieved data from an existing sensor. 251.El 252.Sh SEE ALSO 253.Xr lm 4 , 254.Xr viaenv 4 , 255.Xr envstat 8 256.Sh BUGS 257This entire API should be replaced by a 258.Xr sysctl 8 259interface or a kernel events mechanism, should one be developed. 260