Message-ID: <CABjd4Yzfx-4xBHVB=W_r6nEdbwNJKdpHYB6bN3Xsk8dZOegJWw@mail.gmail.com>
Date: Tue, 28 Oct 2025 00:56:20 +0400
From: Alexey Charkov <alchark@...il.com>
To: Dragan Simic <dsimic@...jaro.org>
Cc: sigmaris@...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

On Tue, Oct 28, 2025 at 12:02 AM Dragan Simic <dsimic@...jaro.org> wrote:
>
> 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.

Sounds like an overcomplication without real benefit. It's one thing
with overlays for functionality that can be software-incompatible
depending on whether an external attachment is connected or depending
on the type of attachment connected. Here we are looking at a plain
2-pin fan which cannot be software incompatible to anything really
(it's not like one could repurpose the fan connector for anything
meaningful if a fan is not in use, and noone gets hurt if a PWM output
is left running without load).

The CPU cycles spent parsing a slightly larger DTB at boot are likely
comparable to those spent activating a PWM output needlessly upon
hitting the active cooling trip point, and both are negligible for any
practical purpose.

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

Sure, but it's a manual configuration step, where otherwise the kernel
would just default to the correct dtb for the board that the firmware
told it about. The fan is not discoverable, so the firmware won't ever
offer the "-with-fan" variant, meaning users would need to supply it
manually in every instance.

> 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.

Practical benefits sound far fetched here, while forcing users to
manually configure something that would have otherwise just worked.
Let's see what Heiko thinks.

> 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.

Agree. Thermal governors can figure out the fan speed ramp-up without
specifying each and every temperature threshold manually. Two trips
seem to be enough for everyone (c) - as we've done e.g. on Rock 5B and
others.

Best regards,
Alexey

Powered by blists - more mailing lists