From nobody Sat May 6 01:12:20 2023 X-Original-To: freebsd-acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QCqKf3YbJz4B2hk for ; Sat, 6 May 2023 01:12:38 +0000 (UTC) (envelope-from dmitry.medvedev@gmail.com) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QCqKf13fvz46jZ for ; Sat, 6 May 2023 01:12:38 +0000 (UTC) (envelope-from dmitry.medvedev@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-6436e075166so1901834b3a.0 for ; Fri, 05 May 2023 18:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683335557; x=1685927557; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nQyWQ6PInpP5YK0WLhapiMiv5q/zr3bQkwJ9aaQkZVE=; b=GlZVKtbv5s3VRJOB9liaLouGtqlm73zaydaVO8EFBx2S1XoCI7nmnSfpBJfDTmO3/g iXPs9466AEKLN1v+PBI+GYAmk7jNCl1Pp5R6oZSZAOOCWcO2kWprS8SFD1u0mJJxQT2I hRYhFA1F7dBJmb23VgMJe/H0KX/vp3HNGI1zH1G2naRYh4PG0gYzzNhjemk4pO6OCGYV 35jim6XTFBu9pKI55gIZJk2He5tL/QCttIQAOqfhopay9FTO60AFn0in6R9qdX67hdv/ 2bi5ewSkN+q9NLwP2Yw0WSLmNYx4L1RENXKU/lJ464cOuqm77zAssKaJNGCFlkGGSFa+ Yc3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683335557; x=1685927557; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nQyWQ6PInpP5YK0WLhapiMiv5q/zr3bQkwJ9aaQkZVE=; b=I5eFU/h1PsYxxCKN0j2c4FzzFf4DxN20mXzZA4a0r45tccOxsrc91waB2v0XBp6gRV 31FzBWoSWJ+gymm85ypfeZQsGIp8C8oCHfEtZL7dg4RMTbcV1DJTsjRtOkiv/ydBGgda bHv8zLnFoeJqyFDPQUPlLY7lbkNby+jrJTqDJubjl2Bz6ppHAQWRW49Vh8yVOOU6H3eV qxjFjm/svH6gfA1GwjOZfCARnPtUIATsXz5LxTZ9Dh0wh5vg89OMZt6/PC1qCiuUi9Z3 NVD94Q4aihoOkmynIQ1Pjwx2yoM3JXDFwJhwrn/QLyzsSRhMEOxV8ePyC0MUsPPmBboy 9pcA== X-Gm-Message-State: AC+VfDxEDUjS1itSb7Al9CBlCYKWox3aNMyRMGmA+B/02QMPH30ygl7v dTBWlVn2lAhXTb5f8qLWiBCXBo/DXqNxj+1HYIc= X-Google-Smtp-Source: ACHHUZ4c7+YCjCZH6H/kNNR812jkMbcYZkNWmfAVetj2x/CV3pK1cBbPLbcqqdRcSecFY+MzEnxAFrKtV1UfhcDs/3c= X-Received: by 2002:a05:6a20:7348:b0:db:b7:fe3f with SMTP id v8-20020a056a20734800b000db00b7fe3fmr4196352pzc.10.1683335556433; Fri, 05 May 2023 18:12:36 -0700 (PDT) List-Id: ACPI and power management development List-Archive: https://lists.freebsd.org/archives/freebsd-acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: "Dmitry N. Medvedev" Date: Sat, 6 May 2023 03:12:20 +0200 Message-ID: Subject: Re: Re: Re: managing a fan speed via memory address To: Georg Lindenberg Cc: freebsd-acpi@freebsd.org Content-Type: multipart/alternative; boundary="000000000000e10e6305fafc199d" X-Rspamd-Queue-Id: 4QCqKf13fvz46jZ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000e10e6305fafc199d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable okay, it's resolved now: according to this -- https://h30434.www3.hp.com/t5/Desktop-Hardware-and-Upgrade-Questions/contro= lling-front-fan-on-Z420/m-p/8681322/highlight/true#M232123 "It is not possible to control the individual fan speeds on the Z420 motherboard. The only available setting in the BIOS is to control the system fans idle speed." On Fri, May 5, 2023 at 7:51=E2=80=AFAM Georg Lindenberg wrote: > If the fan ID is not present in acpidump, then the fan is not in the acpi > namespace, and thus it is not visible to the operating system (aka > FreeBSD). At least according to the acpi documentation. :-) > > Maybe there is a another way to access the fan (bios?), that I am not > aware of. > Good luck. > > > Gesendet: Donnerstag, den 04.05.2023 um 15:45 Uhr > > Von: "Dmitry N. Medvedev" > > An: "Georg Lindenberg" > > Cc: freebsd-acpi@freebsd.org > > Betreff: Re: Re: managing a fan speed via memory address > > > > hi Georg, > > > > it's become even more confusing -- none of the IDs from #1 exist in > > acpidump output :( > > > > researching further > > > > On Wed, May 3, 2023 at 8:02=E2=80=AFPM Georg Lindenberg > > > wrote: > > > > > > > > Hello, > > > > > > ACPI can control fans, but it is up to the hardware manufacturer (OEM= ) > to > > > implement it. > > > > > > _______________________________ > > > Step 1. Check for ACPI fan control > > > > > > The OEM needs to add a device with id "PNP0C0B" to the acpi namespace= . > > > In FreeBSD, you can test this with the command: acpidump -d -t | grep > > > PNP0C0B > > > > > > On Windows, you can download acpi tools at > > > https://acpica.org/downloads/binary-tools > > > Then use the command: acpidump.exe | findstr PNP0C0B > > > > > > Some fans use IDs which are not documented in the ACPI specification: > > > "PNP0C0B", /* Generic Fan */ \ > > > "INT3404", /* Fan */ \ > > > "INTC1044", /* Fan for Tiger Lake generation */ > > > "INTC1048", /* Fan for Alder Lake generation */ > > > "INTC1063", /* Fan for Meteor Lake generation */ > > > "INTC10A2", /* Fan for Raptor Lake generation */ > > > > > > You might want to search for these strings as well. > > > > > > __________________________ > > > Step 2. Check for version of ACPI > > > > > > Fan version is either 1.0 or 4.0. > > > > > > a) Acpi version 1.0 > > > > > > If you suceed with step 1., then you can communicate with the fan. Yo= u > can > > > turn it on and off > > > by putting it in power state D0 or D3. > > > In C, you would probably use acpi_set_powerstate(dev, ACPI_STATE_D3), > > > or maybe use acpi power methods, like _ON, _OFF, _PR3, _PR0 (haven't > > > tested it). > > > > > > Or maybe an alternative: There is a suggestion on FreeBSD acpi wiki: > > > device_power -- Add a "power" argument to devctl(8) that allows a > device > > > to be set into various low power or off states. > > > Noone has implemented that yet ("not done"). :) > > > > > > b) ACPI version 4.0 > > > > > > To check, whether your fan supports fan levels, you can do this: > > > > > > OEM _must_ provide four predefined acpi methods. They are described i= n > > > detail in the acpi > > > specification. They are called: _FIF, _FPS, _FSL, _FST > > > So just use: > > > acpidump -d -t | grep _FPS > > > and so on. If all four are present, you can use fan levels! :-) > > > > > > In your source code, it could look like this: > > > > > > ACPI_HANDLE handle; > > > ACPI_HANDLE tmp; > > > > > > /* fans are either acpi 1.0 or 4.0 compatible, so check now. */ > > > if (ACPI_SUCCESS(acpi_get_handle(handle, "_FIF", &tmp)) && > > > ACPI_SUCCESS(acpi_get_handle(handle, "_FPS", &tmp)) && > > > ACPI_SUCCESS(acpi_get_handle(handle, "_FSL", &tmp)) && > > > ACPI_SUCCESS(acpi_get_handle(handle, "_FST", &tmp))) > > > acpi_fan_initiate_acpi4(dev); > > > > > > else /* nothing to do in acpi version 1, really */ > > > acpi_fan_softc.version =3D 1; > > > > > > 3. How to set fan levels > > > > > > As a driver author, you'd need to decide how you'd want to implement > the > > > fan level. It can be done > > > via /dev/acpi (and also add code to acpiconf (8)). Or it can be done > via > > > systctls. > > > > > > So in your code, you could add a proc sysctl. There are multiple ways > to > > > implement sysctls, > > > one way could be this: > > > > > > sysctl_ctx_init(&clist); /* sysctl context */ > > > > > > struct sysctl_oid *fan_oid =3D device_get_sysctl_tree(dev); > > > SYSCTL_ADD_PROC(&clist, SYSCTL_CHILDREN(fan_oid), OID_AUTO, > > > "Fan level", CTLTYPE_INT | CTLFLAG_RW, 0, 0, > > > acpi_fan_level_sysctl, "I" ,"Fan level"); > > > > > > Or whatever code you like. > > > > > > Then you need a sysctl handler: > > > > > > static int > > > acpi_fan_level_sysctl(SYSCTL_HANDLER_ARGS) { > > > > > > ... > > > } > > > > > > In the handler function you could "handle" the fan level, and probabl= y > call > > > acpi_evaluate_object() on the _FIF, _FPS, _FSL, and _FST methods. > > > > > > Unfortunately, my laptops don't support fans at all. So I can't reall= y > > > write a fan driver. > > > I think it is a good beginners task. > > > > > > Basically, if your fan has three or four pins, it might support fan > > > levels. The first two pins are > > > used for electricity. The third pin is used to upscale or downscale t= he > > > power (voltage?), > > > thus increasing or decreasing the fan speed. There is no magic to thi= s. > > > > > > 4. Sceleton acpi driver > > > > > > If you need a sceleton acpi driver, that shouldn't be a problem. > > > FreeBSD puts all acpi drivers (modules) into the acpi subsystem > > > (sys/dev/acpica), instead > > > of giving them a separate makefile in sys/modules. > > > > > > This was my first attempt, without ever testing anything (bugs to be > > > expected): :-) > > > > > > #include "opt_acpi.h" > > > #include > > > #include > > > #include > > > > > > /* for testing, aka printf */ > > > #include > > > #include > > > > > > #include > > > #include > > > #include > > > > > > /* Hooks for the ACPI CA debugging infrastructure */ > > > #define _COMPONENT ACPI_FAN > > > ACPI_MODULE_NAME("FAN") > > > > > > /* driver software context */ > > > struct acpi_fan_softc { > > > device_t dev; > > > int version; /* either ACPI 1.0 or 4.0 */ > > > }; > > > > > > static device_method_t acpi_fan_methods[] =3D { > > > /* Device interface */ > > > DEVMETHOD(device_probe, acpi_fan_probe), > > > DEVMETHOD(device_attach, acpi_fan_attach), > > > DEVMETHOD(device_detach, acpi_fan_detach), > > > DEVMETHOD_END > > > }; > > > > > > static int > > > acpi_fan_probe(device_t dev) > > > { > > > static char *fan_ids[] =3D { \ > > > "PNP0C0B", /* Generic Fan */ \ > > > "INT3404", /* Fan */ \ > > > "INTC1044", /* Fan for Tiger Lake generation */ \ > > > "INTC1048", /* Fan for Alder Lake generation */ \ > > > "INTC1063", /* Fan for Meteor Lake generation */ \ > > > "INTC10A2", /* Fan for Raptor Lake generation */ \ > > > NULL }; > > > int rv; > > > > > > if (acpi_disabled("fan")) > > > return (ENXIO); > > > rv =3D ACPI_ID_PROBE(device_get_parent(dev), dev, fan_ids, NULL); > > > if (rv <=3D 0) > > > device_set_desc(dev, "ACPI FAN"); > > > return (rv); > > > } > > > > > > static int > > > acpi_fan_attach(device_t dev) > > > { > > > int error; > > > ACPI_HANDLE handle; > > > ACPI_HANDLE tmp; > > > struct acpi_fan_softc *sc; > > > > > > sc =3D device_get_softc(dev); > > > handle =3D acpi_get_handle(dev); > > > > > > /* fans are either acpi 1.0 or 4.0 compatible, so check now. */ > > > if (ACPI_SUCCESS(acpi_get_handle(handle, "_FIF", &tmp)) && > > > ACPI_SUCCESS(acpi_get_handle(handle, "_FPS", &tmp)) && > > > ACPI_SUCCESS(acpi_get_handle(handle, "_FSL", &tmp)) && > > > ACPI_SUCCESS(acpi_get_handle(handle, "_FST", &tmp))) > > > acpi_fan_softc.version =3D 4; > > > > > > else /* nothing to do in acpi version 1, really */ > > > acpi_fan_softc.version =3D 1; > > > > > > return 0; > > > } > > > > > > static int > > > acpi_fan_detach(device_t dev) { > > > sysctl_ctx_free(&clist); > > > return 0; > > > } > > > > > > > > > static driver_t acpi_fan_driver =3D { > > > "fan", > > > acpi_fan_methods, > > > sizeof(struct acpi_fan_softc), > > > }; > > > DRIVER_MODULE(acpi_fan, acpi, acpi_fan_driver, 0, 0); > > > MODULE_DEPEND(acpi_fan, acpi, 1, 1, 1); > > > > > > _____________________ > > > 5. How linux does it > > > > > > You can check linux fan driver on github: > > > https://github.com/torvalds/linux/tree/master/drivers/acpi > > > > > > They separate the driver into three files. > > > fan.h > > > fan_attr.c > > > fan_core.c > > > > > > It's ok to learn from linux. :-) > > > > > > > > > Sorry for long message. > > > Georg. > > > *Gesendet:* Mittwoch, 03. Mai 2023 um 02:26 Uhr > > > *Von:* "Dmitry N. Medvedev" > > > *An:* "Adrian Chadd" > > > *Cc:* freebsd-acpi@freebsd.org > > > *Betreff:* Re: managing a fan speed via memory address > > > good morning Adrian, > > > > > > 1. I am just learning :) Not 100% sure ACPI has anything to do with f= an > > > control ( still it looks that it actually does ) > > > -- found the Advanced Configuration and Power Interface Specification > PDF. > > > Will spend some time grasping the ideas > > > 2. to quickly write any driver I will have to first find out how to d= o > it > > > :) any guidance ( preferable in textual form will be greatly > appreciated ) > > > will learn it :) > > > 3. there isn't a single thermal sensor, but the SAS disks report thei= r > > > temperatures > > > ( via dmidecode if I am not mistaken, or some other program -- I will > be > > > more sure tomorrow morning ). > > > so, theoretically I could be able to read their temperature and decid= e > if > > > I would like to send more power to the fan. > > > > > > On Wed, May 3, 2023 at 2:14=E2=80=AFAM Adrian Chadd > wrote: > > > > > >> Is it not an ACPI driver? If not, you could write a quick fan driver= ! > > >> > > >> Is there a thermal sensor(s) you could read to see how warm they get= ? > > >> > > >> > > >> > > >> -adrian > > >> > > >> > > >> On Tue, 2 May 2023 at 17:06, Dmitry N. Medvedev < > > >> dmitry.medvedev@gmail.com> wrote: > > >> > > >>> good morning, > > >>> > > >>> Recently I have learned about the dmidecode program and found the > > >>> address of the FRNTFAN port in my HP Z420 machine: 0x0037. > > >>> Since I am a complete newbie, I would like to learn if there is a > way to > > >>> read and change the value at this address. > > >>> I need a bit of guidance. > > >>> > > >>> *The context*: I have added 8 SAS disks to the machine, put noctua > fan > > >>> in front of them and connected the fan to the FRNTFAN port on the > > >>> motherboard. > > >>> It looks like the fan works, but I am sure the disks would benefit = if > > >>> the fan produced more pressure. Which I fantasize I could do via > changing > > >>> the value at the said address. > > >>> Not sure, of course. > > >>> > > >>> best regards, > > >>> Dmitry N. Medvedev > > >>> > > >> > --000000000000e10e6305fafc199d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
okay, it's resolved now:

=

"It is not possible to control the individual fan = speeds on the Z420 motherboard. The only available setting in the BIOS is t= o control the system fans idle speed."



On Fri, May 5, 2023 at 7:51=E2=80=AFAM Georg Lindenberg <georg.lindenberg@web.de> wrote:
<= /div>
If the fan ID is not= present in acpidump, then the fan is not in the acpi namespace, and thus i= t is not visible to the operating system (aka FreeBSD). At least according = to the acpi documentation. :-)

Maybe there is a another way to access the fan (bios?), that I am not aware= of.
Good luck.

> Gesendet: Donnerstag, den 04.05.2023 um 15:45 Uhr
> Von: "Dmitry N. Medvedev" <dmitry.medvedev@gmail.com>
> An: "Georg Lindenberg" <georg.lindenberg@web.de>
> Cc: free= bsd-acpi@freebsd.org
> Betreff: Re: Re: managing a fan speed via memory address
>
> hi Georg,
>
> it's become even more confusing -- none of the IDs from #1 exist i= n
> acpidump output :(
>
> researching further
>
> On Wed, May 3, 2023 at 8:02=E2=80=AFPM Georg Lindenberg <georg.lindenberg@web.de<= /a>>
> wrote:
>
> >
> > Hello,
> >
> > ACPI can control fans, but it is up to the hardware manufacturer = (OEM) to
> > implement it.
> >
> > _______________________________
> > Step 1. Check for ACPI fan control
> >
> > The OEM needs to add a device with id "PNP0C0B" to the = acpi namespace.
> > In FreeBSD, you can test this with the command: acpidump -d -t | = grep
> > PNP0C0B
> >
> > On Windows, you can download acpi tools at
> > https://acpica.org/downloads/binary-tools
> > Then use the command: acpidump.exe | findstr PNP0C0B
> >
> > Some fans use IDs which are not documented in the ACPI specificat= ion:
> >=C2=A0 =C2=A0 =C2=A0"PNP0C0B",=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/* Generic Fan */ \
> >=C2=A0 =C2=A0 =C2=A0"INT3404",=C2=A0 =C2=A0 =C2=A0 =C2= =A0 /* Fan */ \
> >=C2=A0 =C2=A0 =C2=A0"INTC1044",=C2=A0 =C2=A0 =C2=A0 =C2= =A0 /* Fan for Tiger Lake generation */
> >=C2=A0 =C2=A0 =C2=A0"INTC1048",=C2=A0 =C2=A0 =C2=A0/* Fa= n for Alder Lake generation */
> >=C2=A0 =C2=A0 =C2=A0"INTC1063",=C2=A0 =C2=A0 /* Fan for = Meteor Lake generation */
> >=C2=A0 =C2=A0 =C2=A0"INTC10A2",=C2=A0 =C2=A0 /* Fan for = Raptor Lake generation */
> >
> > You might want to search for these strings as well.
> >
> > __________________________
> > Step 2. Check for version of ACPI
> >
> > Fan version is either 1.0 or 4.0.
> >
> > a) Acpi version 1.0
> >
> > If you suceed with step 1., then you can communicate with the fan= . You can
> > turn it on and off
> > by putting it in power state D0 or D3.
> > In C, you would probably use acpi_set_powerstate(dev, ACPI_STATE_= D3),
> > or maybe use acpi power methods, like _ON, _OFF, _PR3, _PR0 (have= n't
> > tested it).
> >
> > Or maybe an alternative: There is a suggestion on FreeBSD acpi wi= ki:
> > device_power -- Add a "power" argument to devctl(8) tha= t allows a device
> > to be set into various low power or off states.
> > Noone has implemented that yet ("not done"). :)
> >
> > b) ACPI version 4.0
> >
> > To check, whether your fan supports fan levels, you can do this:<= br> > >
> > OEM _must_ provide four predefined acpi methods. They are describ= ed in
> > detail in the acpi
> > specification. They are called: _FIF, _FPS, _FSL, _FST
> > So just use:
> > acpidump -d -t | grep _FPS
> > and so on. If all four are present, you can use fan levels! :-) > >
> > In your source code, it could look like this:
> >
> >=C2=A0 =C2=A0 =C2=A0ACPI_HANDLE=C2=A0 =C2=A0 handle;
> >=C2=A0 =C2=A0 =C2=A0ACPI_HANDLE tmp;
> >
> >=C2=A0 =C2=A0 =C2=A0/* fans are either acpi 1.0 or 4.0 compatible,= so check now. */
> >=C2=A0 =C2=A0 =C2=A0 if (ACPI_SUCCESS(acpi_get_handle(handle, &quo= t;_FIF", &tmp)) &&
> >=C2=A0 =C2=A0 =C2=A0ACPI_SUCCESS(acpi_get_handle(handle, "_FP= S", &tmp)) &&
> >=C2=A0 =C2=A0 =C2=A0ACPI_SUCCESS(acpi_get_handle(handle, "_FS= L", &tmp)) &&
> >=C2=A0 =C2=A0 =C2=A0ACPI_SUCCESS(acpi_get_handle(handle, "_FS= T", &tmp)))
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acpi_fan_initiate_acpi4(dev); > >
> >=C2=A0 =C2=A0 =C2=A0else=C2=A0 =C2=A0 /* nothing to do in acpi ver= sion 1, really */
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acpi_fan_softc.version =3D 1; > >
> > 3. How to set fan levels
> >
> > As a driver author, you'd need to decide how you'd want t= o implement the
> > fan level. It can be done
> > via /dev/acpi (and also add code to acpiconf (8)). Or it can be d= one via
> > systctls.
> >
> > So in your code, you could add a proc sysctl. There are multiple = ways to
> > implement sysctls,
> > one way could be this:
> >
> >=C2=A0 =C2=A0 =C2=A0sysctl_ctx_init(&clist);=C2=A0 =C2=A0 =C2= =A0 =C2=A0 /* sysctl context */
> >
> >=C2=A0 =C2=A0 =C2=A0struct sysctl_oid *fan_oid =3D device_get_sysc= tl_tree(dev);
> >=C2=A0 =C2=A0 =C2=A0SYSCTL_ADD_PROC(&clist, SYSCTL_CHILDREN(fa= n_oid), OID_AUTO,
> >=C2=A0 =C2=A0 =C2=A0"Fan level", CTLTYPE_INT | CTLFLAG_R= W, 0, 0,
> >=C2=A0 =C2=A0 =C2=A0acpi_fan_level_sysctl, "I" ,"Fa= n level");
> >
> > Or whatever code you like.
> >
> > Then you need a sysctl handler:
> >
> > static int
> > acpi_fan_level_sysctl(SYSCTL_HANDLER_ARGS) {
> >
> > ...
> > }
> >
> > In the handler function you could "handle" the fan leve= l, and probably call
> > acpi_evaluate_object() on the _FIF, _FPS, _FSL, and _FST methods.=
> >
> > Unfortunately, my laptops don't support fans at all. So I can= 't really
> > write a fan driver.
> > I think it is a good beginners task.
> >
> > Basically, if your fan has three or four pins, it might support f= an
> > levels. The first two pins are
> > used for electricity. The third pin is used to upscale or downsca= le the
> > power (voltage?),
> > thus increasing or decreasing the fan speed. There is no magic to= this.
> >
> > 4. Sceleton acpi driver
> >
> > If you need a sceleton acpi driver, that shouldn't be a probl= em.
> > FreeBSD puts all acpi drivers (modules) into the acpi subsystem > > (sys/dev/acpica), instead
> > of giving them a separate makefile in sys/modules.
> >
> > This was my first attempt, without ever testing anything (bugs to= be
> > expected): :-)
> >
> > #include "opt_acpi.h"
> > #include <sys/param.h>
> > #include <sys/kernel.h>
> > #include <sys/module.h>
> >
> > /* for testing, aka printf */
> > #include <sys/types.h>
> > #include <sys/systm.h>
> >
> > #include <contrib/dev/acpica/include/acpi.h>
> > #include <dev/acpica/acpivar.h>
> > #include <dev/acpica/acpiio.h>
> >
> > /* Hooks for the ACPI CA debugging infrastructure */
> > #define=C2=A0 =C2=A0 _COMPONENT=C2=A0 =C2=A0 ACPI_FAN
> > ACPI_MODULE_NAME("FAN")
> >
> > /* driver software context */
> > struct acpi_fan_softc {
> >=C2=A0 =C2=A0 =C2=A0device_t=C2=A0 =C2=A0 dev;
> >=C2=A0 =C2=A0 =C2=A0int=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v= ersion;=C2=A0 =C2=A0 /* either ACPI 1.0 or 4.0 */
> > };
> >
> > static device_method_t acpi_fan_methods[] =3D {
> >=C2=A0 =C2=A0 =C2=A0/* Device interface */
> >=C2=A0 =C2=A0 =C2=A0DEVMETHOD(device_probe,=C2=A0 =C2=A0 =C2=A0 = =C2=A0 acpi_fan_probe),
> >=C2=A0 =C2=A0 =C2=A0DEVMETHOD(device_attach,=C2=A0 =C2=A0 acpi_fan= _attach),
> >=C2=A0 =C2=A0 =C2=A0DEVMETHOD(device_detach,=C2=A0 =C2=A0 acpi_fan= _detach),
> >=C2=A0 =C2=A0 =C2=A0DEVMETHOD_END
> > };
> >
> > static int
> > acpi_fan_probe(device_t dev)
> > {
> >=C2=A0 =C2=A0 =C2=A0static char *fan_ids[] =3D { \
> >=C2=A0 =C2=A0 =C2=A0"PNP0C0B",=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/* Generic Fan */ \
> >=C2=A0 =C2=A0 =C2=A0"INT3404",=C2=A0 =C2=A0 =C2=A0 =C2= =A0 /* Fan */ \
> >=C2=A0 =C2=A0 =C2=A0"INTC1044",=C2=A0 =C2=A0 =C2=A0 =C2= =A0 /* Fan for Tiger Lake generation */ \
> >=C2=A0 =C2=A0 =C2=A0"INTC1048",=C2=A0 =C2=A0 =C2=A0/* Fa= n for Alder Lake generation */ \
> >=C2=A0 =C2=A0 =C2=A0"INTC1063",=C2=A0 =C2=A0 =C2=A0/* Fa= n for Meteor Lake generation */ \
> >=C2=A0 =C2=A0 =C2=A0"INTC10A2",=C2=A0 =C2=A0 =C2=A0/* Fa= n for Raptor Lake generation */ \
> >=C2=A0 =C2=A0 =C2=A0NULL };
> >=C2=A0 =C2=A0 =C2=A0int rv;
> >
> >=C2=A0 =C2=A0 =C2=A0if (acpi_disabled("fan"))
> >=C2=A0 =C2=A0 =C2=A0return (ENXIO);
> >=C2=A0 =C2=A0 =C2=A0rv =3D ACPI_ID_PROBE(device_get_parent(dev), d= ev, fan_ids, NULL);
> >=C2=A0 =C2=A0 =C2=A0if (rv <=3D 0)
> >=C2=A0 =C2=A0 =C2=A0device_set_desc(dev, "ACPI FAN"); > >=C2=A0 =C2=A0 =C2=A0return (rv);
> > }
> >
> > static int
> > acpi_fan_attach(device_t dev)
> > {
> >=C2=A0 =C2=A0 =C2=A0int=C2=A0 =C2=A0 error;
> >=C2=A0 =C2=A0 =C2=A0ACPI_HANDLE=C2=A0 =C2=A0 handle;
> >=C2=A0 =C2=A0 =C2=A0ACPI_HANDLE tmp;
> >=C2=A0 =C2=A0 =C2=A0struct acpi_fan_softc *sc;
> >
> >=C2=A0 =C2=A0 =C2=A0sc =3D device_get_softc(dev);
> >=C2=A0 =C2=A0 =C2=A0handle =3D acpi_get_handle(dev);
> >
> >=C2=A0 =C2=A0 =C2=A0/* fans are either acpi 1.0 or 4.0 compatible,= so check now. */
> >=C2=A0 =C2=A0 =C2=A0if (ACPI_SUCCESS(acpi_get_handle(handle, "= ;_FIF", &tmp)) &&
> >=C2=A0 =C2=A0 =C2=A0ACPI_SUCCESS(acpi_get_handle(handle, "_FP= S", &tmp)) &&
> >=C2=A0 =C2=A0 =C2=A0ACPI_SUCCESS(acpi_get_handle(handle, "_FS= L", &tmp)) &&
> >=C2=A0 =C2=A0 =C2=A0ACPI_SUCCESS(acpi_get_handle(handle, "_FS= T", &tmp)))
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acpi_fan_softc.version =3D 4; > >
> >=C2=A0 =C2=A0 =C2=A0else=C2=A0 =C2=A0 /* nothing to do in acpi ver= sion 1, really */
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acpi_fan_softc.version =3D 1; > >
> >=C2=A0 =C2=A0return 0;
> > }
> >
> > static int
> > acpi_fan_detach(device_t dev) {
> >=C2=A0 =C2=A0 =C2=A0sysctl_ctx_free(&clist);
> >=C2=A0 =C2=A0 =C2=A0return 0;
> > }
> >
> >
> > static driver_t acpi_fan_driver =3D {
> >=C2=A0 =C2=A0 =C2=A0"fan",
> >=C2=A0 =C2=A0 =C2=A0acpi_fan_methods,
> >=C2=A0 =C2=A0 =C2=A0sizeof(struct acpi_fan_softc),
> > };
> > DRIVER_MODULE(acpi_fan, acpi, acpi_fan_driver, 0, 0);
> > MODULE_DEPEND(acpi_fan, acpi, 1, 1, 1);
> >
> > _____________________
> > 5. How linux does it
> >
> > You can check linux fan driver on github:
> > https://github.com/torvalds/linu= x/tree/master/drivers/acpi
> >
> > They separate the driver into three files.
> > fan.h
> > fan_attr.c
> > fan_core.c
> >
> > It's ok to learn from linux. :-)
> >
> >
> > Sorry for long message.
> > Georg.
> > *Gesendet:* Mittwoch, 03. Mai 2023 um 02:26 Uhr
> > *Von:* "Dmitry N. Medvedev" <dmitry.medvedev@gmail.com> > > *An:* "Adrian Chadd" <adrian@freebsd.org>
> > *Cc:* freebsd-acpi@freebsd.org
> > *Betreff:* Re: managing a fan speed via memory address
> > good morning Adrian,
> >
> > 1. I am just learning :) Not 100% sure ACPI has anything to do wi= th fan
> > control ( still it looks that it actually does )
> > -- found the Advanced Configuration and Power Interface Specifica= tion PDF.
> > Will spend some time grasping the ideas
> > 2. to quickly write any driver I will have to first find out how = to do it
> > :) any guidance ( preferable in textual form will be greatly appr= eciated )
> > will learn it :)
> > 3. there isn't a single thermal sensor, but the SAS disks rep= ort their
> > temperatures
> > ( via dmidecode if I am not mistaken, or some other program -- I = will be
> > more sure tomorrow morning ).
> > so, theoretically I could be able to read their temperature and d= ecide if
> > I would like to send more power to the fan.
> >
> > On Wed, May 3, 2023 at 2:14=E2=80=AFAM Adrian Chadd <adrian@freebsd.org>= wrote:
> >
> >> Is it not an ACPI driver? If not, you could write a quick fan= driver!
> >>
> >> Is there a thermal sensor(s) you could read to see how warm t= hey get?
> >>
> >>
> >>
> >> -adrian
> >>
> >>
> >> On Tue, 2 May 2023 at 17:06, Dmitry N. Medvedev <
> >> dmitry.medvedev@gmail.com> wrote:
> >>
> >>> good morning,
> >>>
> >>> Recently I have learned about the dmidecode program and f= ound the
> >>> address of the FRNTFAN port in my HP Z420 machine: 0x0037= .
> >>> Since I am a complete newbie, I would like to learn if th= ere is a way to
> >>> read and change the value at this address.
> >>> I need a bit of guidance.
> >>>
> >>> *The context*: I have added 8 SAS disks to the machine, p= ut noctua fan
> >>> in front of them and connected the fan to the FRNTFAN por= t on the
> >>> motherboard.
> >>> It looks like the fan works, but I am sure the disks woul= d benefit if
> >>> the fan produced more pressure. Which I fantasize I could= do via changing
> >>> the value at the said address.
> >>> Not sure, of course.
> >>>
> >>> best regards,
> >>> Dmitry N. Medvedev
> >>>
> >>
--000000000000e10e6305fafc199d-- From nobody Sat Jun 24 13:30:05 2023 X-Original-To: acpi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QpFMx6yK8z4gRLg for ; Sat, 24 Jun 2023 13:30:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QpFMx3QZrz3xFt for ; Sat, 24 Jun 2023 13:30:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1687613405; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=S9AOCD6G8ALvpPupa/XmONCmfQhuTsYvqKpW9VIDjEk=; b=qpfUvBmEUeSWKeVsWPnqmMrGNk/TE3wx25UQ3wmA0y2fkE8QhjT60yyoQJ9m7qETLW6aFg 2Owys9kRS9WeMZ8aEPxbSDUmnFJunrWqJe+m9BSrG0tAVWZ8Ys5kf5DlsP6PoduxUqns1X 86YyPYNkFQINMl6KF5UnpL/QLNnwWZkJ4B4+T+M+oJN1NowU4JRg0nM0zg3rYR/8/dlR6w wWZYUh+uOyIaXuUSfDzHDZJaLHB2MWzL4uE3tCl+Jblzo1vmrocoFEVoux2pt3hHjta96J V/Kw0BvdxFprtRChtKinPhT7SRSboht3suETrkeV+rayrG0j01PSHseO+KxnYw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1687613405; a=rsa-sha256; cv=none; b=ADBRoZNa3mwIgJWgVlHKd58bZT15AvVEtu4Vd/xG17PLrZv2hfFrMz+SguwbpnzpiaQEkp KHg6nadnCGLq/eP0OLG+UjNqY0vPoJaUhCHinrcC47XbS44L9WelMofmh+q5irdZKGzGxa +SUr6AD+i3UPC5z6W5IkfZldJIdl0ip3VgG4ZOmGz9HN9Aj+spGZOLw206kWyaZh8xaw3O TeklN42VB8mVQE4ONW1ybENknsy+xVIDZVmwXEHbYNf5DYlGysqW3n4KEXO7ymArfkaMSM glVMeDf7EXgvUNLl97ZfiMMH61GJMbqtcZMR3V7l9BkTQlha7YyuYMuKEvljZA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QpFMx2RCLznm5 for ; Sat, 24 Jun 2023 13:30:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 35ODU5dn023158 for ; Sat, 24 Jun 2023 13:30:05 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 35ODU5vM023157 for acpi@FreeBSD.org; Sat, 24 Jun 2023 13:30:05 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: acpi@FreeBSD.org Subject: [Bug 122887] atkbdc(4): FreeBSD 7.0-RELEASE on IBM HS20 panics immediately when switching VGA port at BladeCenter Date: Sat, 24 Jun 2023 13:30:05 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: i386 X-Bugzilla-Version: 7.0-RELEASE X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: grahamperrin@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: grahamperrin@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution assigned_to bug_status cc short_desc priority Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: ACPI and power management development List-Archive: https://lists.freebsd.org/archives/freebsd-acpi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-acpi@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D122887 Graham Perrin changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Overcome By Events Assignee|acpi@FreeBSD.org |grahamperrin@freebsd.org Status|Open |Closed CC| |acpi@FreeBSD.org Summary|[panic] [atkbdc] |atkbdc(4): FreeBSD |7.0-RELEASE on IBM HS20 |7.0-RELEASE on IBM HS20 |panics immediately when |panics immediately when |switching VGA port at |switching VGA port at |BladeCenter |BladeCenter Priority|Normal |--- --- Comment #12 from Graham Perrin --- (In reply to Eitan Adler from comment #10) Let's assume that this bug was overcome by events; and comment 9 notes that= the linked backtrace no longer exists. --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.=