1.\" $NetBSD: envsys.4,v 1.3 2000/03/09 04:17:20 groo 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 39.Dd February 26, 2000 40.Dt ENVSYS 4 41.Os 42.Sh NAME 43.Nm envsys 44.Nd Environmental Systems API 45.Sh SYNOPSIS 46.Fd #include <sys/envsys.h> 47.Sh DESCRIPTION 48.Pp 49.Bd -offset center 50.Em This API is experimental and may be deprecated at 51.Em any time 52.Ed 53.Pp 54There are a number of considerations: 55.Bl -enum 56.It 57This API is designed to support various environmental sensor ICs 58available on modern motherboards. Initially it supports three 59distinct sensor types; fan speed, temperature, and voltage. 60Additional sensor types can be added with new ioctl's without 61disrupting the current API. 62.It 63Many sensor ICs have no fixed assignment of registers to 64physical phenomena. Thus, some userland mechanism of 65assigning meanings to the registers is required to allow 66userland utilities to produce reasonable output. 67.It 68The number of registers for each class of sensor varies 69among devices. Therefore a way to enumerate all data of 70a particular sensor type is required. Fixed limits on the 71number of sensors per type is not desirable. 72.It 73Some ICs provide useful statistical information. 74Collecting reliable statistical information in userland 75from a polled device is problematic. We would like to use 76the on-chip information when it is available. 77.It 78A useful balance between complexity of use and amount 79of available information is desired. While it may be 80possible to allow for an unlimited number of statistical 81measures to be returned by a device, we have chosen only 82four common ones: current, minimum, maximum, and average. 83Even with this limited set, it may be impractical or 84impossible for devices to produce them all. Thus, a 85mechanism to determine which statistics are valid is required. 86.It 87The API is designed in a way that can be used to monitor 88both system-internal, and system-external environmental 89sensors. 90.El 91.Pp 92For the purposes of this API, all devices must number the sensors 93sequentially, beginning with 0. Moreover, all sensors of the same 94type must occupy a sub-interval of [0..n-1]. This arrangement 95allows easy iteration over the entire collection of sensors or over 96sensors of a particular type. 97.Pp 98The following 99.Xr ioctl 2 's 100must be supported by any device claiming to 101be compliant with version 1.0 of 102.Nm 103.Pp 104.Bl -tag -width indent 105.It Dv ENVSYS_VERSION (int) 106Returns API version * 1000. A userland application could use 107this command to determine further supported ioctl's of the 108device. 109.It Dv ENVSYS_GRANGE (envsys_range_t) 110The caller fills in the 111.Va units 112member of: 113.Bd -literal 114typedef struct envsys_range { 115 u_int low; 116 u_int high; 117 118 u_int units; /* see GTREDATA */ 119} envsys_range_t; 120.Ed 121.Pp 122The driver fills in the 123.Va low 124and 125.Va high 126values such that 127sensor numbers from 128.Va low 129to 130.Va high , 131inclusive, contain sensors of type 132.Va units . 133.Pp 134NOTE: 135.Va high 136< 137.Va low 138implies no sensors of the unit type specified exist. 139.It Dv ENVSYS_GTREDATA (envsys_tre_data) 140This command makes use of: 141.Bd -literal 142typedef struct envsys_tre_data { 143 u_int sensor; 144 union { /* all data is given */ 145 u_int32_t data_us; /* in microKelvins, */ 146 int32_t data_s; /* rpms, volts, amps, */ 147 } cur, min, max, avg; /* ohms, watts, etc */ 148 /* see units below */ 149 150 u_int32_t warnflags; /* warning flags */ 151 u_int32_t validflags; /* sensor valid flags */ 152 u_int units; /* type of sensor */ 153} envsys_tre_data_t; 154.Ed 155.Pp 156At request time, the caller of this command fills only the 157.Va sensor 158member with the sensor number for which data is being 159requested. The structure is returned with available data 160filled in by the driver. 161.Pp 162Zero or more of the following bits may be set in 163.Va validflags : 164.Pp 165.Bl -tag -width indent -compact -offset indent 166.It Dv ENVSYS_FVALID 167Not set implies an illegal sensor number was requested. 168.Pp 169.It Dv ENVSYS_FCURVALID 170.It Dv ENVSYS_FMINVALID 171.It Dv ENVSYS_FMAXVALID 172.It Dv ENVSYS_FAVGVALID 173Set if these fields are filled with valid data 174.Pp 175Although 176.Dv !ENVSYS_FVALID 177might be implied from the absence of 178all other *VALID flags, it is conceivable that some ICs have 179a period during which valid sensors contain invalid data. 180.El 181.Pp 182Valid 183.Va warnflags 184are: 185.Pp 186.Bl -tag -width indent -compact -offset indent 187.It Dv ENVSYS_WARN_OK 188.It Dv ENVSYS_WARN_UNDER 189.It Dv ENVSYS_WARN_CRITUNDER 190.It Dv ENVSYS_WARN_OVER 191.It Dv ENVSYS_WARN_CRITOVER 192.El 193.Pp 194The driver may return 195.Dv ENVSYS_WARN_OK 196at all times if the hardware or driver does not support warning flags. 197.Pp 198Valid 199.Va units 200are: 201.Pp 202.Bl -tag -width indent -compact -offset indent 203.It Dv ENVSYS_STEMP 204.It Dv ENVSYS_SFANRPM 205.It Dv ENVSYS_SVOLTS_AC 206.It Dv ENVSYS_SVOLTS_DC 207.It Dv ENVSYS_SOHMS 208.It Dv ENVSYS_SWATTS 209.Ir Dv ENVSYS_SAMPS 210.El 211.It Dv ENVSYS_STREINFO (envsys_basic_info_t) 212.It Dv ENVSYS_GTREINFO (envsys_basic_info_t) 213These commands make use of: 214.Bd -literal 215typedef struct envsys_basic_info { 216 u_int sensor; /* sensor number */ 217 u_int units; /* type of sensor */ 218 char desc[33]; /* sensor description */ 219 u_int rpms; /* for fans */ 220 u_int rfact; /* for volts, (factor x 10^4) */ 221 u_int32_t validflags; /* sensor valid flags */ 222} envsys_basic_info_t; 223.Ed 224.Pp 225.Dv ENVSYS_STREINFO is for setting this information in the driver, 226while 227.DV ENVSYS_GTREINFO is for retrieving this information. 228.Pp 229To retrieve information, simply fill in the 230.Va sensor 231member. 232.Pp 233All environmental sensor types read the supplied 234.Va desc 235field and store the contents for subsequent requests. The 236driver is expected to supply a default 237.Dv NULL 238terminated string for 239.Va desc . 240.Pp 241RPM sensor types additionally read the nominal RPM value from 242.Va rpms . 243Voltage sensors read 244.Va rfact . 245Drivers are expected to multiply DC voltage values by this factor before 246returning them to the user. 247.Pp 248The driver will fill in the 249.Va flags 250value, indicating to the user that he has successfully programmed or 251retrieved data from an existing sensor. 252.El 253.Sh SEE ALSO 254.Xr lm 4 255.Sh BUGS 256This entire API should be replaced by a 257.Xr sysctl 8 258interface or a kernel events mechanism, should one be developed. 259 260