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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20251027200213.1821809-1-dsimic@manjaro.org>
Date: Mon, 27 Oct 2025 21:02:13 +0100
From: Dragan Simic <dsimic@...jaro.org>
To: sigmaris@...il.com
Cc: alchark@...il.com,
	conor+dt@...nel.org,
	devicetree@...r.kernel.org,
	heiko@...ech.de,
	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

Hello Hugh and Alexey,

On Mon, Oct 27, 2025 at 7:08 PM Hugh Cole-Baker <sigmaris@...il.com> wrote:
> On 27/10/2025 09:14, Alexey Charkov wrote:
>
>> Is there any downside to enabling this unconditionally in the board
>> .dts?
>
> Only that it goes against the principle that the DT should describe the
> hardware; the board .dts would describe a cooling device that doesn't
> actually exist on the base board.

Having a separate DT overlay is perfectly fine if we want to
describe a board absolutely correctly: if the fan actually isn't
present, the operating system shouldn't be made to think it is
there, especially if there's no fan RPM feedback, which is the
case on almost all Rockchip boards that support a fan.

Preventing the kernel from managing a non-existent fan might even
save some CPU cycles, ending up producing a bit less heat, which
can only help in passively cooled setups.

However, the practice so far has been to describe the fans in the
main board dts files, if the board provides fan support, regardless
of the fan being present in a particular board setup or not.

> I guess then in theory, an OS might allow the SoC to reach undesirably high
> temperatures if it's relying on the nonexistent fan to cool it down. But I
> don't think this would be an issue on Linux, at least, in practice.

We're safe, a thermal runaway isn't going to happen when the fan is
defined in a board DT but actually isn't present.  Thermal CPU and
GPU throttling will prevent the overheating from happening.

>> Overlays require more user configuration, and not all
>> bootloaders support them directly (e.g. systemd-boot users would
>> struggle). Compiling with overlays enabled also makes .dtb's a lot
>> larger due to added symbols information.
>
> Nowadays (on Debian at least) using overlays is pretty easy, I'm using the
> u-boot-menu package in Debian, I just copy the overlay(s) to /boot/dtbo/ and
> it detects them automatically and adds them to extlinux.conf for u-boot to
> apply.
>
> Couldn't systemd-boot users just use rk3588-nanopc-t6-(lts-)with-fan.dtb as
> their single DT to load, if it doesn't support applying overlays and they
> want to use the fan addon?

Yes, that's an option.  However, that in general doesn't resolve
the issues arising from systemd-boot users wanting to apply more
than a single DT overlay.

> FWIW, I haven't noticed any problems with having a larger .dtb (using mainline
> U-Boot to load it) and several other RK3588 boards are also compiled with
> symbols enabled already, and I haven't seen any issues reported with them.

After thinking a bit about it, I'd support the extraction of fan
definitions into separate DT overlays.  As I wrote above already,
not managing the non-existent fan might actually help a bit with
passively cooled board setups, which is a good enough reason for
me to support separate DT overlays.

If we end up agreeing to accept this DT overlay, I'll have some
comments on the way cooling maps are defined.  I think there's
quite a bit of redundancy there.