From nobody Sun Apr 9 21:10:14 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 4Pvl9y4Mwzz44GHb for ; Sun, 9 Apr 2023 21:10:14 +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 4Pvl9x6wPCz3Klx for ; Sun, 9 Apr 2023 21:10:13 +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=1681074614; 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=zkiwmU5hsN7gewKIgnTL8TxoP7/GXzEECcVz3FnY/9I=; b=k13jMCv5Yt764k3O0xILrTeGtOtc5T3rctApkhDTjp6AvjE+WCDOTdNihePd93RQ5yafr7 oyfsZvMRF/LdjZDISKN64vvOX0U1qdXam1ZytgVx/zj27/w/LIkeEZ2QQlROUnnwtiVqDh wDrswVaIvLgFZukahp8CItco80pyUFktcmQWKVB2yJlC9rwDv2IRW5qZ9g+Ix/Ctbp/EVK gcQkruuyMfFx3wRl3y7gkuEqU3TMDigLbVZaIc+hy3QuFkvA2R1GeEoOKlBmLAUYo7Nwix BANrTlbLI1KttDKQehsdBhXti/Q5A7l+daybbiwjDYcAqFU77w4CvqtWtEJUPQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681074614; a=rsa-sha256; cv=none; b=JMcdVYUNLDw4JTIrZuygxlP8WftEaiGFgac5IgxtP0HnSJV3GlTvl4ytYfFhdvil4Jcr34 ZV+NjRt/cDTkzC1GddkisUudFwHv//XICrEoLWlVsuZNGCjCeTYI2IhjujaSzj1SLs/Jq1 JTysGmIJpfM0kj6G04cN8wop8GRcXl8R9o9RTdeDAExvKdRnu0Zw2mSc7fdszmDJuO17cr NjpeuVz/xeDJbCj+/EZgF7d4E1/xThWzzIHvtbqmVAng7JbyMnNZbhmLt+53ye0Z9Av+Ep NRqZTLAsZv15h2jpMUjv2V//F3AX/lrjsC7z1dUtSj589OCFnOapJVcTDGipDA== 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 4Pvl9x5smrzP0l for ; Sun, 9 Apr 2023 21:10:13 +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 339LADlF094981 for ; Sun, 9 Apr 2023 21:10:13 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 339LADTh094980 for acpi@FreeBSD.org; Sun, 9 Apr 2023 21:10:13 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 264775] [PATCH] acpi_thermal: passive cooling only throttles cpu0 Date: Sun, 09 Apr 2023 21:10:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.2-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rkoberman@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: acpi@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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=3D264775 --- Comment #11 from rkoberman@gmail.com --- I'll apply this patch and see how it does but the issue I saw, which led to many over-temp warnings with fan speed remaining low has stopped being an i= ssue since the kernel was modified to allow all 12 threads to run without panick= ing. Typically, when not busy, the performance CPUs are running at a slightly lo= wer temperature than the others, but all seem to adjust up and down as they sho= uld and I have not seen a temperature alert since 2022-11-20. Of course, my problem may not be the same as yours. I'm running HEAD and tr= y to update it every 2 or 3 weeks. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed May 3 00:06:02 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 4Q9y0b05vXz48MSs for ; Wed, 3 May 2023 00:06:23 +0000 (UTC) (envelope-from dmitry.medvedev@gmail.com) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 4Q9y0X0x9Kz3jbC for ; Wed, 3 May 2023 00:06:20 +0000 (UTC) (envelope-from dmitry.medvedev@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=YCK8hIPM; spf=pass (mx1.freebsd.org: domain of dmitry.medvedev@gmail.com designates 2607:f8b0:4864:20::636 as permitted sender) smtp.mailfrom=dmitry.medvedev@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-1aafa03f541so28404145ad.0 for ; Tue, 02 May 2023 17:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683072378; x=1685664378; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Vu2c9c13cS5mY80+IgEoYuX4o2Aw6WY6msIIJO52gT8=; b=YCK8hIPMiYUd8bo+DUqRzBxvE06N8Oc1PlCqW04uXvuW36/kB6eTZ9P681U6Ajhn1s D1YihSmR9lYmZ+/ep8BcXMJwJBbe28RMDjCUJig0uV/HJzvN4agYThUCGJX1lbDhPiXr E1n3Mmqt82qbEXUcmw648ZKiqskpL5ZqoSONkgeFKdg+Kzr/EV/7aUmIxg0igdbMi3CL uHWxAEyb/Wu6jHsZml6nTI6PzAsRaZZtrw2DpkUU0DkVrte38Qn4gmL9QSODZDzLw1pJ seeR0R57NdnQ458OgbnWzZCdG1O0vthEgU8+cjtMrd4KU40HUCnxsi2X1BRDqBK61JRh V3ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683072378; x=1685664378; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Vu2c9c13cS5mY80+IgEoYuX4o2Aw6WY6msIIJO52gT8=; b=l+elnI1xJKyC6Isr0oZp+8808tUgFW/PNmeh70LLTOqzP1TNn4GIbpmHobQkmk0f9w 1HDjR57NOXzFntPNkqU95fs0rBIH4gOIEB3qUR5YnqyCQljI3Cin3M5ue7mSrThXSDtQ LoBQy17pK4XLQBye0akCjIYnq03P+sPNajF5t3Zo6ZcK7rETYxiP7T0MXpEyhoeanBz8 NtYhPESPJGiHpay8+iAzZ68MUHLIEd9pAfHOnsyhXt2wvd3VAWbUA3/6lw/OAZtIj3CU qxTKSbcskQflIIwt7fsuDzT2tiwa34o95wYLma3ZWzGvULwlDkjgDcQUTjHpJqS+IB5R 2d+A== X-Gm-Message-State: AC+VfDxJxbMqHix6aFts3V3rtu0jrd3mO3syJHqkU8szS/5vl3XQp0gg QPJFbxf5pYpzsqq2FWZjMtkytMXFs0OCDnNUQ8o2BjWLE7Dx8g== X-Google-Smtp-Source: ACHHUZ6ydGkVpaTPHMREnqR/UjIomqde00ekw4jZaHIH7mVHGY/yr2R6o9rF0DqDdkHTgvHSFcULk2qRyMFF2V27RzE= X-Received: by 2002:a17:902:d511:b0:1a8:1b63:8aee with SMTP id b17-20020a170902d51100b001a81b638aeemr290842plg.46.1683072378372; Tue, 02 May 2023 17:06:18 -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 From: "Dmitry N. Medvedev" Date: Wed, 3 May 2023 02:06:02 +0200 Message-ID: Subject: managing a fan speed via memory address To: freebsd-acpi@freebsd.org Content-Type: multipart/alternative; boundary="0000000000003e894505fabed359" X-Spamd-Result: default: False [-3.88 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.88)[-0.884]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-acpi@freebsd.org]; BLOCKLISTDE_FAIL(0.00)[2607:f8b0:4864:20::636:server fail]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::636:from]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-acpi@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Q9y0X0x9Kz3jbC X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --0000000000003e894505fabed359 Content-Type: text/plain; charset="UTF-8" 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 --0000000000003e894505fabed359 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
good m= orning,

Recently I have learned about the dmidecode prog= ram 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 S= AS disks to the machine, put noctua fan in front of them and connected the = fan to the FRNTFAN=C2=A0port on the motherboard.
It looks like th= e 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 regar= ds,
D= mitry N. Medvedev
--0000000000003e894505fabed359-- From nobody Wed May 3 00:14:34 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 4Q9yBP66jTz48MXw for ; Wed, 3 May 2023 00:14:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (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 4Q9yBN6zncz3kKB for ; Wed, 3 May 2023 00:14:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of adrian.chadd@gmail.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=adrian.chadd@gmail.com; dmarc=none Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2a8c51ba511so44286191fa.1 for ; Tue, 02 May 2023 17:14:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683072891; x=1685664891; 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=I6ytRCHS2CosqQHTybechdGjvpKLRu/VYKTKqqwqFAA=; b=QgpNUQHHWXhGgPTixEZMPcYfAPdx3M1smlymNbTB1S4wN9J4/bJCO0HkbzD6rs3M0/ T1pPCAqepCmXnQCVireJEcpgyUeHezzW/1WoWm1NJgVSKKPcVXLhj2WpibHxBQkqHLrB gzQsTRzESnde2ks0ENF8vG6NKwx1H4FKjg0pIrEKxJRXA47Z4EheK9PZSFZM3O5YefTx 45qwi4SBC546vtHwxP2H9gs0lMGFqd4uZccTm8y5rRfeuiTuP8j3jj15184iKkoFTz7k 8IlAAwVD8gf4YLqy92dTAp1JOLSNafQ3tPaiJc9tbZLVcyH3W3/fZkrouYDeIWThLDub BEuw== X-Gm-Message-State: AC+VfDyQg0mAl2YTzYa2XKLjZNvotehuKhKmVzq5rl2kwz6cRJlW1eKb hnVBGXqPiYVjMMCZM3AcQMAKoTPY6IUIioDf2ds= X-Google-Smtp-Source: ACHHUZ7iEsrkruhtwjdsfvMmFkiALQ+tmaSrJmgClOfTAggbApxqwEgW7SHoW98V3VQMImGdQGllBG8m5QjY3pPqPNo= X-Received: by 2002:a2e:3804:0:b0:2aa:3bda:9aba with SMTP id f4-20020a2e3804000000b002aa3bda9abamr5089527lja.42.1683072890616; Tue, 02 May 2023 17:14:50 -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: Adrian Chadd Date: Tue, 2 May 2023 17:14:34 -0700 Message-ID: Subject: Re: managing a fan speed via memory address To: "Dmitry N. Medvedev" Cc: freebsd-acpi@freebsd.org Content-Type: multipart/alternative; boundary="000000000000c6bffa05fabef185" X-Spamd-Result: default: False [-0.76 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.86)[0.865]; NEURAL_HAM_MEDIUM(-0.63)[-0.626]; FORGED_SENDER(0.30)[adrian@freebsd.org,adrianchadd@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-acpi@freebsd.org]; RCVD_TLS_LAST(0.00)[]; TAGGED_RCPT(0.00)[]; DMARC_NA(0.00)[freebsd.org]; BLOCKLISTDE_FAIL(0.00)[209.85.208.179:server fail]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-acpi@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.179:from]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCPT_COUNT_TWO(0.00)[2]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.179:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_NEQ_ENVFROM(0.00)[adrian@freebsd.org,adrianchadd@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TAGGED_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Q9yBN6zncz3kKB X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N --000000000000c6bffa05fabef185 Content-Type: text/plain; charset="UTF-8" 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 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 > --000000000000c6bffa05fabef185 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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. Me= dvedev <dmitry.medvedev@gma= il.com> wrote:
good morning,

Recently I have learned abou= t 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 the= m and connected the fan to the FRNTFAN=C2=A0port on the motherboard.
<= div>It looks like the fan works, but I am sure the disks would benefit if t= he fan produced more pressure. Which I fantasize I could do via changing th= e value at the said address.
Not sure, of course.

<= /div>
best regards,
Dmitry N. Medvedev
--000000000000c6bffa05fabef185-- From nobody Wed May 3 00:26:02 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 4Q9yRf1yPjz48NHG for ; Wed, 3 May 2023 00:26:22 +0000 (UTC) (envelope-from dmitry.medvedev@gmail.com) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 4Q9yRd4wdGz3l55; Wed, 3 May 2023 00:26:21 +0000 (UTC) (envelope-from dmitry.medvedev@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x533.google.com with SMTP id 41be03b00d2f7-52c30fa5271so1398548a12.0; Tue, 02 May 2023 17:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683073579; x=1685665579; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nuUvkttjojbwX8mHfwXjdYxblMQj3VTtpyuSvfc3rOA=; b=HMmxSJ5rjedju6gYz2bdzCIoqp4dJgCQb75LXjYhgwCCiad0AC37wa5Wqx2rNbwVOc Q8xJSBySsgdReWOA3TqZ6fcEQCm8UhSx5/xvjKir2YDG5CvDrfnTdKObRGsn99AS457Q v7fjRjAt2WWt/KiN8a5PDx9FqkGmjILzAQ3IS3EVvZq/wLTwn/IYdDStUW1+pXxqvbWt 5IqUqv+wlNLwzVut+b9H6/x4msl7X5medwVscdCKx/pqXFl9KBOtxKgR0r0HAhA6+P/4 xqoCxm/q7Og8BejBZzm1dWUNJv82gpcsZVz8qCxax/YZICwHd/2rRPhRX9m2zldQOEk3 0org== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683073579; x=1685665579; 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=nuUvkttjojbwX8mHfwXjdYxblMQj3VTtpyuSvfc3rOA=; b=CQHyDcbfIWGoef3UMLAcAgkGJwWiIAFWhME2YuSPvGMqPN+6QELpJwrt+hY+KtFZ7J VGbYSbwFFPy5X0QijHZsfTnXVAwVQcSvwiW/d8M2rrg1GIWMVav3SIcWwQ88UTR5msl4 AhQZGc2LNOmbH4+gjBTzS1Fp2gN1SyrvrUuO1qUyq++iJuW043RFEBymKG2MWb85Kyvr zo3aGLWxkNVTGyZEABp1axyfUgn94f3jcAxrjSVhLrB0I1rWkEbqpASsHPNcfuv7f8AU KeHgDg6XmkKV2sHk4Xn5+YujVBVarxIXQUh1u/uFwe57ss7XT4+A7jeopyuFd7F3cNZd e2Wg== X-Gm-Message-State: AC+VfDxZvJYulStBtECeDetsORobQc7ALMd/C/DOmeCou4Cn4CdblScV zJfvy+yyT2vZue5m6KVXSnlg8dyW2s8tT9LgLNCNR/a4xMk= X-Google-Smtp-Source: ACHHUZ6DhGQkbb4z3x8NonOJaH34zsJ+sRma8MBigB15B7LSpzBH94PH2pCjo3LqIr273X51CbYMZDd0h2WEZXbqTU8= X-Received: by 2002:a17:90b:80f:b0:24e:4c8:3ae5 with SMTP id bk15-20020a17090b080f00b0024e04c83ae5mr8867391pjb.28.1683073578697; Tue, 02 May 2023 17:26:18 -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: Wed, 3 May 2023 02:26:02 +0200 Message-ID: Subject: Re: managing a fan speed via memory address To: Adrian Chadd Cc: freebsd-acpi@freebsd.org Content-Type: multipart/alternative; boundary="000000000000ca094605fabf1af5" X-Rspamd-Queue-Id: 4Q9yRd4wdGz3l55 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000ca094605fabf1af5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable good morning Adrian, 1. I am just learning :) Not 100% sure ACPI has anything to do with fan 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 do 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 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 decide if I would like to send more power to the fan. On Wed, May 3, 2023 at 2:14=E2=80=AFAM Adrian Chadd wr= ote: > 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 > wrote: > >> good morning, >> >> Recently I have learned about the dmidecode program and found the addres= s >> 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 th= e >> fan produced more pressure. Which I fantasize I could do via changing th= e >> value at the said address. >> Not sure, of course. >> >> best regards, >> Dmitry N. Medvedev >> > --000000000000ca094605fabf1af5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
good morning Adrian,

1. I am just learn= ing :) Not 100% sure ACPI has anything to do with fan control ( still it lo= oks that it actually does )
-- found the Advanced Configuration a= nd Power Interface Specification PDF. Will spend some time grasping the ide= as
2. to quickly write any driver=C2=A0I will have to first find = out how to do it :) any=C2=A0guidance ( preferable in textual form will be = greatly appreciated ) will learn it :)
3. there isn't a singl= e thermal sensor, but the SAS disks report their temperatures
( v= ia dmidecode if I am not mistaken, or some other program -- I will be more = sure tomorrow morning ).
so, theoretically I could be able to rea= d their temperature and decide if I would like to send more power to the fa= n.

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 they get?



-adrian


On Tue, 2 May 2023 at 17:06, Dmitry N. Medvedev <dmitry.medvedev@gmail.com&g= t; wrote:
good morning,

Recently I have learned about the dmidec= ode 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 ne= ed a bit of guidance.

The context: I have a= dded 8 SAS disks to the machine, put noctua fan in front of them and connec= ted the fan to the FRNTFAN=C2=A0port on the motherboard.
It looks= like the fan works, but I am sure the disks would benefit if the fan produ= ced more pressure. Which I fantasize I could do via changing the value at t= he said address.
Not sure, of course.

be= st regards,
Dmitry N. Medvedev
--000000000000ca094605fabf1af5-- From nobody Wed May 3 18:02:25 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 4QBPtG06qZz495yP for ; Wed, 3 May 2023 18:02:30 +0000 (UTC) (envelope-from georg.lindenberg@web.de) Received: from mout.web.de (mout.web.de [212.227.15.14]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.web.de", Issuer "Telekom Security ServerID OV Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QBPtD4zCTz3GYj for ; Wed, 3 May 2023 18:02:28 +0000 (UTC) (envelope-from georg.lindenberg@web.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=web.de header.s=s29768273 header.b=bJ4qHIal; spf=pass (mx1.freebsd.org: domain of georg.lindenberg@web.de designates 212.227.15.14 as permitted sender) smtp.mailfrom=georg.lindenberg@web.de; dmarc=pass (policy=none) header.from=web.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1683136945; i=georg.lindenberg@web.de; bh=LIrjfJ6rvwHIN5mCW2B1qS6zx9ITVkRjmkkfpKkAfdA=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=bJ4qHIal3MgrmgJQeSZru1pQlsUaHLkMNGnDzH1X6lbMEzvmu9rxemP/+3nGOPNPN DZ5BuJi6xuLDL37jHd4M3YQxlkYpHgROUjOtp7NGo6LqdmNlcB26yQidGi/YArTVBH kQ8VLZBgPxsBh90GqeBYdzKeKgMzAScOzr0CQLQCGR3+rAAKqzJbwRvn4a1R8OQx3z 4PWNVH3BdOKXt3xXBXxiVYDpjjk6xAJYKFsN4pzd9gVoQFzWqJHUA6kCK5fYAvDz00 mKUFoQt5cYzH7XPwGeXXgjvOorx5Asid8uMZ9wsFR9WlTmLvEdG8mi4khVBIsm3KA1 A7+aeZMQC2hWQ== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Received: from [217.72.213.59] ([217.72.213.59]) by web-mail.web.de (3c-app-webde-bs51.server.lan [172.19.170.107]) (via HTTP); Wed, 3 May 2023 20:02:25 +0200 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 Message-ID: From: Georg Lindenberg To: "Dmitry N. Medvedev" Cc: freebsd-acpi@freebsd.org Subject: Aw: Re: managing a fan speed via memory address Content-Type: text/html; charset=UTF-8 Date: Wed, 3 May 2023 20:02:25 +0200 Importance: normal Sensitivity: Normal In-Reply-To: References: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:tXaCWBiUcVIRhz3K/oLm4yBP23rJ4KT2nEyMjTvETmRt480fhRrxm2YnmxZ3SJwHIR1qi cUInHTvpid7Gp/hi//FUMXLxCuVNBxyittPjyF4sIN2kXQT5JhSwG7/uwIk0pj8XYqhZyc9PMH+N 3UrDTq3dsCpXJvspXqjW5yrrL2WkoDdTc+xGqI8QGExx2uBd3wzVhf59X/Z7Xe4zah6wDdRrTzS5 /zwgc2QXUxMnBHkNNFlkJKoWRyJRY8gbVaQvuuFnP2cBthsL6PTMUc0UnLAGsFRSdl3sVzLwxFPx a4= X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:ALPPiGZsLxI=;RX/i6NskOHZihfzSep4KCkoQQ5Z +MIdrEfvRZCtePS1k8MCl6wpCtxrVpZ8ASUOfOvmRjw6nwyikr83CaroFgfNFhR6oT60IZC5S hIHSIJNPBpCsC7qSXkff/UsBMsMoHDlpCjW2OPFBgrd+tQzsOZfqalWUwqT0tE3YqkrjR1PKR brpXp/twOizVJYQuBT7kYSMeC5udmiQ/N1q4NHjt0ZhhdXm7h0kw9q27UgigT7ejutRB6WU1z O3a3ngwdqzBYhEcAtfpLfguNAo/yYY/ZX92z+/Y6UPDdnMEd1SJhmQMxBIAvWWuQW+jy7lyd9 d7eoWzRcGJqAYJWAclZNt3pq93LEerdWasfLxrSesuiPlsxgzEKq+rQQVxEQj1144SkL/0Cb3 +9xiqLuLUDoLsaHGulJEKhTnWJb7yu14Zy+/EL1LLybUkmv1pOZodM3PikVdaeFii4PpN3YPT +MXYqQ9JuDjJLcmfVUl8/7++U712BHfzREk38nCx10HYR//Esh+3Y2NgcgoOgUIx71SvxRxZ+ xwJ9GKIATd/vS4MGdj8Z4Yyi51qqrflyVTapYeMq+CYkrg0uQkaifDr/JpT+gYr3stHtrGiEb 4bx+tK/luk+RVnXVasAez5EDm1cPo+QT+N14wKvqhDhTXmEpgjQUh5gCilPv+IFuJtRa1sgek n58eIK8nNatwq7hjDQSehm3Ak4Ch1oUuV0gXOf19wSVSbrYeGFeEoV5c4i2D3XEzRwhV5YwvC sBtnEp9Q3izA8vp2hM1BWXWMFWP1DfCubV/ZnnLNLx8qlwhP5cksZ6b+//0nJqM31a2e6Di1Z RXuwLGIQVEz0Rd8bltyaU/2RXBWJLtNn9M3lnrQ4ewyzM= X-Spamd-Result: default: False [-2.73 / 15.00]; DWL_DNSWL_LOW(-1.00)[web.de:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.57)[0.570]; DMARC_POLICY_ALLOW(-0.50)[web.de,none]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[web.de:s=s29768273]; MIME_HTML_ONLY(0.20)[]; R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.14:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.14:from]; MLMMJ_DEST(0.00)[freebsd-acpi@freebsd.org]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; DKIM_TRACE(0.00)[web.de:+]; FREEMAIL_FROM(0.00)[web.de]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[web.de]; MIME_TRACE(0.00)[0:~]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QBPtD4zCTz3GYj X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N
 
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. 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 (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 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:
 
    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 = 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 = 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 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 fan levels. The first two pins are
used for electricity. The third pin is used to upscale or downscale 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 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 <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    _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[] = {
    /* 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[] = { \
    "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 = ACPI_ID_PROBE(device_get_parent(dev), dev, fan_ids, NULL);
    if (rv <= 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 = device_get_softc(dev);
    handle = 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 = 4;
    
    else    /* nothing to do in acpi version 1, really */
        acpi_fan_softc.version = 1;
 
  return 0;
}
 
static int
acpi_fan_detach(device_t dev) {
    sysctl_ctx_free(&clist);
    return 0;
}
 

static driver_t acpi_fan_driver = {
    "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" <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 with fan 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 do 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 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 decide if I would like to send more power to the fan.
 
On Wed, May 3, 2023 at 2:14 AM 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 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
From nobody Thu May 4 00:27:04 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 4QBZQM1hzgz49RLW for ; Thu, 4 May 2023 00:27:23 +0000 (UTC) (envelope-from dmitry.medvedev@gmail.com) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 4QBZQL1hWDz4GSm for ; Thu, 4 May 2023 00:27:22 +0000 (UTC) (envelope-from dmitry.medvedev@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x431.google.com with SMTP id d2e1a72fcca58-64115e652eeso8928037b3a.0 for ; Wed, 03 May 2023 17:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683160041; x=1685752041; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=a8iGHQptZZ9N4LK+EigAlcE61ijxYIx4seCSJYB3Th0=; b=PzXz3Kbdfq3CfVYbyOXOmdxg58/ogJwR88BAEfkRSMiugDbgQJFRzS6D3f8bUHu6iI OJrmcJYs+vtHta/gCOLpaoFOWz9YZ3MDWKOu/LMdcm4YVna8XGJGiuWqHGVTjTEKk6Oa +qB4mxjl0quU/MLL/xZ49srKfxLYebQ1Scno/7rHEfNGqu4Tl8JMHiy7zo/OcLeCR5qM ZnfbRWdsEshqKZ35J4u+Z3h9IMR+MDc3Fw0BFIgWTAmxFrkMtahsdltwJNH5QgQ8qTkp DDfb+mVZ8W2ke5TklTCvn6MN19dZMBlfw8K/XwoZBLdQRo50BQuwca2BbDpehhXWVr7j V3Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683160041; x=1685752041; 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=a8iGHQptZZ9N4LK+EigAlcE61ijxYIx4seCSJYB3Th0=; b=Dnvp2JeIsRIzCREFVsPeWQyz9xcMKUzR4EX7sqflGWrcSz0Ua3mATmcW6+R2E/XVJ6 dgZiMcgu+W3jW9Bdb5f2lHnSvXDGZiqqwAENn/XnTfXdUjY8ZbgSZDEPt4iCaw9LFGcx XzhDOijU2X32wdMKnIQfBVi7VF2gNZg6uC1O36UUvoYUq/5b/WsZyUY8lqYok669juws mURqu1BZoCGgWLUFLslCGy0R5vD4SvCvupO34OS7mCAVosuBZTn0pPhujC6UExRRd6cK iUzDEkKDbU3TCwDxWXTiJ8xSavR5CeHM5CIbIpSoFtMzAz45LTClh+5EyFI2T5SoEAP9 Wu5g== X-Gm-Message-State: AC+VfDzJtyR+V1U9vm6RbGRsOBW4w8itvRoYUexKvjD9q6WO5LW9qiNo KcbOpThFykcZM+TN3TrEmtvrNb6ar6e0AwisdeM= X-Google-Smtp-Source: ACHHUZ6ymCIelis7KbFylGybG7TqKPmQ8+z1jTJUkkkY+wcMn4FLDa581n3RSyMucO2iR+fmt1Cm3nqX56N44BKg+io= X-Received: by 2002:a17:90a:3807:b0:246:9c75:351a with SMTP id w7-20020a17090a380700b002469c75351amr156694pjb.12.1683160040547; Wed, 03 May 2023 17:27:20 -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: Thu, 4 May 2023 02:27:04 +0200 Message-ID: Subject: Re: Re: managing a fan speed via memory address To: Georg Lindenberg Cc: freebsd-acpi@freebsd.org Content-Type: multipart/alternative; boundary="000000000000512a4e05fad33cb5" X-Rspamd-Queue-Id: 4QBZQL1hWDz4GSm X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000512a4e05fad33cb5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable oh!.. will do! much appreciated, Georg! 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. You ca= n > 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 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: > > 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 probably ca= ll > 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 fan > levels. The first two pins are > used for electricity. The third pin is used to upscale or downscale 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 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 fan > 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 do 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 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 decide 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 t= o >>> 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 changi= ng >>> the value at the said address. >>> Not sure, of course. >>> >>> best regards, >>> Dmitry N. Medvedev >>> >> --000000000000512a4e05fad33cb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
oh!.. will do! much appreciated, Georg!

On Wed, May 3, 2023= at 8:02=E2=80=AFPM Georg Lindenberg <georg.lindenberg@web.de> wrote:
=C2=A0
Hello,
=C2=A0
ACPI can control fans, but it is up to the hardware manufacturer (OEM)= to implement it.
=C2=A0
_______________________________
Step 1. Check for ACPI fan control
=C2=A0
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
=C2=A0
On Windows, you can download acpi tools at https://acpica.org/downloads/b= inary-tools
Then use the command: acpidump.exe | findstr PNP0C0B
=C2=A0
Some fans use IDs which are not documented in the ACPI specification:<= /div>
=C2=A0=C2=A0=C2=A0 "PNP0C0B", =C2=A0=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=C2=A0 /* = Fan */ \
=C2=A0=C2=A0 =C2=A0"INTC1044", =C2=A0 =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 /* Fan for Alde= r Lake generation */
=C2=A0=C2=A0 =C2=A0"INTC1063", =C2=A0=C2=A0 /* Fan for Meteor Lak= e generation */
=C2=A0=C2=A0 =C2=A0"INTC10A2", =C2=A0=C2=A0 /* Fan for Raptor Lak= e generation */
=C2=A0
You might want to search for these strings as well.
=C2=A0
__________________________
Step 2. Check for version of ACPI
=C2=A0
Fan version is either 1.0 or 4.0.
=C2=A0
a) Acpi version 1.0
=C2=A0
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),<= /div>
or maybe use acpi power methods, like _ON, _OFF, _PR3, _PR0 (haven'= ;t tested it).
=C2=A0
Or maybe an alternative: There is a suggestion on FreeBSD acpi wiki:
device_power -- Add a "power" argument to devctl(8) that all= ows a device to be set into various low power or off states.
Noone has implemented that yet ("not done"). :)
=C2=A0
b) ACPI version 4.0
=C2=A0
To check, whether your fan supports fan levels, you can do this:
=C2=A0
OEM _must_ provide four predefined acpi methods. They are described 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! :-)
=C2=A0
In your source code, it could look like this:
=C2=A0
=C2=A0=C2=A0=C2=A0 ACPI_HANDLE=C2=A0=C2=A0 =C2=A0handle;
=C2=A0=C2=A0 =C2=A0ACPI_HANDLE tmp;
=C2=A0
=C2=A0=C2=A0=C2=A0 /* fans are either acpi 1.0 or 4.0 compatible, so c= heck now. */
=C2=A0=C2=A0=C2=A0 =C2=A0if (ACPI_SUCCESS(acpi_get_handle(handle, "_FI= F", &tmp)) &&
=C2=A0=C2=A0 =C2=A0ACPI_SUCCESS(acpi_get_handle(handle, "_FPS", &= amp;tmp)) &&
=C2=A0=C2=A0 =C2=A0ACPI_SUCCESS(acpi_get_handle(handle, "_FSL", &= amp;tmp)) &&
=C2=A0=C2=A0 =C2=A0ACPI_SUCCESS(acpi_get_handle(handle, "_FST", &= amp;tmp))) =C2=A0=C2=A0
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0acpi_fan_initiate_acpi4(dev);
=C2=A0
=C2=A0=C2=A0=C2=A0 else=C2=A0=C2=A0 =C2=A0/* nothing to do in acpi ver= sion 1, really */
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0acpi_fan_softc.version =3D 1;
=C2=A0
3. How to set fan levels
=C2=A0
As a driver author, you'd need to decide how you'd want to imp= lement the fan level. It can be done
via /dev/acpi (and also add code to acpiconf (8)). Or it can be done v= ia systctls.
=C2=A0
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=A0=C2=A0 sysctl_ctx_init(&clist);=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0 =C2=A0/* sysctl context */

=C2=A0=C2=A0 =C2=A0struct sysctl_oid *fan_oid =3D device_get_sysctl_tree(de= v);
=C2=A0=C2=A0 =C2=A0SYSCTL_ADD_PROC(&clist, SYSCTL_CHILDREN(fan_oid), OI= D_AUTO,
=C2=A0=C2=A0 =C2=A0"Fan level", CTLTYPE_INT | CTLFLAG_RW, 0, 0, =C2=A0=C2=A0 =C2=A0acpi_fan_level_sysctl, "I" ,"Fan level&qu= ot;);
=C2=A0
Or whatever code you like.
=C2=A0
Then you need a sysctl handler:
=C2=A0
static int
acpi_fan_level_sysctl(SYSCTL_HANDLER_ARGS) {
=C2=A0
...
}
=C2=A0
In the handler function you could "handle" the fan level, an= d probably call
acpi_evaluate_object() on the _FIF, _FPS, _FSL, and _FST methods.
=C2=A0
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.
=C2=A0
Basically, if your fan has three or four pins, it might support fan le= vels. The first two pins are
used for electricity. The third pin is used to upscale or downscale th= e power (voltage?),
thus increasing or decreasing the fan speed. There is no magic to this= .
=C2=A0
4. Sceleton acpi driver
=C2=A0
If you need a sceleton acpi driver, that shouldn't be a problem.
FreeBSD puts all acpi drivers (modules) into the acpi subsystem (sys/d= ev/acpica), instead
of giving them a separate makefile in sys/modules.
=C2=A0
This was my first attempt, without ever testing anything (bugs to be e= xpected): :-)
=C2=A0
#include "opt_acpi.h"
#include <sys/param.h>
#include <sys/kernel.h>
#include <sys/module.h>
=C2=A0
/* for testing, aka printf */
#include <sys/types.h>
#include <sys/systm.h>
=C2=A0
#include <contrib/dev/acpica/include/acpi.h>
#include <dev/acpica/acpivar.h>
#include <dev/acpica/acpiio.h>
=C2=A0
/* Hooks for the ACPI CA debugging infrastructure */
#define=C2=A0=C2=A0 =C2=A0_COMPONENT=C2=A0=C2=A0 =C2=A0ACPI_FAN
ACPI_MODULE_NAME("FAN")
=C2=A0
/* driver software context */
struct acpi_fan_softc {
=C2=A0=C2=A0 =C2=A0device_t=C2=A0=C2=A0 =C2=A0dev;
=C2=A0=C2=A0 =C2=A0int=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0version;=C2=A0=C2=A0 =C2=A0/* either ACPI 1.0 or 4.0 */
};
=C2=A0
static device_method_t acpi_fan_methods[] =3D {
=C2=A0=C2=A0=C2=A0 /* Device interface */
=C2=A0=C2=A0=C2=A0 DEVMETHOD(device_probe,=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0acpi_fan_probe),
=C2=A0=C2=A0=C2=A0 DEVMETHOD(device_attach,=C2=A0=C2=A0 =C2=A0acpi_fan_atta= ch),
=C2=A0=C2=A0=C2=A0 DEVMETHOD(device_detach,=C2=A0=C2=A0 =C2=A0acpi_fan_deta= ch),
=C2=A0=C2=A0=C2=A0 DEVMETHOD_END
};
=C2=A0
static int
acpi_fan_probe(device_t dev)
{
=C2=A0=C2=A0=C2=A0 static char *fan_ids[] =3D { \
=C2=A0=C2=A0 =C2=A0"PNP0C0B", =C2=A0=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=C2=A0 =C2= =A0/* Fan */ \
=C2=A0=C2=A0 =C2=A0"INTC1044",=C2=A0=C2=A0 =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/* Fan for Alde= r Lake generation */ \
=C2=A0=C2=A0 =C2=A0"INTC1063", =C2=A0=C2=A0 =C2=A0/* Fan for Mete= or Lake generation */ \
=C2=A0=C2=A0 =C2=A0"INTC10A2", =C2=A0=C2=A0 =C2=A0/* Fan for Rapt= or Lake generation */ \
=C2=A0=C2=A0 =C2=A0NULL };
=C2=A0=C2=A0=C2=A0 int rv;
=C2=A0=C2=A0 =C2=A0
=C2=A0=C2=A0=C2=A0 if (acpi_disabled("fan"))
=C2=A0=C2=A0 =C2=A0return (ENXIO);
=C2=A0=C2=A0=C2=A0 rv =3D ACPI_ID_PROBE(device_get_parent(dev), dev, fan_id= s, NULL);
=C2=A0=C2=A0=C2=A0 if (rv <=3D 0)
=C2=A0=C2=A0 =C2=A0device_set_desc(dev, "ACPI FAN");
=C2=A0=C2=A0=C2=A0 return (rv);
}
=C2=A0
static int
acpi_fan_attach(device_t dev)
{
=C2=A0=C2=A0 =C2=A0int=C2=A0=C2=A0 =C2=A0error;
=C2=A0=C2=A0 =C2=A0ACPI_HANDLE=C2=A0=C2=A0 =C2=A0handle;
=C2=A0=C2=A0 =C2=A0ACPI_HANDLE tmp;
=C2=A0=C2=A0 =C2=A0struct acpi_fan_softc *sc;
=C2=A0=C2=A0 =C2=A0
=C2=A0=C2=A0=C2=A0 sc =3D device_get_softc(dev);
=C2=A0=C2=A0=C2=A0 handle =3D acpi_get_handle(dev);
=C2=A0
=C2=A0=C2=A0 =C2=A0/* fans are either acpi 1.0 or 4.0 compatible, so c= heck 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, "_FPS", &= amp;tmp)) &&
=C2=A0=C2=A0 =C2=A0ACPI_SUCCESS(acpi_get_handle(handle, "_FSL", &= amp;tmp)) &&
=C2=A0=C2=A0 =C2=A0ACPI_SUCCESS(acpi_get_handle(handle, "_FST", &= amp;tmp)))=C2=A0=C2=A0 =C2=A0
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 acpi_fan_softc.version =3D 4;
=C2=A0=C2=A0 =C2=A0
=C2=A0=C2=A0 =C2=A0else=C2=A0=C2=A0 =C2=A0/* nothing to do in acpi version = 1, really */
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0acpi_fan_softc.version =3D 1;
=C2=A0
=C2=A0 return 0;
}
=C2=A0
static int
acpi_fan_detach(device_t dev) {
=C2=A0=C2=A0 =C2=A0sysctl_ctx_free(&clist);
=C2=A0=C2=A0 =C2=A0return 0;
}
=C2=A0

static driver_t acpi_fan_driver =3D {
=C2=A0=C2=A0=C2=A0 "fan",
=C2=A0=C2=A0=C2=A0 acpi_fan_methods,
=C2=A0=C2=A0=C2=A0 sizeof(struct acpi_fan_softc),
};
DRIVER_MODULE(acpi_fan, acpi, acpi_fan_driver, 0, 0);
MODULE_DEPEND(acpi_fan, acpi, 1, 1, 1);
=C2=A0
_____________________
5. How linux does it
=C2=A0
You can check linux fan driver on github:
=C2=A0
They separate the driver into three files.
fan.h
fan_attr.c
fan_core.c
=C2=A0
It's ok to learn from linux. :-)
=C2=A0
=C2=A0
Sorry for long message.
Georg.
Gesendet:=C2=A0Mittwoch, 03. Mai = 2023 um 02:26 Uhr
Von:=C2=A0"Dmitry N. Medvedev" <dmitry.medvedev@gmail.com> An:=C2=A0"Adrian Chadd" <adrian@freebsd.org>
Cc:=C2=A0freebsd-acpi@freebsd.org
Betreff:=C2=A0Re: managing a fan speed via memory address
good morning Adrian,
=C2=A0
1. I am just learning :) Not 100% sure ACPI has anything to do with fa= n 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=C2=A0I will have to first find out how = to do it :) any=C2=A0guidance ( preferable in textual form will be greatly = appreciated ) will learn it :)
3. there isn't a single thermal sensor, but the SAS disks report t= heir 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 decide= if I would like to send more power to the fan.
=C2=A0
On Wed, May 3, 2023 at 2:14=E2=80=AFAM Adrian Cha= dd <adrian@freeb= sd.org> wrote:
Is it not an ACPI driver? If not, you could write a quick fan driver!
=C2=A0
Is there a thermal sensor(s) you could read to see how warm they get?<= /div>
=C2=A0
=C2=A0
=C2=A0
-adrian
=C2=A0
=C2=A0
On Tue, 2 May 2023 at 17:06, Dmitry N. Medvedev &= lt;dmitry.me= dvedev@gmail.com> wrote:
good morning,
=C2=A0
Recently I have learned about the dmidecode program and found the addr= ess 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.
=C2=A0
The context: I have added 8 SAS disks to the machine, put noctu= a fan in front of them and connected the fan to the FRNTFAN=C2=A0port on th= e 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 t= he value at the said address.
Not sure, of course.
=C2=A0
best regards,
Dmitry N. Medvedev
--000000000000512a4e05fad33cb5-- From nobody Thu May 4 13:45:22 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 4QBw7V57Xpz497cS for ; Thu, 4 May 2023 13:45:42 +0000 (UTC) (envelope-from dmitry.medvedev@gmail.com) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 4QBw7T4rf1z4lMb for ; Thu, 4 May 2023 13:45:41 +0000 (UTC) (envelope-from dmitry.medvedev@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x52a.google.com with SMTP id 41be03b00d2f7-517bdd9957dso296290a12.1 for ; Thu, 04 May 2023 06:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683207939; x=1685799939; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1JhP488UgI1G3HgIY4eAOfP/bAdzVprqShpGPm2LdcA=; b=ZXwvXnRWwHoPksU56C/VSE8FPw5GQgrDpOBAG+aosc8CX2GuYCm8yk6heVcg6AZQsR 3IxFcESof84lz1CltXtN36UaoU2Y25IljV0voAuOeMQ21njHU1DGpjoRSUi/qCgcSP1i r4lhP9F6wb2NdpSiwhjFwtLPG5wr/qOOn7B6WVqFYXzswKQH8cK7ZiacodRiPgeGIXE0 Nbp35J21eSwx/bT4Lu/Gyaw0kCYrKR4pl/RB9x+sEqK4rz/XKTrM1w6prMQBxTMDs6C6 oXYTVp28hlW32SaInAUu2YxHAgeuZeV6MnKyLHe4V1uxqI36N0FLQzE+tCE3kOYEQ+QK 6TuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683207939; x=1685799939; 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=1JhP488UgI1G3HgIY4eAOfP/bAdzVprqShpGPm2LdcA=; b=is/mQr9Vwl78nvVNXxAHdwswlgiLy7fZWF/cpbR1gnnppU1F8VLR+37WT1bsu4fAHW IrJDNzyEoWHqN9+/+T3Eyv7KxMwu9BUAgjEiX+3a/8Q153TTt78JOQiALO4stgCcoJE9 D3yVGJ7q8sxk+ljwwdx1LEw7i0y1Nlk7rG3YVePBsxNqd6Dynp5BZg8hpMqbNLiCP0kx trA5CDAZTcUuIr7yeV1LDAn+Cv0KqjlzViQecxomaRst4tilT9vvHvEEpg7ThBE2rd9M XTqMJ2KM5WwDHFt8NlfWy9RVn7yjYP1ckueOf4P0m53JFb2T8zZR+rkqp1AJMFUQdTwd uY5g== X-Gm-Message-State: AC+VfDwuSbmcmxFnZOIQ/y/cUFQxvFk3qXsh28TQQ4i4M59Btk9Nlccx mEFMRsPuXWe78eT8UROfyYxl+MZJGLVcdLp9zrznJm2D X-Google-Smtp-Source: ACHHUZ4RPhsotIXGPirAkkB0h9YKFq++3NXl/oVRPm9yy/xgs0In6w7rtERYG4Rkm4PQO/YaNRCTNRL9niW15x22nMs= X-Received: by 2002:a17:90b:4a01:b0:237:62f7:3106 with SMTP id kk1-20020a17090b4a0100b0023762f73106mr2236385pjb.17.1683207938957; Thu, 04 May 2023 06:45:38 -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: Thu, 4 May 2023 15:45:22 +0200 Message-ID: Subject: Re: Re: managing a fan speed via memory address To: Georg Lindenberg Cc: freebsd-acpi@freebsd.org Content-Type: multipart/alternative; boundary="00000000000048e5e805fade63ed" X-Rspamd-Queue-Id: 4QBw7T4rf1z4lMb X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000048e5e805fade63ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. You ca= n > 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 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: > > 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 probably ca= ll > 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 fan > levels. The first two pins are > used for electricity. The third pin is used to upscale or downscale 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 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 fan > 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 do 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 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 decide 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 t= o >>> 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 changi= ng >>> the value at the said address. >>> Not sure, of course. >>> >>> best regards, >>> Dmitry N. Medvedev >>> >> --00000000000048e5e805fade63ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hi Georg,

it's become ev= en 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 <georg.lindenberg@web.de> wrote:
=C2=A0
Hello,
=C2=A0
ACPI can control fans, but it is up to the hardware manufacturer (OEM)= to implement it.
=C2=A0
_______________________________
Step 1. Check for ACPI fan control
=C2=A0
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
=C2=A0
On Windows, you can download acpi tools at https://acpica.org/downloads/b= inary-tools
Then use the command: acpidump.exe | findstr PNP0C0B
=C2=A0
Some fans use IDs which are not documented in the ACPI specification:<= /div>
=C2=A0=C2=A0=C2=A0 "PNP0C0B", =C2=A0=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=C2=A0 /* = Fan */ \
=C2=A0=C2=A0 =C2=A0"INTC1044", =C2=A0 =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 /* Fan for Alde= r Lake generation */
=C2=A0=C2=A0 =C2=A0"INTC1063", =C2=A0=C2=A0 /* Fan for Meteor Lak= e generation */
=C2=A0=C2=A0 =C2=A0"INTC10A2", =C2=A0=C2=A0 /* Fan for Raptor Lak= e generation */
=C2=A0
You might want to search for these strings as well.
=C2=A0
__________________________
Step 2. Check for version of ACPI
=C2=A0
Fan version is either 1.0 or 4.0.
=C2=A0
a) Acpi version 1.0
=C2=A0
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),<= /div>
or maybe use acpi power methods, like _ON, _OFF, _PR3, _PR0 (haven'= ;t tested it).
=C2=A0
Or maybe an alternative: There is a suggestion on FreeBSD acpi wiki:
device_power -- Add a "power" argument to devctl(8) that all= ows a device to be set into various low power or off states.
Noone has implemented that yet ("not done"). :)
=C2=A0
b) ACPI version 4.0
=C2=A0
To check, whether your fan supports fan levels, you can do this:
=C2=A0
OEM _must_ provide four predefined acpi methods. They are described 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! :-)
=C2=A0
In your source code, it could look like this:
=C2=A0
=C2=A0=C2=A0=C2=A0 ACPI_HANDLE=C2=A0=C2=A0 =C2=A0handle;
=C2=A0=C2=A0 =C2=A0ACPI_HANDLE tmp;
=C2=A0
=C2=A0=C2=A0=C2=A0 /* fans are either acpi 1.0 or 4.0 compatible, so c= heck now. */
=C2=A0=C2=A0=C2=A0 =C2=A0if (ACPI_SUCCESS(acpi_get_handle(handle, "_FI= F", &tmp)) &&
=C2=A0=C2=A0 =C2=A0ACPI_SUCCESS(acpi_get_handle(handle, "_FPS", &= amp;tmp)) &&
=C2=A0=C2=A0 =C2=A0ACPI_SUCCESS(acpi_get_handle(handle, "_FSL", &= amp;tmp)) &&
=C2=A0=C2=A0 =C2=A0ACPI_SUCCESS(acpi_get_handle(handle, "_FST", &= amp;tmp))) =C2=A0=C2=A0
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0acpi_fan_initiate_acpi4(dev);
=C2=A0
=C2=A0=C2=A0=C2=A0 else=C2=A0=C2=A0 =C2=A0/* nothing to do in acpi ver= sion 1, really */
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0acpi_fan_softc.version =3D 1;
=C2=A0
3. How to set fan levels
=C2=A0
As a driver author, you'd need to decide how you'd want to imp= lement the fan level. It can be done
via /dev/acpi (and also add code to acpiconf (8)). Or it can be done v= ia systctls.
=C2=A0
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=A0=C2=A0 sysctl_ctx_init(&clist);=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0 =C2=A0/* sysctl context */

=C2=A0=C2=A0 =C2=A0struct sysctl_oid *fan_oid =3D device_get_sysctl_tree(de= v);
=C2=A0=C2=A0 =C2=A0SYSCTL_ADD_PROC(&clist, SYSCTL_CHILDREN(fan_oid), OI= D_AUTO,
=C2=A0=C2=A0 =C2=A0"Fan level", CTLTYPE_INT | CTLFLAG_RW, 0, 0, =C2=A0=C2=A0 =C2=A0acpi_fan_level_sysctl, "I" ,"Fan level&qu= ot;);
=C2=A0
Or whatever code you like.
=C2=A0
Then you need a sysctl handler:
=C2=A0
static int
acpi_fan_level_sysctl(SYSCTL_HANDLER_ARGS) {
=C2=A0
...
}
=C2=A0
In the handler function you could "handle" the fan level, an= d probably call
acpi_evaluate_object() on the _FIF, _FPS, _FSL, and _FST methods.
=C2=A0
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.
=C2=A0
Basically, if your fan has three or four pins, it might support fan le= vels. The first two pins are
used for electricity. The third pin is used to upscale or downscale th= e power (voltage?),
thus increasing or decreasing the fan speed. There is no magic to this= .
=C2=A0
4. Sceleton acpi driver
=C2=A0
If you need a sceleton acpi driver, that shouldn't be a problem.
FreeBSD puts all acpi drivers (modules) into the acpi subsystem (sys/d= ev/acpica), instead
of giving them a separate makefile in sys/modules.
=C2=A0
This was my first attempt, without ever testing anything (bugs to be e= xpected): :-)
=C2=A0
#include "opt_acpi.h"
#include <sys/param.h>
#include <sys/kernel.h>
#include <sys/module.h>
=C2=A0
/* for testing, aka printf */
#include <sys/types.h>
#include <sys/systm.h>
=C2=A0
#include <contrib/dev/acpica/include/acpi.h>
#include <dev/acpica/acpivar.h>
#include <dev/acpica/acpiio.h>
=C2=A0
/* Hooks for the ACPI CA debugging infrastructure */
#define=C2=A0=C2=A0 =C2=A0_COMPONENT=C2=A0=C2=A0 =C2=A0ACPI_FAN
ACPI_MODULE_NAME("FAN")
=C2=A0
/* driver software context */
struct acpi_fan_softc {
=C2=A0=C2=A0 =C2=A0device_t=C2=A0=C2=A0 =C2=A0dev;
=C2=A0=C2=A0 =C2=A0int=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0version;=C2=A0=C2=A0 =C2=A0/* either ACPI 1.0 or 4.0 */
};
=C2=A0
static device_method_t acpi_fan_methods[] =3D {
=C2=A0=C2=A0=C2=A0 /* Device interface */
=C2=A0=C2=A0=C2=A0 DEVMETHOD(device_probe,=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0acpi_fan_probe),
=C2=A0=C2=A0=C2=A0 DEVMETHOD(device_attach,=C2=A0=C2=A0 =C2=A0acpi_fan_atta= ch),
=C2=A0=C2=A0=C2=A0 DEVMETHOD(device_detach,=C2=A0=C2=A0 =C2=A0acpi_fan_deta= ch),
=C2=A0=C2=A0=C2=A0 DEVMETHOD_END
};
=C2=A0
static int
acpi_fan_probe(device_t dev)
{
=C2=A0=C2=A0=C2=A0 static char *fan_ids[] =3D { \
=C2=A0=C2=A0 =C2=A0"PNP0C0B", =C2=A0=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=C2=A0 =C2= =A0/* Fan */ \
=C2=A0=C2=A0 =C2=A0"INTC1044",=C2=A0=C2=A0 =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/* Fan for Alde= r Lake generation */ \
=C2=A0=C2=A0 =C2=A0"INTC1063", =C2=A0=C2=A0 =C2=A0/* Fan for Mete= or Lake generation */ \
=C2=A0=C2=A0 =C2=A0"INTC10A2", =C2=A0=C2=A0 =C2=A0/* Fan for Rapt= or Lake generation */ \
=C2=A0=C2=A0 =C2=A0NULL };
=C2=A0=C2=A0=C2=A0 int rv;
=C2=A0=C2=A0 =C2=A0
=C2=A0=C2=A0=C2=A0 if (acpi_disabled("fan"))
=C2=A0=C2=A0 =C2=A0return (ENXIO);
=C2=A0=C2=A0=C2=A0 rv =3D ACPI_ID_PROBE(device_get_parent(dev), dev, fan_id= s, NULL);
=C2=A0=C2=A0=C2=A0 if (rv <=3D 0)
=C2=A0=C2=A0 =C2=A0device_set_desc(dev, "ACPI FAN");
=C2=A0=C2=A0=C2=A0 return (rv);
}
=C2=A0
static int
acpi_fan_attach(device_t dev)
{
=C2=A0=C2=A0 =C2=A0int=C2=A0=C2=A0 =C2=A0error;
=C2=A0=C2=A0 =C2=A0ACPI_HANDLE=C2=A0=C2=A0 =C2=A0handle;
=C2=A0=C2=A0 =C2=A0ACPI_HANDLE tmp;
=C2=A0=C2=A0 =C2=A0struct acpi_fan_softc *sc;
=C2=A0=C2=A0 =C2=A0
=C2=A0=C2=A0=C2=A0 sc =3D device_get_softc(dev);
=C2=A0=C2=A0=C2=A0 handle =3D acpi_get_handle(dev);
=C2=A0
=C2=A0=C2=A0 =C2=A0/* fans are either acpi 1.0 or 4.0 compatible, so c= heck 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, "_FPS", &= amp;tmp)) &&
=C2=A0=C2=A0 =C2=A0ACPI_SUCCESS(acpi_get_handle(handle, "_FSL", &= amp;tmp)) &&
=C2=A0=C2=A0 =C2=A0ACPI_SUCCESS(acpi_get_handle(handle, "_FST", &= amp;tmp)))=C2=A0=C2=A0 =C2=A0
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 acpi_fan_softc.version =3D 4;
=C2=A0=C2=A0 =C2=A0
=C2=A0=C2=A0 =C2=A0else=C2=A0=C2=A0 =C2=A0/* nothing to do in acpi version = 1, really */
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0acpi_fan_softc.version =3D 1;
=C2=A0
=C2=A0 return 0;
}
=C2=A0
static int
acpi_fan_detach(device_t dev) {
=C2=A0=C2=A0 =C2=A0sysctl_ctx_free(&clist);
=C2=A0=C2=A0 =C2=A0return 0;
}
=C2=A0

static driver_t acpi_fan_driver =3D {
=C2=A0=C2=A0=C2=A0 "fan",
=C2=A0=C2=A0=C2=A0 acpi_fan_methods,
=C2=A0=C2=A0=C2=A0 sizeof(struct acpi_fan_softc),
};
DRIVER_MODULE(acpi_fan, acpi, acpi_fan_driver, 0, 0);
MODULE_DEPEND(acpi_fan, acpi, 1, 1, 1);
=C2=A0
_____________________
5. How linux does it
=C2=A0
You can check linux fan driver on github:
=C2=A0
They separate the driver into three files.
fan.h
fan_attr.c
fan_core.c
=C2=A0
It's ok to learn from linux. :-)
=C2=A0
=C2=A0
Sorry for long message.
Georg.
Gesendet:=C2=A0Mittwoch, 03. Mai = 2023 um 02:26 Uhr
Von:=C2=A0"Dmitry N. Medvedev" <dmitry.medvedev@gmail.com> An:=C2=A0"Adrian Chadd" <adrian@freebsd.org>
Cc:=C2=A0freebsd-acpi@freebsd.org
Betreff:=C2=A0Re: managing a fan speed via memory address
good morning Adrian,
=C2=A0
1. I am just learning :) Not 100% sure ACPI has anything to do with fa= n 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=C2=A0I will have to first find out how = to do it :) any=C2=A0guidance ( preferable in textual form will be greatly = appreciated ) will learn it :)
3. there isn't a single thermal sensor, but the SAS disks report t= heir 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 decide= if I would like to send more power to the fan.
=C2=A0
On Wed, May 3, 2023 at 2:14=E2=80=AFAM Adrian Cha= dd <adrian@freeb= sd.org> wrote:
Is it not an ACPI driver? If not, you could write a quick fan driver!
=C2=A0
Is there a thermal sensor(s) you could read to see how warm they get?<= /div>
=C2=A0
=C2=A0
=C2=A0
-adrian
=C2=A0
=C2=A0
On Tue, 2 May 2023 at 17:06, Dmitry N. Medvedev &= lt;dmitry.me= dvedev@gmail.com> wrote:
good morning,
=C2=A0
Recently I have learned about the dmidecode program and found the addr= ess 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.
=C2=A0
The context: I have added 8 SAS disks to the machine, put noctu= a fan in front of them and connected the fan to the FRNTFAN=C2=A0port on th= e 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 t= he value at the said address.
Not sure, of course.
=C2=A0
best regards,
Dmitry N. Medvedev
--00000000000048e5e805fade63ed-- From nobody Fri May 5 05:51:31 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 4QCKZ05tY2z49hj6 for ; Fri, 5 May 2023 05:51:36 +0000 (UTC) (envelope-from georg.lindenberg@web.de) Received: from mout.web.de (mout.web.de [212.227.17.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.web.de", Issuer "Telekom Security ServerID OV Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QCKYz0Hyfz42Wh for ; Fri, 5 May 2023 05:51:34 +0000 (UTC) (envelope-from georg.lindenberg@web.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=web.de header.s=s29768273 header.b=qdEWz+zL; spf=pass (mx1.freebsd.org: domain of georg.lindenberg@web.de designates 212.227.17.12 as permitted sender) smtp.mailfrom=georg.lindenberg@web.de; dmarc=pass (policy=none) header.from=web.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1683265891; i=georg.lindenberg@web.de; bh=nDVz6im83lXcpSEKB68GIcaab3vLADwpJx4XraYAN8M=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=qdEWz+zL+EvLLv0IAXVt8PnX2fgE2Ru5gNgP9lL/1ZOFSl2RWxKIaLvFGoO+MSetK ALk560Xl2ejj4gtGIe37cED+PFCG39xB97lRI1/++XJZ7bZFdDS+bklAv9YlYIV/tV K503YkB+5znwfZG7y6AYAVifAyqHFvX8kcb40keOegjWimoBYkNF8UgLPok3YOknCt L11bMNsAFKcBzY9/pAQpS8MunqGRwlb2GcC3aeZG5eMhOsqYLzfYDXGUtPGR6q+UPy 5F5EXNZZWSnLXyU/gIxX0z12C8FNQ5tacVdGkMACDFWGXajukiagJHyYOfEsW65OG5 TJMPAHhmJxraQ== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Received: from [10.236.203.2] ([10.236.203.2]) by msvc-mesg-web102.server.lan (via HTTP); Fri, 5 May 2023 07:51:31 +0200 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 Message-ID: From: Georg Lindenberg To: "Dmitry N. Medvedev" Cc: freebsd-acpi@freebsd.org Subject: Aw: Re: Re: managing a fan speed via memory address Content-Type: text/plain; charset=UTF-8 Importance: normal Sensitivity: Normal Content-Transfer-Encoding: quoted-printable Date: Fri, 5 May 2023 07:51:31 +0200 In-Reply-To: References: X-Priority: 3 X-Provags-ID: V03:K1:+Si87OPcc9hGihgMlsffNpgQC5MHirys055PSqPNAv6Xc8AjXPYDyj20WDY0xDiG2uHNZ /lFARCPoT92UF59mTFgfbHpH1QaJtwCYarTRCnnrcKyPgVWhRfiWObzIUe1xIudTIgBS1GWKBMe9 Vt3GubEeiStH0uVBFIYUrinNx3Q85kw0rm5jbmMO3BHE1sYHxPMcp1pzhqtjd08HB8G2zpmv5BYf /CmdDVsiQs5m3VToKgOzeC2N1D0fliogNr0dmU0rRy+JJboP/59zF2tT4Djd+FQdUIreZAVZzDzN og= X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:vuNIImFfVbk=;XngRCRgeuNVzMCN8ZdYurhXKbAs QgZ0rzgTHBGbaF2pSYE46aSkQjFnxe2n1S9JyRsOhzI1yIDpRm1lfLgCp4+GNH26WS+UjrqTJ epitc2VDprLlORroQTRWaTynfqaf04V8KJGxRb3TScafSCbQbhhnoLfiA04kjN8p7lNbNKvnx cBpD9ZzXjMeWVCb6zgOLRprm63Uxc+14JKF9S5yOh0SkzqimQZ1QDrkckwnN1HJkhfvnI8NDm spWHHkuAZhnKyEYPJ3BaqWmhaCaDcbUqQ7I5vJ/8aSRoakBeAcfzAWkULNRvPHdeWi52m1QCh MWUYuky8e3QIlwJGQUe1xakLNfGQi4fqOVneXf2ecPihPtyaY4ldzHfShNyHQIzGGsl8gV2Qo 0uwR/a7bYq87iaWwwT4MYcM7WtGFa6H0zhBRCmnlgT5/DYbXEI3ef/To+tFUbPs8r1vlTEIse ICXqSmaAIGYCxQfiuzJgbt1vnGCz37j3phl+E1CbeExUggpKgsh3gOXE6nG7D92mvpUaqo+dM x9jnhPUcAaO1VvXhJsuX8/HZAu+6yG+z+KVzCsJU+LDauB5OXDQUrxCX75WdeQCKLVzW35hcO /JcdngmFWKJbvVl0NvyZeE3s/6Bs5eUxJpeOZVe5tVN+mkJH3wuvIffkNf4fxH9EaX++QOAmF ycqh8ESJeFApYZIf+YlVp0Vo6gaFd744lEOyxZAmg4JYUN/yx8TXdZl+QJo2vZlonmlCU9cNo yZR+Zl9KTA/9N8ry43uIrHuNCZ1laIsf/RhFEaaYd73bFEIPzPj8cfeCnHkQSa2W6pUQNXJF0 6aNwNAhwPcNJ/zRiJp0FlBgZ2YBe01drTrR2tRsFR77PA= X-Spamd-Result: default: False [-4.56 / 15.00]; DWL_DNSWL_LOW(-1.00)[web.de:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.960]; DMARC_POLICY_ALLOW(-0.50)[web.de,none]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[web.de:s=s29768273]; R_SPF_ALLOW(-0.20)[+ip4:212.227.17.0/27]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[212.227.17.12:from]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-acpi@freebsd.org]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[web.de]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[web.de:+]; FREEMAIL_FROM(0.00)[web.de]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; HAS_X_PRIO_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QCKYz0Hyfz42Wh X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N If the fan ID is not present in acpidump, then the fan is not in the acpi n= amespace, and thus it is not visible to the operating system (aka FreeBSD)= =2E At least according to the acpi documentation=2E :-) Maybe there is a another way to access the fan (bios?), that I am not awar= e of=2E Good luck=2E > Gesendet: Donnerstag, den 04=2E05=2E2023 um 15:45 Uhr > Von: "Dmitry N=2E Medvedev" > An: "Georg Lindenberg" > Cc: freebsd-acpi@freebsd=2Eorg > Betreff: Re: Re: managing a fan speed via memory address >=20 > hi Georg, >=20 > it's become even more confusing -- none of the IDs from #1 exist in > acpidump output :( >=20 > researching further >=20 > On Wed, May 3, 2023 at 8:02=E2=80=AFPM Georg Lindenberg > wrote: >=20 > > > > Hello, > > > > ACPI can control fans, but it is up to the hardware manufacturer (OEM)= to > > implement it=2E > > > > _______________________________ > > Step 1=2E Check for ACPI fan control > > > > The OEM needs to add a device with id "PNP0C0B" to the acpi namespace= =2E > > In FreeBSD, you can test this with the command: acpidump -d -t | grep > > PNP0C0B > > > > On Windows, you can download acpi tools at > > https://acpica=2Eorg/downloads/binary-tools > > Then use the command: acpidump=2Eexe | 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=2E > > > > __________________________ > > Step 2=2E Check for version of ACPI > > > > Fan version is either 1=2E0 or 4=2E0=2E > > > > a) Acpi version 1=2E0 > > > > If you suceed with step 1=2E, then you can communicate with the fan=2E= You can > > turn it on and off > > by putting it in power state D0 or D3=2E > > 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)=2E > > > > Or maybe an alternative: There is a suggestion on FreeBSD acpi wiki: > > device_power -- Add a "power" argument to devctl(8) that allows a devi= ce > > to be set into various low power or off states=2E > > Noone has implemented that yet ("not done")=2E :) > > > > b) ACPI version 4=2E0 > > > > To check, whether your fan supports fan levels, you can do this: > > > > OEM _must_ provide four predefined acpi methods=2E They are described = in > > detail in the acpi > > specification=2E They are called: _FIF, _FPS, _FSL, _FST > > So just use: > > acpidump -d -t | grep _FPS > > and so on=2E 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=2E0 or 4=2E0 compatible, so check now=2E= */ > > 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=2Eversion =3D 1; > > > > 3=2E How to set fan levels > > > > As a driver author, you'd need to decide how you'd want to implement t= he > > fan level=2E It can be done > > via /dev/acpi (and also add code to acpiconf (8))=2E Or it can be done= via > > systctls=2E > > > > So in your code, you could add a proc sysctl=2E There are multiple way= s 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=2E > > > > Then you need a sysctl handler: > > > > static int > > acpi_fan_level_sysctl(SYSCTL_HANDLER_ARGS) { > > > > =2E=2E=2E > > } > > > > In the handler function you could "handle" the fan level, and probably= call > > acpi_evaluate_object() on the _FIF, _FPS, _FSL, and _FST methods=2E > > > > Unfortunately, my laptops don't support fans at all=2E So I can't real= ly > > write a fan driver=2E > > I think it is a good beginners task=2E > > > > Basically, if your fan has three or four pins, it might support fan > > levels=2E The first two pins are > > used for electricity=2E The third pin is used to upscale or downscale = the > > power (voltage?), > > thus increasing or decreasing the fan speed=2E There is no magic to th= is=2E > > > > 4=2E Sceleton acpi driver > > > > If you need a sceleton acpi driver, that shouldn't be a problem=2E > > FreeBSD puts all acpi drivers (modules) into the acpi subsystem > > (sys/dev/acpica), instead > > of giving them a separate makefile in sys/modules=2E > > > > This was my first attempt, without ever testing anything (bugs to be > > expected): :-) > > > > #include "opt_acpi=2Eh" > > #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=2E0 or 4=2E0 */ > > }; > > > > 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=2E0 or 4=2E0 compatible, so check now=2E= */ > > 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=2Eversion =3D 4; > > > > else /* nothing to do in acpi version 1, really */ > > acpi_fan_softc=2Eversion =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=2E How linux does it > > > > You can check linux fan driver on github: > > https://github=2Ecom/torvalds/linux/tree/master/drivers/acpi > > > > They separate the driver into three files=2E > > fan=2Eh > > fan_attr=2Ec > > fan_core=2Ec > > > > It's ok to learn from linux=2E :-) > > > > > > Sorry for long message=2E > > Georg=2E > > *Gesendet:* Mittwoch, 03=2E Mai 2023 um 02:26 Uhr > > *Von:* "Dmitry N=2E Medvedev" > > *An:* "Adrian Chadd" > > *Cc:* freebsd-acpi@freebsd=2Eorg > > *Betreff:* Re: managing a fan speed via memory address > > good morning Adrian, > > > > 1=2E I am just learning :) Not 100% sure ACPI has anything to do with = fan > > control ( still it looks that it actually does ) > > -- found the Advanced Configuration and Power Interface Specification = PDF=2E > > Will spend some time grasping the ideas > > 2=2E 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 appreciat= ed ) > > will learn it :) > > 3=2E there isn't a single thermal sensor, but the SAS disks report the= ir > > temperatures > > ( via dmidecode if I am not mistaken, or some other program -- I will = be > > more sure tomorrow morning )=2E > > so, theoretically I could be able to read their temperature and decide= if > > I would like to send more power to the fan=2E > > > > 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=2E Medvedev < > >> dmitry=2Emedvedev@gmail=2Ecom> 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=2E > >>> Since I am a complete newbie, I would like to learn if there is a wa= y to > >>> read and change the value at this address=2E > >>> I need a bit of guidance=2E > >>> > >>> *The context*: I have added 8 SAS disks to the machine, put noctua f= an > >>> in front of them and connected the fan to the FRNTFAN port on the > >>> motherboard=2E > >>> It looks like the fan works, but I am sure the disks would benefit i= f > >>> the fan produced more pressure=2E Which I fantasize I could do via c= hanging > >>> the value at the said address=2E > >>> Not sure, of course=2E > >>> > >>> best regards, > >>> Dmitry N=2E Medvedev > >>> > >>