From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D0999CCF9F8 for ; Sat, 1 Nov 2025 11:45:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type: Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date :Subject:Cc:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=PHVYSvdDYI0ifXKzRw7b8rWjTZ1yx6Imu7EM6kr3mrU=; b=z7qnMSbgFUjOw3LLbX36dPzNVh qRXxrTS7+01f31CM18bIPSfUIzUzqA53edwVnijAE1n8yXZmF4yeGvU9xmcX8BqNXmRi68C9tp9dK ugtVG5eE9KjELOQMyn+flvMKQhWFvS8qb4ytAXduI9CBgj0FkhvlOByxBsykyVEWhs7rmzwDZypkE IZWJqnfFiaYOxYiMTRyZvNOvETVxTnTyYfJNg4HLVkn105oJPV1+ezJHLC5ZwwmYyKq7ZvJYh24gH rxp07Vj8sPIDULH/6oouVsjBtNM2XWEKb9eXPkZxVL/mUtgpkqPxXjWdfiBXJL5bW9+wlmBohXMwr UaEEtFqQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vFA2Z-00000007JIm-1ZtX; Sat, 01 Nov 2025 11:45:03 +0000 Received: from gloria.sntech.de ([185.11.138.130]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vFA2X-00000007JI5-1y6S; Sat, 01 Nov 2025 11:45:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sntech.de; s=gloria202408; h=Content-Type:Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Reply-To; bh=PHVYSvdDYI0ifXKzRw7b8rWjTZ1yx6Imu7EM6kr3mrU=; b=F9EcTBASWM5qh/zDz2Za0DKHJv O86Tv5obC46pwjRdwxGXFTKR4PRNCzkPOkXPSnqWov/3dIxsIxD3Ne0RjmQzOn0YG5aAkU3hFoL4g +s+WRlofAnWqd/jtEX59Us1aepVBVm2xn/WwE+qLd5oUHbVJjWXwdXWvVmywqjAXM7DJGN55ERaWK ek3ieHeDNY1kQSmWmFNZZTLr6kiWLGzqpxVmOjvJjL/CWDZDHP1owMZ6CwrvOLr8Nxh+wdd0rAeyu yCkTa1xbnBENaEsSEpr7zWK1X5Tn51bI3PZMKji1nQ1FpOIhiRfPgPeFX3BGaw9AcTUdIwyK3/A3G FK1eTZ3g==; Received: from i53875b80.versanet.de ([83.135.91.128] helo=phil.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vFA2Q-0008ME-Vd; Sat, 01 Nov 2025 12:44:55 +0100 From: Heiko Stuebner To: Alexey Charkov , Dragan Simic Cc: sigmaris@gmail.com, conor+dt@kernel.org, devicetree@vger.kernel.org, krzk+dt@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, robh@kernel.org Subject: Re: [PATCH] arm64: dts: rockchip: pwm-fan overlay for NanoPC-T6 Date: Sat, 01 Nov 2025 12:44:54 +0100 Message-ID: <2246326.irdbgypaU6@phil> In-Reply-To: <2cfeeb0c-f7e0-b101-62c4-3b6eae40a30b@manjaro.org> References: <2cfeeb0c-f7e0-b101-62c4-3b6eae40a30b@manjaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20251101_044501_536406_5C2CB679 X-CRM114-Status: GOOD ( 55.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Am Montag, 27. Oktober 2025, 22:15:05 Mitteleurop=C3=A4ische Normalzeit sch= rieb Dragan Simic: > Hello Alexey, >=20 > On Monday, October 27, 2025 21:56 CET, Alexey Charkov = wrote: > > On Tue, Oct 28, 2025 at 12:02=E2=80=AFAM Dragan Simic wrote: > > > On Mon, Oct 27, 2025 at 7:08=E2=80=AFPM Hugh Cole-Baker 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. > >=20 > > 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). > >=20 > > 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. >=20 > Hmm, right, I forgot for a moment that the PWM output is generated > by dedicated hardware, so not many CPU cycles would be wasted. >=20 > BTW, with a fan PWM signal generated by a soft-GPIO output, much > more CPU cycles would've been saved by omitting the fan definition > if it isn't present, but that isn't the case here. >=20 > > > 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 undesira= bly high > > > > temperatures if it's relying on the nonexistent fan to cool it down= =2E 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 us= ing 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-fa= n.dtb as > > > > their single DT to load, if it doesn't support applying overlays an= d they > > > > want to use the fan addon? > >=20 > > 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. >=20 > FWIW, the most user-friendly SBC family in the world, Raspberry > Pi, :) requires manual enabling of the fan on Raspberry Pi 4. > I haven't researched what's the background for that, perhaps the > need to keep the GPIO expansion header completely unoccupied by > default, because the fan attaches to the GPIO header, instead of > to some dedicated fan connector. >=20 > > > 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 (usi= ng mainline > > > > U-Boot to load it) and several other RK3588 boards are also compile= d with > > > > symbols enabled already, and I haven't seen any issues reported wit= h 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. > >=20 > > 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. 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. Heiko