meson64: bump edge to 6.19
#9069
Conversation
WalkthroughThis PR introduces Linux kernel 6.19 support for Amlogic Meson64 (AML SoC) platforms, updating kernel version references and adding comprehensive device-tree patches, new drivers, overlay definitions, and build system enhancements across multiple board variants including Khadas VIM3, ODROID, Radxa, Cainiao, JetHub, and others. Changes
Sequence Diagram(s)Sequence diagrams are not generated for this PR because:
Estimated code review effort🎯 4 (Complex) | ⏱️ ~70 minutes Areas requiring extra attention:
Possibly related PRs
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
02
EvilOlaf
requested review from
NicoD-SBC,
SteeManMI,
Tonymac32,
adeepn,
igorpecovnik,
pyavitz,
rpardini and
teknoid
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: 8
Note
Due to the large number of review comments, Critical severity comments were prioritized as inline comments.
♻️ Duplicate comments (1)
patch/kernel/archive/meson64-6.19/meson-gxl-gxm-arm64-dts-meson-set-p212-p23x-q20x-SDIO-to-100MH.patch (1)
110-122: Same verification needed as meson-gx-p23x-q20x.dtsi.The changes here are identical in structure to the first DTSI file modification. The same concern about verifying UHS voltage switching support applies.
🟠 Major comments (16)
patch/kernel/archive/meson64-6.19/general-soc-0002-soc-amlogic-meson-gx-socinfo-sm-Add-Amlogic-secure-m.patch-214-230 (1)
214-230: Memory leak:revisionandsoc_idstrings not freed on remove.The
revisionandsoc_idstrings are allocated withkasprintf()but are never freed when the driver is removed. Thesoc_device_unregister()in the remove function doesn't free these strings.Additionally, line 228 uses
kfree_const()which is intended for strings that might be constant - butkasprintf()always returns dynamically allocated memory, sokfree()would be more appropriate.Consider storing references to these strings to free them in remove, or use
devm_kasprintf()if appropriate:- soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%x:%x - %x:%x", + soc_dev_attr->revision = devm_kasprintf(&pdev->dev, GFP_KERNEL, "%x:%x - %x:%x", socinfo.v1.major_id, socinfo.v1.chip_rev, socinfo.v1.pack_id, (socinfo.v1.reserved<<4) + socinfo.v1.layout_ver); - soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "%s (%s)", + soc_dev_attr->soc_id = devm_kasprintf(&pdev->dev, GFP_KERNEL, "%s (%s)", socinfo_v1_to_soc_id(socinfo), socinfo_v1_to_package_id(socinfo));And update the error path accordingly:
if (IS_ERR(soc_dev)) { - kfree(soc_dev_attr->revision); - kfree_const(soc_dev_attr->soc_id); return PTR_ERR(soc_dev); }patch/kernel/archive/meson64-6.19/general-meson-vdec-add-HEVC-decode-codec.patch-662-680 (1)
662-680: Memory leak in error path: workspace not freed if AUX allocation fails.If
dma_alloc_coherentforaux_vaddrfails at line 662, the function jumps tofree_hevcwhich only frees thehevcstruct, but not the previously allocatedworkspace_vaddr.Apply this diff to fix the error handling:
/* AUX buffers */ hevc->aux_vaddr = dma_alloc_coherent(core->dev, SIZE_AUX, &hevc->aux_paddr, GFP_KERNEL); if (!hevc->aux_vaddr) { dev_err(core->dev, "Failed to request HEVC AUX\n"); ret = -ENOMEM; - goto free_hevc; + goto free_workspace; } amvdec_write_dos(core, HEVC_AUX_ADR, hevc->aux_paddr); @@ -676,6 +676,10 @@ static int codec_hevc_start(struct amvdec_session *sess) return 0; +free_workspace: + dma_free_coherent(core->dev, SIZE_WORKSPACE, + hevc->workspace_vaddr, hevc->workspace_paddr); free_hevc: kfree(hevc); return ret;patch/kernel/archive/meson64-6.19/general-meson-vdec-add-HEVC-decode-codec.patch-743-751 (1)
743-751: Memory leak:new_framenot freed ifv4l2_m2m_dst_buf_removefails.If
v4l2_m2m_dst_buf_removereturns NULL at line 748, the function returns NULL but thenew_frameallocated at line 743 is never freed.Apply this diff to fix the memory leak:
vbuf = v4l2_m2m_dst_buf_remove(sess->m2m_ctx); if (!vbuf) { dev_err(sess->core->dev, "No dst buffer available\n"); + kfree(new_frame); return NULL; }patch/kernel/archive/meson64-6.19/general-input-touchscreen-Add-D-WAV-Multitouch.patch-239-248 (1)
239-248: Missing packet length validation before parsing.The function casts
pkttostruct dwav_rawwithout verifying thatlen >= sizeof(struct dwav_raw). If a partial URB is received, this could result in out-of-bounds reads.static void dwav_usb_mt_process(struct dwav_usb_mt *dwav_usb_mt, unsigned char *pkt, int len) { struct dwav_raw *dwav_raw = (struct dwav_raw *)pkt; unsigned char bit_mask, cnt; + if (len < sizeof(struct dwav_raw)) + return; + for (cnt = 0, bit_mask = 0x01;patch/kernel/archive/meson64-6.19/general-input-touchscreen-Add-D-WAV-Multitouch.patch-460-468 (1)
460-468: Unchecked return value frominput_mt_init_slots().
input_mt_init_slots()can fail and return a negative error code, but the return value is ignored. This could result in registering a device with improperly initialized multitouch slots.- input_mt_init_slots(input_dev, - DEV_INFO[dwav_usb_mt->dev_id].max_finger, 0); + err = input_mt_init_slots(input_dev, + DEV_INFO[dwav_usb_mt->dev_id].max_finger, 0); + if (err) { + pr_err("%s - input_mt_init_slots failed, err: %d\n", + __func__, err); + return err; + } err = input_register_device(input_dev);patch/kernel/archive/meson64-6.19/general-memory-marked-nomap.patch-20-36 (1)
20-36: Removal of memory management safety check masks underlying issue.The patch removes validation that prevented marking already-reserved memory as
nomap. While this may resolve the immediate error messages and crashes, it bypasses a safety mechanism rather than fixing the root cause of overlapping memory reservations.The proper fix would be to:
- Correct the device tree memory region definitions to avoid overlaps
- Adjust the reservation order in the kernel initialization
- Or ensure upstream kernel handles this case correctly
While "edge" kernels are experimental and some risk is acceptable, removing safety checks in memory management code can lead to subtle corruption or undefined behavior.
Consider this diff if the overlap is intentional and safe:
if (nomap) { + /* + * Allow nomap marking even if region overlaps reserved memory. + * This is required for Amlogic Meson platforms where secure + * monitor memory regions may be pre-reserved by firmware. + */ return memblock_mark_nomap(base, size); }This documents the intentional behavior while maintaining the workaround.
patch/kernel/archive/meson64-6.19/general-sound-soc-remove-mono-channel-as-it-curren.patch-17-26 (1)
17-26: Scope mismatch: patch affects all AXG platforms, not just ODROID-N2.The commit message references ODROID-N2 specifically, but this change affects
axg_frddr_dai_drv, which is used by all AXG-based platforms. If mono audio only fails on specific boards or HDMI configurations, this blanket restriction may be overly broad.Consider adding an inline comment in the code explaining why mono is disabled, especially since this deviates from typical hardware capabilities.
#!/bin/bash # Description: Find which boards use the AXG FRDDR driver # Search for AXG platform references in board configs and device trees rg -n 'axg.*frddr|frddr.*axg' --type dts -g '*.dts*' -i # Search for meson64 board configurations fd -e conf -e csc . config/boards/ | xargs rg -l 'meson64|BOARD.*meson'patch/kernel/archive/meson64-6.19/overlay/meson-g12-pwm-gpiox-5-fan.dtso-23-42 (1)
23-42: Movepolling-delayinto__overlay__so it actually applies tocpu_thermal.Right now
polling-delay = <2000>;is a property offragment@1(line 25), not of thecpu_thermalnode. In device tree overlays, only the subtree under__overlay__is merged into the target node at runtime; properties onfragment@...itself are ignored. Your new polling delay will not take effect.Move
polling-delayto be a property on&cpu_thermalvia the overlay:fragment@1 { target = <&cpu_thermal>; - polling-delay = <2000>; __overlay__ { + polling-delay = <2000>; trips { cpu_active: cpu-active {patch/kernel/archive/meson64-6.19/general-soc-0001-soc-amlogic-meson-gx-socinfo-move-common-code-to-hea.patch-62-124 (1)
62-124: SoC ID/package tables drop S7/S7D/S6 and S805X3/S905X5 entries present in the base driver*In the removed
meson-gx-socinfo.ctables, the following entries existed but are missing from the new header:
soc_ids[]:S7(0x46),S7D(0x47),S6(0x48).soc_packages[]:S805X3(0x46, 0x3, 0xf),S905X5M(0x47, 0x1, 0xf),S905X5(0x48, 0x1, 0xf).With this patch,
socinfo_v1_to_soc_id()andsocinfo_v1_to_package_id()will now return"Unknown"for these SoCs, which is a regression vs the pre-refactor code and vs the 6.19 base that already carried these IDs.To keep the refactor behaviour‑neutral, please restore these entries in the header, e.g.:
static const struct meson_gx_soc_id { const char *name; unsigned int id; } soc_ids[] = { { "GXBB", 0x1f }, { "GXTVBB", 0x20 }, { "GXL", 0x21 }, { "GXM", 0x22 }, { "TXL", 0x23 }, { "TXLX", 0x24 }, { "AXG", 0x25 }, { "GXLX", 0x26 }, { "TXHD", 0x27 }, { "G12A", 0x28 }, { "G12B", 0x29 }, { "SM1", 0x2b }, { "A1", 0x2c }, { "T7", 0x36 }, { "S4", 0x37 }, { "A5", 0x3c }, { "C3", 0x3d }, - { "A4", 0x40 }, + { "A4", 0x40 }, + { "S7", 0x46 }, + { "S7D", 0x47 }, + { "S6", 0x48 }, }; static const struct meson_gx_package_id { const char *name; unsigned int major_id; unsigned int pack_id; unsigned int pack_mask; } soc_packages[] = { { "S905", 0x1f, 0, 0x20 }, /* pack_id != 0x20 */ { "S905H", 0x1f, 0x3, 0xf }, /* pack_id & 0xf == 0x3 */ { "S905M", 0x1f, 0x20, 0xf0 }, /* pack_id == 0x20 */ { "S905D", 0x21, 0, 0xf0 }, { "S905X", 0x21, 0x80, 0xf0 }, { "S905W", 0x21, 0xa0, 0xf0 }, { "S905L", 0x21, 0xc0, 0xf0 }, { "S905M2", 0x21, 0xe0, 0xf0 }, { "S805X", 0x21, 0x30, 0xf0 }, { "S805Y", 0x21, 0xb0, 0xf0 }, { "S912", 0x22, 0, 0x0 }, /* Only S912 is known for GXM */ { "962X", 0x24, 0x10, 0xf0 }, { "962E", 0x24, 0x20, 0xf0 }, { "A113X", 0x25, 0x37, 0xff }, { "A113X", 0x25, 0x43, 0xff }, { "A113D", 0x25, 0x22, 0xff }, { "S905L", 0x26, 0, 0x0 }, { "S905D2", 0x28, 0x10, 0xf0 }, { "S905Y2", 0x28, 0x30, 0xf0 }, { "S905X2", 0x28, 0x40, 0xf0 }, { "A311D", 0x29, 0x10, 0xf0 }, { "S922X", 0x29, 0x40, 0xf0 }, { "S905D3", 0x2b, 0x4, 0xf5 }, { "S905X3", 0x2b, 0x5, 0xf5 }, { "S905X3", 0x2b, 0x10, 0x3f }, { "S905D3", 0x2b, 0x30, 0x3f }, { "A113L", 0x2c, 0x0, 0xf8 }, { "S805X2", 0x37, 0x2, 0xf }, { "C308L", 0x3d, 0x1, 0xf }, { "A311D2", 0x36, 0x1, 0xf }, { "A113X2", 0x3c, 0x1, 0xf }, { "A113L2", 0x40, 0x1, 0xf }, + { "S805X3", 0x46, 0x3, 0xf }, + { "S905X5M", 0x47, 0x1, 0xf }, + { "S905X5", 0x48, 0x1, 0xf }, };This keeps the header-based refactor aligned with the pre-existing 6.19 SoC coverage and avoids silent behavioural changes introduced by the patch rewrite. Based on learnings, this is exactly the sort of semantic drift REWRITE_PATCHES can cause and is worth correcting explicitly.
patch/kernel/archive/meson64-6.19/general-meson-mmc-3-arm64-dts-docs-Update-mmc-meson-gx-documentation-for.patch-4-5 (1)
4-5: Fix property name and YAML schema to match driver implementationThe patch introduces two issues that will make the binding non-functional:
Property name mismatch with driver
- The driver patch reads
"amlogic,mmc-phase"(singular) viadevice_property_read_u32_array(line 47 of general-meson-mmc-1)- This patch documents and adds
amlogic,mmc-phases(plural) to the YAML binding (line 30) and example (line 47)- The subject line correctly uses the singular form: "option amlogic,mmc-phase"
- Board patches in the series also use the singular form
- Result: DTS authors following these binding docs will use
amlogic,mmc-phases, but the driver readsamlogic,mmc-phaseand will never find the property- Rename the YAML property and example to use
amlogic,mmc-phase(singular) to match the driver and subject lineYAML schema type is inconsistent with description
- The YAML declares
type: integerbut describes it as a "3-element array of clock phases"- The example shows three values:
<CLK_PHASE_180 CLK_PHASE_0 CLK_PHASE_0>- A scalar integer type will fail
dtbs_checkvalidation for array values- Change the schema to declare an array type (e.g.,
type: array,items: { type: integer }, withminItems: 3,maxItems: 3) to match the actual usagepatch/kernel/archive/meson64-6.19/jethome-0002-arm64-dts-jethub-j1xx-add-eeprom-node.patch-16-31 (1)
16-31: Duplicateeeprompdlabel definition in both hunks; patch conflicts with existing nodeThe hunk context (
@@ -47,3 +47,15 @@ eeprompd: eeprom@56 {) already shows aneeprompd: eeprom@56block present in the file before this patch applies. The patch then adds anothereeprompd: eeprom@56node under&i2c_AO, creating a duplicate label that device tree tooling does not permit. This same conflict occurs in both the rev-2 and rev-3 device tree files.Either drop this patch for 6.19 if the EEPROM node is already present in the base kernel, or rewrite it to modify the existing node using
&eeprompd { ... }syntax instead of redefining it.Additionally, fix indentation inconsistency: lines 24–26 and 29 in both hunks use spaces; align all with tabs per kernel device tree conventions.
patch/kernel/archive/meson64-6.19/dt/meson-sm1-jethome-jethub-j200.dts-251-253 (1)
251-253: Duplicatesoundnode will cause issues.There's a second
soundnode at lines 251-253 that only sets themodelproperty. This duplicates thesoundnode defined at lines 183-219. In device-tree, duplicate nodes at the same level will cause either compilation errors or unexpected property overwriting.Merge the
modelproperty into the existing sound node:sound { compatible = "amlogic,axg-sound-card"; + model = "JETHUB-D2"; audio-aux-devs = <&tdmout_b>; audio-routing = "TDM_B Playback", "TDMOUT_B OUT"; ... }; - - sound { - model = "JETHUB-D2"; - };Committable suggestion skipped: line range outside the PR's diff.
patch/kernel/archive/meson64-6.19/dt/meson-sm1-odroid-c4-spidev.dts-8-8 (1)
8-8: Replace placeholder text with actual pin numbers.The model string contains placeholder text "MOSI is pin y, CLK is pin x" instead of actual physical pin numbers. This should be updated with the correct pin mapping for ODROID-C4, similar to how the Radxa Zero spidev file specifies concrete pin numbers (e.g., "MOSI pin 19, CLK pin 23").
Please update with the actual physical pin numbers for the ODROID-C4 GPIO header, or remove the pin reference entirely if the mapping is not yet determined.
patch/kernel/archive/meson64-6.19/overlay/README.meson-overlays-11-13 (1)
11-13: Remove i2c8 from the overlay list—this file does not exist in the overlay directory.The README lists three overlays (i2c8, meson-sm1-odroid-c4-i2c0, meson-sm1-odroid-c4-i2c1), but only two actually exist: meson-sm1-odroid-c4-i2c0.dtso and meson-sm1-odroid-c4-i2c1.dtso. There is no i2c8.dtso file in patch/kernel/archive/meson64-6.19/overlay/. Either remove i2c8 from the documentation or add the corresponding .dtso file.
patch/kernel/archive/meson64-6.19/dt/meson-gxm-c400-plus.dts-1-9 (1)
1-9: Missing SPDX license header.This file is missing the SPDX license identifier and copyright notice that other DTS files in this PR include (e.g.,
meson-gxm-mini-m8s-pro.dtshas// SPDX-License-Identifier: (GPL-2.0+ OR MIT)). Consider adding a proper header for consistency.+// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Copyright (c) 2025 <author> + */ + /dts-v1/; #include "meson-gxm.dtsi"patch/kernel/archive/meson64-6.19/dt/meson-axg-amper-gateway-gz80x.dtsi-232-252 (1)
232-252: Missing WiFi device node under&sd_emmc_b.The
&sd_emmc_bnode is configured with SDIO pins, power sequencing, andnon-removableflag typical for a WiFi module, but there's no child WiFi device node (e.g.,wifi@1) defined. This will result in the WiFi hardware not being properly bound to a driver./* WiFi module */ &sd_emmc_b { status = "okay"; #address-cells = <1>; #size-cells = <0>; pinctrl-0 = <&sdio_pins>; pinctrl-1 = <&sdio_clk_gate_pins>; pinctrl-names = "default", "clk-gate"; bus-width = <4>; cap-sd-highspeed; max-frequency = <50000000>; disable-wp; non-removable; mmc-pwrseq = <&sdio_pwrseq>; vmmc-supply = <&vddao_3v3>; vqmmc-supply = <&vddio_boot>; + + wifi@1 { + reg = <1>; + compatible = "realtek,rtl8723bs"; /* verify correct chip */ + }; };
🟡 Minor comments (18)
patch/kernel/archive/meson64-6.19/board-t95z-add-rc-remote-keymap.patch-64-67 (1)
64-67: Minor typo: missing closing angle bracket in copyright comment.The email address in the copyright comment is missing the closing
>.// SPDX-License-Identifier: GPL-2.0+ /* - * Copyright (c) 2023 Christian Hewitt <christianshewitt@gmail.com + * Copyright (c) 2023 Christian Hewitt <christianshewitt@gmail.com> */patch/kernel/archive/meson64-6.19/jethome-0003-arm64-dts-meson-add-dts-links-to-secure-monitor-for-jethub.patch-34-34 (1)
34-34: Remove extraneous tab before opening brace.Line 34 contains a tab character between
&sec_AOand{, which is inconsistent with the identical addition at line 22 that uses a single space.Apply this diff to fix the formatting inconsistency:
-&sec_AO { +&sec_AO {patch/kernel/archive/meson64-6.19/driver-power-meson64-reset.patch-190-193 (1)
190-193:psci_function_id_restartis set but never used.The value read from
sys_resetis stored inpsci_function_id_restart, but the restart handler (do_meson64_restart) only callsmeson64_card_reset()and never uses this PSCI function ID. If a PSCI restart call is intended, it should be invoked; otherwise, reading this property is unnecessary.patch/kernel/archive/meson64-6.19/driver-power-meson64-reset.patch-178-183 (1)
178-183:psci_function_id_poweroffis set but unused; hardcoded value used instead.The probe function reads
sys_powerofffrom the device tree intopsci_function_id_poweroff, butdo_meson64_poweroffuses a hardcoded magic number0x82000042. This makes the DT property ineffective.Consider using the DT-provided value:
static void do_meson64_poweroff(void) { meson64_card_reset(); - __invoke_psci_fn_smc(0x82000042, 1, 0, 0); + __invoke_psci_fn_smc(psci_function_id_poweroff, 1, 0, 0); }patch/kernel/archive/meson64-6.19/general-meson-aiu-Fix-HDMI-codec-control-selection.patch-35-38 (1)
35-38: Minor typo in commit message.Line 38 states "0x0 (using cts_aoclkx2_int as AIU clk)" but according to lines 26-28,
0x1selectscts_aoclkx2_intand0x0selectscts_i958. The code implementation is correct (sets BIT(6) for I2S), so this is just a documentation inconsistency.patch/kernel/archive/meson64-6.19/general-driver-tm1628-auxdisplay-add-support-for-Titanmec-TM16.patch-460-463 (1)
460-463: Add validation for display mode constraints.The driver hardcodes 6x12 display mode (line 461) with a comment stating "For now we support 6x12 mode only," but doesn't validate that the configured
grid_sizeis compatible. The 6x12 mode supports a maximum of 6 grids, but the driver allowsgrid_sizeup toMAX_GRID_SIZE(7).Apply this diff to add validation:
ret = device_property_count_u8(&spi->dev, "grid"); - if (ret < 1 || ret > MAX_GRID_SIZE) { + if (ret < 1 || ret > 6) { dev_err(&spi->dev, "Invalid display length (%d)\n", ret); return -EINVAL; }Or update the error message to mention the 6x12 mode limitation:
ret = device_property_count_u8(&spi->dev, "grid"); - if (ret < 1 || ret > MAX_GRID_SIZE) { - dev_err(&spi->dev, "Invalid display length (%d)\n", ret); + if (ret < 1 || ret > 6) { + dev_err(&spi->dev, "Invalid display length %d (6x12 mode supports max 6 grids)\n", ret); return -EINVAL; }Also applies to: 506-512
patch/kernel/archive/meson64-6.19/general-driver-tm1628-auxdisplay-add-support-for-Titanmec-TM16.patch-91-91 (1)
91-91: Fix incorrect schema $id path.The
$idpath referencesleds/titanmec,tm1628.yamlbut this driver is in theauxdisplaysubsystem (as evidenced by its location indrivers/auxdisplay/and Kconfig).Apply this diff:
-$id: http://devicetree.org/schemas/leds/titanmec,tm1628.yaml# +$id: http://devicetree.org/schemas/auxdisplay/titanmec,tm1628.yaml#patch/kernel/archive/meson64-6.19/general-input-touchscreen-Add-D-WAV-Multitouch.patch-51-60 (1)
51-60: Incomplete Kconfig help text.The help text is missing the standard phrasing before the module name. Compare with other entries in the same file (e.g.,
TOUCHSCREEN_HIMAX_HX83112Babove).Apply this diff:
config TOUCHSCREEN_DWAV_USB_MT tristate "D-WAV Scientific USB MultiTouch" depends on USB_ARCH_HAS_HCD select USB help Say Y here if you have a D-WAV Scientific USB(HID) based MultiTouch controller. - module will be called dwav-usb-mt. + To compile this driver as a module, choose M here: the + module will be called dwav-usb-mt.patch/kernel/archive/meson64-6.19/general-sound-soc-remove-mono-channel-as-it-curren.patch-27-35 (1)
27-35: This patch includes documented justification—clarify if the HDMI mono output issue is universal or board-specific.The commit message explicitly states the purpose: "remove mono channel as it currently doesn't work hdmi output." Since the change modifies driver code (not board-specific code), the broad impact on all G12A boards (Radxa Zero, Khadas VIM3, ODROID-N2/C4, Banana Pi CM4 IO, SEI 510, and others) appears intentional. However, verify whether the mono HDMI output issue is a universal driver limitation or specific to certain platforms—if platform-specific, a more targeted approach may be warranted.
patch/kernel/archive/meson64-6.19/dt/meson-g12b-a311d-cainiao-cniot-core.dts-31-34 (1)
31-34: Memory size comment is inaccurate.The value
0x77359400equals 2,000,000,000 bytes (~1.86 GiB), not 2GB (which would be0x80000000= 2,147,483,648 bytes). If this is intentional due to reserved memory regions, please update the comment to reflect the actual usable memory. Otherwise, correct the register value.memory@0 { device_type = "memory"; - reg = <0x0 0x0 0x0 0x77359400>; /* 2GB */ + reg = <0x0 0x0 0x0 0x77359400>; /* ~1.86 GiB */ };patch/kernel/archive/meson64-6.19/board-khadas-vims-add-rtc-vrtc-aliases.patch-6-6 (1)
6-6: Minor typo in commit messages.The commit messages contain a typo: "proves first" should be "probes first" when referring to device probe order.
Apply this diff to correct line 6:
-Add aliases to ensure the vrtc time (which normally proves first) is /dev/rtc1 +Add aliases to ensure the vrtc time (which normally probes first) is /dev/rtc1Apply this diff to correct line 35:
-Add aliases to ensure the vrtc time (which normally proves first) is /dev/rtc1 +Add aliases to ensure the vrtc time (which normally probes first) is /dev/rtc1Also applies to: 35-35
patch/kernel/archive/meson64-6.19/hwmon-emc2305-fixups-for-driver.patch-97-138 (1)
97-138: DT override helper is reasonable; ensure cooling-levels reaches 255 for full fan control
emc2305_get_tz_of()cleanly makes theemc2305,cooling-levels,emc2305,pwm-max,emc2305,pwm-min, andemc2305,pwm-channelproperties optional (only treating non--EINVALerrors as fatal), and the u8 reads match the downstream 5.15 behavior. This enables proper device tree configuration for boards using the emc2305 controller.While no boards currently use these properties, the fine3399 cooling-level problem shows the importance of proper fan configuration: the 6.18 fine3399 DT defines
cooling-levels = <0 30 60 90 120 160>(max 160) whereas 6.12 uses<0 50 100 150 200 255>(max 255). The insufficient 160 value prevents the fan from reaching full duty cycle even under thermal stress. When any future overlays introduceemc2305,cooling-levels, ensure the highest value reaches 255 for complete fan control capability.patch/kernel/archive/meson64-6.19/dt/meson-gxm-t95z-plus.dts-153-166 (1)
153-166: Missing closing brace and semicolon for the file.The DTS file appears to end abruptly at the
uart_Ablock without a closing brace and semicolon for the root node. The file should end with};to properly close the root/block.Expected file ending:
bluetooth { compatible = "brcm,bcm43438-bt"; shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>; max-speed = <2000000>; clocks = <&wifi32k>; clock-names = "lpo"; }; }; +};patch/kernel/archive/meson64-6.19/drv-spi-spidev-remove-warnings.patch-4-4 (1)
4-4: Incorrect patch metadata in subject line.The subject line references "rockchip64: edge: 6.10.5" but this patch is for meson64-6.19. This appears to be copy-pasted from another patch without updating the metadata.
The subject should reference the correct platform and kernel version:
-Subject: rockchip64: edge: 6.10.5 drv:spi:spidev remove warnings +Subject: meson64: edge: 6.19 drv:spi:spidev remove warningspatch/kernel/archive/meson64-6.19/dt/meson-sm1-khadas-vim3l-spidev.dts-8-8 (1)
8-8: Fix duplicate I2C pin assignment in model description.The model string lists both SDA and SCL on "pin 23", which is physically impossible. Verify the correct I2C3 pin numbers and update the model description accordingly (actual GPIO pins A14 and A15 are correctly defined in the pinctrl configuration).
patch/kernel/archive/meson64-6.19/dt/meson-g12b-a311d-khadas-vim3-spidev.dts-8-8 (1)
8-8: Minor: Model string may have pin typo.The model string states "SDA pin 23, SCL pin 23" - both pins are listed as pin 23, which seems like a documentation typo. However, the actual pinctrl configuration (i2c3_sck_a_pins and i2c3_sda_a_pins) is correct.
patch/kernel/archive/meson64-6.19/dt/meson-axg-amper-gateway-gz80x.dtsi-1-11 (1)
1-11: Remove/dts-v1/;directive or rename file to.dts.This file is included by
meson-axg-amper-gateway-am-gz80x.dts, making.dtsithe correct extension for an include file. However, it contains the/dts-v1/;directive andchosennode, which are non-standard for included fragments. Either remove these elements to make it a pure overlay file, or rename the file to.dtsif it's intended to be standalone. No other Meson64 DTSI files in this directory include the/dts-v1/;directive.patch/kernel/archive/meson64-6.19/general-add-Amlogic-Meson-GX-PM-Suspend.patch-77-79 (1)
77-79: Add preprocessor guards forPSCI_FN_NATIVEmacro redefinition.The macro is already defined in kernel headers and will conflict when included. Other patches in this repository (e.g., rockchip-6.17) protect such redefinitions with
#ifdef CONFIG_64BITguards. Wrap the macro definition or use#ifndef PSCI_FN_NATIVEto prevent redefinition warnings/errors.
🧹 Nitpick comments (44)
patch/kernel/archive/meson64-6.19/kernel-6.8-tools-cgroup-makefile.patch (2)
34-35: Consider using$<instead of$^in the pattern rule.The pattern rule uses
$^(all prerequisites) to reference the source file, but$<(first prerequisite) is more idiomatic here since there's only one source dependency. This improves clarity and is a Makefile best practice.-%: %.c - $(CC) $(CFLAGS) -o $@ $^ +%: %.c + $(CC) $(CFLAGS) -o $@ $<
19-19: Patch filename reflects kernel 6.8 but targets 6.19.The filename
kernel-6.8-tools-cgroup-makefile.patchsuggests this patch originated from a 6.8 kernel version update. Since this is now being applied to the 6.19 kernel tree, consider renaming it for consistency (e.g., tokernel-6.19-tools-cgroup-makefile.patch) to avoid confusion during future maintenance.The git archeology headers (lines 7–16) document the original provenance, so the rename would not lose that information.
patch/kernel/archive/meson64-6.19/general-spi-nor-add-support-for-XT25F128B.patch (1)
74-93: Implementation follows standard spi-nor driver pattern.The new XTX manufacturer driver correctly uses the modern
SNOR_ID()macro format and integrates properly with the spi-nor subsystem. The commented-outINFO()lines (83, 85) serve as useful historical documentation showing the API migration path.One minor observation: consider removing the commented-out old
INFO()format lines if they're no longer needed for reference, as they constitute dead code. However, keeping them for migration documentation is also acceptable.If you prefer to clean up the dead code:
static const struct flash_info xtx_parts[] = { /* XTX (Shenzhen Xin Tian Xia Tech) */ - // { "xt25f128b", INFO(0x0b4018, 0, 64 * 1024, 256) }, { "xt25f128b", SNOR_ID(0x0b, 0x40, 0x18) }, - // { "XT25Q64", INFO(0x0b6017, 0, 64 * 1024, 128) }, { "XT25Q64", SNOR_ID(0x0b, 0x60, 0x17) }, };patch/kernel/archive/meson64-6.19/jethome-0001-Fix-meson64-add-gpio-irq-patch-from-https-lkml.org-l.patch (2)
51-57: Replace rawprintkwith proper kernel debug logging.The
printk()call on line 52 lacks a log level and will emit at default level, potentially spamming the kernel log. For debug output, usedev_dbg()which can be compiled out or filtered.Additionally, the opening brace on line 54 should be on the same line as the
ifstatement per kernel coding style.- hwirq = gpio - bank->first + bank->irq_first; - printk("gpio irq setup: hwirq: 0x%X irqfirst: 0x%X irqlast: 0x%X pin[%d]\n", hwirq, bank->irq_first, bank->irq_last, gpio); - if (hwirq > bank->irq_last) - { + hwirq = gpio - bank->first + bank->irq_first; + dev_dbg(pc->dev, "gpio irq setup: hwirq: 0x%X irqfirst: 0x%X irqlast: 0x%X pin[%d]\n", + hwirq, bank->irq_first, bank->irq_last, gpio); + if (hwirq > bank->irq_last) { dev_warn(pc->dev, "no more irq for pin[%d]\n", gpio); return -EINVAL; }
81-86: Consider adding a warning when no IRQ controller node is found.If both
of_find_compatible_node()calls fail,pc->of_irqremains NULL with no diagnostic output. The error only surfaces later inmeson_gpio_to_irq(). Adding adev_warn()here would help with debugging on boards lacking the IRQ controller node.Also note that
of_find_compatible_node()returns a refcounted node. If this pinctrl can be unloaded, ensureof_node_put(pc->of_irq)is called during cleanup to avoid a reference leak.pc->of_irq = of_find_compatible_node(NULL, NULL, "amlogic,meson-gpio-intc"); if (!pc->of_irq) pc->of_irq = of_find_compatible_node(NULL, NULL, "amlogic,meson-gpio-intc-ext"); + if (!pc->of_irq) + dev_warn(pc->dev, "gpio-intc node not found, gpio_to_irq will fail\n"); + pc->reg_mux = meson_map_resource(pc, gpio_np, "mux");patch/kernel/archive/meson64-6.19/general-meson-mmc-2-arm64-amlogic-dts-meson-update-meson-axg-device-tree.patch (1)
27-31: MMC phase properties look consistent; consider quick sanity check and minor ordering tweakFunctionally:
amlogic,mmc-phase = <CLK_PHASE_270 CLK_PHASE_0 CLK_PHASE_0>;on bothsd_emmc_bandsd_emmc_cmatches the “core, tx, rx phase” intent described in the subject and aligns with the new binding.- Triple length and macro usage look correct, so DT parsing and driver consumption should be fine.
Two small points:
Sanity-check vs original source/binding
Given the known risk ofREWRITE_PATCHESsubtly changing DT semantics, it’s worth quickly confirming these phase values against the original meson MMC phase patch/binding doc (or against what you use on other Meson families) to ensure 270° core / 0° tx / 0° rx is really what you want on AXG. Based on learnings, this is exactly the kind of DT change that can drift.Optional style nit: property ordering
Onsd_emmc_bthe new property is placed beforeresets, while onsd_emmc_cit’s afterresets. DT order is not semantically relevant, but for readability you might want to keep the order consistent between the two nodes (e.g., always afterclock-namesand beforeresets).No blockers from my side; this is just a suggestion and a quick sanity-check reminder.
Also applies to: 34-39
patch/kernel/archive/meson64-6.19/general-media-cec-silence-CEC-timeout-message-HACK.patch (1)
25-37: Logging-only change; timeout handling preserved (OK for edge / HACK patch)The change cleanly silences the noisy CEC timeout
pr_warn()while keepingcec_data_cancel(..., CEC_TX_STATUS_TIMEOUT, 0)intact, so functional timeout handling is unchanged and only log volume is reduced. This aligns with the stated goal of avoiding log spam from misbehaving AVRs, and is reasonable for the meson64edgekernel where such HACK patches are acceptable.If you ever want to retain some observability, a future refinement could be to switch this to
pr_debug()or a*_ratelimitedvariant instead of fully commenting it out, but that's optional and not a blocker here.patch/kernel/archive/meson64-6.19/meson-gxbb-dts-i2cX-missing-pins.patch (1)
1-9: Optional: fix typo in patch subjectPurely cosmetic, but if you end up touching this patch again, consider correcting the subject typo:
-Subject: fix i2cA and i2cB miossing pins +Subject: fix i2cA and i2cB missing pinsNo build/runtime impact; feel free to leave as‑is if respinning the series would be noisy.
patch/kernel/archive/meson64-6.19/meson-g12a-pinctrl-add-missing-ir-options.patch (1)
18-29: DTSremote_input_pinswiring is consistent with pinctrl namingLabel,
groups = "remote_input",function = "remote_input", andbias-disableare all consistent with the new pinctrl group/function added in the driver and follow existing naming patterns. Nothing problematic spotted; just ensure any board DTS that expects this pin uses"remote_input"as the group name.patch/kernel/archive/meson64-6.19/general-gpu-drm-add-new-display-resolution-2560x1440.patch (1)
61-67: HDMI hdisplay upper bound widened appropriately for 2560×1440Bumping
mode->hdisplaymax from 1920 to 2560 is exactly what’s needed for 2560×1440 (h=2560, v=1440) to pass validation; the existingvdisplaylimit (<= 1920) already covers 1440p. If you later want to support 2560×1600, you can mirror this change on the vertical bound as well. This is a reasonable relaxation for the meson64 edge kernel.Based on learnings, this kind of experimental mode enablement is aligned with the purpose of the edge branch.
patch/kernel/archive/meson64-6.19/driver-power-meson64-reset.patch (2)
86-91: Global variables should bestatic.The GPIO number variables are used only within this file and should be declared
staticto limit their scope and avoid potential symbol conflicts.-int sd_vqsw; -int sd_vmmc; -int sd_vqen; +static int sd_vqsw; +static int sd_vmmc; +static int sd_vqen;
112-165: Legacy GPIO API usage.This driver uses the legacy
gpio_*API (e.g.,gpio_request_one,gpio_free) rather than the moderngpiod_*(GPIO descriptor) API. While this works, the descriptor-based API is preferred for new kernel code. Given this is a carried patch for the edge kernel, this is acceptable as-is but worth noting for potential future refactoring.patch/kernel/archive/meson64-6.19/general-soc-0002-soc-amlogic-meson-gx-socinfo-sm-Add-Amlogic-secure-m.patch (3)
115-117: Minor: Unnecessary +1 in allocation size.The
+1in the allocation is not needed - the union is already properly sized for the data. This doesn't cause any functional issue but is slightly misleading.- id_buf = kzalloc(sizeof(union meson_sm_chip_id)+1, GFP_KERNEL); + id_buf = kzalloc(sizeof(*id_buf), GFP_KERNEL);
232-243: Simplify return:soc_device_to_devicewon't return an error after successful registration.After successful
soc_device_register(),soc_device_to_device()returns the embeddedstruct device*which won't be an error pointer. ThePTR_ERR_OR_ZERO(dev)check is defensive but unnecessary.dev = soc_device_to_device(soc_dev); platform_set_drvdata(pdev, soc_dev); dev_info(dev, "Amlogic Meson %s Revision %x:%x (%x:%x) Detected (SM)\n", soc_dev_attr->soc_id, socinfo.v1.major_id, socinfo.v1.chip_rev, socinfo.v1.pack_id, (socinfo.v1.reserved<<4) + socinfo.v1.layout_ver); - return PTR_ERR_OR_ZERO(dev); + return 0; }
246-252: Remove dead comment.The commented
// return 0;is a leftover from when.removereturnedint. Since this is now avoidfunction (as noted in the patch header hack), the comment can be removed.static void meson_gx_socinfo_sm_remove(struct platform_device *pdev) { struct soc_device *soc_dev = platform_get_drvdata(pdev); soc_device_unregister(soc_dev); - // return 0; }patch/kernel/archive/meson64-6.19/general-meson-vdec-add-HEVC-decode-codec.patch (3)
1366-1372: Missingfallthroughannotation for intentional case fallthrough.The kernel coding style requires explicit
fallthrough;annotation when falling through switch cases intentionally.switch (param->p.chroma_format_idc) { case 1: - sub_height = 2; /* fallthrough */ + sub_height = 2; + fallthrough; case 2: sub_width = 2; break; }
1501-1502: Missing space before==operator.Minor formatting issue violating kernel coding style.
- if (sess->fmt_out->pixfmt == V4L2_PIX_FMT_VP9 || sess->fmt_out->pixfmt ==V4L2_PIX_FMT_HEVC) { + if (sess->fmt_out->pixfmt == V4L2_PIX_FMT_VP9 || sess->fmt_out->pixfmt == V4L2_PIX_FMT_HEVC) {
1582-1584: Missing space before{in struct initializer.Minor formatting inconsistency.
- },{ + }, {patch/kernel/archive/meson64-6.19/general-meson-vdec-improve-mmu-and-fbc-handling-.patch (7)
84-85: Incorrect indentation: spaces instead of tabs.Kernel code style requires tabs for indentation. Line 84 uses spaces.
- const u32 revision = core->platform->revision; + const u32 revision = core->platform->revision;
104-105: Incorrect indentation: leading space instead of tab.- } else { - buf_y_paddr = vb2_dma_contig_plane_dma_addr(vb, 0); - } + } else { + buf_y_paddr = vb2_dma_contig_plane_dma_addr(vb, 0); + }
203-204: Incorrect indentation: spaces instead of tabs.- codec_hevc_free_mmu_headers(sess, comm); + codec_hevc_free_mmu_headers(sess, comm);
264-265: Incorrect indentation: spaces instead of tabs.- struct device *dev = core->dev; + struct device *dev = core->dev;
291-292: Incorrect indentation: leading space instead of tab.- if (ret) - return ret; + if (ret) + return ret;
366-368: Incorrect indentation: leading space instead of tab.if (codec_hevc_use_fbc(sess->pixfmt_cap, vp9->is_10bit)) - amvdec_write_dos(core, HEVC_CM_BODY_START_ADDR, buf_y_paddr); + amvdec_write_dos(core, HEVC_CM_BODY_START_ADDR, buf_y_paddr);
539-542: Incorrect indentation: leading space instead of tab.} else { sess->status = STATUS_NEEDS_RESUME; sess->changed_format = 0; - } + }patch/kernel/archive/meson64-6.19/overlay/meson-g12a-radxa-zero-gpio-8-led.dtso (1)
10-13: Consider fixing indentation for better consistency.The
__overlay__node at line 12 should be at the same indentation level astarget-path(line 11), as both are direct children offragment@0. The current indentation incorrectly suggests__overlay__is nested under thetarget-pathproperty. Additionally, the blank line at line 13 could be removed.Apply this diff to improve consistency:
fragment@0 { target-path = "/"; - __overlay__ { - + __overlay__ { leds { compatible = "gpio-leds";patch/kernel/archive/meson64-6.19/general-driver-tm1628-auxdisplay-add-support-for-Titanmec-TM16.patch (1)
533-535: Consider using attribute groups instead of direct sysfs file creation.The driver uses
device_create_file()anddevice_remove_file()for thedisplay_textattribute. Modern kernel drivers typically use attribute groups, which handle cleanup automatically and integrate better with device model lifecycle.Example refactor (if desired):
static struct attribute *tm1628_attrs[] = { &dev_attr_display_text.attr, NULL }; ATTRIBUTE_GROUPS(tm1628);Then add to the driver struct:
static struct spi_driver tm1628_spi_driver = { .probe = tm1628_spi_probe, .remove = tm1628_spi_remove, .shutdown = tm1628_spi_shutdown, .id_table = tm1628_spi_id_table, .driver = { .name = "tm1628", .of_match_table = tm1628_spi_of_matches, + .dev_groups = tm1628_groups, }, };And remove the manual
device_create_file()anddevice_remove_file()calls.Also applies to: 545-545
patch/kernel/archive/meson64-6.19/general-input-touchscreen-Add-D-WAV-Multitouch.patch (2)
117-139: Addstaticqualifier to limit symbol scope.
DEV_INFOis only used within this file and should not be visible externally.-const struct usbtouch_device_info DEV_INFO[] = { +static const struct usbtouch_device_info DEV_INFO[] = {
206-237: Consider movinginput_sync()outside the loop.
input_mt_report_pointer_emulation()andinput_sync()are called inside the loop for each finger. The typical pattern is to report all MT slots first, then call these once after the loop to batch the input events.for (id = 0; id < max_finger; id++) { if (dwav_usb_mt->finger[id].status == TS_EVENT_UNKNOWN) continue; if (dwav_usb_mt->finger[id].x >= max_x || dwav_usb_mt->finger[id].y >= max_y) continue; input_mt_slot(dwav_usb_mt->input, id); if (dwav_usb_mt->finger[id].status != TS_EVENT_RELEASE) { input_mt_report_slot_state(dwav_usb_mt->input, MT_TOOL_FINGER, true); input_report_abs(dwav_usb_mt->input, ABS_MT_POSITION_X, dwav_usb_mt->finger[id].x); input_report_abs(dwav_usb_mt->input, ABS_MT_POSITION_Y, dwav_usb_mt->finger[id].y); input_report_abs(dwav_usb_mt->input, ABS_MT_PRESSURE, max_press); } else { input_mt_report_slot_state(dwav_usb_mt->input, MT_TOOL_FINGER, false); dwav_usb_mt->finger[id].status = TS_EVENT_UNKNOWN; } - input_mt_report_pointer_emulation(dwav_usb_mt->input, true); - input_sync(dwav_usb_mt->input); } + input_mt_report_pointer_emulation(dwav_usb_mt->input, true); + input_sync(dwav_usb_mt->input); }patch/kernel/archive/meson64-6.19/dt/meson-g12b-a311d-cainiao-cniot-core.dts (1)
528-539: Note: spidev compatible string is a workaround.Using
"rohm,dh2228fv"for spidev instantiation is a well-known workaround in the embedded community. While functional, this may trigger "spidev listed directly in DT" warnings during kernel boot. Consider adding a brief comment explaining this is intentional for userspace WS2812 control./* Controlling WS2812 LEDs via spidev in user space. */ &spicc1 { status = "okay"; pinctrl-0 = <&spicc1_pins>; pinctrl-names = "default"; + /* + * Using "rohm,dh2228fv" compatible to instantiate spidev. + * This is a common workaround for userspace SPI access. + */ spidev@0 { compatible = "rohm,dh2228fv"; reg = <0>; spi-max-frequency = <3340000>; }; };patch/kernel/archive/meson64-6.19/dt/meson-sm1-ugoos-x3.dts (2)
13-23: Rootcompatibleshould include a board-specific string, not only the SoCHere you only expose
compatible = "amlogic,sm1";. All other SM1 ac2xx boards in mainline-style trees use a board-specific compatible first (e.g."cyx,a95xf3-air-100", "amlogic,sm1"), so that DT bindings and userspace can distinguish boards instead of seeing a generic SoC-only compatible. (lists.infradead.org)For Ugoos X3, consider something along the lines of:
/ { compatible = "ugoos,x3", "amlogic,sm1"; model = "Ugoos X3"; ... };This keeps you aligned with the ac2xx family and upstream expectations while still working fine in Armbian.
117-121: Double‑check CPU voltage limits vs added 2.016 GHz OPPYou restrict
&vddcputo 721000–1022000 µV and then addopp-2016000000at exactly 1.0 V. That’s a fairly tight headroom at the top end for an overclocked SM1 core, especially across voltage/temperature and silicon variation.If this OPP/voltage pair is known to be stable on real Ugoos X3 samples, then it’s fine, but if you copied values from another board, it may be worth revalidating under load (thermal stress + low input voltage) to ensure you don’t get random lockups.
Also applies to: 265-270
patch/kernel/archive/meson64-6.19/board-odroidc2-usb-hub-disable-autosuspend-for-Genesys-Logic-.patch (1)
10-11: Documentation claim doesn't match implementation scope.The commit message states "This patch only impacts GXBB devices," but the implementation applies the quirk globally to all Genesys Logic hubs (matched by vendor ID) across any platform, not just GXBB/Odroid C2 boards. While the fix may only be needed for GXBB devices, it will affect any system with these hubs.
Consider clarifying the commit message to reflect the actual scope, e.g., "This patch disables autosuspend for all Genesys Logic hubs system-wide, which fixes USB device issues on GXBB devices (Odroid C2). GXL/GXM devices use the newer dwc3 core and are not affected by the underlying issue."
patch/kernel/archive/meson64-6.19/overlay/meson-g12-pwm-gpiox-5-fan.dtso (1)
14-20: Optional: sanity‑check fan speed map and thermal trip against real hardware behavior.The
gpio-fanis binary‑state withgpio-fan,speed-map = <0 0>, <5000 1>;and a single active trip at 55 °C with 10 °C hysteresis tied to&fan. For an edge kernel this is fine as a starting point, but fan characteristics can be quirky (on some boards we’ve seen fans that only spin reliably at their maximum drive level). Based on learnings, hardware-specific fan behavior can be non‑obvious.If you have access to target hardware, it’s worth confirming that:
- The fan reliably starts at the configured “on” state when CPU temp crosses the
cpu_activetrip.- The chosen temperature/hysteresis values give reasonable noise/thermals for these SoCs.
No changes are strictly required here; just treat this as a tuning/verification reminder.
Also applies to: 28-40
patch/kernel/archive/meson64-6.19/general-meson-mmc-1-arm64-amlogic-mmc-meson-gx-Add-core-tx-rx-eMMC-SD-SD.patch (2)
44-52: Consider simplifying the error-path condition for readabilityThe current condition:
if (!(host->dev && host->dev->of_node) || (device_property_read_u32_array(host->dev, "amlogic,mmc-phase", phase, 3) < 0)) { ... }is correct but a bit dense to read.
As a minor style/readability tweak, you could rewrite it as:
if (!host->dev || !host->dev->of_node || device_property_read_u32_array(host->dev, "amlogic,mmc-phase", phase, 3) < 0) { ... }This keeps the same short‑circuit behavior but is easier to follow for future maintainers.
70-105: Clarify comments in newmeson-gx-mmc.hheader to avoid confusion about bit positionsThe functional part of the header looks good:
#define CLK_PHASE_0 0 #define CLK_PHASE_90 1 #define CLK_PHASE_180 2 #define CLK_PHASE_270 3However, the preceding comment block says for
Cfg_rx_phase,Cfg_tx_phase, andCfg_co_phasethat the relevant bits are all9:8, and duplicates that for each field. In the driver, the masks are:#define CLK_CORE_PHASE_MASK GENMASK(9, 8) #define CLK_TX_PHASE_MASK GENMASK(11, 10) #define CLK_RX_PHASE_MASK GENMASK(13, 12)So the comment in the header does not reflect how those fields are actually mapped in the register and may confuse readers.
Suggestion:
- Rephrase the comment block to state that these macros are values for the phase fields (0/90/180/270 degrees), without claiming specific bit positions, or
- Clarify the bit positions per field if you want to document the register layout here.
This is documentation‑only and doesn’t affect runtime behavior, but cleaning it up will make the binding header clearer.
patch/kernel/archive/meson64-6.19/jethome-0002-arm64-dts-jethub-j1xx-add-eeprom-node.patch (1)
21-31: Normalize DTS indentation to tabs for consistencyWithin the new
&i2c_AOblocks, some property lines and the closing brace are indented with spaces instead of tabs. That diverges from the rest of the DTS and kernel style for DT files.Consider re-indenting these lines to use tabs consistently (matching the surrounding DTS files) to avoid noisy diffs in future rewrites and keep the patch closer to upstream formatting.
Also applies to: 41-51
patch/kernel/archive/meson64-6.19/dt/meson-sm1-jethome-jethub-j200.dts (1)
677-685: Consider using generic node names for temperature sensors.While
tmp102@48andtmp102@49work correctly, the preferred device-tree convention is to use generic descriptive node names liketemperature-sensor@48. The compatible string already identifies the device type.- temp1: tmp102@48 { + temp1: temperature-sensor@48 { compatible = "ti,tmp102"; reg = <0x48>; }; - temp2: tmp102@49 { + temp2: temperature-sensor@49 { compatible = "ti,tmp102"; reg = <0x49>; };patch/kernel/archive/meson64-6.19/board-bananapim5-002-add-wifi-bt-support.patch (1)
1-4: Consider dropping "WIP" from the patch subjectIf this patch is considered stable for inclusion, you may want to remove the
WIP:prefix from the subject to avoid confusion about its maturity in our patchset.patch/kernel/archive/meson64-6.19/board-khadas-vim3-fix-missing-i2c3-nod.patch (1)
11-12: Minor typo in Signed-off-by name
Signed-off-by: Christian Hewittthas three “t” characters. If this is not taken verbatim from upstream, you may want to correct it toHewittfor consistency with other patches.config/sources/mainline-kernel.conf.sh (1)
30-34: Minor mismatch in commented example log messageThe (commented-out) example function now checks for
KERNELBRANCH == 'tag:v6.19-rc1'but the seconddisplay_alertstring still says “missing torvalds tag on 6.9-rc1”. If you ever re-enable this example, consider aligning the message with 6.19-rc1 for clarity.-# display_alert "mainline-kernel: missing torvalds tag on 6.9-rc1" "Using KERNELSOURCE='${KERNELSOURCE}' for KERNELBRANCH='${KERNELBRANCH}'" "info" +# display_alert "mainline-kernel: missing torvalds tag on 6.19-rc1" "Using KERNELSOURCE='${KERNELSOURCE}' for KERNELBRANCH='${KERNELBRANCH}'" "info"patch/kernel/archive/meson64-6.19/dt/meson-g12b-waveshare-cm4-io-base-b.dts (1)
19-45: Trailing whitespace on line 26.There appears to be a trailing tab character at the end of line 26 (after the closing brace of
fanmid0). While this won't affect functionality, it should be cleaned up for consistency.trips { fanmid0: fanmid0 { temperature = <60000>; hysteresis = <2000>; type = "active"; }; - + fanmax0: fanmax0 {patch/kernel/archive/meson64-6.19/dt/meson-gxm-mini-m8s-pro.dts (1)
71-76: Misleading label name for QCA9377 WiFi node.The label
brcmf:suggests Broadcom FMAC, but the compatible string is"qcom,qca9377"(Qualcomm Atheros). Consider renaming the label to something more accurate likeqcawifi:or simplywifi:to avoid confusion.&sd_emmc_a { - brcmf: wifi@1 { + wifi: wifi@1 { reg = <1>; compatible = "qcom,qca9377"; }; };patch/kernel/archive/meson64-6.19/dt/meson-gxm-c400-plus.dts (1)
17-22: Consider consolidating duplicate&sd_emmc_anode references.The
&sd_emmc_anode is defined in two separate blocks (lines 17-22 and 39-42). While the DT compiler will merge these correctly, consolidating them improves readability.&sd_emmc_a { + max-frequency = <50000000>; + brcmf: wifi@1 { reg = <1>; compatible = "brcm,bcm4329-fmac"; }; }; - -/* Wireless SDIO Module */ -&sd_emmc_a { - max-frequency = <50000000>; -};Also applies to: 39-42
| name: meson64-6.7 | ||
| kind: kernel | ||
| type: mainline # or: vendor | ||
| branch: linux-6.7.y | ||
| last-known-good-tag: v6.7.0 |
There was a problem hiding this comment.
Critical: Version metadata mismatch.
The configuration metadata references version 6.7, but this file is for meson64-6.19. Update the following fields:
- name: should be "meson64-6.19"
- branch: should be "linux-6.19.y"
- last-known-good-tag: should be "v6.19" or the appropriate 6.19 tag
Apply this diff:
- name: meson64-6.7
+ name: meson64-6.19
kind: kernel
type: mainline # or: vendor
- branch: linux-6.7.y
- last-known-good-tag: v6.7.0
+ branch: linux-6.19.y
+ last-known-good-tag: v6.19📝 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.
| name: meson64-6.7 | |
| kind: kernel | |
| type: mainline # or: vendor | |
| branch: linux-6.7.y | |
| last-known-good-tag: v6.7.0 | |
| name: meson64-6.19 | |
| kind: kernel | |
| type: mainline # or: vendor | |
| branch: linux-6.19.y | |
| last-known-good-tag: v6.19 |
🤖 Prompt for AI Agents
In patch/kernel/archive/meson64-6.19/0000.patching_config.yaml around lines 4 to
8, the metadata incorrectly references 6.7; update the fields to match 6.19: set
name to "meson64-6.19", set branch to "linux-6.19.y", and set
last-known-good-tag to the correct 6.19 tag (e.g. "v6.19" or the precise v6.19.x
tag you intend to use).
There was a problem hiding this comment.
This stuff is more or less informational. Also we cannot assume that 6.19 is a known good tag.
There was a problem hiding this comment.
@EvilOlaf, thank you for the clarification! You're right—since this metadata is informational (as noted in the comment "not used by the patching scripts") and 6.19 is still being validated as part of this PR, it makes sense to leave last-known-good-tag pointing to a verified version rather than the new 6.19.
The name and branch fields being out of sync with the directory name is minor for informational metadata. Feel free to update them later for consistency once 6.19 is confirmed stable, or leave as-is if it's not causing any issues. 👍
🧠 Learnings used
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:65-72
Timestamp: 2025-09-14T11:37:35.089Z
Learning: In the Armbian build system, patch directories referenced in BOOTPATCHDIR and KERNELPATCHDIR configurations can be non-existent without causing build failures. Empty patch directories are also ignored by git, so missing patch directories should not be flagged as errors during code review.
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: 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: tabrisnet
Repo: armbian/build PR: 8661
File: lib/functions/compilation/armbian-kernel.sh:194-201
Timestamp: 2025-09-22T21:52:01.225Z
Learning: In lib/functions/compilation/armbian-kernel.sh, the kernel_config_modifying_hashes array is not universally required for all kernel configuration functions - some functions like armbian_kernel_config__netkit() operate without it, and adding entries with '=m' would be incorrect when the actual result might be '=y' for options already built-in.
Learnt from: tabrisnet
Repo: armbian/build PR: 8661
File: lib/functions/compilation/armbian-kernel.sh:194-201
Timestamp: 2025-09-22T21:52:01.225Z
Learning: In lib/functions/compilation/armbian-kernel.sh, the kernel_config_modifying_hashes array is not universally required for all kernel configuration functions - some functions like armbian_kernel_config__netkit() operate without it, and adding entries with '=m' would be incorrect when the actual result might be '=y' for options already built-in.
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.
Learnt from: rpardini
Repo: armbian/build PR: 8044
File: patch/u-boot/v2025.04/cmd-fileenv-read-string-from-file-into-env.patch:73-75
Timestamp: 2025-03-31T22:20:41.849Z
Learning: When porting patches between U-Boot versions (like from 2025.01 to 2025.04), rpardini prefers to maintain patches as-is rather than introducing refactoring changes, even when potential improvements are identified. This approach prioritizes consistency and reduces the risk of introducing new issues.
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: 8820
File: config/sources/families/include/meson64_common.inc:51-53
Timestamp: 2025-10-26T12:56:29.185Z
Learning: In the Armbian build framework, scripts/config correctly handles kernel configuration option names both with and without the CONFIG_ prefix, so opts_m+=("CONFIG_RTL8822CS") and opts_m+=("RTL8822CS") are both valid and will work correctly.
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: 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: 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.
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.
| + fan-supply = <&vcc_5v>; | ||
| + interrupt-parent = <&gpio_intc>; | ||
| + interrupts = <84 IRQ_TYPE_EDGE_FALLING>; | ||
| + pulses-per-revolutions = <2>; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "*board-odroidhc4-enable-fan1_input.patch" -type fRepository: armbian/build
Length of output: 284
🏁 Script executed:
rg -n "pulses-per-revolution" --type=patch -iRepository: armbian/build
Length of output: 86
🌐 Web query:
device tree binding fan tachometer pulses-per-revolution kernel documentation
💡 Result:
Short answer — use the devicetree property pulses-per-revolution (integer, >0) on the fan/tach binding; default assumed = 2 if absent. See the pwm-fan binding and hwmon/sysfs docs for type, examples and behavior. (kernel.googlesource.com)
Citations:
🏁 Script executed:
cat -n "./patch/kernel/archive/meson64-6.19/board-odroidhc4-enable-fan1_input.patch"Repository: armbian/build
Length of output: 1236
Fix property name typo.
The property name should be pulses-per-revolution (singular), not pulses-per-revolutions (plural). According to the kernel device tree bindings documentation for pwm-fan, the correct property is singular. This typo will cause the kernel driver to ignore the property, breaking fan speed monitoring functionality.
Apply this diff:
- pulses-per-revolutions = <2>;
+ pulses-per-revolution = <2>;🤖 Prompt for AI Agents
In patch/kernel/archive/meson64-6.19/board-odroidhc4-enable-fan1_input.patch
around line 23, the device tree property is misspelled as
"pulses-per-revolutions"; change it to the correct binding name
"pulses-per-revolution" (singular) so the pwm-fan driver recognizes the setting
and fan speed monitoring works; update the patch line to use
pulses-per-revolution = <2>; and ensure no other occurrences of the plural form
remain in the file.
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!
There was a problem hiding this comment.
I actually maintain the HC4 for the last few years...
And yes, the rabbit is right: the correct property is pulses-per-revolution (singular) (See https://www.kernel.org/doc/Documentation/devicetree/bindings/hwmon/pwm-fan.yaml).
That prop (in the plural/wrong form) comes all the way back from the vendor kernel and has AFAIK "always" been wrong. Fact is, with it "wrong", the default kicks in, and the default is... also 2.
| diff --git a/Documentation/devicetree/bindings/auxdisplay/titanmec,tm1628.yaml b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm1628.yaml | ||
| new file mode 100644 | ||
| index 000000000000..111111111111 | ||
| --- /dev/null | ||
| +++ b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm1628.yaml | ||
| @@ -0,0 +1,82 @@ | ||
| +# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) | ||
| +%YAML 1.2 | ||
| +--- | ||
| +$id: http://devicetree.org/schemas/leds/titanmec,tm1628.yaml# | ||
| +$schema: http://devicetree.org/meta-schemas/core.yaml# | ||
| + | ||
| +title: Titan Micro Electronics TM1628 LED controller | ||
| + | ||
| +properties: | ||
| + compatible: | ||
| + enum: | ||
| + - titanmec,tm1628 | ||
| + | ||
| + reg: | ||
| + maxItems: 1 | ||
| + | ||
| + grid: | ||
| + description: | ||
| + Mapping of display digit position to grid number. | ||
| + This implicitly defines the display size. | ||
| + $ref: /schemas/types.yaml#/definitions/uint8-array | ||
| + minItems: 1 | ||
| + maxItems: 7 | ||
| + | ||
| + segment-mapping: | ||
| + description: | ||
| + Mapping of 7 segment display segments A-G to bit numbers 1-12. | ||
| + $ref: /schemas/types.yaml#/definitions/uint8-array | ||
| + minItems: 7 | ||
| + maxItems: 7 | ||
| + | ||
| + "#address-cells": | ||
| + const: 2 | ||
| + | ||
| + "#size-cells": | ||
| + const: 0 | ||
| + | ||
| +required: | ||
| + - compatible | ||
| + - reg | ||
| + | ||
| +patternProperties: | ||
| + "^.*@[1-7],([1-9]|1[0-6])$": | ||
| + type: object | ||
| + description: | | ||
| + Properties for a single LED. | ||
| + | ||
| + properties: | ||
| + reg: | ||
| + description: | | ||
| + 1-based grid number, followed by 1-based segment bit number. | ||
| + maxItems: 1 | ||
| + | ||
| + required: | ||
| + - reg | ||
| + | ||
| +examples: | ||
| + - | | ||
| + #include <dt-bindings/leds/common.h> | ||
| + | ||
| + spi { | ||
| + #address-cells = <1>; | ||
| + #size-cells = <0>; | ||
| + | ||
| + led-controller@0 { | ||
| + compatible = "titanmec,tm1628"; | ||
| + reg = <0>; | ||
| + spi-3-wire; | ||
| + spi-lsb-first; | ||
| + spi-max-frequency = <500000>; | ||
| + grid = /bits/ 8 <4 3 2 1>; | ||
| + segment-mapping = /bits/ 8 <4 5 6 1 2 3 7>; | ||
| + #address-cells = <2>; | ||
| + #size-cells = <0>; | ||
| + | ||
| + alarmn@5,4 { | ||
| + reg = <5 4>; | ||
| + function = LED_FUNCTION_ALARM; | ||
| + }; | ||
| + }; | ||
| + }; | ||
| +... |
There was a problem hiding this comment.
Critical: Property name mismatch between device tree bindings and driver code.
The device tree bindings document properties as grid and segment-mapping (lines 104, 112), and the example uses these names without vendor prefixes (lines 158-159). However, the driver code reads these properties with vendor prefixes: titanmec,grid (lines 506, 514) and titanmec,segment-mapping (line 523).
This mismatch will cause the driver to fail probe when used with device trees that follow the documented bindings.
Apply this diff to align the driver with the bindings:
- ret = device_property_count_u8(&spi->dev, "titanmec,grid");
+ ret = device_property_count_u8(&spi->dev, "grid");
if (ret < 1 || ret > MAX_GRID_SIZE) {
dev_err(&spi->dev, "Invalid display length (%d)\n", ret);
return -EINVAL;
}
s->grid_size = ret;
- ret = device_property_read_u8_array(&spi->dev, "titanmec,grid", s->grid, s->grid_size);
+ ret = device_property_read_u8_array(&spi->dev, "grid", s->grid, s->grid_size);
if (ret < 0)
return ret;
for (i = 0; i < s->grid_size; i++) {
if (s->grid[i] < 1 || s->grid[i] > s->grid_size)
return -EINVAL;
}
- ret = device_property_read_u8_array(&spi->dev, "titanmec,segment-mapping",
+ ret = device_property_read_u8_array(&spi->dev, "segment-mapping",
s->segment_mapping, NUM_LED_SEGS);Also applies to: 506-526
| + if (!dwav_usb_mt->finger) | ||
| + goto err_free_mem; | ||
| + | ||
| + input_dev = input_allocate_device(); | ||
| + if (!input_dev) | ||
| + goto err_free_mem; | ||
| + | ||
| + dwav_usb_mt->data_size = sizeof(struct dwav_raw); | ||
| + dwav_usb_mt->data = usb_alloc_coherent(udev, dwav_usb_mt->data_size, | ||
| + GFP_KERNEL, &dwav_usb_mt->data_dma); | ||
| + if (!dwav_usb_mt->data) | ||
| + goto err_free_mem; |
There was a problem hiding this comment.
Memory leak: dwav_usb_mt->finger not freed in error paths.
When input_allocate_device() or usb_alloc_coherent() fails, the code jumps to err_free_mem which frees dwav_usb_mt but not the previously allocated finger array.
Apply this diff to fix the leak:
err_free_mem:
if (input_dev)
input_free_device(input_dev);
+ kfree(dwav_usb_mt->finger);
kfree(dwav_usb_mt);
return err;Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In
patch/kernel/archive/meson64-6.19/general-input-touchscreen-Add-D-WAV-Multitouch.patch
around lines 499-510, the error paths jump to err_free_mem without freeing the
previously allocated dwav_usb_mt->finger buffer; update the error handling so
that on failure of input_allocate_device() or usb_alloc_coherent() you first
kfree(dwav_usb_mt->finger) (or call a new err_free_finger label that frees
finger then falls through to err_free_mem) before freeing dwav_usb_mt to prevent
the memory leak.
| + | ||
| + usb_set_intfdata(intf, NULL); | ||
| + | ||
| + /* this will stop IO via close */ | ||
| + input_unregister_device(dwav_usb_mt->input); | ||
| + | ||
| + usb_free_urb(dwav_usb_mt->irq); | ||
| + | ||
| + dwav_usb_mt_free_buffers(interface_to_usbdev(intf), dwav_usb_mt); | ||
| + | ||
| + kfree(dwav_usb_mt); | ||
| +} |
There was a problem hiding this comment.
Memory leak: finger array not freed on disconnect.
The dwav_usb_mt->finger array allocated during probe is never freed in the disconnect handler.
Apply this diff:
dwav_usb_mt_free_buffers(interface_to_usbdev(intf), dwav_usb_mt);
+ kfree(dwav_usb_mt->finger);
kfree(dwav_usb_mt);
}📝 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.
| + | |
| + usb_set_intfdata(intf, NULL); | |
| + | |
| + /* this will stop IO via close */ | |
| + input_unregister_device(dwav_usb_mt->input); | |
| + | |
| + usb_free_urb(dwav_usb_mt->irq); | |
| + | |
| + dwav_usb_mt_free_buffers(interface_to_usbdev(intf), dwav_usb_mt); | |
| + | |
| + kfree(dwav_usb_mt); | |
| +} | |
| dwav_usb_mt_free_buffers(interface_to_usbdev(intf), dwav_usb_mt); | |
| kfree(dwav_usb_mt->finger); | |
| kfree(dwav_usb_mt); | |
| } |
🤖 Prompt for AI Agents
In
patch/kernel/archive/meson64-6.19/general-input-touchscreen-Add-D-WAV-Multitouch.patch
around lines 599-610, the disconnect path frees irq, buffers and the main
dwav_usb_mt struct but never frees the dynamically allocated dwav_usb_mt->finger
array; add a check and call kfree(dwav_usb_mt->finger) (if non-NULL) before
kfree(dwav_usb_mt) so the per-touch fingerprint array is released on disconnect.
| + }, { | ||
| + .pixfmt = V4L2_PIX_FMT_VP9, | ||
| + .min_buffers = 16, | ||
| + .max_buffers = 24, | ||
| + .max_width = 3840, | ||
| + .max_height = 2160, | ||
| + .vdec_ops = &vdec_hevc_ops, | ||
| + .codec_ops = &codec_vp9_ops, | ||
| + .firmware_path = "meson/vdec/gxl_vp9.bin", | ||
| + .pixfmts_cap = { V4L2_PIX_FMT_NV12M, 0 }, | ||
| + .flags = V4L2_FMT_FLAG_COMPRESSED | | ||
| + V4L2_FMT_FLAG_DYN_RESOLUTION, | ||
| + }, { |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify that codec_vp9_ops and vdec_hevc_ops are defined in the kernel source
# Search for codec_vp9_ops definition
echo "=== Searching for codec_vp9_ops definition ==="
rg -n --type c -C3 'codec_vp9_ops' patch/kernel/archive/meson64-6.19/
# Search for vdec_hevc_ops definition
echo -e "\n=== Searching for vdec_hevc_ops definition ==="
rg -n --type c -C3 'vdec_hevc_ops' patch/kernel/archive/meson64-6.19/
# Search for vdec_formats_gxbb to understand its usage context
echo -e "\n=== Searching for vdec_formats_gxbb array usage ==="
rg -n --type c -C5 'vdec_formats_gxbb' patch/kernel/archive/meson64-6.19/Repository: armbian/build
Length of output: 204
🏁 Script executed:
#!/bin/bash
# Examine the patch file structure
echo "=== File type and size ==="
file patch/kernel/archive/meson64-6.19/meson-gxm-vdec-add-VP9-support-to-GXM.patch
wc -l patch/kernel/archive/meson64-6.19/meson-gxm-vdec-add-VP9-support-to-GXM.patch
echo -e "\n=== First 60 lines of patch file ==="
head -60 patch/kernel/archive/meson64-6.19/meson-gxm-vdec-add-VP9-support-to-GXM.patch
echo -e "\n=== Check for symbol context in patch ==="
rg -n 'codec_vp9_ops|vdec_hevc_ops|vdec_formats' patch/kernel/archive/meson64-6.19/meson-gxm-vdec-add-VP9-support-to-GXM.patch
echo -e "\n=== Look for source file being patched ==="
head -20 patch/kernel/archive/meson64-6.19/meson-gxm-vdec-add-VP9-support-to-GXM.patch | grep -E '^\-\-\-|^\+\+\+'Repository: armbian/build
Length of output: 2147
🏁 Script executed:
#!/bin/bash
# Search for symbol definitions in the broader kernel patch context
echo "=== Search all meson64-6.19 patches for symbol definitions ==="
rg -l 'codec_vp9_ops|vdec_hevc_ops' patch/kernel/archive/meson64-6.19/
echo -e "\n=== List all patches in meson64-6.19 directory ==="
ls -1 patch/kernel/archive/meson64-6.19/ | head -20
echo -e "\n=== Search for vdec_hevc_ops in any of the patches ==="
grep -r 'vdec_hevc_ops' patch/kernel/archive/meson64-6.19/
echo -e "\n=== Search for codec_vp9_ops in any of the patches ==="
grep -r 'codec_vp9_ops' patch/kernel/archive/meson64-6.19/
echo -e "\n=== Search for platform data structure context ==="
rg -A10 'struct amvdec_format' patch/kernel/archive/meson64-6.19/ | head -40Repository: armbian/build
Length of output: 6425
🏁 Script executed:
#!/bin/bash
# Search for vdec_formats_gxm array to confirm it exists separately from gxbb
echo "=== Search for vdec_formats_gxm array ==="
grep -n 'vdec_formats_gxm' patch/kernel/archive/meson64-6.19/*.patch
echo -e "\n=== Check if general HEVC patch adds to both gxbb and gxm ==="
grep -B2 -A2 'vdec_formats_gxm\|vdec_formats_gxbb' patch/kernel/archive/meson64-6.19/general-meson-vdec-add-HEVC-decode-codec.patch | head -50
echo -e "\n=== Verify codec_vp9_ops definition location ==="
echo "Checking if codec_vp9_ops is defined in any kernel patch in the repository..."
find patch/kernel/archive -name '*.patch' -exec grep -l 'codec_vp9_ops\s*=' {} \;Repository: armbian/build
Length of output: 877
Add VP9 entry to vdec_formats_gxm array instead of vdec_formats_gxbb.
The commit message states "add VP9 support to GXM," but the patch modifies the vdec_formats_gxbb array. The codebase contains separate format arrays for different platforms—vdec_formats_gxbb and vdec_formats_gxm (as shown in the general HEVC codec patch). To match the stated intent, the VP9 entry should be added to the vdec_formats_gxm array. Without this correction, VP9 support will be added to the GXBB platform instead of GXM.
🤖 Prompt for AI Agents
In patch/kernel/archive/meson64-6.19/meson-gxm-vdec-add-VP9-support-to-GXM.patch
around lines 25 to 37, the new VP9 format entry is being added to the
vdec_formats_gxbb array instead of vdec_formats_gxm; to fix, remove the inserted
block from vdec_formats_gxbb and add the exact same block into the
vdec_formats_gxm array (or change the insertion point/array name to
vdec_formats_gxm) so the VP9 entry is registered for the GXM platform, leaving
other fields unchanged.
| ### i2c8 | ||
|
|
||
| Activates TWI/I2C bus 8 | ||
|
|
||
| I2C8 pins (SCL, SDA): GPIO1-C4, GPIO1-C5 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if i2c8 overlay file actually exists for meson64-6.19
fd -t f "i2c8" patch/kernel/archive/meson64-6.19/overlay/
# Check for any rockchip-style GPIO references in meson overlay files
rg -n "GPIO[0-9]+-[A-Z][0-9]+" patch/kernel/archive/meson64-6.19/overlay/Repository: armbian/build
Length of output: 164
🏁 Script executed:
# Read the specific README file to see the actual content
cat -n patch/kernel/archive/meson64-6.19/overlay/README.meson-overlays | sed -n '10,25p'Repository: armbian/build
Length of output: 422
🏁 Script executed:
# Check if similar GPIO naming patterns exist in rockchip overlays for comparison
rg -n "GPIO[0-9]+-[A-Z][0-9]+" patch/kernel/archive/rockchip64*/overlay/ 2>/dev/null | head -20Repository: armbian/build
Length of output: 1474
🏁 Script executed:
# List what Meson overlay files exist
fd -t f . patch/kernel/archive/meson64-6.19/overlay/ | head -20Repository: armbian/build
Length of output: 1727
Remove or correct the i2c8 overlay entry—it uses Rockchip GPIO naming, not Meson.
The i2c8 description at line 21 references "GPIO1-C4, GPIO1-C5", which is the Rockchip GPIO naming convention (confirmed across rockchip64-6.18, 6.6, 6.12, and 6.9 overlays). Meson uses GPIOX, GPIOA, GPIOH, and GPIOAO naming patterns (as seen in other entries in this same README). Additionally, no corresponding i2c8.dtso overlay file exists in the meson64-6.19/overlay/ directory. Either remove this orphaned documentation or replace it with correct Meson hardware and GPIO pin information.
There was a problem hiding this comment.
This readme probably hasn't been touched in ages...
There was a problem hiding this comment.
🧩 Analysis chain
@EvilOlaf, you're right—it does look like copy-paste from another platform that was never cleaned up.
🏁 Script executed:
#!/bin/bash
# Check when this README was last modified and its git history
git log --oneline --follow -- patch/kernel/archive/meson64-6.19/overlay/README.meson-overlays | head -10
# Also check if similar README exists in other meson kernel versions
fd -t f "README.meson-overlays" patch/kernel/archive/
Length of output: 397
@EvilOlaf, the git history confirms your suspicion—it was copied from odroid-c4 overlays back in commit 47cffce2 and has been carried forward through 6.12 → 6.18 → 6.19 with only a docs URL update along the way.
Since there's no actual i2c8.dtso overlay file and the GPIO naming is Rockchip-specific, you should remove the entire i2c8 section (lines 17-21) from the README. The only valid overlays documented should be the meson-sm1-odroid-c4-i2c0 and meson-sm1-odroid-c4-i2c1 entries that actually exist in the directory.
🧠 Learnings used
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: djurny
Repo: armbian/build PR: 8287
File: config/bootscripts/boot-sunxi.cmd:13-23
Timestamp: 2025-06-12T21:08:11.318Z
Learning: In config/bootscripts/boot-sunxi.cmd the variable name `align_overlap_oboe_avoidance` intentionally uses the acronym “OBOE” (Off-By-One Error); it is not a typo and should not be renamed.
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: 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: tabrisnet
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-08-30T04:13:16.457Z
Learning: Armbian kernel configuration files like linux-filogic-current.config are autogenerated overlays on top of arch defconfig. Comments added manually will be lost during future updates by maintainers, and explicit "CONFIG_OPTION is not set" statements aren't needed for mutually exclusive options since these are overlay configs that only specify changes from the base configuration.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8537
File: config/boards/qcom-robotics-rb5.conf:1-1
Timestamp: 2025-09-18T03:36:17.862Z
Learning: In Armbian board configuration files, .wip and .conf extensions require BOARD_MAINTAINER to be present and contain at least one maintainer. If no maintainer is present, the board support rules state it does not qualify for standard support and must be moved to community support (.csc extension). This is documented at https://docs.armbian.com/User-Guide_Board-Support-Rules/
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.
Learnt from: djurny
Repo: armbian/build PR: 8287
File: config/bootscripts/boot-sunxi.cmd:38-44
Timestamp: 2025-06-12T21:14:36.024Z
Learning: In config/bootscripts/boot-sunxi.cmd the unconditional "+1" increment in func_align_addr_next (when align_overlap_oboe_avoidance="on") is intentional. It compensates for a known off-by-one error in U-Boot where the end address is calculated as start+size instead of start+size-1, so the extra page prevents overlap. This behavior should not be “optimized away”.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8537
File: config/boards/qcom-robotics-rb5.conf:1-1
Timestamp: 2025-09-18T03:36:17.862Z
Learning: In Armbian board configuration files (regardless of file extension), the standard pattern is to have only one line as a comment describing the board hardware specifications. This single-line description typically includes the SoC model, core count, RAM options, and key features like connectivity options, storage interfaces, and special features. The file extensions indicate board support status: .conf (standard support), .csc (community supported), .eos (end of support), .tvb (tvbox), .wip (work in progress).
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:44:54.545Z
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.
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: 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: 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: 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: 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.
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.
Just for the heck of it, feel free to refactor this readme and either provide a PR or commitable suggestion to address this.
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# List all overlay files in the meson64-6.19 overlay directory
echo "=== All overlay files ==="
fd -e dtso . patch/kernel/archive/meson64-6.19/overlay/ | sort
echo ""
echo "=== Count by category ==="
fd -e dtso . patch/kernel/archive/meson64-6.19/overlay/ | grep -o 'radxa-zero\|odroid\|g12-gxl\|g12-pwm\|sm1-\|g12a-\|g12b-' | sort | uniq -c
Length of output: 2779
@EvilOlaf, here's a complete refactored README documenting all 34 overlays currently in the directory:
This document describes overlays provided in the kernel packages
For generic Armbian overlays documentation please see
https://docs.armbian.com/User-Guide_Armbian_overlays/
### Platform:
meson / meson64 (Amlogic)
### Provided overlays:
#### Generic Meson overlays (works on multiple boards):
- meson-i2cA
- meson-i2cB
- meson-uartA
- meson-uartC
- meson-w1-gpio
- meson-w1AB-gpio
- meson-g12-gxl-cma-pool-896MB
- meson-g12-pwm-gpiox-5-fan
#### Radxa Zero (G12A) overlays:
- meson-g12a-radxa-zero-gpio-8-led
- meson-g12a-radxa-zero-gpio-10-led
- meson-g12a-radxa-zero-i2c-ao-m0-gpioao-2-gpioao-3
- meson-g12a-radxa-zero-i2c-ee-m1-gpioh-6-gpioh-7
- meson-g12a-radxa-zero-i2c-ee-m1-gpiox-10-gpiox-11
- meson-g12a-radxa-zero-i2c-ee-m3-gpioa-14-gpioa-15
- meson-g12a-radxa-zero-pwm-c-on-gpiox-8
- meson-g12a-radxa-zero-pwmao-a-on-gpioao-11
- meson-g12a-radxa-zero-spi-spidev
- meson-g12a-radxa-zero-uart-ao-a-on-gpioao-0-gpioao-1
- meson-g12a-radxa-zero-uart-ao-b-on-gpioao-2-gpioao-3
- meson-g12a-radxa-zero-uart-ao-b-on-gpioao-8-gpioao-9
- meson-g12a-radxa-zero-uart-ee-c
#### Banana Pi (G12B/SM1) overlays:
- meson-g12b-bananapi-cm4-i2c2
- meson-g12b-bananapi-cm4-pwm-gpioh-5-fan
- meson-g12b-bananapi-m2s-rtl8822cs
- meson-sm1-bananapi-m5-rtl8822cs
- meson-sm1-bananapi-uartA
- meson-sm1-bananapi-uartAO_B
- meson-sm1-bananapi-uartA_cts_rts
#### Odroid overlays:
- meson-g12b-odroid-n2-spi
- meson-sm1-odroid-c4-i2c0
- meson-sm1-odroid-c4-i2c1
#### Other board-specific overlays:
- meson-g12b-waveshare-cm4-io-base-usb
- meson-sm1-jethome-jethub-j200-spi
### Overlay details:
#### Generic I2C overlays
**meson-i2cA** / **meson-i2cB**
Activates I2C bus A or B on compatible Meson boards.
#### Generic UART overlays
**meson-uartA** / **meson-uartC**
Activates UART A or C on compatible Meson boards.
#### Generic 1-Wire overlays
**meson-w1-gpio** / **meson-w1AB-gpio**
Activates 1-Wire bus on GPIO pins.
#### CMA memory pool
**meson-g12-gxl-cma-pool-896MB**
Configures a 896MB CMA (Contiguous Memory Allocator) pool for G12/GXL platforms, useful for video decoding/encoding.
#### PWM fan control
**meson-g12-pwm-gpiox-5-fan**
Enables PWM-controlled fan on GPIOX_5 with thermal control for G12 series SoCs (A311D/G12A/G12B/SM1).
#### Radxa Zero overlays
All Radxa Zero overlays are prefixed with `meson-g12a-radxa-zero-` and enable various peripherals:
- **gpio-8-led** / **gpio-10-led**: GPIO LEDs on GPIOAO_8 or GPIOAO_10
- **i2c-*** overlays: Enable I2C buses on different pin combinations
- **pwm-*** overlays: Enable PWM outputs for various purposes
- **spi-spidev**: Enable SPI with spidev interface
- **uart-*** overlays: Enable UART interfaces on different pin sets
#### Odroid C4 overlays
**meson-sm1-odroid-c4-i2c0** / **meson-sm1-odroid-c4-i2c1**
Activates I2C bus 0 or 1 on Odroid C4.
#### Wireless module overlays
**meson-g12b-bananapi-m2s-rtl8822cs** / **meson-sm1-bananapi-m5-rtl8822cs**
Enables RTL8822CS WiFi/Bluetooth module on Banana Pi M2S and M5 boards.
### GPIO naming convention:
Meson/Amlogic SoCs use the following GPIO naming:
- GPIOAO_x: Always-On GPIO bank
- GPIOX_x: Main GPIO bank X
- GPIOH_x: Main GPIO bank H
- GPIOA_x: Main GPIO bank A
- GPIOBOOT_x: Boot GPIO bank
Refer to your board's pinout diagram for specific pin locations.This refactored README:
- ✅ Removes the incorrect i2c8 entry with Rockchip GPIO naming
- ✅ Documents all 34 actual overlay files in the directory
- ✅ Organizes overlays logically by board family
- ✅ Uses proper Meson GPIO naming conventions
- ✅ Provides functional descriptions for major overlay categories
- ✅ Includes a GPIO naming convention reference section
🧠 Learnings used
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: 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: 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: 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: 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: 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: tabrisnet
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-08-30T04:13:16.457Z
Learning: Armbian kernel configuration files like linux-filogic-current.config are autogenerated overlays on top of arch defconfig. Comments added manually will be lost during future updates by maintainers, and explicit "CONFIG_OPTION is not set" statements aren't needed for mutually exclusive options since these are overlay configs that only specify changes from the base configuration.
Learnt from: djurny
Repo: armbian/build PR: 8287
File: config/bootscripts/boot-sunxi.cmd:13-23
Timestamp: 2025-06-12T21:08:11.318Z
Learning: In config/bootscripts/boot-sunxi.cmd the variable name `align_overlap_oboe_avoidance` intentionally uses the acronym “OBOE” (Off-By-One Error); it is not a typo and should not be renamed.
Learnt from: pyavitz
Repo: armbian/build PR: 9058
File: patch/u-boot/legacy/u-boot-spacemit-k1/003-SpacemiT-K1X-Fixups.patch:28-67
Timestamp: 2025-12-13T11:38:58.965Z
Learning: In the Armbian build system for SpacemiT U-Boot patches (patch/u-boot/legacy/u-boot-spacemit-k1/), alignment with mainline U-Boot behavior is prioritized. For example, in boot mode handling, leaving devnum unchanged in the default case (when devtype is cleared) follows mainline conventions rather than explicitly clearing it to handle edge cases.
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.
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: 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: 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.
|
I don't know why I'm getting notifications off of this AI drivel, but can you just fuck off? |
I mentioned you (#9069 (comment)) to please take a look at the finding if it makes any sense as you are listed as maintainer for HC4: https://www.armbian.com/odroid-hc4/ |
|
Yeah, no. I do not wish to be associated with AI drivel, or any project that uses such things. Shame on you. Please remove me from this project. |
4 participants
Description
copy patches
fix those who won't apply
whatever I forgot to mention
How Has This Been Tested?
Checklist:
Summary by CodeRabbit
Release Notes: meson64-6.19
New Features
Bug Fixes
Chores
✏️ Tip: You can customize this high-level summary in your review settings.