Re: [GIT PULL] Rockchip dts fixes for 7.0 #1

[Heiko Stuebner <heiko@sntech.de>]

Am Dienstag, 17. März 2026, 10:19:29 Mitteleuropäische Normalzeit schrieb Krzysztof Kozlowski:
> On 17/03/2026 10:05, Heiko Stuebner wrote:
> > Am Dienstag, 17. März 2026, 09:45:30 Mitteleuropäische Normalzeit schrieb Krzysztof Kozlowski:
> >> On Sat, Mar 14, 2026 at 07:42:38PM +0100, Heiko Stuebner wrote:
> >>> Hi SoC maintainers,
> >>>
> >>> please find a below some Rockchip fixes for the current 7.0 release-cycle.
> >>> And in the next PR, even one driver-fix this time.
> >>>
> >>> Please pull
> >>>
> >>> Thanks
> >>> Heiko
> >>>
> >>>
> >>> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
> >>>
> >>>   Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
> >>>
> >>> are available in the Git repository at:
> >>>
> >>>   https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v7.0-rockchip-dtsfixes1
> >>>
> >>> for you to fetch changes up to 2ed11ad1c2b4c191cb2ed6741be127eb99f8634f:
> >>>
> >>>   arm64: dts: rockchip: Correct Joystick Axes on Gameforce Ace (2026-03-12 20:52:53 +0100)
> >>>
> >>> ----------------------------------------------------------------
> >>> A big number of changes fixing dt-schema issues on the ARM32 side,
> >>> fixes for the Gameforce-Ace to make the hardware work properly
> >>> (including thermals) as well as fixing issues both on Beelink A1 (spdif)
> >>> and Pinebook Pro (Wifi) by reverting the commits that created the issues
> >>>
> >>> ----------------------------------------------------------------
> >>> Chris Morgan (2):
> >>>       arm64: dts: rockchip: Correct Fan Supply for Gameforce Ace
> >>>       arm64: dts: rockchip: Correct Joystick Axes on Gameforce Ace
> >>>
> >>> Fabio Estevam (11):
> >>>       ARM: dts: rockchip: Remove rockchip,grf from rk3288 tsadc
> >>>       ARM: dts: rockchip: Move PHY reset to ethernet-phy node on rk3036 boards
> >>>       ARM: dts: rockchip: Fix RTC compatible on rk3288-phycore-rdk
> >>>       ARM: dts: rockchip: Use mount-matrix on rk3188-bqedison2qc
> >>>       ARM: dts: rockchip: Remove invalid regulator-property from rk3288-veyron
> >>
> >> Not a fix.
> >>
> >>>       ARM: dts: rockchip: Fix the Bluetooth node name on rk3288-veyron
> >>
> >> Not a fix. This is a pure style change. Fixes for current cycle means
> >> either important issues being fixed or errors introduced in current
> >> cycle.
> >>
> >> Changing style from one to another is not a fix.
> >>
> >>>       ARM: dts: rockchip: Fix the trackpad supply on rk3288-veyron-jerry
> >>>       ARM: dts: rockchip: Add missing the touchscreen interrupt on rk3288-phycore-rdk
> >>>       ARM: dts: rockchip: Fix RTC description on rk3288-firefly-reload
> >>
> >> Not a fix. Style of node name is not a bug, otherwise describe user
> >> visible (not "internal tools" visible) impact.
> >>
> >>>       ARM: dts: rockchip: Fix GMAC description n RK3288 boards
> >>>       ARM: dts: rockchip: Fix LED node names on rk3288-phycore-rdk
> >>
> >> Several other are questionable as well, since they were in DTS for long
> >> time. Please also read Linus' explanation here from some time ago - if
> >> the issue is for long time and no one cared, then changing it is a normal
> >> development.
> >>
> >> Several changed pieces here look like 3 or more years old, so does not
> >> fit criteria of current cycle fix at all.
> >>
> >> Please split the pull.
> > 
> > I do remember in the past, changes that reduced the number of
> > dt-checker errors were considered fixes, but it seems that has
> > changed, so I'll split that accordingly.
> 
> It is subjective and of course dtbs_check fix for issue introduced in
> current cycle is a RC-fix. I am pretty sure that many maintainers would
> pull all above to RC, but I follow a bit stricter interpretation just
> like Linus explained it:
> 
> https://lore.kernel.org/lkml/CA+55aFyvW38WU93CqegHiKt-ReO8yNfAOUGZRFGY3-Aq0UsETw@mail.gmail.com/
> 
> https://lore.kernel.org/all/CAHk-%3DwgFuoHpMk_Z_R3qMXVDgq0N1592%2BbABkyGjwwSL4zBtHA@mail.gmail.com/
> 
> So the issues were there probably for many years and fixes do not have
> user-visible impact, thus they look like regular improvement of poor
> code. Just like I evaluated dtbs_check findings in 2024 - 50% of
> warnings are style.


Thanks for the explanation. As I said, I'll adapt the PR accordingly :-) .

Heiko