linux-kernel - Re: [PATCH] arm64: dts: rockchip: pwm-fan overlay for NanoPC-T6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <232be108-ea84-2808-77b9-ff46d2b8baf7@manjaro.org>
Date: Tue, 04 Nov 2025 15:15:10 +0100
From: "Dragan Simic" <dsimic@...jaro.org>
To: "Hugh Cole-Baker" <sigmaris@...il.com>
Cc: "Heiko Stuebner" <heiko@...ech.de>, "Alexey Charkov" <alchark@...il.com>, conor+dt@...nel.org, devicetree@...r.kernel.org, krzk+dt@...nel.org, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org, robh@...nel.org
Subject: Re: [PATCH] arm64: dts: rockchip: pwm-fan overlay for NanoPC-T6

(Resending because the original message ended up on some spam lists,
seemingly as a result of some UTF-8 characters in the subject.)

Hello Hugh,

On Saturday, November 01, 2025 14:14 CET, Hugh Cole-Baker <sigmaris@...il.com> wrote:
> On 01/11/2025 11:44, Heiko Stuebner wrote:
> > Personally, I'm more on the less complication side.
> > 
> > I.e. if there is an actual fan-connector on the board we should describe
> > it as such.
> > 
> > Overlays I see for things where you attach hats to generic pin headers
> > to create specific functionality on top of a generic interface.
> > 
> > But if the board itself has an actual fan header, it should be described
> > as such. Because that then _is_ the standard use of that.
> 
> The board does have a fan connector, just no fan by default. But anyway,
> since it sounds like the preferred approach I'll send a v2 which puts the
> fan into the base board .dts.
> 
> Dragan, you mentioned there's no need for more than 2 trip points - if
> I remove the trip points between "SoC is warm, start fan at slow speed"
> and "SoC is v. hot, run fan at full speed" is the OS/kernel expected to
> interpolate between those 2 trip points (if you have a link to docs or
> code about this it'd be interesting, I couldn't find anything in the
> dt-bindings)?

True, that isn't described in the bindings, because it basically
doesn't belong there.  Thus, the most specific description of the
associated cooling stuff, as provided by the bindings, is the
following excerpt from Documentation/devicetree/bindings/thermal/
thermal-zones.yaml:

  209 cooling-device:
  210   $ref: /schemas/types.yaml#/definitions/phandle-array
  211   description:
  212     A list of cooling device phandles along with the minimum
  213     and maximum cooling state specifiers for each cooling
  214     device. Using the THERMAL_NO_LIMIT (-1UL) constant in the
  215     cooling-device phandle limit specifier lets the framework
  216     use the minimum and maximum cooling state for that cooling
  217     device automatically.

That's where the cooling hardware description ends, so that's also
where the associated binding ends.  Everything else belongs to the
thermal governors, because they actually decide on how to best use
the available cooling features.

For example, the chain of events may look like this:

  (1) The rockchip_thermal_alarm_irq_thread() function, defined in
      drivers/thermal/rockchip_thermal.c, gets triggered by TSADC
      within the parameters of DT-defined "active" trip types

  (2) It calls the thermal_zone_device_update() function defined
      in drivers/thermal/thermal_core.c

  (3) This ends up calling the step_wise_manage() function that's
      defined in drivers/thermal/gov_step_wise.c, which handles
      the previously triggered "active" trip

  (4) This calls the drivers/thermal/gov_step_wise.c's locally
      defined thermal_zone_trip_update() and get_target_state()
      functions, which end up ramping the fan speed up and down
      as needed, while respecting the upper and lower limits
      defined through the "cooling-device" DT map properties,
      which correspond to the "cooling-levels" defined in the
      DT fan property

Here's also an excerpt from drivers/thermal/gov_step_wise.c, which
confirms all this and explains it a bit further:

  113  /*
  114   * Throttling Logic: Use the trend of the thermal zone to throttle.
  115   * If the thermal zone is 'heating up', throttle all of the cooling
  116   * devices associated with each trip point by one step. If the zone
  117   * is 'cooling down', it brings back the performance of the devices
  118   * by one step.
  119   */

With all that in mind, the fan will ramp its speed up and down
nicely, according to the current temperature, with no need for
having multiple manually defined steps.

The intended benefit of having the two usual, distinct "active"
thermal trips and cooling maps is to lower the fan-induced noise
a bit while not affecting the cooling much.  This is all visible
in rk3399-rockpro64.dtsi, for example.