From owner-freebsd-drivers@FreeBSD.ORG Sun Apr 11 19:25:08 2010 Return-Path: Delivered-To: freebsd-drivers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 804B0106564A; Sun, 11 Apr 2010 19:25:08 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from hita.home.const.name (dale.cnst.cs.uwaterloo.ca [129.97.7.219]) by mx1.freebsd.org (Postfix) with ESMTP id E79028FC14; Sun, 11 Apr 2010 19:25:07 +0000 (UTC) Received: from dale.cnst.cs.uwaterloo.ca (localhost [127.0.0.1]) by hita.home.const.name (8.14.3/8.14.3) with ESMTP id o3BJOowt001457; Sun, 11 Apr 2010 15:24:50 -0400 (EDT) (envelope-from cnst@FreeBSD.org) Received: (from constant@localhost) by dale.cnst.cs.uwaterloo.ca (8.14.3/8.14.3/Submit) id o3BJOn3p001456; Sun, 11 Apr 2010 15:24:49 -0400 (EDT) (envelope-from cnst@FreeBSD.org) X-Authentication-Warning: dale.cnst.cs.uwaterloo.ca: constant set sender to cnst@FreeBSD.org using -f Date: Sun, 11 Apr 2010 15:24:49 -0400 From: "Constantine A. Murenin" To: "M. Warner Losh" Message-ID: <20100411192449.GA1367@dale.cnst.cs.uwaterloo.ca> References: <20100405055947.GA3544@hita.home.const.name> <20100406.074313.364718154403381345.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <20100406.074313.364718154403381345.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Organization: David R. Cheriton School of Computer Science, Faculty of Mathematics, University of Waterloo X-Postal-Address: Constantine A. Murenin, David R. Cheriton School of Computer Science, University of Waterloo, 200 University Avenue West, Waterloo, Ontario N2L 3G1 Canada X-Office-Phone: +1-519-888-4567 x33581 X-Mobile-Phone: +1-K1W-ST1-CNST X-WWW: http://Constantine.SU/ X-LinkedIn: http://www.linkedin.com/in/mureninc Cc: freebsd-acpi@FreeBSD.org, "Constantine A. Murenin" , rpaulo@FreeBSD.org, freebsd-drivers@FreeBSD.org, freebsd-hardware@FreeBSD.org Subject: Re: aibs(4): ASUSTeK AI Booster (ACPI ATK0110) Hardware Monitor X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 19:25:08 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On Tue, Apr 06, 2010 at 07:43:13AM -0600, M. Warner Losh wrote: > In message: > Rui Paulo writes: > : Hi, > : > : On 5 Apr 2010, at 06:59, Constantine A. Murenin wrote: > : > : > Dear freebsd-{acpi,drivers,hardware}@, > : > > : > Attached patch provides support for the hardware monitoring capabilities that are present in many modern desktop motherboards from ASUS featuring the ATK0110 ACPI device. > : > > : > This driver, aibs(4), is a fresh replacement for FreeBSD's existing acpi_aiboost(4). The new aibs(4) driver has the following advantages when compared to the old acpi_aiboost(4): > : > * the sensors are now provided through the user-serviceable hw.acpi.aibs0 tree (with a subtree for each sensor type), instead of the Newbus-internal dev.acpi_aiboost.0 tree that contains various nonprime data at the same level as the actual sensors > : > : I was under the impression that this the right way in FreeBSD. > > To be clear, this is a regression. They should be through the dev > tree. We've been migrating exposed functionality from the hw. tree to > the dev. tree for quite some time now. hw. isn't any more > user-serviceable than dev. is. > > Warner Thanks for your comments. But what about the %desc, %driver, %location, %pnpinfo and %parent leaves that, for example, appear under the dev.aibs.0 tree? Don't they introduce the perception that the dev tree is not really user-serviceable, as most of the tree is practically entirely useless for the end-user? Is there, or should there be, a way to tell sysctl(8) to not print such %driver leaves under the dev tree? I've simply used acpi_thermal.c as the exemplar for hw.acpi attachment, as I've found it to produce more elegant results than the dev attachment. Should acpi_thermal be also converted to use the dev tree? I can write a patch. In any case, I've modified aibs(4) to now use its dev tree (see the patch inline); aibs(4) is now even smaller than it was before, still supporting several additional features: > ll /usr/c/src/sys/dev/acpi_support/{acpi_aiboost,atk0110}.c -rw-r--r-- 1 constant wheel 8919 Apr 3 20:31 /usr/c/src/sys/dev/acpi_support/acpi_aiboost.c -rw-r--r-- 1 constant wheel 8299 Apr 11 12:29 /usr/c/src/sys/dev/acpi_support/atk0110.c > ll /boot/kernel/*aib*s* -r-xr-xr-x 1 root wheel 11581 Apr 11 12:57 /boot/kernel/acpi_aiboost.ko -r-xr-xr-x 1 root wheel 24504 Apr 11 12:57 /boot/kernel/acpi_aiboost.ko.symbols -r-xr-xr-x 1 root wheel 9801 Apr 11 12:57 /boot/kernel/aibs.ko -r-xr-xr-x 1 root wheel 21203 Apr 11 12:57 /boot/kernel/aibs.ko.symbols > sysctl dev.aibs.0.{volt,temp,fan} dev.aibs.0.volt.0: 1240 850 1600 dev.aibs.0.volt.1: 3312 2970 3630 dev.aibs.0.volt.2: 5017 4500 5500 dev.aibs.0.volt.3: 12302 10200 13800 dev.aibs.0.temp.0: 30.0C 80.0C 95.0C dev.aibs.0.temp.1: 56.0C 60.0C 95.0C dev.aibs.0.fan.0: 878 600 7200 dev.aibs.0.fan.1: 0 700 7200 Best regards, Constantine. --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="svn_diff.aibs.r0.2010-04-11T123857-0400.dev.patch" Index: share/man/man4/aibs.4 =================================================================== --- share/man/man4/aibs.4 (revision 0) +++ share/man/man4/aibs.4 (revision 0) @@ -0,0 +1,209 @@ +.\" $FreeBSD$ +.\" $NetBSD: aibs.4,v 1.2 2010/02/09 05:37:25 cnst Exp $ +.\" $OpenBSD: aibs.4,v 1.4 2009/07/30 06:30:45 jmc Exp $ +.\" +.\" Copyright (c) 2009/2010 Constantine A. Murenin +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.Dd April 4, 2010 +.Dt AIBS 4 +.Os +.Sh NAME +.Nm aibs +.Nd "ASUSTeK AI Booster ACPI ATK0110 voltage, temperature and fan sensor" +.Sh SYNOPSIS +To compile this driver into the kernel, +place the following lines in your +kernel configuration file: +.Bd -ragged -offset indent +.Cd "device acpi" +.Cd "device aibs" +.Ed +.Pp +Alternatively, to load the driver as a +module at boot time, place the following lines in +.Xr loader.conf 5 : +.Bd -literal -offset indent +acpi_load="YES" +aibs_load="YES" +.Ed +.Sh DESCRIPTION +The +.Nm +driver provides support for the voltage, temperature and fan sensors +available through the +.Tn ATK0110 +.Tn ASOC +.Tn ACPI +device +on +.Tn ASUSTeK +motherboards. +The number of sensors of each type, +as well as the description of each sensor, +varies according to the motherboard. +.Pp +The driver supports an arbitrary set of sensors, +provides descriptions regarding what each sensor is used for, +and reports the current values as well as +the supposed range specifications of each sensor's input +as defined by the motherboard manufacturer through +.Tn ACPI . +.Pp +The range specifications are as follows: +.Bl -bullet +.It +Voltage sensors have a lower and an upper range specification. +.It +Temperature sensors have two upper specifications. +.It +Fan sensors may either have only the lower specification, +or, depending on the +.Tn DSDT , +one lower and one upper specification. +.El +.Pp +Sensor readings and the range specifications are made available through the +.Xr sysctl 3 +interface, +and can be monitored with +.Xr sysctl 8 . +For example, on an ASUS V3-P5G965 barebone: +.Bd -literal -offset indent +> sysctl dev.aibs.0.{volt,temp,fan} +dev.aibs.0.volt.0: 1192 850 1600 +dev.aibs.0.volt.1: 3312 2970 3630 +dev.aibs.0.volt.2: 5017 4500 5500 +dev.aibs.0.volt.3: 12302 10200 13800 +dev.aibs.0.temp.0: 28.0C 80.0C 95.0C +dev.aibs.0.temp.1: 55.0C 60.0C 95.0C +dev.aibs.0.fan.0: 878 600 7200 +dev.aibs.0.fan.1: 0 700 7200 +.Pp +> sysctl -d dev.aibs.0.{volt,temp,fan} +dev.aibs.0.volt: +dev.aibs.0.volt.0: Vcore Voltage +dev.aibs.0.volt.1: +3.3 Voltage +dev.aibs.0.volt.2: +5 Voltage +dev.aibs.0.volt.3: +12 Voltage +dev.aibs.0.temp: +dev.aibs.0.temp.0: CPU Temperature +dev.aibs.0.temp.1: MB Temperature +dev.aibs.0.fan: +dev.aibs.0.fan.0: CPU FAN Speed +dev.aibs.0.fan.1: CHASSIS FAN Speed +.Ed +.Pp +Generally, sensors provided by the +.Nm +driver may also be supported by certain other drivers or utilities +that access the +.Tn ISA / +.Tn LPC +or +.Tn I2C / +.Tn SMBus +devices directly. +The precise collection of +.Nm +sensors is comprised of the sensors +specifically utilised in the motherboard +design, which may be supported through +a combination of one or more physical hardware monitoring chips. +.Pp +The +.Nm +driver, however, provides the following advantages +when compared to the native hardware monitoring drivers or other utilities: +.Bl -bullet +.It +Sensor values from +.Nm +are expected to be more reliable. +For example, voltage sensors in many hardware monitoring chips +can only sense voltage from 0 to 2 or 4 volts, and the excessive +voltage is removed by the resistors, which may vary with the motherboard +and with the voltage that is being sensed. +In +.Nm , +the required resistor factors are provided by +the motherboard manufacturer through +.Tn ACPI ; +in the native drivers, the resistor factors +are encoded into the driver based on the chip manufacturer's recommendations. +In essence, sensor values from +.Nm +are very likely to be identical to the readings from the +Hardware Monitor screen in the BIOS. +.It +Sensor descriptions from +.Nm +are more likely to match the markings on the motherboard. +.It +Sensor range specifications are supported by +.Nm . +The range specification is reported +for each individual sensor as suggested by the motherboard manufacturer. +For example, the threshold for the CPU temperature sensor is likely +to be significantly higher than that for the chassis temperature sensor. +.It +Support for newer chips in +.Nm . +Newer chips may miss a native driver, +but should be supported through +.Nm +regardless. +.El +.Sh SEE ALSO +.Xr sysctl 3 , +.Xr acpi 4 , +.Xr sysctl 8 +.Sh HISTORY +The +.Nm +driver first appeared in +.Ox 4.7 , +.Dx 2.5 , +.Nx 6.0 +and +.Fx 9.0 . +.Pp +An earlier version of the driver, +.Nm acpi_aiboost , +first appeared in +.Fx 7.0 +and +.Nx 5.0 . +.Sh AUTHORS +.An -nosplit +The +.Nm +driver was written for +.Ox , +.Dx , +.Nx +and +.Fx +by +.An Constantine A. Murenin Aq cnst@FreeBSD.org , +Raouf Boutaba Research Group, +David R. Cheriton School of Computer Science, +University of Waterloo. +.Pp +An earlier version of the driver, named +.Nm acpi_aiboost , +was written for +.Fx +by +.An Takanori Watanabe . Index: share/man/man4/Makefile =================================================================== --- share/man/man4/Makefile (revision 206482) +++ share/man/man4/Makefile (working copy) @@ -26,6 +26,7 @@ ahc.4 \ ahci.4 \ ahd.4 \ + ${_aibs.4} \ aio.4 \ alc.4 \ ale.4 \ @@ -629,6 +630,7 @@ _acpi_sony.4= acpi_sony.4 _acpi_toshiba.4=acpi_toshiba.4 _acpi_wmi.4= acpi_wmi.4 +_aibs.4= aibs.4 _amdsbwd.4= amdsbwd.4 _amdsmb.4= amdsmb.4 _amdtemp.4= amdtemp.4 Index: sys/conf/files =================================================================== --- sys/conf/files (revision 206482) +++ sys/conf/files (working copy) @@ -416,6 +416,7 @@ dev/acpi_support/acpi_panasonic.c optional acpi_panasonic acpi dev/acpi_support/acpi_sony.c optional acpi_sony acpi dev/acpi_support/acpi_toshiba.c optional acpi_toshiba acpi +dev/acpi_support/atk0110.c optional aibs acpi dev/acpica/Osd/OsdDebug.c optional acpi dev/acpica/Osd/OsdHardware.c optional acpi dev/acpica/Osd/OsdInterrupt.c optional acpi Index: sys/modules/acpi/Makefile =================================================================== --- sys/modules/acpi/Makefile (revision 206482) +++ sys/modules/acpi/Makefile (working copy) @@ -6,6 +6,6 @@ SUBDIR+= acpi_aiboost acpi_asus acpi_fujitsu acpi_hp acpi_ibm \ acpi_panasonic acpi_sony acpi_toshiba acpi_video \ - acpi_dock acpi_wmi + acpi_dock acpi_wmi aibs .include Index: sys/modules/acpi/aibs/Makefile =================================================================== --- sys/modules/acpi/aibs/Makefile (revision 0) +++ sys/modules/acpi/aibs/Makefile (revision 0) @@ -0,0 +1,10 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../../dev/acpi_support + +KMOD= aibs +SRCS= atk0110.c +SRCS+= opt_acpi.h acpi_if.h bus_if.h device_if.h +SRCS+= opt_ddb.h + +.include Index: sys/dev/acpi_support/atk0110.c =================================================================== --- sys/dev/acpi_support/atk0110.c (revision 0) +++ sys/dev/acpi_support/atk0110.c (revision 0) @@ -0,0 +1,359 @@ +/* $FreeBSD$ */ +/* $NetBSD: atk0110.c,v 1.4 2010/02/11 06:54:57 cnst Exp $ */ +/* $OpenBSD: atk0110.c,v 1.1 2009/07/23 01:38:16 cnst Exp $ */ + +/* + * Copyright (c) 2009/2010 Constantine A. Murenin + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +/* + * ASUSTeK AI Booster (ACPI ASOC ATK0110). + * + * This code was originally written for OpenBSD after the techniques + * described in the Linux's asus_atk0110.c and FreeBSD's Takanori Watanabe's + * acpi_aiboost.c were verified to be accurate on the actual hardware kindly + * provided by Sam Fourman Jr. It was subsequently ported from OpenBSD to + * DragonFly BSD, to NetBSD's sysmon_envsys(9) and to FreeBSD's sysctl(9). + * + * -- Constantine A. Murenin + */ + +#define _COMPONENT ACPI_OEM +ACPI_MODULE_NAME("aibs"); +ACPI_SERIAL_DECL(aibs, "aibs"); + +#define AIBS_MORE_SENSORS +#define AIBS_VERBOSE + +enum aibs_type { + AIBS_VOLT, + AIBS_TEMP, + AIBS_FAN +}; + +struct aibs_sensor { + ACPI_INTEGER v; + ACPI_INTEGER i; + ACPI_INTEGER l; + ACPI_INTEGER h; + enum aibs_type t; +}; + +struct aibs_softc { + struct device *sc_dev; + ACPI_HANDLE sc_ah; + + struct aibs_sensor *sc_asens_volt; + struct aibs_sensor *sc_asens_temp; + struct aibs_sensor *sc_asens_fan; +}; + +static int aibs_probe(device_t); +static int aibs_attach(device_t); +static int aibs_detach(device_t); +static int aibs_sysctl(SYSCTL_HANDLER_ARGS); + +static void aibs_attach_sif(struct aibs_softc *, enum aibs_type); + +static device_method_t aibs_methods[] = { + DEVMETHOD(device_probe,aibs_probe), + DEVMETHOD(device_attach,aibs_attach), + DEVMETHOD(device_detach,aibs_detach), + { NULL, NULL } +}; + +static driver_t aibs_driver = { + "aibs", + aibs_methods, + sizeof(struct aibs_softc) +}; + +static devclass_t aibs_devclass; + +DRIVER_MODULE(aibs, acpi, aibs_driver, aibs_devclass, NULL, NULL); + + +static char* aibs_hids[] = { + "ATK0110", + NULL +}; + +static int +aibs_probe(device_t dev) +{ + if (acpi_disabled("aibs") || + ACPI_ID_PROBE(device_get_parent(dev), dev, aibs_hids) == NULL) + return ENXIO; + + device_set_desc(dev, "ASUSTeK AI Booster (ACPI ASOC ATK0110)"); + return 0; +} + +static int +aibs_attach(device_t dev) +{ + struct aibs_softc *sc = device_get_softc(dev); + + sc->sc_dev = dev; + sc->sc_ah = acpi_get_handle(dev); + + aibs_attach_sif(sc, AIBS_VOLT); + aibs_attach_sif(sc, AIBS_TEMP); + aibs_attach_sif(sc, AIBS_FAN); + + return 0; +} + +static void +aibs_attach_sif(struct aibs_softc *sc, enum aibs_type st) +{ + ACPI_STATUS s; + ACPI_BUFFER b; + ACPI_OBJECT *bp, *o; + int i, n; + const char *node; + char name[] = "?SIF"; + struct aibs_sensor *as; + struct sysctl_oid *so; + + switch (st) { + case AIBS_VOLT: + node = "volt"; + name[0] = 'V'; + break; + case AIBS_TEMP: + node = "temp"; + name[0] = 'T'; + break; + case AIBS_FAN: + node = "fan"; + name[0] = 'F'; + break; + default: + return; + } + + b.Length = ACPI_ALLOCATE_BUFFER; + s = AcpiEvaluateObjectTyped(sc->sc_ah, name, NULL, &b, + ACPI_TYPE_PACKAGE); + if (ACPI_FAILURE(s)) { + device_printf(sc->sc_dev, "%s not found\n", name); + return; + } + + bp = b.Pointer; + o = bp->Package.Elements; + if (o[0].Type != ACPI_TYPE_INTEGER) { + device_printf(sc->sc_dev, "%s[0]: invalid type\n", name); + AcpiOsFree(b.Pointer); + return; + } + + n = o[0].Integer.Value; + if (bp->Package.Count - 1 < n) { + device_printf(sc->sc_dev, "%s: invalid package\n", name); + AcpiOsFree(b.Pointer); + return; + } else if (bp->Package.Count - 1 > n) { + int on = n; + +#ifdef AIBS_MORE_SENSORS + n = bp->Package.Count - 1; +#endif + device_printf(sc->sc_dev, "%s: malformed package: %i/%i" + ", assume %i\n", name, on, bp->Package.Count - 1, n); + } + if (n < 1) { + device_printf(sc->sc_dev, "%s: no members in the package\n", + name); + AcpiOsFree(b.Pointer); + return; + } + + as = malloc(sizeof(*as) * n, M_DEVBUF, M_NOWAIT | M_ZERO); + if (as == NULL) { + device_printf(sc->sc_dev, "%s: malloc fail\n", name); + AcpiOsFree(b.Pointer); + return; + } + switch (st) { + case AIBS_VOLT: + sc->sc_asens_volt = as; + break; + case AIBS_TEMP: + sc->sc_asens_temp = as; + break; + case AIBS_FAN: + sc->sc_asens_fan = as; + break; + } + + /* sysctl subtree for sensors of this type */ + so = SYSCTL_ADD_NODE(device_get_sysctl_ctx(sc->sc_dev), + SYSCTL_CHILDREN(device_get_sysctl_tree(sc->sc_dev)), st, + node, CTLFLAG_RD, NULL, NULL); + + for (i = 0, o++; i < n; i++, o++) { + ACPI_OBJECT *oi; + char si[3]; + const char *desc; + + /* acpica5 automatically evaluates the referenced package */ + if(o[0].Type != ACPI_TYPE_PACKAGE) { + device_printf(sc->sc_dev, + "%s: %i: not a package: %i type\n", + name, i, o[0].Type); + continue; + } + oi = o[0].Package.Elements; + if (o[0].Package.Count != 5 || + oi[0].Type != ACPI_TYPE_INTEGER || + oi[1].Type != ACPI_TYPE_STRING || + oi[2].Type != ACPI_TYPE_INTEGER || + oi[3].Type != ACPI_TYPE_INTEGER || + oi[4].Type != ACPI_TYPE_INTEGER) { + device_printf(sc->sc_dev, + "%s: %i: invalid package\n", + name, i); + continue; + } + as[i].i = oi[0].Integer.Value; + desc = oi[1].String.Pointer; + as[i].l = oi[2].Integer.Value; + as[i].h = oi[3].Integer.Value; + as[i].t = st; +#ifdef AIBS_VERBOSE + device_printf(sc->sc_dev, "%c%i: " + "0x%08"PRIx64" %20s %5"PRIi64" / %5"PRIi64" " + "0x%"PRIx64"\n", + name[0], i, + as[i].i, desc, (int64_t)as[i].l, (int64_t)as[i].h, + oi[4].Integer.Value); +#endif + snprintf(si, sizeof(si), "%i", i); + SYSCTL_ADD_PROC(device_get_sysctl_ctx(sc->sc_dev), + SYSCTL_CHILDREN(so), i, si, CTLTYPE_OPAQUE | CTLFLAG_RD, + sc, st, aibs_sysctl, st == AIBS_TEMP ? "IK" : "I", desc); + } + + AcpiOsFree(b.Pointer); +} + +static int +aibs_detach(device_t dev) +{ + struct aibs_softc *sc = device_get_softc(dev); + + if (sc->sc_asens_volt != NULL) + free(sc->sc_asens_volt, M_DEVBUF); + if (sc->sc_asens_temp != NULL) + free(sc->sc_asens_temp, M_DEVBUF); + if (sc->sc_asens_fan != NULL) + free(sc->sc_asens_fan, M_DEVBUF); + return 0; +} + +#ifdef AIBS_VERBOSE +#define ddevice_printf(x...) device_printf(x) +#else +#define ddevice_printf(x...) +#endif + +static int +aibs_sysctl(SYSCTL_HANDLER_ARGS) +{ + struct aibs_softc *sc = arg1; + enum aibs_type st = arg2; + int i = oidp->oid_number; + ACPI_STATUS rs; + ACPI_OBJECT p, *bp; + ACPI_OBJECT_LIST mp; + ACPI_BUFFER b; + char *name; + struct aibs_sensor *as; + ACPI_INTEGER v, l, h; + int so[3]; + + switch (st) { + case AIBS_VOLT: + name = "RVLT"; + as = sc->sc_asens_volt; + break; + case AIBS_TEMP: + name = "RTMP"; + as = sc->sc_asens_temp; + break; + case AIBS_FAN: + name = "RFAN"; + as = sc->sc_asens_fan; + break; + default: + return ENOENT; + } + if (as == NULL) + return ENOENT; + l = as[i].l; + h = as[i].h; + p.Type = ACPI_TYPE_INTEGER; + p.Integer.Value = as[i].i; + mp.Count = 1; + mp.Pointer = &p; + b.Length = ACPI_ALLOCATE_BUFFER; + ACPI_SERIAL_BEGIN(aibs); + rs = AcpiEvaluateObjectTyped(sc->sc_ah, name, &mp, &b, + ACPI_TYPE_INTEGER); + if (ACPI_FAILURE(rs)) { + ddevice_printf(sc->sc_dev, + "%s: %i: evaluation failed\n", + name, i); + ACPI_SERIAL_END(aibs); + return EIO; + } + bp = b.Pointer; + v = bp->Integer.Value; + AcpiOsFree(b.Pointer); + ACPI_SERIAL_END(aibs); + + switch (st) { + case AIBS_VOLT: + break; + case AIBS_TEMP: + v += 2732; + l += 2732; + h += 2732; + break; + case AIBS_FAN: + break; + } + so[0] = v; + so[1] = l; + so[2] = h; + return sysctl_handle_opaque(oidp, &so, sizeof(so), req); +} Index: sys/i386/conf/NOTES =================================================================== --- sys/i386/conf/NOTES (revision 206482) +++ sys/i386/conf/NOTES (working copy) @@ -506,6 +506,9 @@ # ACPI Docking Station device acpi_dock +# ACPI ASOC ATK0110 ASUSTeK AI Booster (voltage, temperature and fan sensors) +device aibs + # The cpufreq(4) driver provides support for non-ACPI CPU frequency control device cpufreq --gBBFr7Ir9EOA20Yy-- From owner-freebsd-drivers@FreeBSD.ORG Sun Apr 11 20:08:14 2010 Return-Path: Delivered-To: freebsd-drivers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0954C106566C; Sun, 11 Apr 2010 20:08:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 761118FC13; Sun, 11 Apr 2010 20:08:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o3BK0dl4093898; Sun, 11 Apr 2010 14:00:39 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 11 Apr 2010 14:00:47 -0600 (MDT) Message-Id: <20100411.140047.527849116143353707.imp@bsdimp.com> To: cnst@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20100411192449.GA1367@dale.cnst.cs.uwaterloo.ca> References: <20100406.074313.364718154403381345.imp@bsdimp.com> <20100411192449.GA1367@dale.cnst.cs.uwaterloo.ca> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, rpaulo@FreeBSD.org, freebsd-drivers@FreeBSD.org, freebsd-hardware@FreeBSD.org Subject: Re: aibs(4): ASUSTeK AI Booster (ACPI ATK0110) Hardware Monitor X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 20:08:14 -0000 In message: <20100411192449.GA1367@dale.cnst.cs.uwaterloo.ca> "Constantine A. Murenin" writes: : On Tue, Apr 06, 2010 at 07:43:13AM -0600, M. Warner Losh wrote: : > In message: : > Rui Paulo writes: : > : Hi, : > : : > : On 5 Apr 2010, at 06:59, Constantine A. Murenin wrote: : > : : > : > Dear freebsd-{acpi,drivers,hardware}@, : > : > : > : > Attached patch provides support for the hardware monitoring : > capabilities that are present in many modern desktop motherboards from : > ASUS featuring the ATK0110 ACPI device. : > : > : > : > This driver, aibs(4), is a fresh replacement for FreeBSD's : > existing acpi_aiboost(4). The new aibs(4) driver has the following : > advantages when compared to the old acpi_aiboost(4): : > : > * the sensors are now provided through the user-serviceable : > hw.acpi.aibs0 tree (with a subtree for each sensor type), instead of : > the Newbus-internal dev.acpi_aiboost.0 tree that contains various : > nonprime data at the same level as the actual sensors : > : : > : I was under the impression that this the right way in FreeBSD. : > : > To be clear, this is a regression. They should be through the dev : > tree. We've been migrating exposed functionality from the hw. tree to : > the dev. tree for quite some time now. hw. isn't any more : > user-serviceable than dev. is. : > Warner : : Thanks for your comments. But what about the %desc, %driver, : %location, %pnpinfo and %parent leaves that, for example, appear under : the dev.aibs.0 tree? Yes. They do. : Don't they introduce the perception that the dev : tree is not really user-serviceable, as most of the tree is : practically entirely useless for the end-user? No, they shouldn't. There's documented APIs for hooking into this tree. That sounds like it would be user-serviceable. That certainly was the intent when DES added them. : Is there, or should : there be, a way to tell sysctl(8) to not print such %driver leaves : under the dev tree? sysctl dev.acpi | grep -v % will do the trick. : I've simply used acpi_thermal.c as the exemplar : for hw.acpi attachment, as I've found it to produce more elegant : results than the dev attachment. Should acpi_thermal be also : converted to use the dev tree? I can write a patch. I think it should be. : In any case, I've modified aibs(4) to now use its dev tree (see the : patch inline); aibs(4) is now even smaller than it was before, still : supporting several additional features: Woo Hoo! : > ll /usr/c/src/sys/dev/acpi_support/{acpi_aiboost,atk0110}.c : -rw-r--r-- 1 constant wheel 8919 Apr 3 20:31 : -/usr/c/src/sys/dev/acpi_support/acpi_aiboost.c : -rw-r--r-- 1 constant wheel 8299 Apr 11 12:29 : -/usr/c/src/sys/dev/acpi_support/atk0110.c : > ll /boot/kernel/*aib*s* : -r-xr-xr-x 1 root wheel 11581 Apr 11 12:57 /boot/kernel/acpi_aiboost.ko : -r-xr-xr-x 1 root wheel 24504 Apr 11 12:57 : -/boot/kernel/acpi_aiboost.ko.symbols : -r-xr-xr-x 1 root wheel 9801 Apr 11 12:57 /boot/kernel/aibs.ko : -r-xr-xr-x 1 root wheel 21203 Apr 11 12:57 /boot/kernel/aibs.ko.symbols : > sysctl dev.aibs.0.{volt,temp,fan} : dev.aibs.0.volt.0: 1240 850 1600 : dev.aibs.0.volt.1: 3312 2970 3630 : dev.aibs.0.volt.2: 5017 4500 5500 : dev.aibs.0.volt.3: 12302 10200 13800 : dev.aibs.0.temp.0: 30.0C 80.0C 95.0C : dev.aibs.0.temp.1: 56.0C 60.0C 95.0C : dev.aibs.0.fan.0: 878 600 7200 : dev.aibs.0.fan.1: 0 700 7200 Cool. Warner From owner-freebsd-drivers@FreeBSD.ORG Mon Apr 12 10:27:15 2010 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39518106564A for ; Mon, 12 Apr 2010 10:27:15 +0000 (UTC) (envelope-from 380008156@qq.com) Received: from smtpbg52.qq.com (smtpbg52.qq.com [64.71.138.43]) by mx1.freebsd.org (Postfix) with SMTP id 1F1FE8FC08 for ; Mon, 12 Apr 2010 10:27:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907; t=1271068020; bh=5a+ULm9n8d/sbhb8puDeGWpj1zQqZPg/mw6n5LVf1YU=; h=X-QQ-ThreadID:X-QQ-SSF:X-Originating-IP:X-QQ-STYLE:X-QQ-mid:From: To:Sender:Subject:Mime-Version:Content-Type: Content-Transfer-Encoding:Date:X-Priority:Message-ID:X-QQ-MIME: X-Mailer:X-QQ-Mailer; b=fNbCZKQ0q3I89glzUWtkSnFoDT0Dnr61IgvhaJ5j+orSw3XH5sZ2F6GCWqbnTWtD8 hDMZ5x0rdWt453IlMq8On4q24bNS3468q+DpJdS3YAaL0KLm0Y6YVmLAweh1Jo6 X-QQ-ThreadID: s3jtAhJjR9,0 X-QQ-SSF: 000000000000006000000 X-Originating-IP: 60.176.198.96 X-QQ-STYLE: X-QQ-mid: webmail34t1271067133t3042 From: "=?ISO-8859-1?B?S0dC?=" To: "=?ISO-8859-1?B?ZnJlZWJzZC1kcml2ZXJz?=" Sender: 380008156@qq.com Mime-Version: 1.0 Date: Mon, 12 Apr 2010 18:12:13 +0800 X-Priority: 3 Message-ID: X-QQ-MIME: TCMime 1.0 by Tencent X-Mailer: QQMail 2.x X-QQ-Mailer: QQMail 2.x X-Mailman-Approved-At: Mon, 12 Apr 2010 11:19:34 +0000 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: kldunload: can't unload file: Operation not supported by device X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 10:27:15 -0000 SGkgYWxsOg0KICAgICAgSSBoYXZlIGEgcHJvYmxlbSB1c2luZyBrbGR1bmxvYWQgc3lzdGVt IGNhbGwgdG8gdW5sb2FkIG15IGRyaXZlciBtb2R1bGUuDQogICAgICANCiAgICAgIEJTRCMg a2xkc3RhdA0KICAgSWQgUmVmcyBBZGRyZXNzICAgIFNpemUgICAgIE5hbWUNCiAgICAxICAg IDYgMHhjMDQwMDAwMCA5MDY1MTggICBrZXJuZWwNCiAgICAyICAgIDEgMHhjMGQwNzAwMCA2 YTMyYyAgICBhY3BpLmtvDQogICAgMyAgICAzIDB4YzRmMGUwMDAgMzQwMDAgICAgemFwdGVs LmtvDQogICAgNCAgICAxIDB4YzRmNjUwMDAgMjAwMCAgICAgenRkdW1teS5rbw0KICAgIDUg ICAgMSAweGM0ZjY3MDAwIDkwMDAgICAgIGZ4bThhcGNpLmtvDQogICAgICAgQlNEI2tsZHVu bG9hZCBmeG04YXBjaQ0KICAgICAga2xkdW5sb2FkOiBjYW4ndCB1bmxvYWQgZmlsZTogT3Bl cmF0aW9uIG5vdCBzdXBwb3J0ZWQgYnkgZGV2aWNlDQogICAgICANCiAgICAgIElmIEkgdXNl IHRoZSBwYXJhbWV0ZXIgIi1mIiB3aXRoIGtsZHVubG9hZCAsdGhlIHJlc3VsdCBpcyBpZGVu dGljYWwuICAgDQogICAgICANCiAgICAgIENhbiBzb21lb25lIGdpdmUgbWUgYWR2aWNlPw0K ICAgICAgDQogICAgICBUaGFua3MgaW4gYWR2YW5jZS4= From owner-freebsd-drivers@FreeBSD.ORG Mon Apr 12 11:46:39 2010 Return-Path: Delivered-To: freebsd-drivers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3470106564A for ; Mon, 12 Apr 2010 11:46:39 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward3.mail.yandex.net (forward3.mail.yandex.net [77.88.46.8]) by mx1.freebsd.org (Postfix) with ESMTP id 51D6E8FC0A for ; Mon, 12 Apr 2010 11:46:39 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward3.mail.yandex.net (Yandex) with ESMTP id D8E1B56D85C3; Mon, 12 Apr 2010 15:33:41 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1271072021; bh=I5uz6IMYmGv/4FeNYHdLDLRE7N3/AXehJGXs4TcksSg=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=e3XtSPGy8lhAuW8PdcYQUb2ZxMUR3CjyHwmMZlMjpukjueOwJ1LYhnXkU/SK+z+1o 1/YfYFXhLh73ndkjmDcAhJa8e5KtaX7yIZfNI1VFRCpT9ZTvYcBbWK25Dbw9un7ChJ RUNBErNLM/koFxf78sy5a/ccEt/QQr6KpU2qMZsg= Received: from [127.0.0.1] (ns.kirov.so-ups.ru [77.72.136.145]) by smtp4.mail.yandex.net (Yandex) with ESMTPSA id 9D5291280A3; Mon, 12 Apr 2010 15:33:41 +0400 (MSD) Message-ID: <4BC30514.3090301@yandex.ru> Date: Mon, 12 Apr 2010 15:33:40 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: KGB References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1271072021 X-Yandex-Spam: 1 X-Yandex-Front: smtp4.mail.yandex.net Cc: freebsd-drivers Subject: Re: kldunload: can't unload file: Operation not supported by device X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 11:46:39 -0000 On 12.04.2010 14:12, KGB wrote: > kldunload: can't unload file: Operation not supported by device > If I use the parameter "-f" with kldunload ,the result is identical. > Can someone give me advice? Not all modules can be unloaded. See module(9). -- WBR, Andrey V. Elsukov From owner-freebsd-drivers@FreeBSD.ORG Mon Apr 12 14:29:27 2010 Return-Path: Delivered-To: freebsd-drivers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC8BF1065677 for ; Mon, 12 Apr 2010 14:29:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 93ECF8FC12 for ; Mon, 12 Apr 2010 14:29:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o3CEMsfJ004242; Mon, 12 Apr 2010 08:22:54 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 12 Apr 2010 08:23:04 -0600 (MDT) Message-Id: <20100412.082304.514512658442604308.imp@bsdimp.com> To: bu7cher@yandex.ru From: "M. Warner Losh" In-Reply-To: <4BC30514.3090301@yandex.ru> References: <4BC30514.3090301@yandex.ru> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-drivers@FreeBSD.org Subject: Re: kldunload: can't unload file: Operation not supported by device X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 14:29:28 -0000 In message: <4BC30514.3090301@yandex.ru> "Andrey V. Elsukov" writes: : On 12.04.2010 14:12, KGB wrote: : > kldunload: can't unload file: Operation not supported by device : > If I use the parameter "-f" with kldunload ,the result is identical. : > Can someone give me advice? : : Not all modules can be unloaded. See module(9). Or there's a program with the device open... But the -f flag is just a stronger hint to unload than without it. Warner From owner-freebsd-drivers@FreeBSD.ORG Thu Apr 15 14:38:26 2010 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B65CD106566C; Thu, 15 Apr 2010 14:38:26 +0000 (UTC) (envelope-from daniel.rodrick@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 89F808FC0A; Thu, 15 Apr 2010 14:38:26 +0000 (UTC) Received: by pwi9 with SMTP id 9so1175932pwi.13 for ; Thu, 15 Apr 2010 07:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=E4GoelLAQblwS/5ZeLMtrtTR1Q2UTbUEPPGFNmTMaqk=; b=QADC22lZI7RKVtdDy4T7xOYqrbriNPms//Cv7LiIYserDnH0Gx7cw7WF09d5f25b6M QfbE4yfvh5e30H/tlG0rA1oZU24B/M9cjrV2QM1+ZAqdfPzDz2KnkNY0nMYbQTa2IBBy 8FhfFU/3Tm1IRcFjZ3leVZ2WmqYvmyUSdgWbc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HD+LNdyeBNe2Je4fduT3kKpMTv1GSTmvDU55qnXRURWZRCec9QmKfLRM+EPzma41bL lFuyxorHHav4ieWcNFAdS5KG+FNSEXfjhjauyLpKzKdj+rRXExTKc4VsDg2S7UTr4NB3 JyOtLKq4jtroteOqTmNZD6Ybp2vyfw6VHgl9s= MIME-Version: 1.0 Received: by 10.142.230.18 with HTTP; Thu, 15 Apr 2010 07:38:25 -0700 (PDT) Date: Thu, 15 Apr 2010 20:08:25 +0530 Received: by 10.142.247.33 with SMTP id u33mr154860wfh.44.1271342305705; Thu, 15 Apr 2010 07:38:25 -0700 (PDT) Message-ID: From: Daniel Rodrick To: freebsd-arch@freebsd.org, freebsd-drivers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Multiple PCI controllers X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 14:38:26 -0000 Hello, Can some one please help me understand how did the old FreeBSD kernel that DID not have the PCI domains concept (say 6.x) used to deal with systems that had multiple PCI / PCIe controllers on them, from a bus numbering point of view? Was there a unified PCI tree - thus each PCI bus number being unique in the system? Also, how is this dealt with now? Dan From owner-freebsd-drivers@FreeBSD.ORG Thu Apr 15 14:58:26 2010 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 015BF106564A; Thu, 15 Apr 2010 14:58:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 802CF8FC08; Thu, 15 Apr 2010 14:58:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o3FEljvH072965; Thu, 15 Apr 2010 08:47:45 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 15 Apr 2010 08:48:00 -0600 (MDT) Message-Id: <20100415.084800.714788496340685106.imp@bsdimp.com> To: daniel.rodrick@gmail.com From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-drivers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Multiple PCI controllers X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 14:58:26 -0000 In message: Daniel Rodrick writes: : Can some one please help me understand how did the old FreeBSD kernel : that DID not have the PCI domains concept (say 6.x) used to deal with : systems that had multiple PCI / PCIe controllers on them, from a bus : numbering point of view? Was there a unified PCI tree - thus each PCI : bus number being unique in the system? FreeBSD has handled multiple PCI domains for a very long time. The support was added so that the Alpha machines could run FreeBSD. The bus numbers were whatever the BIOS programmed them to be. FreeBSD doesn't program bus numbers at all, except in some very limited cases. : Also, how is this dealt with now? The same. Each host controller will have a pci device tree under it. Warner From owner-freebsd-drivers@FreeBSD.ORG Thu Apr 15 18:30:09 2010 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4D311065674; Thu, 15 Apr 2010 18:30:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 762878FC1C; Thu, 15 Apr 2010 18:30:09 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0E83D46B81; Thu, 15 Apr 2010 14:30:09 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 5B2358A01F; Thu, 15 Apr 2010 14:30:08 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 15 Apr 2010 13:11:18 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004151311.18487.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 15 Apr 2010 14:30:08 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-drivers@freebsd.org Subject: Re: Multiple PCI controllers X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 18:30:09 -0000 On Thursday 15 April 2010 10:38:25 am Daniel Rodrick wrote: > Hello, > > Can some one please help me understand how did the old FreeBSD kernel > that DID not have the PCI domains concept (say 6.x) used to deal with > systems that had multiple PCI / PCIe controllers on them, from a bus > numbering point of view? Was there a unified PCI tree - thus each PCI > bus number being unique in the system? I think there were not multiple-domain machines that FreeBSD ran on in previous releases in general. Some alpha machines had multiple domains (the alpha port referred to them as 'hoses') and the support was incomplete (VGA cards had to be in domain 0 for FreeBSD to see them IIRC). I am not personally aware of any x86 machines with multiple domains. I believe the x86 port only supports domain 0 currently. -- John Baldwin From owner-freebsd-drivers@FreeBSD.ORG Fri Apr 16 01:54:31 2010 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 357431065670; Fri, 16 Apr 2010 01:54:31 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by mx1.freebsd.org (Postfix) with ESMTP id 4222D8FC0A; Fri, 16 Apr 2010 01:54:29 +0000 (UTC) Received: from dallas-lxp.hq.netapp.com (c-67-190-167-186.hsd1.co.comcast.net [67.190.167.186]) by dommail.onthenet.com.au (MOS 4.1.8-GA) with ESMTP id ALT72123 (AUTH peterg@ptree32.com.au); Fri, 16 Apr 2010 11:42:42 +1000 Message-ID: <4BC7C08C.2050002@freebsd.org> Date: Thu, 15 Apr 2010 19:42:36 -0600 From: Peter Grehan User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <201004151311.18487.jhb@freebsd.org> In-Reply-To: <201004151311.18487.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-drivers@freebsd.org Subject: Re: Multiple PCI controllers X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 01:54:31 -0000 > I think there were not multiple-domain machines that FreeBSD ran on in > previous releases in general. Power Macs have up to 3 PCI buses, with each one having bus number 0 at the host bridge. FreeBSD 6.* was fine with that, except if there was a conflict in bus/slot/function. Fortunately it looked like OpenFirmware was careful to avoid creating these conflicts when doing bus assignment. later, Peter. From owner-freebsd-drivers@FreeBSD.ORG Fri Apr 16 09:23:54 2010 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D41C106564A for ; Fri, 16 Apr 2010 09:23:54 +0000 (UTC) (envelope-from andre@wensing.org) Received: from mail.wensing.org (wensing.xs4all.nl [80.101.217.189]) by mx1.freebsd.org (Postfix) with ESMTP id E7E778FC13 for ; Fri, 16 Apr 2010 09:23:53 +0000 (UTC) Received: from ares.wensing.org (localhost [127.0.0.1]) by mail.wensing.org (Postfix) with ESMTP id 8DA8717253 for ; Fri, 16 Apr 2010 11:04:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at wensing.org Received: from mail.wensing.org ([127.0.0.1]) by ares.wensing.org (ares.wensing.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ucu8IyY65ZlA for ; Fri, 16 Apr 2010 11:04:29 +0200 (CEST) Received: from webmail.wensing.org (localhost [127.0.0.1]) by mail.wensing.org (Postfix) with ESMTP id 15BEB17050 for ; Fri, 16 Apr 2010 11:04:29 +0200 (CEST) Received: from 145.119.165.99 (proxying for unknown) (SquirrelMail authenticated user andre@wensing.org) by webmail.wensing.org with HTTP; Fri, 16 Apr 2010 11:04:29 +0200 Message-ID: Date: Fri, 16 Apr 2010 11:04:29 +0200 From: =?iso-8859-1?Q?Andr=E9_Wensing?= To: freebsd-drivers@freebsd.org User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Adaptec ASC-1405 (Marvell 88SE6440) X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 09:23:54 -0000 Hi, Just a quick question: Will the Adaptec ASC-1405 SAS/SATA adapter (non-RAID) ever be supported by FreeBSD? Adaptec claims support but they don't have a driver. Maybe the linux sourcecode might be used, but I have no idea if that would be possible (and I don't have any programming skills whatsoever). It is a nice card for low-cost FreeNAS-systems that don't need RAID-cards and just use software-RAID (like mine). The controller-chip that's used on this card is probably also used on other cards (don't know what other cards), so maybe that might give some clues... André Wensing