rockchip64: bump edge to 6.19
#9067
Conversation
WalkthroughThis PR updates Armbian's Rockchip64 kernel configuration from version 6.18 to 6.19, introducing a new patching configuration file and 90+ device tree patches/additions spanning multiple RK3328/RK3366/RK3399/RK3588 boards. Changes include new board support (Helios64, Sakura Pi, Dusun DSOM), USB-C DisplayPort alt mode integration, audio codec additions, Ethernet PHY updates, thermal management enhancements, and peripheral expansioning for existing boards. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
bot
added
size/large
| @@ -0,0 +1,856 @@ | |||
| From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 | |||
There was a problem hiding this comment.
breaks compilation. don't know how to fix
| @@ -0,0 +1,7156 @@ | |||
| From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 | |||
There was a problem hiding this comment.
does not align anymore due to upstream renaming of functions as it seems. horrible task to align manually again...
|
Is it possible to list all the deleted patches so we can continue working on them? I can't find media-0001 rkvdec patches now. |
|
Yes, I did my work step by step and commited inbetween to make it easier to get such info: 12aeef4 |
EvilOlaf
requested review from
ColorfulRhino,
HeyMeco,
JohnTheCoolingFan,
SuperKali,
TheSnowfield,
Tonymac32,
ahoneybun and
amazingfate
as code owners
EvilOlaf
requested review from
catalinii,
chainsx,
efectn,
igorpecovnik,
joekhoobyar,
krachlatte,
lanefu,
paolosabatino,
prahal,
pyavitz and
schwar3kat
as code owners
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 14
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
🟡 Minor comments (17)
patch/kernel/archive/rockchip64-6.19/board-rock64-mail-supply.patch-1-1 (1)
1-1: Fix the filename typo: "mail" should be "mali".The patch filename contains "mail-supply" but should be "mali-supply" to correctly reflect that it configures the Mali GPU power supply.
Suggested filename:
board-rock64-mali-supply.patchpatch/kernel/archive/rockchip64-6.19/dt/rk3318-box.dts-326-326 (1)
326-326: Empty phandle may cause DTC warning or unexpected behavior.An empty phandle reference
<>is not standard DTS syntax. If no power sequence is needed for this node, either omit themmc-pwrseqproperty entirely or comment it out. The current form may produce a device tree compiler warning.- mmc-pwrseq = <>; + /* mmc-pwrseq: set via overlay when wifi is attached */patch/kernel/archive/rockchip64-6.19/board-rock3a-0003-add-gpio-names.patch-38-38 (1)
38-38: GPIO bank mismatch in line name.Line 38 references "GPIO0_C0" but this entry is in the GPIO1 bank's C0 position.
Apply this diff to correct the GPIO bank reference:
/* GPIO1_C0 - C7 */ - "pin-15 [GPIO0_C0]", "", "", "", "", "", "", "", + "pin-15 [GPIO1_C0]", "", "", "", "", "", "", "",patch/kernel/archive/rockchip64-6.19/board-rock3a-0003-add-gpio-names.patch-74-75 (1)
74-75: Fix duplicate pin-21 assignment in GPIO4_C mapping.Pin-21 is assigned to both GPIO4_C2 and GPIO4_C5 on line 74. This violates physical pin constraints since a physical pin cannot map to two different GPIO lines simultaneously. Based on earlier versions of this patch (6.12) and similar boards (Radxa Zero 3), GPIO4_C2 should map to pin-23, not pin-21.
patch/kernel/archive/rockchip64-6.19/board-rocks0.patch-4-4 (1)
4-4: Typo in patch subject: "rock-so" should be "rock-s0"The subject line has a typo - "rock-so" (letter O) should be "rock-s0" (zero) to match the actual board name and filename.
-Subject: Add some missing nodes in rk3308-rock-so device tree +Subject: Add some missing nodes in rk3308-rock-s0 device treepatch/kernel/archive/rockchip64-6.19/board-firefly-rk3399-dts.patch-285-293 (1)
285-293: Incorrect interrupt type constant used.The interrupt specification was changed from
IRQ_TYPE_LEVEL_HIGHtoGPIO_ACTIVE_HIGH. Theinterruptsproperty expects IRQ type constants (IRQ_TYPE_*), not GPIO polarity flags. While these may have the same numeric value, this is semantically incorrect.Based on learnings, the
rewrite-patchestool can inadvertently introduce such semantic changes when the git base revision differs from expected state.brcmf: wifi@1 { reg = <1>; compatible = "brcm,bcm4329-fmac"; interrupt-parent = <&gpio0>; - interrupts = <RK_PA3 GPIO_ACTIVE_HIGH>; + interrupts = <RK_PA3 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "host-wake";patch/kernel/archive/rockchip64-6.19/dt/rk3399-am40.dts-616-618 (1)
616-618: Typo in pinctrl node name: "hots" → "host".The node name contains a typo that should be corrected for consistency with the regulator name
vcc5v0_host.- vcc5v0_host_en: vcc5v0-hots-en { + vcc5v0_host_en: vcc5v0-host-en { rockchip,pins = <1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>; };patch/kernel/archive/rockchip64-6.19/dt/rk3328-dusun-dsom-010r.dts-305-305 (1)
305-305: Minor typo: inconsistent GPIO naming.
GPIO2-A3uses a hyphen while all other entries use underscores (e.g.,GPIO2_A4).- "pin-13 [GPIO2-A3]", "pin-27 [GPIO2_A4]", "pin-28 [GPIO2_A5]", + "pin-13 [GPIO2_A3]", "pin-27 [GPIO2_A4]", "pin-28 [GPIO2_A5]",patch/kernel/archive/rockchip64-6.19/dt/rk3399-tinker-2.dts-210-226 (1)
210-226: Fix property type for wakeup-enable.Line 224 sets
wakeup-enable = "0"as a string. Device tree properties should use proper types—typically a boolean (presence/absence), integer<0>, or according to the binding specification.Check the gmac/ethernet binding documentation to determine the correct type, and update accordingly. If it's a boolean, remove the property (false) or use
wakeup-enable;(true). If it's an integer, usewakeup-enable = <0>;.patch/kernel/archive/rockchip64-6.19/board-radxa-e25-sdmmc0-fix.patch-28-29 (1)
28-29: Fix indentation to use tabs instead of spaces.Line 29 uses spaces for indentation, but device tree files should use tabs for consistency with the rest of the file.
Apply this diff to fix the indentation:
- sd-uhs-sdr104; - sd-uhs-sdr50; + sd-uhs-sdr104; + sd-uhs-sdr50;patch/kernel/archive/rockchip64-6.19/dt/rk3399-fine3399.dts-129-135 (1)
129-135: PWM fan cooling-levels may need to extend to 255.Based on prior learnings for rk3399-fine3399, the PWM fan requires
cooling-levelsto extend to 255 (full duty cycle) for the fan to spin up properly. The current maximum of 160 may be insufficient.- cooling-levels = <0 30 60 90 120 160>; + cooling-levels = <0 30 60 90 120 160 200 255>;Based on learnings, this is a hardware characteristic specific to this board's fan configuration.
patch/kernel/archive/rockchip64-6.19/dt/rk3399-fine3399.dts-246-249 (1)
246-249: Duplicate&gpunode definition.This
&gpublock is identical to the one already defined at lines 193-196. Remove this duplicate.-&gpu { - mali-supply = <&vdd_gpu>; - status = "okay"; -}; - &gpu_thermal {patch/kernel/archive/rockchip64-6.19/board-nanopi-m4v2-dts-add-sound-card.patch-151-153 (1)
151-153: Duplicate&i2s2node.The
&i2s2node is already defined and enabled in the context above (lines 141-143). This duplicate reference is redundant.Remove this duplicate block:
-&i2s2 { - status = "okay"; -}; -patch/kernel/archive/rockchip64-6.19/board-nanopi-m4v2-dts-add-sound-card.patch-117-119 (1)
117-119: Duplicate&hdmi_soundnode will cause DTC warnings.The patch adds a second
&hdmi_soundnode at this location, but there's already one defined in the context above (lines 113-115). This duplicate reference will cause device tree compiler warnings.Remove this duplicate block:
-&hdmi_sound { - status = "okay"; -}; -patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts-213-213 (1)
213-213: Use"disabled"instead of"disable"for status property.The device tree specification requires
"disabled"(not"disable") for the status property. This typo appears in multiple nodes:spdif-sound(line 213),spdif_out(line 225),pwm_bl(line 231),spi1(line 458),spdif(line 871),hdmi_in_vopl(line 1261), anddp_in_vopb(line 1265).spdif-sound { - status = "disable"; + status = "disabled";patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4.dts-195-195 (1)
195-195: Use"disabled"instead of"disable"for status property.Same issue as in the LTS variant. The status property should be
"disabled"per the device tree specification. Affected nodes:dw_hdmi_audio(line 195),spdif-sound(line 212),spdif_out(line 224),pwm_bl(line 230),spi1(line 392),spdif(line 834),hdmi_in_vopl(line 1206),dp_in_vopb(line 1210).dw_hdmi_audio: dw-hdmi-audio { - status = "disable"; + status = "disabled";patch/kernel/archive/rockchip64-6.19/board-nanopi-r2s.patch-267-276 (1)
267-276: Remove duplicateassigned-clocksproperty in gmac2phy node.The
gmac2phynode at lines 270 and 272 hasassigned-clocksdefined twice. The second definition will override the first, losing the initial clock assignment. Combine them into a single property with both clock references:assigned-clocks = <&cru SCLK_MAC2PHY_SRC>, <&cru SCLK_MAC2PHY>; assigned-clock-rates = <50000000>, <0>; assigned-clock-parents = <0>, <&cru SCLK_MAC2PHY_SRC>;
🧹 Nitpick comments (42)
patch/kernel/archive/rockchip64-6.19/dt/rk3328-nanopi-neo3-rev02.dts (1)
34-54: Inconsistent indentation: mixed tabs and spaces.These nodes use spaces for indentation while the rest of the file uses tabs. Consider aligning with kernel DTS conventions (tabs).
patch/kernel/archive/rockchip64-6.19/dt/rk3318-box.dts (1)
305-305: Minor typo in comment."non-convential" → "non-conventional"
patch/kernel/archive/rockchip64-6.19/board-firefly-rk3399-dts.patch (1)
76-85: Use named GPIO constant for consistency.Line 79 uses the raw number
2for the GPIO pin, while the rest of the file consistently uses named constants likeRK_PA2. This reduces readability.vcc3v3_3g: vcc3v3-3g-regulator { compatible = "regulator-fixed"; enable-active-high; - gpio = <&gpio0 2 GPIO_ACTIVE_HIGH>; + gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>; pinctrl-names = "default"; pinctrl-0 = <&pcie_3g_drv>; regulator-name = "vcc3v3_3g";patch/kernel/archive/rockchip64-6.19/board-rk3328-roc-pc.patch (1)
470-481: Inconsistent indentation: mixed tabs and spaces.Lines 474-480 use spaces for indentation while the rest of the file uses tabs. This is a minor style issue but could cause problems with some editors or linters.
&pinctrl { pinctrl-names = "default"; - pinctrl-0 = <&clk_32k_out>; + pinctrl-0 = <&clk_32k_out>; - clk_32k { + clk_32k { clk_32k_out: clk-32k-out { rockchip,pins = <1 RK_PD4 1 &pcfg_pull_none>; - }; - }; + }; + };patch/kernel/archive/rockchip64-6.19/dt/rk3566-lckfb-tspi.dts (1)
528-530: Node name inconsistency with label.The label
wifi_host_wake_hsuggests active-high, but the node namewifi-host-wake-lsuggests active-low. Based on the interrupt configuration at line 618 (IRQ_TYPE_LEVEL_HIGH), the signal is active-high. Consider renaming the node towifi-host-wake-hfor consistency.- wifi_host_wake_h: wifi-host-wake-l { + wifi_host_wake_h: wifi-host-wake-h { rockchip,pins = <2 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>; };patch/kernel/archive/rockchip64-6.19/dt/rk3328-dusun-dsom-010r.dts (3)
247-247: Deprecated propertynum-slots.The
num-slotsproperty has been deprecated and removed from the MMC binding schema. Modern kernels ignore this property.Consider removing this deprecated property:
- num-slots = <1>;
359-360: Remove or document commented-out code.Commented-out
regulator-min-microvoltvalue without explanation. If712500was intentionally changed to1100000, remove the old line to avoid confusion.- //regulator-min-microvolt = <712500>; regulator-min-microvolt = <1100000>;
552-555: Minor whitespace issue.Line 553 appears to have inconsistent leading whitespace (possible space before tab).
&gpu { - status = "okay"; + status = "okay"; mali-supply = <&vdd_logic>; };patch/kernel/archive/rockchip64-6.19/board-rock5c-add-gpio-names.patch (1)
51-73: Remove unnecessary empty GPIO blocks.Both
gpio2andgpio3definegpio-line-nameswith all 32 entries as empty strings. If no pins require naming, thegpio-line-namesproperty should be omitted entirely rather than defining it with empty values.Apply this diff to remove the empty GPIO blocks:
-&gpio2 { - gpio-line-names = - /* GPIO2_A0 - A7 */ - "", "", "", "", "", "", "", "", - /* GPIO2_B0 - B7 */ - "", "", "", "", "", "", "", "", - /* GPIO2_C0 - C7 */ - "", "", "", "", "", "", "", "", - /* GPIO2_D0 - D7 */ - "", "", "", "", "", "", "", ""; -}; - -&gpio3 { - gpio-line-names = - /* GPIO3_A0 - A7 */ - "", "", "", "", "", "", "", "", - /* GPIO3_B0 - B7 */ - "", "", "", "", "", "", "", "", - /* GPIO3_C0 - C7 */ - "", "", "", "", "", "", "", "", - /* GPIO3_D0 - D7 */ - "", "", "", "", "", "", "", ""; -}; -patch/kernel/archive/rockchip64-6.19/dt/rk3399-tinker-2.dts (1)
428-449: Fix indentation for consistency.The
regulator-state-memblock at line 446 (and similarly at line 548) is indented inconsistently. It should align withregulator-initial-stateat line 445.Apply this diff to fix the indentation:
regulator-initial-state = <3>; - regulator-state-mem { + regulator-state-mem { regulator-off-in-suspend; };Repeat the same fix at lines 547-550 for the vdd_gpu regulator.
patch/kernel/archive/rockchip64-6.19/dt/rk3566-panther-x2.dts (3)
8-11: Unused include:dt-bindings/input/input.h.The
input.hheader is included but noKEY_*or other input constants are used in this DTS. Consider removing it if not needed.#include <dt-bindings/gpio/gpio.h> -#include <dt-bindings/input/input.h> #include <dt-bindings/pinctrl/rockchip.h> #include "rk3566.dtsi"
148-151: Minor: Inconsistent indentation.Line 149 uses spaces instead of tabs for indentation. Consider aligning with the rest of the file for consistency.
&gpu { - mali-supply = <&vdd_gpu>; - status = "okay"; + mali-supply = <&vdd_gpu>; + status = "okay"; };
248-253: Minor: Inconsistent indentation in DCDC_REG2 state-mem block.The
regulator-state-memblock has extra indentation compared to sibling regulator nodes.regulator-initial-mode = <0x2>; - regulator-state-mem { + regulator-state-mem { regulator-off-in-suspend; };patch/kernel/archive/rockchip64-6.19/dt/rk3399-xiaobao-nas.dts (2)
140-144: Use symbolic constant for key code instead of magic number.The
linux,code = <0x168>uses a hex value (360 = KEY_OK). Since<dt-bindings/input/input.h>is already included, usingKEY_OKwould improve readability and maintainability.recovery { label = "Recovery"; - linux,code = <0x168>; + linux,code = <KEY_OK>; press-threshold-microvolt = <18000>; };
625-638: Deprecatednum-slotsproperty.The
num-slots = <1>property is deprecated in modern device trees. The kernel ignores this property for single-slot controllers.&sdio0 { bus-width = <4>; clock-frequency = <50000000>; cap-sdio-irq; cap-sd-highspeed; keep-power-in-suspend; mmc-pwrseq = <&sdio_pwrseq>; non-removable; - num-slots = <1>; pinctrl-names = "default"; pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>; sd-uhs-sdr104; status = "okay"; };patch/kernel/archive/rockchip64-6.19/dt/rk3308-sakurapi-rk3308b.dts (4)
12-14: Add board-specific compatible string.The compatible should include a board-specific string before the SoC fallback for proper board identification.
/ { model = "Sakura Pi RK3308B"; - compatible = "rockchip,rk3308"; + compatible = "sakurapi,rk3308b", "rockchip,rk3308"; };
200-205: Avoidspidevcompatible string and hex frequency.The
spidevcompatible triggers a kernel warning. Also, using decimal format forspi-max-frequencyimproves readability.spi_dev@0 { - compatible = "spidev"; + compatible = "linux,spidev"; reg = <0>; - spi-max-frequency = <0x2faf080>; + spi-max-frequency = <50000000>; };Also applies to: 211-216
153-155: Duplicate&i2c1node definitions.The
&i2c1node is defined twice withstatus = "okay". While harmless (last definition wins), this is redundant.Remove the duplicate at lines 287-289:
-&i2c1 { - status = "okay"; -};Also applies to: 287-289
315-317: Fix indentation in tsadc node.The tsadc node uses space indentation instead of tabs, inconsistent with the rest of the file.
-&tsadc{ - status = "okay"; -}; +&tsadc { + status = "okay"; +};patch/kernel/archive/rockchip64-6.19/dt/rk3328-mksklipad50.dts (1)
561-568: Formatting issues in SPI device node.Missing space after
compatibleequals sign and extra blank line.&spi0 { max-freq = <48000000>; cs-gpios = <&gpio3 RK_PA7 GPIO_ACTIVE_LOW>; pinctrl-0 = <&spi0m2_clk &spi0m2_tx &spi0m2_rx>; status = "okay"; - - spi_for_cs2@0 { reg = <0>; - compatible ="armbian,spi-dev"; - pinctrl-names ="default"; + compatible = "armbian,spi-dev"; + pinctrl-names = "default"; pinctrl-0 = <&pinctrl_spi0_cs2>; spi-max-frequency = <5000000>; status = "okay"; }; };patch/kernel/archive/rockchip64-6.19/add-board-helios64.patch (1)
833-834: Address or track the TODO comment.There's a TODO regarding the SD card detect definition that should be addressed or tracked for follow-up.
The comment
// TODO: verify what needs to be done to use implicit CD definitionsuggests this may need investigation. Would you like me to open an issue to track this?patch/kernel/archive/rockchip64-6.19/dt/rk3566-h96-tvbox.dts (4)
15-17: Use consistent compatible string format.The compatible string should use lowercase and follow the standard
vendor,productformat./ { model = "h96 TVbox 3566"; - compatible = "h96-TVbox,rk3566", "rockchip,rk3566"; + compatible = "h96,tvbox-rk3566", "rockchip,rk3566"; };
26-28: Unnecessary label on chosen node.The
chosen: chosenlabel is redundant since the chosen node is typically not referenced by phandle.- chosen: chosen { + chosen { stdout-path = "serial2:1500000n8"; };
453-457: Fix indentation in regulator-state-mem.The
regulator-state-memblock has incorrect indentation (extra tab).vdd_gpu: DCDC_REG2 { regulator-name = "vdd_gpu"; regulator-always-on; regulator-boot-on; regulator-min-microvolt = <500000>; regulator-max-microvolt = <1350000>; regulator-init-microvolt = <900000>; regulator-ramp-delay = <6001>; regulator-initial-mode = <0x2>; - regulator-state-mem { + regulator-state-mem { regulator-off-in-suspend; - }; + }; };
713-721: Inconsistent pinctrl node naming.The
led_power_enable_hnode uses underscores while other nodes use hyphens (e.g.,led-status-enable-h). Follow consistent naming.- led_power_enable_h: led_power_enable_h { + led_power_enable_h: led-power-enable-h { rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>; };patch/kernel/archive/rockchip64-6.19/board-nanopi-r3s-fix-leds.patch (2)
1-6: Patch metadata has placeholder author and future date.The author "John Doe" at line 2 and the date "2025" appear to be placeholders, while the actual Signed-off-by is from retro98boy. This is cosmetic but may cause confusion when tracking patch origins.
86-97: Minor: Trailing whitespace on line 86.There's a trailing tab/space before the
pcie@0,0block. The PCIe topology itself is correctly structured for the r8169 endpoint.status = "okay"; - + pcie@0,0 {patch/kernel/archive/rockchip64-6.19/dt/rk3566-jp-tvbox.dts (3)
14-16: Compatible string uses unconventional vendor prefix format.The compatible
"JP-TVbox,rk3566"uses uppercase and hyphen in the vendor prefix. DT binding conventions typically use lowercase vendor prefixes (e.g.,"jp-tvbox,rk3566"or similar). This may cause binding checker warnings.- compatible = "JP-TVbox,rk3566", "rockchip,rk3566"; + compatible = "jp-tvbox,rk3566", "rockchip,rk3566";
110-116: Inconsistent indentation in combphy blocks.These blocks use spaces while the rest of the file uses tabs. Consider aligning with the file's tab-based indentation.
&combphy1 { - status = "okay"; + status = "okay"; }; &combphy2 { - status = "okay"; + status = "okay"; };
256-261: Minor: Indentation inconsistency in vdd_gpu regulator-state-mem.The
regulator-state-memblock is missing a leading tab compared to the pattern in other regulator blocks (e.g., line 244).regulator-initial-mode = <0x2>; - regulator-state-mem { + regulator-state-mem { regulator-off-in-suspend; - }; + };patch/kernel/archive/rockchip64-6.19/dt/rk3399-fine3399.dts (1)
716-726: Consider removing commented-out SPI NOR flash section.If this configuration is not planned for use, consider removing the commented-out block to keep the DTS clean. If it's kept for documentation purposes, a brief comment explaining why it's disabled would be helpful.
patch/kernel/archive/rockchip64-6.19/board-orangepi-rk3399-pcie.patch (1)
38-39: Use clock macros for improved readability and consistency.The
assigned-clocksandassigned-clock-parentsuse raw CRU clock IDs (138and167). The codebase already uses macros fromdt-bindings/clock/rk3399-cru.hfor similar configurations. Consider updating to useSCLK_PCIEPHY_REFandSCLK_PCIEPHY_REF100Mmacros to match the pattern used in other RK3399 device tree files:&pcie_phy { status = "okay"; - assigned-clocks = <&cru 138>; - assigned-clock-parents = <&cru 167>; + assigned-clocks = <&cru SCLK_PCIEPHY_REF>; + assigned-clock-parents = <&cru SCLK_PCIEPHY_REF100M>; assigned-clock-rates = <100000000>; };patch/kernel/archive/rockchip64-6.19/dt/rk3328-mkspi.dts (2)
122-140: LED labels reference "firefly" but this is an MKS-PI board.The LED labels use
firefly:blue:powerandfirefly:yellow:userwhich are copied from the ROC-RK3328-CC (Firefly) template. For consistency and proper identification, consider updating to reflect the actual board name.leds { compatible = "gpio-leds"; power_led: led-0 { - label = "firefly:blue:power"; + label = "mkspi:blue:power"; linux,default-trigger = "heartbeat"; gpios = <&rk805 1 GPIO_ACTIVE_LOW>; default-state = "on"; mode = <0x23>; }; user_led: led-1 { - label = "firefly:yellow:user"; + label = "mkspi:yellow:user"; linux,default-trigger = "mmc1"; gpios = <&rk805 0 GPIO_ACTIVE_LOW>; default-state = "off"; mode = <0x05>; }; };
198-199: Minor: Inconsistent leading whitespace.Line 198 has an extra leading space before
status. Similar inconsistencies appear in lines 442-443, 448-449, 479, and 502. While not functional issues, these may cause problems during future patch rewrites.patch/kernel/archive/rockchip64-6.19/dt/rk3328-nanopi-r2-rev06.dts (1)
72-91: Minor: Inconsistent indentation in gmac2io block.Lines 74-76 have inconsistent indentation - line 74 uses spaces while lines 75-76 use tabs. This doesn't affect functionality but may cause issues during patch rewrites.
&gmac2io { phy-handle = <ðphy3>; - snps,reset-delays-us = <0 15000 50000>; - tx_delay = <0x22>; + snps,reset-delays-us = <0 15000 50000>; + tx_delay = <0x22>; rx_delay = <0x12>;patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts (2)
12-14: Duplicate include of<dt-bindings/usb/pd.h>.Line 12 and line 14 both include the same header. Remove one to avoid redundancy.
#include <dt-bindings/pwm/pwm.h> #include <dt-bindings/usb/pd.h> #include <dt-bindings/leds/common.h> -#include <dt-bindings/usb/pd.h> #include "rk3399.dtsi"
437-453: Inconsistent indentation in MDIO section.The MDIO block has mixed indentation (tabs and spaces). While this doesn't affect functionality, it reduces readability and may cause issues with automated tools.
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4.dts (2)
204-209: Inconsistent indentation style.The
hdmi_dp_soundnode uses space indentation while the rest of the file uses tabs. Consider aligning for consistency.
1162-1166: Inconsistent indentation in cam0_sleep_pins.The pin definitions inside
cam0_sleep_pinshave misaligned indentation.cam0_sleep_pins: cam0-sleep-pins { - rockchip,pins = - <4 27 3 &pcfg_pull_none>, - <2 11 0 &pcfg_pull_none>; - }; + rockchip,pins = + <4 27 3 &pcfg_pull_none>, + <2 11 0 &pcfg_pull_none>; + };patch/kernel/archive/rockchip64-6.19/board-station-p2.patch (1)
537-575: Inconsistent indentation: mixed tabs and spaces.Several nodes use 4-space indentation instead of tabs (lines 538-539, 545-546, 550-551, 562, 572-574), while the rest of the file uses tabs. This inconsistency can cause issues with strict parsers and reduces maintainability.
&i2c1 { - status = "okay"; + status = "okay"; }; &i2c4 { status = "okay"; }; &i2c5 { - status = "okay"; + status = "okay"; }; &gic { - status = "okay"; + status = "okay"; };patch/kernel/archive/rockchip64-6.19/board-station-m2.patch (2)
1-9: Consider a more descriptive commit subject.The subject "fix rk3566-roc-pc" is quite generic and doesn't indicate what specific issues are being addressed (GPIO remapping, hardware enablement, etc.). A more descriptive subject would improve patch traceability.
187-188: Add explanatory comment for UART pinctrl in SDMMC1 configuration.Line 188 adds
uart9m1_xferanduart8m1_xferto sdmmc1's pinctrl for the WiFi/Bluetooth SDIO module. While this is intentional hardware multiplexing on the Station M2 board (both UART and SDIO are functional), the unusual configuration lacks documentation. Add a comment such as:/* uart9m1 and uart8m1 pins are shared with SDIO data lines and must be configured in this context */This clarifies why UART pins appear in an SDIO device configuration and prevents future confusion or accidental removal of these references.
| config: # This is file 'patch/kernel/archive/rockchip64-6.13/0000.patching_config.yaml' | ||
|
|
||
| # Just some info stuff; not used by the patching scripts | ||
| name: rockchip64-6.14 | ||
| kind: kernel | ||
| type: mainline # or: vendor | ||
| branch: linux-6.14.y | ||
| last-known-good-tag: v6.14-rc2 |
There was a problem hiding this comment.
Fix incorrect version numbers in patching configuration.
The configuration references kernel versions 6.13 and 6.14, but this file is in the rockchip64-6.19 directory and the PR is bumping to 6.19. All version references should be updated to 6.19.
Apply this diff to correct the version numbers:
-config: # This is file 'patch/kernel/archive/rockchip64-6.13/0000.patching_config.yaml'
+config: # This is file 'patch/kernel/archive/rockchip64-6.19/0000.patching_config.yaml'
# Just some info stuff; not used by the patching scripts
- name: rockchip64-6.14
+ name: rockchip64-6.19
kind: kernel
type: mainline # or: vendor
- branch: linux-6.14.y
- last-known-good-tag: v6.14-rc2
+ branch: linux-6.19.y
+ last-known-good-tag: v6.19-rc2
maintainers:🤖 Prompt for AI Agents
In patch/kernel/archive/rockchip64-6.19/0000.patching_config.yaml lines 1-8,
update the version references from 6.13/6.14 to 6.19: change the comment path to
reference rockchip64-6.19, set name: rockchip64-6.19, set branch: linux-6.19.y,
and update last-known-good-tag to v6.19-rc2 so all version fields consistently
reflect 6.19.
| +&spdif { | ||
| + i2c-scl-rising-time-ns = <450>; | ||
| + i2c-scl-falling-time-ns = <15>; | ||
| + status = "okay"; | ||
| +}; |
There was a problem hiding this comment.
SPDIF node has incorrect I2C timing properties.
The &spdif node contains i2c-scl-rising-time-ns and i2c-scl-falling-time-ns properties, which are I2C-specific timing properties and are not valid for an SPDIF controller. This appears to be a copy-paste error.
Remove the invalid properties:
&spdif {
- i2c-scl-rising-time-ns = <450>;
- i2c-scl-falling-time-ns = <15>;
status = "okay";
};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| +&spdif { | |
| + i2c-scl-rising-time-ns = <450>; | |
| + i2c-scl-falling-time-ns = <15>; | |
| + status = "okay"; | |
| +}; | |
| &spdif { | |
| status = "okay"; | |
| }; |
🤖 Prompt for AI Agents
In
patch/kernel/archive/rockchip64-6.19/board-nanopi-m4v2-dts-add-sound-card.patch
around lines 163 to 167, the &spdif node incorrectly includes I2C timing
properties i2c-scl-rising-time-ns and i2c-scl-falling-time-ns; remove those two
properties from the &spdif node so only valid SPDIF properties remain and leave
status = "okay"; ensure no other I2C-specific props are present in the SPDIF
node.
| +&pwm1 { | ||
| + status = "disabled"; | ||
| + pinctrl-0 = <&pwm1m1_pins>; | ||
| +}; | ||
| + | ||
| +&pwm2 { | ||
| + status = "disabled"; | ||
| + pinctrl-0 = <&pwm2m1_pins>; | ||
| +}; |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Add missing pinctrl-names property to pwm1 and pwm2 nodes.
Both pwm1 and pwm2 nodes define pinctrl-0 but lack the corresponding pinctrl-names property. According to device tree binding standards, when pinctrl-0 is specified, pinctrl-names should be present to name the pin control state (typically "default"). This is inconsistent with the i2c3 node above, which correctly includes pinctrl-names = "default".
Apply this diff to add the missing properties:
&pwm1 {
status = "disabled";
+ pinctrl-names = "default";
pinctrl-0 = <&pwm1m1_pins>;
};
&pwm2 {
status = "disabled";
+ pinctrl-names = "default";
pinctrl-0 = <&pwm2m1_pins>;
};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| +&pwm1 { | |
| + status = "disabled"; | |
| + pinctrl-0 = <&pwm1m1_pins>; | |
| +}; | |
| + | |
| +&pwm2 { | |
| + status = "disabled"; | |
| + pinctrl-0 = <&pwm2m1_pins>; | |
| +}; | |
| &pwm1 { | |
| status = "disabled"; | |
| pinctrl-names = "default"; | |
| pinctrl-0 = <&pwm1m1_pins>; | |
| }; | |
| &pwm2 { | |
| status = "disabled"; | |
| pinctrl-names = "default"; | |
| pinctrl-0 = <&pwm2m1_pins>; | |
| }; |
🤖 Prompt for AI Agents
In
patch/kernel/archive/rockchip64-6.19/board-odroidm1-add-nodes-for-i2c-pwm-uart-spi.patch
around lines 28 to 36, the pwm1 and pwm2 device tree nodes set pinctrl-0 but are
missing the corresponding pinctrl-names property; add pinctrl-names = "default";
to each node (pwm1 and pwm2) so the pinctrl state is named and complies with
device tree binding conventions, matching the i2c3 node above.
| +&uart1 { | ||
| + status = "disabled"; | ||
| + dma-names = "tx", "rx"; | ||
| + /* uart1 uart1-with-ctsrts */ | ||
| + pinctrl-0 = <&uart1m1_xfer>; | ||
| + pinctrl-1 = <&uart1m1_xfer &uart1m1_ctsn &uart1m1_rtsn>; | ||
| +}; |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Add missing pinctrl-names property to uart1 node.
The uart1 node defines both pinctrl-0 and pinctrl-1 (for configurations with and without CTS/RTS flow control) but lacks the corresponding pinctrl-names property. Based on the inline comment and pin configurations, these states should be named appropriately.
Apply this diff to add the missing property:
&uart1 {
status = "disabled";
+ pinctrl-names = "default", "ctsrts";
dma-names = "tx", "rx";
/* uart1 uart1-with-ctsrts */
pinctrl-0 = <&uart1m1_xfer>;
pinctrl-1 = <&uart1m1_xfer &uart1m1_ctsn &uart1m1_rtsn>;
};🤖 Prompt for AI Agents
In
patch/kernel/archive/rockchip64-6.19/board-odroidm1-add-nodes-for-i2c-pwm-uart-spi.patch
around lines 48 to 54, the uart1 device node defines pinctrl-0 and pinctrl-1 but
is missing the corresponding pinctrl-names property; add a pinctrl-names
property listing the two states consistent with the inline comment (for example
pinctrl-names = "uart1", "uart1-with-ctsrts";) placed before the pinctrl-0 and
pinctrl-1 lines so the phandles are correctly named for the default and CTS/RTS
configurations.
| + opp-786000000 { | ||
| + opp-hz = /bits/ 64 <786000000>; | ||
| + opp-microvolt = <1075000 1075000 12000000>; | ||
| + }; | ||
| + opp-798000000 { | ||
| + opp-hz = /bits/ 64 <798000000>; | ||
| + opp-microvolt = <1075000 1075000 12000000>; | ||
| + }; | ||
| + opp-840000000 { | ||
| + opp-hz = /bits/ 64 <840000000>; | ||
| + opp-microvolt = <1075000 1075000 12000000>; | ||
| + }; | ||
| + opp-924000000 { | ||
| + opp-hz = /bits/ 64 <924000000>; | ||
| + opp-microvolt = <1100000 1100000 12000000>; | ||
| + }; | ||
| + opp-1068000000 { | ||
| + opp-hz = /bits/ 64 <1068000000>; | ||
| + opp-microvolt = <1175000 1175000 12000000>; | ||
| + }; |
There was a problem hiding this comment.
Critical: opp-microvolt max value appears incorrect.
The third value in opp-microvolt represents the maximum voltage in microvolts. The value 12000000 (12V) is clearly incorrect for DDR voltage - it should be 1200000 (1.2V).
Compare with board-rk3328-roc-pc.patch which correctly uses 1200000 for the same OPP entries.
Apply this diff to fix the voltage values:
opp-786000000 {
opp-hz = /bits/ 64 <786000000>;
- opp-microvolt = <1075000 1075000 12000000>;
+ opp-microvolt = <1075000 1075000 1200000>;
};
opp-798000000 {
opp-hz = /bits/ 64 <798000000>;
- opp-microvolt = <1075000 1075000 12000000>;
+ opp-microvolt = <1075000 1075000 1200000>;
};
opp-840000000 {
opp-hz = /bits/ 64 <840000000>;
- opp-microvolt = <1075000 1075000 12000000>;
+ opp-microvolt = <1075000 1075000 1200000>;
};
opp-924000000 {
opp-hz = /bits/ 64 <924000000>;
- opp-microvolt = <1100000 1100000 12000000>;
+ opp-microvolt = <1100000 1100000 1200000>;
};
opp-1068000000 {
opp-hz = /bits/ 64 <1068000000>;
- opp-microvolt = <1175000 1175000 12000000>;
+ opp-microvolt = <1175000 1175000 1200000>;
};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| + opp-786000000 { | |
| + opp-hz = /bits/ 64 <786000000>; | |
| + opp-microvolt = <1075000 1075000 12000000>; | |
| + }; | |
| + opp-798000000 { | |
| + opp-hz = /bits/ 64 <798000000>; | |
| + opp-microvolt = <1075000 1075000 12000000>; | |
| + }; | |
| + opp-840000000 { | |
| + opp-hz = /bits/ 64 <840000000>; | |
| + opp-microvolt = <1075000 1075000 12000000>; | |
| + }; | |
| + opp-924000000 { | |
| + opp-hz = /bits/ 64 <924000000>; | |
| + opp-microvolt = <1100000 1100000 12000000>; | |
| + }; | |
| + opp-1068000000 { | |
| + opp-hz = /bits/ 64 <1068000000>; | |
| + opp-microvolt = <1175000 1175000 12000000>; | |
| + }; | |
| opp-786000000 { | |
| opp-hz = /bits/ 64 <786000000>; | |
| opp-microvolt = <1075000 1075000 1200000>; | |
| }; | |
| opp-798000000 { | |
| opp-hz = /bits/ 64 <798000000>; | |
| opp-microvolt = <1075000 1075000 1200000>; | |
| }; | |
| opp-840000000 { | |
| opp-hz = /bits/ 64 <840000000>; | |
| opp-microvolt = <1075000 1075000 1200000>; | |
| }; | |
| opp-924000000 { | |
| opp-hz = /bits/ 64 <924000000>; | |
| opp-microvolt = <1100000 1100000 1200000>; | |
| }; | |
| opp-1068000000 { | |
| opp-hz = /bits/ 64 <1068000000>; | |
| opp-microvolt = <1175000 1175000 1200000>; | |
| }; |
🤖 Prompt for AI Agents
In patch/kernel/archive/rockchip64-6.19/board-rk3328-roc-cc-dts-enable-dmc.patch
around lines 30 to 49 the third element of each opp-microvolt tuple is
incorrectly set to 12000000 (12V); replace those values with 1200000 (1.2V) so
each opp-microvolt line becomes <1075000 1075000 1200000> or <1100000 1100000
1200000> or <1175000 1175000 1200000> respectively to match the correct DDR
voltages used in board-rk3328-roc-pc.patch.
There was a problem hiding this comment.
Can you research who initially added these opp nodes? You may have to search across tags of this repo since blame history may have gotten lost due to copy&paste of whole patch sets on version change.
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for this patch file across different kernel versions in git history
echo "=== Searching for board-rk3328-roc-cc-dts-enable-dmc.patch across git history ==="
git log --all --oneline --name-only -- '**/board-rk3328-roc-cc-dts-enable-dmc.patch' | head -100
echo -e "\n=== Checking for the patch in previous kernel version directories ==="
# List all kernel version directories that exist
fd -t d 'rockchip64-' patch/kernel/archive/ --max-depth 1 | sort -V
echo -e "\n=== Searching for similar patches with roc-cc in older versions ==="
fd -t f 'roc-cc' patch/kernel/archive/
echo -e "\n=== Checking git log for the patch file with full history ==="
git log --all --follow --oneline -- 'patch/kernel/archive/rockchip64-*/board-rk3328-roc-cc-dts-enable-dmc.patch' | head -50
Length of output: 3888
🏁 Script executed:
#!/bin/bash
# Search for the incorrect value "12000000" in opp-microvolt context across git history
echo "=== Searching for commits containing '12000000' in rockchip64 patches ==="
git log --all --oneline -S '12000000' -- 'patch/kernel/archive/rockchip64-*/' | head -50
echo -e "\n=== Search for commits with roc-cc dmc in commit message ==="
git log --all --oneline --grep='roc-cc' --grep='dmc' --all-match | head -30
echo -e "\n=== Check git tags to search across version history ==="
git tag | grep -E 'v[0-9]+\.[0-9]+' | sort -V | tail -20
Length of output: 192
🏁 Script executed:
#!/bin/bash
# Check if the patch exists in rockchip64-6.18 (previous version)
echo "=== Checking for the patch in rockchip64-6.18 ==="
if [ -f "patch/kernel/archive/rockchip64-6.18/board-rk3328-roc-cc-dts-enable-dmc.patch" ]; then
echo "File exists in 6.18"
echo "=== Checking for the incorrect value in 6.18 version ==="
grep -n "12000000" patch/kernel/archive/rockchip64-6.18/board-rk3328-roc-cc-dts-enable-dmc.patch || echo "Value not found in 6.18"
echo -e "\n=== Getting git log for 6.18 version ==="
git log --oneline --follow -- patch/kernel/archive/rockchip64-6.18/board-rk3328-roc-cc-dts-enable-dmc.patch | head -20
else
echo "File does not exist in 6.18"
fi
echo -e "\n=== Searching for who added the 6.19 version ==="
git log --oneline --diff-filter=A -- patch/kernel/archive/rockchip64-6.19/board-rk3328-roc-cc-dts-enable-dmc.patch | head -10
Length of output: 927
🏁 Script executed:
#!/bin/bash
# Get detailed commit info for when the 6.19 file was added
echo "=== Getting detailed commit information for 6.19 patch addition ==="
git log --format="%H|%an|%ae|%ad|%s" --diff-filter=A -- patch/kernel/archive/rockchip64-6.19/board-rk3328-roc-cc-dts-enable-dmc.patch | head -5
echo -e "\n=== Checking the actual content from that commit ==="
COMMIT=$(git log --format="%H" --diff-filter=A -- patch/kernel/archive/rockchip64-6.19/board-rk3328-roc-cc-dts-enable-dmc.patch | head -1)
if [ -n "$COMMIT" ]; then
echo "Commit hash: $COMMIT"
echo -e "\n=== Showing the patch content from that commit ==="
git show "$COMMIT":patch/kernel/archive/rockchip64-6.19/board-rk3328-roc-cc-dts-enable-dmc.patch | grep -A 5 -B 5 "12000000" | head -30
fi
Length of output: 1052
🏁 Script executed:
#!/bin/bash
# Search for the original introduction across all rockchip64 versions
echo "=== Searching all rockchip64 versions for this patch with the incorrect value ==="
for version in patch/kernel/archive/rockchip64-*/; do
version_name=$(basename "$version")
patch_file="${version}board-rk3328-roc-cc-dts-enable-dmc.patch"
if [ -f "$patch_file" ]; then
echo "Found in: $version_name"
if grep -q "12000000" "$patch_file"; then
echo " -> Contains incorrect value 12000000"
# Get the first commit that added this file
git log --format=" First added by: %an <%ae> on %ad" --diff-filter=A -- "$patch_file" | head -1
else
echo " -> Does NOT contain incorrect value"
fi
fi
done
Length of output: 864
🏁 Script executed:
#!/bin/bash
# Check commit c647f409 which appears to be an early mention
echo "=== Examining commit c647f409 ==="
git show --stat c647f409 | head -50
echo -e "\n=== Checking what files were added/modified for roc-cc in that commit ==="
git show c647f409 -- '*roc-cc*' | grep -A 10 -B 5 "12000000" | head -50
Length of output: 4382
🏁 Script executed:
#!/bin/bash
# Search for the very first introduction of this patch in the repo
echo "=== Finding the original commit that added this patch to any version ==="
git log --all --diff-filter=A --format="%H|%an|%ae|%ad|%s" -- '**/board-rk3328-roc-cc-dts-enable-dmc.patch' | tail -5
echo -e "\n=== Checking if there are versions before 6.6 ==="
git log --all --oneline -- 'patch/kernel/archive/rockchip64-*/board-rk3328-roc-cc-dts-enable-dmc.patch' | tail -20
Length of output: 1168
🏁 Script executed:
#!/bin/bash
# Check the commit from efectn on Nov 30, 2024 - find the exact commit hash
echo "=== Finding the exact commit by efectn that introduced this ==="
git log --all --author="efectn" --since="2024-11-29" --until="2024-12-01" --oneline | head -20
echo -e "\n=== Check for rockchip64 versions before 6.6 ==="
fd -t d 'rockchip64-' patch/kernel/archive/ --max-depth 1 | sort -V | head -20
Length of output: 383
🏁 Script executed:
#!/bin/bash
# Look at the commit from efectn
echo "=== Looking for the commit c647f409 details ==="
git show c647f409 --format=fuller | head -100
Length of output: 2805
🏁 Script executed:
#!/bin/bash
# Get the actual first commit that introduced this patch
echo "=== Getting the ACTUAL first commit that added this patch file ==="
OLDEST_COMMIT=$(git log --all --diff-filter=A --format="%H" -- '**/board-rk3328-roc-cc-dts-enable-dmc.patch' | tail -1)
if [ -n "$OLDEST_COMMIT" ]; then
echo "Oldest commit: $OLDEST_COMMIT"
echo -e "\n=== Commit details ==="
git show --stat --format=fuller "$OLDEST_COMMIT" | head -50
echo -e "\n=== Checking if this commit has the incorrect value ==="
git show "$OLDEST_COMMIT" -- '**/board-rk3328-roc-cc-dts-enable-dmc.patch' | grep -A 2 -B 2 "12000000" | head -20
fi
Length of output: 3713
@EvilOlaf, I've traced the origin of these OPP nodes with the incorrect voltage values:
Original Introduction
Author: Muhammed Efe Cetin (efectn@protonmail.com)
Commit: c647f409b206ccf7404b0dbde24f702c230d4b36
Date: November 30, 2024 at 02:45:25 +0300
Committed by: Igor (igor@armbian.com)
Commit message: "nanopi-r6s: fix mmc0/mmc1 ordering"
The incorrect value 12000000 (12V) was present from the very first introduction of this patch. This commit appears to have been a large restructuring that added the entire repository structure (including .github/, .editorconfig, etc.) along with the patch files.
Propagation Path
The patch with the incorrect voltage values then propagated through version bumps:
- rockchip64-6.6, 6.9, 6.12: Added by efectn on Nov 30, 2024
- rockchip64-6.18: Copied during version bump by Jianfeng Liu on Oct 13, 2025
- rockchip64-6.19: Copied during your version bump on Dec 14, 2025
All versions from 6.6 onwards contain this error, and there are no earlier versions in the archive with this patch file.
The issue should be fixed across all affected versions (6.6, 6.9, 6.12, 6.18, and 6.19) by changing the third value in each opp-microvolt tuple from 12000000 to 1200000.
🧠 Learnings used
Learnt from: EvilOlaf
Repo: armbian/build PR: 9086
File: patch/kernel/archive/uefi-arm64-6.19/net-stmicro-stmmac-Phytium-onboard-ethernet-drivers-and-ACPI-glue-for-6.x.patch.disabled:625-633
Timestamp: 2025-12-21T10:28:41.028Z
Learning: The patch "net-stmicro-stmmac-Phytium-onboard-ethernet-drivers-and-ACPI-glue-for-6.x.patch" in patch/kernel/archive/uefi-arm64-6.19/ is known to break compilation on kernel 6.19 and is therefore disabled (has .disabled extension).
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:222-230
Timestamp: 2025-09-14T06:32:29.806Z
Learning: In the Armbian build system, the write_uboot_platform() function implementations follow different patterns across Rockchip family files. The newer standard (used in rockchip64_common.inc and rk3506) includes 'status=none' parameter in dd commands, while older implementations (rk3288, rk322x) use an older pattern without this parameter. The rk3506 implementation correctly follows the current Rockchip family standard.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8968
File: patch/u-boot/u-boot-sunxi/arm64-dts-sun50i-h6-orangepi.dtsi-Rollback-r_rsb-to-r_i2c.patch:36-36
Timestamp: 2025-11-20T18:20:11.985Z
Learning: The rewrite-patches tool (REWRITE_PATCHES=yes) in the Armbian build system can inadvertently introduce semantic changes when the u-boot/kernel git base revision differs from expected state. The tool applies patches, commits them, and re-exports them using git format-patch, which can cause the re-exported patch to reflect the base revision's state rather than preserving the original patch intent. This is particularly problematic for device tree changes like interrupt specifications. The tool currently lacks validation mechanisms to detect such semantic drift, and affected patches must be manually corrected after rewriting.
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-17T05:09:02.306Z
Learning: In the Armbian build system, kernel patches (e.g., in patch/kernel/archive/sunxi-6.18/patches.armbian/) contain device tree overlays and other code that have existed for years and are maintained/ported across kernel versions. When reviewing PRs that modify these patch files, focus on the actual changes being made (e.g., Makefile fixes, new additions) rather than reviewing the entire existing content within the patch as if it were new code. The patch file contents are existing, stable code unless explicitly modified in the PR diff.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-19T13:56:45.124Z
Learning: When reviewing kernel or u-boot version bump PRs in the Armbian build system, check if patches existed in previous kernel version directories (e.g., sunxi-6.12, sunxi-6.13) before describing them as new features. If a patch and the majority of its contents existed previously with no major functionality changes, focus the review on the actual changes: the version bump itself and patch compatibility adjustments. Don't describe existing patches being ported/maintained across versions as new features or drivers—this is misleading. The patches are existing code being re-aligned to work with the new upstream version.
Learnt from: EvilOlaf
Repo: armbian/build PR: 9096
File: patch/kernel/archive/sunxi-6.18/patches.armbian/arm64-dts-sun50i-h616-add-overlays.patch:4-5
Timestamp: 2025-12-17T15:46:22.709Z
Learning: In Armbian kernel patches, when patches are renamed or reorganized, the old Subject line may be intentionally preserved in the patch header (as a second Subject line) for archival/historical purposes to document the previous patch name. This is an Armbian-specific practice for tracking patch evolution and should not be flagged as an error when the maintainer has intentionally included it for documentation.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub API (https://api.github.com/repos/armbian/build/pulls/{pr_number}/files) to get the complete picture of what files are being added or modified, especially for U-Boot patches that will be applied during the build process.
Learnt from: rpardini
Repo: armbian/build PR: 8044
File: patch/u-boot/v2025.04/cmd-fileenv-read-string-from-file-into-env.patch:76-86
Timestamp: 2025-03-31T22:20:48.475Z
Learning: For the Armbian build project, maintaining consistency with existing patches across U-Boot versions (such as between 2025.01 and 2025.04) is prioritized over refactoring individual patches for code improvements.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub or the PR API to get the complete picture of what files are being added or modified.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
patch/kernel/archive/rockchip64-6.19/drv-spi-spidev-remove-warnings.patch
Show resolved
Hide resolved
| u3phy: usb3-phy@ff470000 { | ||
| compatible = "rockchip,rk3328-u3phy"; | ||
| reg = <0x0 0xff470000 0x0 0x0>; | ||
| rockchip,u3phygrf = <&usb3phy_grf>; |
There was a problem hiding this comment.
Invalid USB3 PHY register size.
The register size 0x0 is invalid for the u3phy parent node. The correct register size is 0x10000 (64K), which encompasses the combined USB3PHY register space.
u3phy: usb3-phy@ff470000 {
compatible = "rockchip,rk3328-u3phy";
- reg = <0x0 0xff470000 0x0 0x0>;
+ reg = <0x0 0xff470000 0x0 0x10000>;
rockchip,u3phygrf = <&usb3phy_grf>;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| u3phy: usb3-phy@ff470000 { | |
| compatible = "rockchip,rk3328-u3phy"; | |
| reg = <0x0 0xff470000 0x0 0x0>; | |
| rockchip,u3phygrf = <&usb3phy_grf>; | |
| u3phy: usb3-phy@ff470000 { | |
| compatible = "rockchip,rk3328-u3phy"; | |
| reg = <0x0 0xff470000 0x0 0x10000>; | |
| rockchip,u3phygrf = <&usb3phy_grf>; |
🤖 Prompt for AI Agents
In patch/kernel/archive/rockchip64-6.19/dt/rk3328-mksklipad50.dts around lines
153-156, the u3phy node's reg property uses an invalid size of 0x0; replace the
final cell with 0x10000 so the reg becomes <0x0 0xff470000 0x0 0x10000>,
ensuring the parent node covers the full 64K USB3PHY register space.
| snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>; | ||
| snps,reset-active-low; |
There was a problem hiding this comment.
GPIO conflict: same pin used for GMAC reset and WiFi enable.
GPIO1_PC2 (<&gpio1 RK_PC2>) is used for both:
- Line 202:
sdio_pwrseq0reset-gpios for WiFi - Line 273:
gmac2iosnps,reset-gpio for Ethernet PHY
This will cause conflicts at runtime.
Verify the correct GPIO assignments from the board schematic and fix the conflict.
Also applies to: 198-203
rockpro64: IEP driver
|
I successfully tested H.264, HEVC and MPEG2 HW decoding and HW deinterlacing on RockPro64 (RK3399) with your branch. |
The deleted patch is not necessary because rkvdec patch v7 has removed h264 sps check at start. And future version of chromium can also get rid of the issue that patch has fixed.
|
Added rkvdec patches v7 from https://patchwork.kernel.org/project/linux-rockchip/cover/20251218232829.337811-1-detlev.casanova@collabora.com/. H264 and HEVC tested on rk3588. |
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…02.dts Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (6)
patch/kernel/archive/rockchip64-6.19/dt/rk3328-nanopi-neo3-rev02.dts (4)
34-54: Fix indentation: use tabs consistently.Lines 39 and 50-54 use spaces for indentation, while the rest of the file uses tabs. This inconsistency can cause issues with tooling and future patch application.
🔎 Proposed fix
i2s-sound { compatible = "simple-audio-card"; simple-audio-card,format = "i2s"; simple-audio-card,mclk-fs = <256>; simple-audio-card,name = "I2S Out"; - status = "okay"; + status = "okay"; simple-audio-card,cpu { sound-dai = <&i2s1>; }; simple-audio-card,codec { sound-dai = <&pcm5102>; }; }; - pcm5102: pcm510x { - #sound-dai-cells = <0>; - compatible = "ti,pcm5102a"; - pcm510x,format = "i2s"; - }; + pcm5102: pcm510x { + #sound-dai-cells = <0>; + compatible = "ti,pcm5102a"; + pcm510x,format = "i2s"; + };
91-101: Fix indentation on line 92.Line 92 uses spaces instead of a tab for indentation, inconsistent with the rest of the file.
🔎 Proposed fix
&i2s1 { - rockchip,playback-channels = <2>; - pinctrl-names = "default"; + rockchip,playback-channels = <2>; + pinctrl-names = "default"; pinctrl-0 = <&i2s1_mclk &i2s1_sclk &i2s1_lrcktx &i2s1_lrckrx &i2s1_sdo &i2s1_sdi>; status = "okay"; };
103-106: Fix indentation in SPDIF node.Lines 104-105 use spaces instead of tabs for indentation.
🔎 Proposed fix
&spdif { - status = "okay"; - pinctrl-0 = <&spdifm0_tx>; + status = "okay"; + pinctrl-0 = <&spdifm0_tx>; };
191-194: Previous critical typo fixed correctly.The
pinctrl-0property is now correctly spelled (waspinctl-0in previous review). However, note minor style inconsistencies: missing space after&uart1on line 191, and lines 192-193 use spaces instead of tabs for indentation.🔎 Optional style fixes
-&uart1{ - status = "okay"; - pinctrl-0 = <&uart1_xfer>; +&uart1 { + status = "okay"; + pinctrl-0 = <&uart1_xfer>; };patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts (2)
462-467: Non-upstream compatible string for spidev.The compatible string
"rockchip,spidev"is not acceptable in upstream kernel device trees. The spidev driver should only bind to actual hardware device strings or remain generic. This pattern is rejected by upstream maintainers.If this is specifically for Armbian userspace SPI access, it may work in practice, but be aware it won't be upstreamable and may break if kernel policies change.
437-453: Mixed indentation in mdio block.The mdio and ethernet-phy nodes use inconsistent indentation mixing spaces and tabs. Device tree files conventionally use tabs for indentation. Consider standardizing to tabs for consistency with the rest of the file.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
patch/kernel/archive/rockchip64-6.19/dt/rk3328-nanopi-neo3-rev02.dts(1 hunks)patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts(1 hunks)
🧰 Additional context used
🧠 Learnings (8)
📓 Common learnings
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-19T13:56:45.124Z
Learning: When reviewing kernel or u-boot version bump PRs in the Armbian build system, check if patches existed in previous kernel version directories (e.g., sunxi-6.12, sunxi-6.13) before describing them as new features. If a patch and the majority of its contents existed previously with no major functionality changes, focus the review on the actual changes: the version bump itself and patch compatibility adjustments. Don't describe existing patches being ported/maintained across versions as new features or drivers—this is misleading. The patches are existing code being re-aligned to work with the new upstream version.
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-17T05:09:02.306Z
Learning: In the Armbian build system, kernel patches (e.g., in patch/kernel/archive/sunxi-6.18/patches.armbian/) contain device tree overlays and other code that have existed for years and are maintained/ported across kernel versions. When reviewing PRs that modify these patch files, focus on the actual changes being made (e.g., Makefile fixes, new additions) rather than reviewing the entire existing content within the patch as if it were new code. The patch file contents are existing, stable code unless explicitly modified in the PR diff.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub API (https://api.github.com/repos/armbian/build/pulls/{pr_number}/files) to get the complete picture of what files are being added or modified, especially for U-Boot patches that will be applied during the build process.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub or the PR API to get the complete picture of what files are being added or modified.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8968
File: patch/u-boot/u-boot-sunxi/arm64-dts-sun50i-h6-orangepi.dtsi-Rollback-r_rsb-to-r_i2c.patch:36-36
Timestamp: 2025-11-20T18:20:11.985Z
Learning: The rewrite-patches tool (REWRITE_PATCHES=yes) in the Armbian build system can inadvertently introduce semantic changes when the u-boot/kernel git base revision differs from expected state. The tool applies patches, commits them, and re-exports them using git format-patch, which can cause the re-exported patch to reflect the base revision's state rather than preserving the original patch intent. This is particularly problematic for device tree changes like interrupt specifications. The tool currently lacks validation mechanisms to detect such semantic drift, and affected patches must be manually corrected after rewriting.
Learnt from: EvilOlaf
Repo: armbian/build PR: 9086
File: patch/kernel/archive/uefi-arm64-6.19/net-stmicro-stmmac-Phytium-onboard-ethernet-drivers-and-ACPI-glue-for-6.x.patch.disabled:625-633
Timestamp: 2025-12-21T10:28:41.028Z
Learning: The patch "net-stmicro-stmmac-Phytium-onboard-ethernet-drivers-and-ACPI-glue-for-6.x.patch" in patch/kernel/archive/uefi-arm64-6.19/ is known to break compilation on kernel 6.19 and is therefore disabled (has .disabled extension).
Learnt from: tabrisnet
Repo: armbian/build PR: 8746
File: config/sources/families/filogic.conf:61-68
Timestamp: 2025-10-13T02:26:18.249Z
Learning: In the Armbian build system, the "edge" kernel branch is intended to be bleeding-edge and experimental. It does not require hardware testing or stability verification before merging, as it's expected to contain potentially unstable or untested code for early adopters and developers.
Learnt from: HackingGate
Repo: armbian/build PR: 8665
File: config/boards/photonicat2.csc:4-4
Timestamp: 2025-10-26T10:41:35.118Z
Learning: In the Armbian build system, rk3576 boards consistently use BOARDFAMILY="rk35xx" for both vendor and edge kernel targets. The rk35xx family configuration sources rockchip64_common.inc, which provides edge and current kernel branch definitions, making these branches available even though they're not defined directly in rk35xx.conf.
Learnt from: rpardini
Repo: armbian/build PR: 8879
File: config/sources/families/uefi-x86.conf:0-0
Timestamp: 2025-11-06T15:36:04.682Z
Learning: As of PR #8879, the uefi-x86 family in the Armbian build system now includes kernel patches for the first time. The current and edge branches for uefi-x86 are specifically configured for Apple T2-based x86 machines, including T2-specific patches from the linux-t2 project and custom kernel configuration options for Apple hardware drivers.
Learnt from: SuperKali
Repo: armbian/build PR: 8608
File: lib/functions/compilation/patch/drivers_network.sh:361-363
Timestamp: 2025-09-11T06:06:52.328Z
Learning: For the RTW88 SDIO RF path detection fix patch (004-rtw88-sdio-rf-path-detection-fix.patch), SuperKali prefers using exact version matching (eq 6.1 || eq 6.16) rather than range checks, as the patch has only been tested on those specific kernel versions and may be mainstreamed soon.
Learnt from: tabrisnet
Repo: armbian/build PR: 9058
File: config/sources/families/spacemit.conf:39-45
Timestamp: 2025-12-12T23:10:00.819Z
Learning: In the Armbian build system, vendor kernel forks can use "vendor-edge" branch naming for bleeding-edge or pre-release vendor kernels, as demonstrated in config/sources/families/k3.conf. The typical vendor branch naming pattern is: "vendor" or "vendor-rt" for stable vendor releases, and "vendor-edge" for bleeding-edge/pre-release vendor versions. The "edge" naming without "vendor-" prefix is reserved for mainline kernel branches.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:10:25.610Z
Learning: In the Armbian build system, rk32xx and rk33xx Rockchip SoCs no longer have BSP-based (vendor) kernel branches. The rk3506 is the first 32-bit Rockchip SoC to use the vendor branch in the current codebase.
Learnt from: amazingfate
Repo: armbian/build PR: 8453
File: lib/functions/compilation/patch/drivers_network.sh:213-216
Timestamp: 2025-08-02T14:59:28.145Z
Learning: The wireless driver patches wireless-rtl8812au-Fix-6.16.patch, wireless-rtl8811cu-Fix-6.16.patch, and wireless-rtl88x2bu-Fix-6.16.patch in the Armbian build system are backward compatible and can be applied unconditionally without version checks, even though they're named for 6.16+ fixes.
📚 Learning: 2025-12-17T05:09:02.306Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-17T05:09:02.306Z
Learning: In the Armbian build system, kernel patches (e.g., in patch/kernel/archive/sunxi-6.18/patches.armbian/) contain device tree overlays and other code that have existed for years and are maintained/ported across kernel versions. When reviewing PRs that modify these patch files, focus on the actual changes being made (e.g., Makefile fixes, new additions) rather than reviewing the entire existing content within the patch as if it were new code. The patch file contents are existing, stable code unless explicitly modified in the PR diff.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dtspatch/kernel/archive/rockchip64-6.19/dt/rk3328-nanopi-neo3-rev02.dts
📚 Learning: 2025-11-08T06:39:24.527Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dtspatch/kernel/archive/rockchip64-6.19/dt/rk3328-nanopi-neo3-rev02.dts
📚 Learning: 2025-12-19T13:56:45.124Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-19T13:56:45.124Z
Learning: When reviewing kernel or u-boot version bump PRs in the Armbian build system, check if patches existed in previous kernel version directories (e.g., sunxi-6.12, sunxi-6.13) before describing them as new features. If a patch and the majority of its contents existed previously with no major functionality changes, focus the review on the actual changes: the version bump itself and patch compatibility adjustments. Don't describe existing patches being ported/maintained across versions as new features or drivers—this is misleading. The patches are existing code being re-aligned to work with the new upstream version.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dtspatch/kernel/archive/rockchip64-6.19/dt/rk3328-nanopi-neo3-rev02.dts
📚 Learning: 2025-11-20T18:20:11.985Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8968
File: patch/u-boot/u-boot-sunxi/arm64-dts-sun50i-h6-orangepi.dtsi-Rollback-r_rsb-to-r_i2c.patch:36-36
Timestamp: 2025-11-20T18:20:11.985Z
Learning: The rewrite-patches tool (REWRITE_PATCHES=yes) in the Armbian build system can inadvertently introduce semantic changes when the u-boot/kernel git base revision differs from expected state. The tool applies patches, commits them, and re-exports them using git format-patch, which can cause the re-exported patch to reflect the base revision's state rather than preserving the original patch intent. This is particularly problematic for device tree changes like interrupt specifications. The tool currently lacks validation mechanisms to detect such semantic drift, and affected patches must be manually corrected after rewriting.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dtspatch/kernel/archive/rockchip64-6.19/dt/rk3328-nanopi-neo3-rev02.dts
📚 Learning: 2025-12-08T04:43:44.601Z
Learnt from: Lemon1151
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-08T04:43:44.601Z
Learning: On the rk3399-fine3399 board, the PWM fan requires cooling-levels to extend to 255 (full duty cycle) in the device tree. With cooling-levels ending at 160, the fan fails to spin up even when temperature exceeds the thermal threshold. This is a hardware characteristic specific to this board's fan configuration.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
📚 Learning: 2025-11-15T14:33:30.654Z
Learnt from: SuperKali
Repo: armbian/build PR: 8936
File: patch/kernel/archive/rockchip64-6.18/dt/rk3576-nanopi-r76s.dts:800-802
Timestamp: 2025-11-15T14:33:30.654Z
Learning: In RK3576 device tree files (like rk3576-nanopi-r76s.dts), the serial0 alias is already defined in the upstream kernel's rk3576.dtsi base file, so board-specific DTS files do not need to redeclare it when enabling &uart0 for serial console.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3328-nanopi-neo3-rev02.dts
📚 Learning: 2025-12-13T11:45:02.422Z
Learnt from: pyavitz
Repo: armbian/build PR: 9058
File: patch/u-boot/legacy/u-boot-spacemit-k1/003-SpacemiT-K1X-Fixups.patch:17-25
Timestamp: 2025-12-13T11:45:02.422Z
Learning: In the SpacemiT U-Boot patches for Armbian (patch/u-boot/legacy/u-boot-spacemit-k1/), the environment variable `devnum` is set to the device name string (e.g., "mmc", "nvme") rather than a numeric index, and `distro_bootpart` holds the partition number. This implementation aligns with mainline U-Boot conventions for the SpacemiT platform and has been verified to work correctly by the maintainer.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3328-nanopi-neo3-rev02.dts
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
Outdated
Show resolved
Hide resolved
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
Outdated
Show resolved
Hide resolved
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts (1)
212-212: Incorrect status property values:"disable"should be"disabled".Multiple nodes use
status = "disable";which is incorrect device tree syntax. The valid value is"disabled"(with the 'd' suffix). This affects:
- Line 212: spdif-sound
- Line 224: spdif_out
- Line 230: pwm_bl
- Line 457: spi1
- Line 870: spdif
- Line 1260: hdmi_in_vopl
- Line 1264: dp_in_vopb (additional occurrence not in previous review)
Also applies to: 224-224, 230-230, 457-457, 870-870, 1260-1260, 1264-1264
🧹 Nitpick comments (2)
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts (2)
436-452: Consider fixing inconsistent indentation in MDIO section.The MDIO node and its child have inconsistent indentation (mixed tabs/spaces and varying indent levels). While functionally correct, this affects readability.
🔎 Proposed fix
mdio { compatible = "snps,dwmac-mdio"; - #address-cells = <1>; - #size-cells = <0>; - yt8531c: ethernet-phy@0 { + #address-cells = <1>; + #size-cells = <0>; + + yt8531c: ethernet-phy@0 { compatible = "ethernet-phy-id4f51.e91b", "ethernet-phy-ieee802.3-c22"; - reg = <0>; + reg = <0>; pinctrl-names = "default"; pinctrl-0 = <&phy_intb>; - motorcomm,clk-out-frequency-hz = <125000000>; - motorcomm,keep-pll-enabled; - motorcomm,auto-sleep-disabled; + motorcomm,clk-out-frequency-hz = <125000000>; + motorcomm,keep-pll-enabled; + motorcomm,auto-sleep-disabled; interrupt-parent = <&gpio3>; interrupts = <RK_PB2 IRQ_TYPE_LEVEL_LOW>; - }; - }; + }; + };
100-110: Optional: Consider removing or documenting commented-out regulator.The
vcc_0v9regulator is commented out. If it's intentionally disabled because the PMIC handles it internally, a brief comment explaining this would improve clarity. Otherwise, consider removing dead code.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts(1 hunks)
🧰 Additional context used
🧠 Learnings (6)
📓 Common learnings
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-19T13:56:45.124Z
Learning: When reviewing kernel or u-boot version bump PRs in the Armbian build system, check if patches existed in previous kernel version directories (e.g., sunxi-6.12, sunxi-6.13) before describing them as new features. If a patch and the majority of its contents existed previously with no major functionality changes, focus the review on the actual changes: the version bump itself and patch compatibility adjustments. Don't describe existing patches being ported/maintained across versions as new features or drivers—this is misleading. The patches are existing code being re-aligned to work with the new upstream version.
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-17T05:09:02.306Z
Learning: In the Armbian build system, kernel patches (e.g., in patch/kernel/archive/sunxi-6.18/patches.armbian/) contain device tree overlays and other code that have existed for years and are maintained/ported across kernel versions. When reviewing PRs that modify these patch files, focus on the actual changes being made (e.g., Makefile fixes, new additions) rather than reviewing the entire existing content within the patch as if it were new code. The patch file contents are existing, stable code unless explicitly modified in the PR diff.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub API (https://api.github.com/repos/armbian/build/pulls/{pr_number}/files) to get the complete picture of what files are being added or modified, especially for U-Boot patches that will be applied during the build process.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8968
File: patch/u-boot/u-boot-sunxi/arm64-dts-sun50i-h6-orangepi.dtsi-Rollback-r_rsb-to-r_i2c.patch:36-36
Timestamp: 2025-11-20T18:20:11.985Z
Learning: The rewrite-patches tool (REWRITE_PATCHES=yes) in the Armbian build system can inadvertently introduce semantic changes when the u-boot/kernel git base revision differs from expected state. The tool applies patches, commits them, and re-exports them using git format-patch, which can cause the re-exported patch to reflect the base revision's state rather than preserving the original patch intent. This is particularly problematic for device tree changes like interrupt specifications. The tool currently lacks validation mechanisms to detect such semantic drift, and affected patches must be manually corrected after rewriting.
Learnt from: EvilOlaf
Repo: armbian/build PR: 9086
File: patch/kernel/archive/uefi-arm64-6.19/net-stmicro-stmmac-Phytium-onboard-ethernet-drivers-and-ACPI-glue-for-6.x.patch.disabled:625-633
Timestamp: 2025-12-21T10:28:41.028Z
Learning: The patch "net-stmicro-stmmac-Phytium-onboard-ethernet-drivers-and-ACPI-glue-for-6.x.patch" in patch/kernel/archive/uefi-arm64-6.19/ is known to break compilation on kernel 6.19 and is therefore disabled (has .disabled extension).
Learnt from: HackingGate
Repo: armbian/build PR: 8665
File: config/boards/photonicat2.csc:4-4
Timestamp: 2025-10-26T10:41:35.118Z
Learning: In the Armbian build system, rk3576 boards consistently use BOARDFAMILY="rk35xx" for both vendor and edge kernel targets. The rk35xx family configuration sources rockchip64_common.inc, which provides edge and current kernel branch definitions, making these branches available even though they're not defined directly in rk35xx.conf.
Learnt from: tabrisnet
Repo: armbian/build PR: 8746
File: config/sources/families/filogic.conf:61-68
Timestamp: 2025-10-13T02:26:18.249Z
Learning: In the Armbian build system, the "edge" kernel branch is intended to be bleeding-edge and experimental. It does not require hardware testing or stability verification before merging, as it's expected to contain potentially unstable or untested code for early adopters and developers.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:10:25.610Z
Learning: In the Armbian build system, rk32xx and rk33xx Rockchip SoCs no longer have BSP-based (vendor) kernel branches. The rk3506 is the first 32-bit Rockchip SoC to use the vendor branch in the current codebase.
Learnt from: rpardini
Repo: armbian/build PR: 8879
File: config/sources/families/uefi-x86.conf:0-0
Timestamp: 2025-11-06T15:36:04.682Z
Learning: As of PR #8879, the uefi-x86 family in the Armbian build system now includes kernel patches for the first time. The current and edge branches for uefi-x86 are specifically configured for Apple T2-based x86 machines, including T2-specific patches from the linux-t2 project and custom kernel configuration options for Apple hardware drivers.
Learnt from: tabrisnet
Repo: armbian/build PR: 9058
File: config/sources/families/spacemit.conf:39-45
Timestamp: 2025-12-12T23:10:00.819Z
Learning: In the Armbian build system, vendor kernel forks can use "vendor-edge" branch naming for bleeding-edge or pre-release vendor kernels, as demonstrated in config/sources/families/k3.conf. The typical vendor branch naming pattern is: "vendor" or "vendor-rt" for stable vendor releases, and "vendor-edge" for bleeding-edge/pre-release vendor versions. The "edge" naming without "vendor-" prefix is reserved for mainline kernel branches.
Learnt from: SuperKali
Repo: armbian/build PR: 8608
File: lib/functions/compilation/patch/drivers_network.sh:361-363
Timestamp: 2025-09-11T06:06:52.328Z
Learning: For the RTW88 SDIO RF path detection fix patch (004-rtw88-sdio-rf-path-detection-fix.patch), SuperKali prefers using exact version matching (eq 6.1 || eq 6.16) rather than range checks, as the patch has only been tested on those specific kernel versions and may be mainstreamed soon.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.
📚 Learning: 2025-12-17T05:09:02.306Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-17T05:09:02.306Z
Learning: In the Armbian build system, kernel patches (e.g., in patch/kernel/archive/sunxi-6.18/patches.armbian/) contain device tree overlays and other code that have existed for years and are maintained/ported across kernel versions. When reviewing PRs that modify these patch files, focus on the actual changes being made (e.g., Makefile fixes, new additions) rather than reviewing the entire existing content within the patch as if it were new code. The patch file contents are existing, stable code unless explicitly modified in the PR diff.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
📚 Learning: 2025-11-08T06:39:24.527Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
📚 Learning: 2025-12-19T13:56:45.124Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-19T13:56:45.124Z
Learning: When reviewing kernel or u-boot version bump PRs in the Armbian build system, check if patches existed in previous kernel version directories (e.g., sunxi-6.12, sunxi-6.13) before describing them as new features. If a patch and the majority of its contents existed previously with no major functionality changes, focus the review on the actual changes: the version bump itself and patch compatibility adjustments. Don't describe existing patches being ported/maintained across versions as new features or drivers—this is misleading. The patches are existing code being re-aligned to work with the new upstream version.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
📚 Learning: 2025-11-20T18:20:11.985Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8968
File: patch/u-boot/u-boot-sunxi/arm64-dts-sun50i-h6-orangepi.dtsi-Rollback-r_rsb-to-r_i2c.patch:36-36
Timestamp: 2025-11-20T18:20:11.985Z
Learning: The rewrite-patches tool (REWRITE_PATCHES=yes) in the Armbian build system can inadvertently introduce semantic changes when the u-boot/kernel git base revision differs from expected state. The tool applies patches, commits them, and re-exports them using git format-patch, which can cause the re-exported patch to reflect the base revision's state rather than preserving the original patch intent. This is particularly problematic for device tree changes like interrupt specifications. The tool currently lacks validation mechanisms to detect such semantic drift, and affected patches must be manually corrected after rewriting.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
📚 Learning: 2025-12-08T04:43:44.601Z
Learnt from: Lemon1151
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-08T04:43:44.601Z
Learning: On the rk3399-fine3399 board, the PWM fan requires cooling-levels to extend to 255 (full duty cycle) in the device tree. With cooling-levels ending at 160, the fan fails to spin up even when temperature exceeds the thermal threshold. This is a hardware characteristic specific to this board's fan configuration.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
🔇 Additional comments (6)
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts (6)
1-54: LGTM!License headers, includes, and root regulator hierarchy are well-structured. The regulator supply chain (vcc_sys → vcc5v0_sys → USB rails) follows proper power sequencing.
519-752: LGTM!PMIC configuration is comprehensive with proper regulator definitions, voltage ranges, and suspend state handling for RK808, SYR827 (CPU-B), and SYR828 (GPU).
785-853: LGTM!USB Type-C configuration with FUSB302, USB-PD negotiation, and DisplayPort alternate mode is well-structured. The port endpoint wiring to tcphy0 and u2phy0 follows the standard RK3399 pattern.
1297-1353: LGTM!Thermal configuration is well-documented with appropriate trip points. The lowered critical temperature (90°C) based on observed hardware behavior is a sensible safety margin. The cooling maps properly implement progressive throttling from big cores to all cores plus DMC.
1111-1253: LGTM!Pinctrl definitions are well-organized. The
/delete-node/ hdmi-i2c-xferis correct since HDMI DDC is routed through i2c7 (per line 516). GPIO configurations and drive strengths are appropriate for the peripherals.
1-1353: Overall: Device tree is well-structured with minor issues to address.This comprehensive DTS for OrangePi 4 LTS covers all major RK3399 subsystems including PMIC/regulators, USB Type-C with PD and DP-altmode, audio codecs, network (YT8531C PHY), and thermal management. The thermal trip points are appropriately conservative based on documented hardware observations.
Key items to fix before merge:
- Replace all
status = "disable"with"disabled"(7 occurrences)- Remove misplaced I2C properties from SPDIF node
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (12)
config/sources/mainline-kernel.conf.shpatch/kernel/archive/rockchip64-6.19/general-drm-panel-add-yixian-yx0345-panel.patchpatch/kernel/archive/rockchip64-6.19/general-rt5651-add-mclk.patchpatch/kernel/archive/rockchip64-6.19/general-v4l2-iep-driver.patchpatch/kernel/archive/rockchip64-6.19/media-0002-media-rkvdec-remove-vb2_is_busy-check-in-rkvdec_s_ct.patchpatch/kernel/archive/rockchip64-6.19/net-ethernet-realtek-add-r8169-LED-configuration-from-OF.patchpatch/kernel/archive/rockchip64-6.19/rk3308-0001-pinctrl-slew-mux.patchpatch/kernel/archive/rockchip64-6.19/rk3308-fix-10mbit-ethernet.patchpatch/kernel/archive/rockchip64-6.19/rk3399-sd-drive-level-8ma.patchpatch/kernel/archive/rockchip64-6.19/rk3399-sd-pwr-pinctrl.patchpatch/kernel/archive/rockchip64-6.19/rk3399-usbc-usb-typec-altmodes-displayport-Respect-DP_CAP_RECEPT.patchpatch/kernel/archive/rockchip64-6.19/rk35xx-montjoie-crypto-v2-rk35xx.patch
🧰 Additional context used
🧠 Learnings (12)
📓 Common learnings
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-19T13:56:45.124Z
Learning: When reviewing kernel or u-boot version bump PRs in the Armbian build system, check if patches existed in previous kernel version directories (e.g., sunxi-6.12, sunxi-6.13) before describing them as new features. If a patch and the majority of its contents existed previously with no major functionality changes, focus the review on the actual changes: the version bump itself and patch compatibility adjustments. Don't describe existing patches being ported/maintained across versions as new features or drivers—this is misleading. The patches are existing code being re-aligned to work with the new upstream version.
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-17T05:09:02.306Z
Learning: In the Armbian build system, kernel patches (e.g., in patch/kernel/archive/sunxi-6.18/patches.armbian/) contain device tree overlays and other code that have existed for years and are maintained/ported across kernel versions. When reviewing PRs that modify these patch files, focus on the actual changes being made (e.g., Makefile fixes, new additions) rather than reviewing the entire existing content within the patch as if it were new code. The patch file contents are existing, stable code unless explicitly modified in the PR diff.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8968
File: patch/u-boot/u-boot-sunxi/arm64-dts-sun50i-h6-orangepi.dtsi-Rollback-r_rsb-to-r_i2c.patch:36-36
Timestamp: 2025-11-20T18:20:11.985Z
Learning: The rewrite-patches tool (REWRITE_PATCHES=yes) in the Armbian build system can inadvertently introduce semantic changes when the u-boot/kernel git base revision differs from expected state. The tool applies patches, commits them, and re-exports them using git format-patch, which can cause the re-exported patch to reflect the base revision's state rather than preserving the original patch intent. This is particularly problematic for device tree changes like interrupt specifications. The tool currently lacks validation mechanisms to detect such semantic drift, and affected patches must be manually corrected after rewriting.
Learnt from: EvilOlaf
Repo: armbian/build PR: 9096
File: patch/kernel/archive/sunxi-6.18/patches.armbian/arm64-dts-sun50i-h616-add-overlays.patch:4-5
Timestamp: 2025-12-17T15:46:22.709Z
Learning: In Armbian kernel patches, when patches are renamed or reorganized, the old Subject line may be intentionally preserved in the patch header (as a second Subject line) for archival/historical purposes to document the previous patch name. This is an Armbian-specific practice for tracking patch evolution and should not be flagged as an error when the maintainer has intentionally included it for documentation.
Learnt from: rpardini
Repo: armbian/build PR: 8044
File: patch/u-boot/v2025.04/cmd-fileenv-read-string-from-file-into-env.patch:76-86
Timestamp: 2025-03-31T22:20:48.475Z
Learning: For the Armbian build project, maintaining consistency with existing patches across U-Boot versions (such as between 2025.01 and 2025.04) is prioritized over refactoring individual patches for code improvements.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub API (https://api.github.com/repos/armbian/build/pulls/{pr_number}/files) to get the complete picture of what files are being added or modified, especially for U-Boot patches that will be applied during the build process.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub or the PR API to get the complete picture of what files are being added or modified.
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-07-21T04:12:02.439Z
Learning: In the Armbian build system, for recurring maintenance tasks like kernel version bumping, TODO comments should use generic version formats (e.g., "MAJOR.MINOR-rc1") rather than specific version numbers (e.g., "6.17-rc1") to avoid the need for frequent comment updates that would create unnecessary maintenance overhead.
Learnt from: rpardini
Repo: armbian/build PR: 8879
File: config/sources/families/uefi-x86.conf:0-0
Timestamp: 2025-11-06T15:36:04.682Z
Learning: As of PR #8879, the uefi-x86 family in the Armbian build system now includes kernel patches for the first time. The current and edge branches for uefi-x86 are specifically configured for Apple T2-based x86 machines, including T2-specific patches from the linux-t2 project and custom kernel configuration options for Apple hardware drivers.
Learnt from: EvilOlaf
Repo: armbian/build PR: 9086
File: patch/kernel/archive/uefi-arm64-6.19/net-stmicro-stmmac-Phytium-onboard-ethernet-drivers-and-ACPI-glue-for-6.x.patch.disabled:625-633
Timestamp: 2025-12-21T10:28:41.028Z
Learning: The patch "net-stmicro-stmmac-Phytium-onboard-ethernet-drivers-and-ACPI-glue-for-6.x.patch" in patch/kernel/archive/uefi-arm64-6.19/ is known to break compilation on kernel 6.19 and is therefore disabled (has .disabled extension).
Learnt from: EvilOlaf
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:10:25.610Z
Learning: In the Armbian build system, rk32xx and rk33xx Rockchip SoCs no longer have BSP-based (vendor) kernel branches. The rk3506 is the first 32-bit Rockchip SoC to use the vendor branch in the current codebase.
Learnt from: HackingGate
Repo: armbian/build PR: 8665
File: config/boards/photonicat2.csc:4-4
Timestamp: 2025-10-26T10:41:35.118Z
Learning: In the Armbian build system, rk3576 boards consistently use BOARDFAMILY="rk35xx" for both vendor and edge kernel targets. The rk35xx family configuration sources rockchip64_common.inc, which provides edge and current kernel branch definitions, making these branches available even though they're not defined directly in rk35xx.conf.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.
Learnt from: SuperKali
Repo: armbian/build PR: 8608
File: lib/functions/compilation/patch/drivers_network.sh:361-363
Timestamp: 2025-09-11T06:06:52.328Z
Learning: For the RTW88 SDIO RF path detection fix patch (004-rtw88-sdio-rf-path-detection-fix.patch), SuperKali prefers using exact version matching (eq 6.1 || eq 6.16) rather than range checks, as the patch has only been tested on those specific kernel versions and may be mainstreamed soon.
Learnt from: tabrisnet
Repo: armbian/build PR: 9058
File: config/sources/families/spacemit.conf:39-45
Timestamp: 2025-12-12T23:10:00.819Z
Learning: In the Armbian build system, vendor kernel forks can use "vendor-edge" branch naming for bleeding-edge or pre-release vendor kernels, as demonstrated in config/sources/families/k3.conf. The typical vendor branch naming pattern is: "vendor" or "vendor-rt" for stable vendor releases, and "vendor-edge" for bleeding-edge/pre-release vendor versions. The "edge" naming without "vendor-" prefix is reserved for mainline kernel branches.
Learnt from: tabrisnet
Repo: armbian/build PR: 8746
File: config/sources/families/filogic.conf:61-68
Timestamp: 2025-10-13T02:26:18.249Z
Learning: In the Armbian build system, the "edge" kernel branch is intended to be bleeding-edge and experimental. It does not require hardware testing or stability verification before merging, as it's expected to contain potentially unstable or untested code for early adopters and developers.
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:29:18.958Z
Learning: In the Armbian build system, vendor branch configurations in family files are designed to be shared across multiple SoCs within the same family that use the same vendor kernel tree. For example, rk35xx and rockchip-rk3588 families both use identical vendor branch settings (same KERNELSOURCE, KERNELBRANCH, and KERNELPATCHDIR), demonstrating that vendor branches are intentionally generic rather than SoC-specific.
📚 Learning: 2025-07-21T04:12:02.439Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-07-21T04:12:02.439Z
Learning: In the Armbian build system, for recurring maintenance tasks like kernel version bumping, TODO comments should use generic version formats (e.g., "MAJOR.MINOR-rc1") rather than specific version numbers (e.g., "6.17-rc1") to avoid the need for frequent comment updates that would create unnecessary maintenance overhead.
Applied to files:
config/sources/mainline-kernel.conf.sh
📚 Learning: 2025-04-30T16:16:47.150Z
Learnt from: The-going
Repo: armbian/build PR: 8147
File: config/sources/families/include/sunxi64_common.inc:38-39
Timestamp: 2025-04-30T16:16:47.150Z
Learning: The Armbian build system references Linux kernel versions in the form "tag:v6.14.4" in the KERNELBRANCH variable, even when point release tags might not be directly visible in the upstream repository in the same form.
Applied to files:
config/sources/mainline-kernel.conf.sh
📚 Learning: 2025-06-25T03:42:09.086Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8330
File: config/sources/families/sun55iw3.conf:32-36
Timestamp: 2025-06-25T03:42:09.086Z
Learning: In Armbian build system configuration files like config/sources/families/*.conf, KERNELSOURCE is explicitly declared when using unofficial or 3rd party kernel repositories (like the "dev" branch using https://github.com/apritzel/linux), but can be omitted when using the standard mainline kernel (like the "edge" branch) since it will fall back to the default mainline source.
Applied to files:
config/sources/mainline-kernel.conf.sh
📚 Learning: 2025-11-10T22:05:40.490Z
Learnt from: tabrisnet
Repo: armbian/build PR: 8913
File: config/sources/families/k3-beagle.conf:16-16
Timestamp: 2025-11-10T22:05:40.490Z
Learning: In the Armbian build system, kernel branches using non-mainline/vendor forks (like BeagleBoard's linux repository) should be named "vendor" or "vendor-rt" rather than "current" or "edge". The "current" and "edge" naming is reserved for mainline kernel branches. This affects both the case statement in family config files (e.g., `vendor | vendor-rt)` instead of `current | current-rt)`) and the corresponding KERNEL_TARGET declarations in board config files.
Applied to files:
config/sources/mainline-kernel.conf.sh
📚 Learning: 2025-12-19T13:56:45.124Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-19T13:56:45.124Z
Learning: When reviewing kernel or u-boot version bump PRs in the Armbian build system, check if patches existed in previous kernel version directories (e.g., sunxi-6.12, sunxi-6.13) before describing them as new features. If a patch and the majority of its contents existed previously with no major functionality changes, focus the review on the actual changes: the version bump itself and patch compatibility adjustments. Don't describe existing patches being ported/maintained across versions as new features or drivers—this is misleading. The patches are existing code being re-aligned to work with the new upstream version.
Applied to files:
config/sources/mainline-kernel.conf.sh
📚 Learning: 2025-11-02T20:49:56.719Z
Learnt from: igorpecovnik
Repo: armbian/build PR: 8849
File: config/boards/radxa-e54c.csc:14-28
Timestamp: 2025-11-02T20:49:56.719Z
Learning: In Armbian board configuration files (config/boards/*.conf, *.csc, etc.), do not use kernel_config_set, kernel_config_set_m, kernel_config_set_y, or custom_kernel_config__* functions to modify kernel configuration. Kernel configuration is associated with LINUXFAMILY/BOARDFAMILY, not individual BOARD. Board-specific kernel modifications cause inconsistency in kernel packages published to the apt repository because boards within a family share the same kernel packages. Kernel configuration changes must be made in the appropriate kernel config file (e.g., config/kernel/linux-*-*.config) or in family configuration files (config/sources/families/*.conf, *.inc) instead.
Applied to files:
config/sources/mainline-kernel.conf.sh
📚 Learning: 2025-06-25T03:40:52.109Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8330
File: config/sources/families/sun55iw3.conf:32-36
Timestamp: 2025-06-25T03:40:52.109Z
Learning: In Armbian build system configuration files like config/sources/families/*.conf, when KERNELSOURCE is not explicitly declared in a case branch, the system falls back to a default KERNELSOURCE value, so missing KERNELSOURCE declarations are not critical issues.
Applied to files:
config/sources/mainline-kernel.conf.sh
📚 Learning: 2025-12-17T15:46:22.709Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 9096
File: patch/kernel/archive/sunxi-6.18/patches.armbian/arm64-dts-sun50i-h616-add-overlays.patch:4-5
Timestamp: 2025-12-17T15:46:22.709Z
Learning: In Armbian kernel patches, when patches are renamed or reorganized, the old Subject line may be intentionally preserved in the patch header (as a second Subject line) for archival/historical purposes to document the previous patch name. This is an Armbian-specific practice for tracking patch evolution and should not be flagged as an error when the maintainer has intentionally included it for documentation.
Applied to files:
config/sources/mainline-kernel.conf.sh
📚 Learning: 2025-09-25T18:37:00.330Z
Learnt from: tabrisnet
Repo: armbian/build PR: 8661
File: lib/functions/compilation/armbian-kernel.sh:194-199
Timestamp: 2025-09-25T18:37:00.330Z
Learning: In PR armbian/build#8661, line 235 of lib/functions/compilation/armbian-kernel.sh already contains the corrected comment "BPF link support for netfilter hooks" for NETFILTER_BPF_LINK, not the misleading "BPF_SYSCALL" comment that was flagged during review.
Applied to files:
config/sources/mainline-kernel.conf.sh
📚 Learning: 2025-09-29T06:32:32.361Z
Learnt from: amazingfate
Repo: armbian/build PR: 8687
File: config/sources/mainline-kernel.conf.sh:11-11
Timestamp: 2025-09-29T06:32:32.361Z
Learning: There can be timing discrepancies between different kernel.org sources (web pages vs git repositories) when new kernel releases are published. Direct verification via git.kernel.org repository URLs is more reliable than general web searches for confirming tag availability.
Applied to files:
config/sources/mainline-kernel.conf.sh
📚 Learning: 2025-12-18T23:40:41.627Z
Learnt from: rpardini
Repo: armbian/build PR: 9101
File: lib/functions/image/compress-checksum.sh:44-48
Timestamp: 2025-12-18T23:40:41.627Z
Learning: In the Armbian build framework, scripts run with set -e, so a non-zero exit status will abort the script. During reviews, assume failures will stop execution unless explicitly handled. Verify that commands that must fail are checked, errors are propagated, and any critical steps have proper error handling (e.g., using pipefail where appropriate, checking exit codes, and not masking failures).
Applied to files:
config/sources/mainline-kernel.conf.sh
🔇 Additional comments (1)
config/sources/mainline-kernel.conf.sh (1)
11-11: LGTM: RC version bump to 6.19-rc2.The update from rc1 to rc2 aligns with the PR objectives and commit message.
|
Please consider also to bump current from 6.12 to 6.18 (which has been declared LTS so far) or keep the older |
Yes of course. That's why the patches from 6.18 were copied instead of moved :) |
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
🧰 Additional context used
🧠 Learnings (14)
📓 Common learnings
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-19T13:56:45.124Z
Learning: When reviewing kernel or u-boot version bump PRs in the Armbian build system, check if patches existed in previous kernel version directories (e.g., sunxi-6.12, sunxi-6.13) before describing them as new features. If a patch and the majority of its contents existed previously with no major functionality changes, focus the review on the actual changes: the version bump itself and patch compatibility adjustments. Don't describe existing patches being ported/maintained across versions as new features or drivers—this is misleading. The patches are existing code being re-aligned to work with the new upstream version.
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-17T05:09:02.306Z
Learning: In the Armbian build system, kernel patches (e.g., in patch/kernel/archive/sunxi-6.18/patches.armbian/) contain device tree overlays and other code that have existed for years and are maintained/ported across kernel versions. When reviewing PRs that modify these patch files, focus on the actual changes being made (e.g., Makefile fixes, new additions) rather than reviewing the entire existing content within the patch as if it were new code. The patch file contents are existing, stable code unless explicitly modified in the PR diff.
Learnt from: EvilOlaf
Repo: armbian/build PR: 9086
File: patch/kernel/archive/uefi-arm64-6.19/net-stmicro-stmmac-Phytium-onboard-ethernet-drivers-and-ACPI-glue-for-6.x.patch.disabled:625-633
Timestamp: 2025-12-21T10:28:41.028Z
Learning: The patch "net-stmicro-stmmac-Phytium-onboard-ethernet-drivers-and-ACPI-glue-for-6.x.patch" in patch/kernel/archive/uefi-arm64-6.19/ is known to break compilation on kernel 6.19 and is therefore disabled (has .disabled extension).
Learnt from: EvilOlaf
Repo: armbian/build PR: 8968
File: patch/u-boot/u-boot-sunxi/arm64-dts-sun50i-h6-orangepi.dtsi-Rollback-r_rsb-to-r_i2c.patch:36-36
Timestamp: 2025-11-20T18:20:11.985Z
Learning: The rewrite-patches tool (REWRITE_PATCHES=yes) in the Armbian build system can inadvertently introduce semantic changes when the u-boot/kernel git base revision differs from expected state. The tool applies patches, commits them, and re-exports them using git format-patch, which can cause the re-exported patch to reflect the base revision's state rather than preserving the original patch intent. This is particularly problematic for device tree changes like interrupt specifications. The tool currently lacks validation mechanisms to detect such semantic drift, and affected patches must be manually corrected after rewriting.
Learnt from: EvilOlaf
Repo: armbian/build PR: 9096
File: patch/kernel/archive/sunxi-6.18/patches.armbian/arm64-dts-sun50i-h616-add-overlays.patch:4-5
Timestamp: 2025-12-17T15:46:22.709Z
Learning: In Armbian kernel patches, when patches are renamed or reorganized, the old Subject line may be intentionally preserved in the patch header (as a second Subject line) for archival/historical purposes to document the previous patch name. This is an Armbian-specific practice for tracking patch evolution and should not be flagged as an error when the maintainer has intentionally included it for documentation.
Learnt from: rpardini
Repo: armbian/build PR: 8044
File: patch/u-boot/v2025.04/cmd-fileenv-read-string-from-file-into-env.patch:76-86
Timestamp: 2025-03-31T22:20:48.475Z
Learning: For the Armbian build project, maintaining consistency with existing patches across U-Boot versions (such as between 2025.01 and 2025.04) is prioritized over refactoring individual patches for code improvements.
Learnt from: rpardini
Repo: armbian/build PR: 8879
File: config/sources/families/uefi-x86.conf:0-0
Timestamp: 2025-11-06T15:36:04.682Z
Learning: As of PR #8879, the uefi-x86 family in the Armbian build system now includes kernel patches for the first time. The current and edge branches for uefi-x86 are specifically configured for Apple T2-based x86 machines, including T2-specific patches from the linux-t2 project and custom kernel configuration options for Apple hardware drivers.
Learnt from: tabrisnet
Repo: armbian/build PR: 8746
File: config/sources/families/filogic.conf:61-68
Timestamp: 2025-10-13T02:26:18.249Z
Learning: In the Armbian build system, the "edge" kernel branch is intended to be bleeding-edge and experimental. It does not require hardware testing or stability verification before merging, as it's expected to contain potentially unstable or untested code for early adopters and developers.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub API (https://api.github.com/repos/armbian/build/pulls/{pr_number}/files) to get the complete picture of what files are being added or modified, especially for U-Boot patches that will be applied during the build process.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub or the PR API to get the complete picture of what files are being added or modified.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:10:25.610Z
Learning: In the Armbian build system, rk32xx and rk33xx Rockchip SoCs no longer have BSP-based (vendor) kernel branches. The rk3506 is the first 32-bit Rockchip SoC to use the vendor branch in the current codebase.
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:29:18.958Z
Learning: In the Armbian build system, vendor branch configurations in family files are designed to be shared across multiple SoCs within the same family that use the same vendor kernel tree. For example, rk35xx and rockchip-rk3588 families both use identical vendor branch settings (same KERNELSOURCE, KERNELBRANCH, and KERNELPATCHDIR), demonstrating that vendor branches are intentionally generic rather than SoC-specific.
Learnt from: HackingGate
Repo: armbian/build PR: 8665
File: config/boards/photonicat2.csc:4-4
Timestamp: 2025-10-26T10:41:35.118Z
Learning: In the Armbian build system, rk3576 boards consistently use BOARDFAMILY="rk35xx" for both vendor and edge kernel targets. The rk35xx family configuration sources rockchip64_common.inc, which provides edge and current kernel branch definitions, making these branches available even though they're not defined directly in rk35xx.conf.
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:222-230
Timestamp: 2025-09-14T06:32:29.806Z
Learning: In the Armbian build system, the write_uboot_platform() function implementations follow different patterns across Rockchip family files. The newer standard (used in rockchip64_common.inc and rk3506) includes 'status=none' parameter in dd commands, while older implementations (rk3288, rk322x) use an older pattern without this parameter. The rk3506 implementation correctly follows the current Rockchip family standard.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.
📚 Learning: 2025-12-17T05:09:02.306Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-17T05:09:02.306Z
Learning: In the Armbian build system, kernel patches (e.g., in patch/kernel/archive/sunxi-6.18/patches.armbian/) contain device tree overlays and other code that have existed for years and are maintained/ported across kernel versions. When reviewing PRs that modify these patch files, focus on the actual changes being made (e.g., Makefile fixes, new additions) rather than reviewing the entire existing content within the patch as if it were new code. The patch file contents are existing, stable code unless explicitly modified in the PR diff.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
📚 Learning: 2025-11-08T06:39:24.527Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
📚 Learning: 2025-12-19T13:56:45.124Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-19T13:56:45.124Z
Learning: When reviewing kernel or u-boot version bump PRs in the Armbian build system, check if patches existed in previous kernel version directories (e.g., sunxi-6.12, sunxi-6.13) before describing them as new features. If a patch and the majority of its contents existed previously with no major functionality changes, focus the review on the actual changes: the version bump itself and patch compatibility adjustments. Don't describe existing patches being ported/maintained across versions as new features or drivers—this is misleading. The patches are existing code being re-aligned to work with the new upstream version.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
📚 Learning: 2025-12-23T04:44:25.212Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 9067
File: patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts:869-875
Timestamp: 2025-12-23T04:44:25.212Z
Learning: During code reviews of device tree changes (any .dts file), verify node properties against the official kernel device tree binding documentation (*.yaml) rather than relying solely on patterns observed in existing DTS files. This helps catch copy-paste or drift errors and ensures properties align with authoritative bindings for each device node type.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
📚 Learning: 2025-11-20T18:20:11.985Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8968
File: patch/u-boot/u-boot-sunxi/arm64-dts-sun50i-h6-orangepi.dtsi-Rollback-r_rsb-to-r_i2c.patch:36-36
Timestamp: 2025-11-20T18:20:11.985Z
Learning: The rewrite-patches tool (REWRITE_PATCHES=yes) in the Armbian build system can inadvertently introduce semantic changes when the u-boot/kernel git base revision differs from expected state. The tool applies patches, commits them, and re-exports them using git format-patch, which can cause the re-exported patch to reflect the base revision's state rather than preserving the original patch intent. This is particularly problematic for device tree changes like interrupt specifications. The tool currently lacks validation mechanisms to detect such semantic drift, and affected patches must be manually corrected after rewriting.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
📚 Learning: 2025-12-08T04:43:44.601Z
Learnt from: Lemon1151
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-08T04:43:44.601Z
Learning: On the rk3399-fine3399 board, the PWM fan requires cooling-levels to extend to 255 (full duty cycle) in the device tree. With cooling-levels ending at 160, the fan fails to spin up even when temperature exceeds the thermal threshold. This is a hardware characteristic specific to this board's fan configuration.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
📚 Learning: 2025-07-21T04:12:02.439Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-07-21T04:12:02.439Z
Learning: In the Armbian build system, for recurring maintenance tasks like kernel version bumping, TODO comments should use generic version formats (e.g., "MAJOR.MINOR-rc1") rather than specific version numbers (e.g., "6.17-rc1") to avoid the need for frequent comment updates that would create unnecessary maintenance overhead.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
📚 Learning: 2025-12-17T15:46:22.709Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 9096
File: patch/kernel/archive/sunxi-6.18/patches.armbian/arm64-dts-sun50i-h616-add-overlays.patch:4-5
Timestamp: 2025-12-17T15:46:22.709Z
Learning: In Armbian kernel patches, when patches are renamed or reorganized, the old Subject line may be intentionally preserved in the patch header (as a second Subject line) for archival/historical purposes to document the previous patch name. This is an Armbian-specific practice for tracking patch evolution and should not be flagged as an error when the maintainer has intentionally included it for documentation.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
📚 Learning: 2025-07-25T03:51:50.830Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub API (https://api.github.com/repos/armbian/build/pulls/{pr_number}/files) to get the complete picture of what files are being added or modified, especially for U-Boot patches that will be applied during the build process.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
📚 Learning: 2025-07-25T03:51:50.830Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub or the PR API to get the complete picture of what files are being added or modified.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
📚 Learning: 2025-03-31T22:20:48.475Z
Learnt from: rpardini
Repo: armbian/build PR: 8044
File: patch/u-boot/v2025.04/cmd-fileenv-read-string-from-file-into-env.patch:76-86
Timestamp: 2025-03-31T22:20:48.475Z
Learning: For the Armbian build project, maintaining consistency with existing patches across U-Boot versions (such as between 2025.01 and 2025.04) is prioritized over refactoring individual patches for code improvements.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
📚 Learning: 2025-12-16T13:40:07.649Z
Learnt from: igorpecovnik
Repo: armbian/build PR: 9087
File: .github/workflows/pr-check-pictures.yml:138-146
Timestamp: 2025-12-16T13:40:07.649Z
Learning: In the Armbian build repository, when introducing new requirements or checks (like the board assets verification workflow), the project prefers an initial educational-only period where violations post helpful PR comments and warnings but don't block merges. This allows contributors to become familiar with new requirements before enforcement is enabled (typically after ~6 months).
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
📚 Learning: 2025-06-24T10:08:40.313Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8328
File: lib/functions/compilation/patch/drivers_network.sh:542-545
Timestamp: 2025-06-24T10:08:40.313Z
Learning: In the Armbian build system, when a PR removes build support for a specific kernel version, version check issues for that removed version become practically irrelevant even if they appear incorrect in isolation. Context about which kernel versions are being deprecated/removed is important for understanding the impact of version-related code changes.
Applied to files:
patch/kernel/archive/rockchip64-6.19/dt/rk3399-orangepi-4-lts.dts
5 participants
Description
disable a few patches
align a few patches
rewrite all patches
temporary changed MAINLINE_KERNEL_SOURCE because stable always lacks a day behind
How Has This Been Tested?
Checklist:
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Chores
✏️ Tip: You can customize this high-level summary in your review settings.