meson64: introduce bleedingedge BRANCH with 7.1-rc2#9761
Conversation
Well, not 100% upstreamed, the upstream timeout was set to 140 while the patch set it to 200. I guess it's fine though.
of_gpio.h was removed upstream
EvilOlaf
requested review from
a team,
NicoD-SBC,
SteeManMI,
Tonymac32,
adeepn,
igorpecovnik,
pyavitz,
rpardini and
teknoid
as code owners
📝 WalkthroughWalkthroughAdds a meson64-7.1 delivery: introduces BRANCH=bleedingedge kernel gating, a patching config, many device-tree board patches and ~50 overlays, MMC phase DT binding, Meson GX PM and Meson64 reboot drivers, HEVC/VP9 vdec work and MMU/FBC changes, multiple driver fixes, and DT/overlay build wiring. Meson64 7.1 Consolidated Delivery
🎯 5 (Critical) | ⏱️ ~120 minutes
✨ Finishing Touches🧪 Generate unit tests (beta)
|
github-actions
Bot
added
05
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Note
Due to the large number of review comments, Critical severity comments were prioritized as inline comments.
🟠 Major comments (19)
patch/kernel/archive/meson64-7.1/overlay/meson-fixup.scr-cmd-1-4 (1)
1-4:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift
meson-fixup.scr-cmdis currently a no-op despite claiming functional fixups.Lines 1-3 state this script implements overlay argument handling, but there are no executable commands. If this is wired into boot overlay processing, fixups won’t actually occur.
Suggested direction
-# overlays fixup script -# implements (or rather substitutes) overlay arguments functionality -# using u-boot scripting, environment variables and "fdt" command +# overlays fixup script (WIP placeholder) +# NOTE: no fixup logic yet; do not wire this into active overlay flow +# until argument parsing + fdt mutation commands are implemented.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/overlay/meson-fixup.scr-cmd` around lines 1 - 4, The meson-fixup.scr-cmd script is currently only comments and performs no overlay argument handling; implement u-boot script logic in meson-fixup.scr-cmd to read overlay-related environment variables (e.g., OVERLAY, OVERLAY_COUNT), iterate over them, and apply each overlay using the fdt command (or fdt apply/overlay sequence) while logging errors via echo; specifically add a handler function that checks for existence of OVERLAY*, loads or reads overlay blobs (from mmc/ramfs/boot) into a known address, calls fdt apply (or fdt addr + fdt apply) with that address, and updates/returns failure status so boot processing can react. Ensure referenced symbols are the script name meson-fixup.scr-cmd, the environment variables OVERLAY/OVERLAY_COUNT (or similar names used elsewhere), and the fdt command so maintainers can locate and wire the logic into boot flow.patch/kernel/archive/meson64-7.1/overlay/meson-g12b-bananapi-cm4-pwm-gpioh-5-fan.dtso-23-26 (1)
23-26:⚠️ Potential issue | 🟠 Major | ⚡ Quick win
polling-delayis outside__overlay__and will not be applied to&cpu_thermal.Properties within a
fragment@nnode are only applied to the target when they appear inside__overlay__. Thepolling-delay = <2000>at line 25 is at thefragment@1level, not inside__overlay__, so the DT overlay framework silently ignores it — thecpu_thermalpolling delay remains at its default value.🐛 Proposed fix
fragment@1 { target = <&cpu_thermal>; - polling-delay = <2000>; __overlay__ { + polling-delay = <2000>; trips {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/overlay/meson-g12b-bananapi-cm4-pwm-gpioh-5-fan.dtso` around lines 23 - 26, The polling-delay property is declared at the fragment@1 level so it isn't applied to &cpu_thermal; move the polling-delay = <2000> into the fragment@1::__overlay__ block (as a direct child of the overlay node targeting &cpu_thermal or under the cpu_thermal node you modify) so that the property is applied to the target. Update the fragment@1 section that contains target = <&cpu_thermal> and __overlay__ to include polling-delay inside the __overlay__ node alongside whatever node you are patching.patch/kernel/archive/meson64-7.1/board-radxa-zero-dts-slow-down-sdio-for-working-wifi.patch-21-24 (1)
21-24:⚠️ Potential issue | 🟠 Major | ⚡ Quick winReplace
cap-mmc-highspeedwith proper SDIO speed limiting viamax-frequency.At line 23, the patch replaces
sd-uhs-sdr50(SD UHS mode flag) withcap-mmc-highspeed(MMC capability flag). This is incorrect for an SDIO node:cap-mmc-highspeedsignals MMC high-speed timing support and does not limit SDIO speed. To properly slow SDIO for WiFi stability, remove the MMC capability and instead reducemax-frequency(e.g., from 100MHz to 50MHz), which is the standard method for SDIO speed capping per Linux devicetree MMC bindings.Suggested patch adjustment
bus-width = <4>; cap-sd-highspeed; - sd-uhs-sdr50; - cap-mmc-highspeed; + max-frequency = <50000000>; - max-frequency = <100000000>;🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/board-radxa-zero-dts-slow-down-sdio-for-working-wifi.patch` around lines 21 - 24, The patch incorrectly replaces the SD UHS flag with an MMC capability—remove the added cap-mmc-highspeed and instead limit SDIO speed via max-frequency on the SDIO node; specifically, revert removal of sd-uhs-sdr50 (or simply drop cap-mmc-highspeed) and set max-frequency to a lower value (e.g., 50000000) in the same node (referencing cap-sd-highspeed, sd-uhs-sdr50/cap-mmc-highspeed, and max-frequency) so the device tree uses frequency capping rather than signaling MMC high-speed capability.patch/kernel/archive/meson64-7.1/general-meson-mmc-3-arm64-dts-docs-Update-mmc-meson-gx-documentation-for.patch-30-38 (1)
30-38:⚠️ Potential issue | 🟠 Major | ⚡ Quick winKeep the binding property name aligned with the rest of the series.
Lines 30-38 and Line 47 document
amlogic,mmc-phases, but the driver patch and both DTS patches in this series useamlogic,mmc-phase. With the plural spelling here, the schema/example describe a property the driver never reads.Also applies to: 47-47
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/general-meson-mmc-3-arm64-dts-docs-Update-mmc-meson-gx-documentation-for.patch` around lines 30 - 38, The binding docs use the plural property name amlogic,mmc-phases but the driver and DTS use amlogic,mmc-phase; change the documented property name to amlogic,mmc-phase (everywhere this patch adds it, including the later occurrence) so it matches the driver and DTS, keeping the same integer array description (3-element core/tx/rx phases), value meanings (0..3) and default <CLK_PHASE_180 CLK_PHASE_0 CLK_PHASE_0>; ensure the example/schema keys and any references are updated to amlogic,mmc-phase.patch/kernel/archive/meson64-7.1/dt/meson-axg-amper-gateway-gz80x.dtsi-65-69 (1)
65-69:⚠️ Potential issue | 🟠 Major | ⚡ Quick winComplete the
reserved-memory/CMA declaration before using it.This
reserved-memoryblock is missing the standard container properties (#address-cells,#size-cells,ranges), and thelinux,cmachild lacks required Device Tree binding properties. The region will not validate or be recognized as the intended default CMA area.Suggested shape
reserved-memory { + `#address-cells` = <2>; + `#size-cells` = <2>; + ranges; + linux,cma { + compatible = "shared-dma-pool"; + reusable; size = <0x0 0x400000>; + linux,cma-default; }; };🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/dt/meson-axg-amper-gateway-gz80x.dtsi` around lines 65 - 69, The reserved-memory node must include container properties and the linux,cma child must follow the CMA binding: add "#address-cells = <1>;", "#size-cells = <1>;" and "ranges;" to the reserved-memory node, and replace the current linux,cma child with a proper memory region node (e.g., memory@0) that contains "reg = <0x0 0x400000>;", "compatible = \"shared-dma-pool\";" (and add "no-map;" if desired), keeping the phandle/name linux,cma so the kernel recognizes it as the default CMA area.lib/functions/compilation/patch/drivers_network.sh-97-97 (1)
97-97:⚠️ Potential issue | 🟠 Major | ⚡ Quick winScope the RTL8189FS disablement to the actual broken kernel range.
This hook is shared across families, but the new guard keys off
BRANCH=bleedingedgeonly. That will also drop RTL8189FS on unrelated bleedingedge families, even when they are not on the kernel/API combination that broke meson64. Please gate this on the real incompatibility (version, andLINUXFAMILYif needed) instead of the branch name.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@lib/functions/compilation/patch/drivers_network.sh` at line 97, The RTL8189FS disablement currently gates on BRANCH=bleedingedge which incorrectly affects unrelated families; update the condition in drivers_network.sh so the guard uses the actual kernel-version check (the linux-version compare function with "${version}") and optionally LINUXFAMILY to target only the kernel/API range known to break meson64, instead of checking BRANCH. Replace the BRANCH test with an explicit version range check (and add a LINUXFAMILY equals check if the bug is limited to a family) around the RTL8189FS removal code so it runs only for the broken kernel versions (use the existing linux-version compare calls and "${version}", and leave BRANCH out).patch/kernel/archive/meson64-7.1/general-driver-tm1628-auxdisplay-add-support-for-Titanmec-TM16.patch-91-118 (1)
91-118:⚠️ Potential issue | 🟠 Major | ⚡ Quick winMake the TM1628 schema and parser agree on the property names.
The schema added here defines
grid/segment-mapping, but the driver later readstitanmec,grid/titanmec,segment-mapping, and the new DTS in this PR uses the vendor-prefixed form. As written, schema-correct DTs will not probe, and driver-correct DTs will fail validation. Also,$idpoints to/schemas/leds/...even though this file lives underauxdisplay. Please align the schema, driver, and DTS on one naming/path convention.Also applies to: 506-524
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/general-driver-tm1628-auxdisplay-add-support-for-Titanmec-TM16.patch` around lines 91 - 118, The schema's property names and $id path must match what the driver and DTS use: rename the schema properties from "grid" and "segment-mapping" to the vendor-prefixed names "titanmec,grid" and "titanmec,segment-mapping" (or change the driver/DTS to use the unprefixed names) and update the $id to the correct auxdisplay path instead of /schemas/leds/; ensure the compatible enum remains "titanmec,tm1628" so the tm1628 driver (probe code that looks up "titanmec,grid"/"titanmec,segment-mapping") and the DTS pass schema validation consistently.patch/kernel/archive/meson64-7.1/dt/meson-sm1-ugoos-x3.dts-13-15 (1)
13-15:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd a board-specific
compatiblestring before the SoC fallback.With only
"amlogic,sm1", this DTS is indistinguishable from every other SM1 board for DT matching, overlay targeting, and board-specific quirks. Similar boards in this repository (e.g.,meson-sm1-jethome-jethub-j200.dts) correctly place a board-specific compatible first:compatible = "jethome,jethub-j200", "amlogic,sm1";. Update this file to follow the same pattern, e.g.,compatible = "ugoos,x3", "amlogic,sm1";.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/dt/meson-sm1-ugoos-x3.dts` around lines 13 - 15, The root node's compatible property currently only lists the SoC fallback ("amlogic,sm1"); update the compatible property in the top-level node (the / node where model = "Ugoos X3") to put a board-specific string first, e.g., change it to include "ugoos,x3" as the primary compatible and keep "amlogic,sm1" as the second entry so DT matching and board-specific overlays/quirks target this board correctly.patch/kernel/archive/meson64-7.1/overlay/meson-i2cB.dtso-1-3 (1)
1-3:⚠️ Potential issue | 🟠 Major | ⚡ Quick winMissing
/plugin/;— file will not be treated as a DT overlay pluginEvery other
.dtsoin this PR has both/dts-v1/;and/plugin/;. Without the/plugin/;declaration,dtcwill not compile this as an overlay plugin; thefragment@*/__overlay__structure won't produce valid overlay metadata and the overlay cannot be applied at runtime.🐛 Proposed fix
/dts-v1/; +/plugin/; / {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/overlay/meson-i2cB.dtso` around lines 1 - 3, The file starts with "/dts-v1/;" but is missing the required "/plugin/;" directive so the DT compiler won't treat it as an overlay plugin; add a line containing "/plugin/;" immediately after the existing "/dts-v1/;" declaration (keeping the same top-of-file ordering) so that the fragment@* and __overlay__ sections produce valid overlay metadata and compile as an overlay plugin.patch/kernel/archive/meson64-7.1/overlay/meson-i2cB.dtso-5-10 (1)
5-10:⚠️ Potential issue | 🟠 Major | ⚡ Quick winWrong alias name:
i2cAshould bei2cB
meson-i2cA.dtsoalready mapsi2cA→i2c@8500. This file (meson-i2cB.dtso) mapsi2cA→i2c@87c0, a different address — meaning applying both overlays creates a conflicting double-definition ofi2cAandi2cBis never registered. The alias must match the file's intended bus.🐛 Proposed fix
__overlay__ { - i2cA = "/soc/bus@c1100000/i2c@87c0"; + i2cB = "/soc/bus@c1100000/i2c@87c0"; };🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/overlay/meson-i2cB.dtso` around lines 5 - 10, The alias in fragment@0 under __overlay__ currently sets i2cA = "/soc/bus@c1100000/i2c@87c0" but this overlay is for meson-i2cB and conflicts with meson-i2cA; update the alias name from i2cA to i2cB so the line reads i2cB = "/soc/bus@c1100000/i2c@87c0", preserving the fragment@0, target-path = "/aliases", and __overlay__ structure.patch/kernel/archive/meson64-7.1/overlay/meson-i2cA.dtso-1-3 (1)
1-3:⚠️ Potential issue | 🟠 Major | ⚡ Quick winMissing
/plugin/;— same issue asmeson-i2cB.dtsoWithout
/plugin/;, this file is not a valid DT overlay plugin and will not compile or apply correctly. All other.dtsofiles in this PR declare both/dts-v1/;and/plugin/;.🐛 Proposed fix
/dts-v1/; +/plugin/; / {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/overlay/meson-i2cA.dtso` around lines 1 - 3, The DT overlay meson-i2cA.dtso is missing the required /plugin/ declaration so it won't be a valid overlay; add the line "/plugin/;" immediately after the existing "/dts-v1/;" header (matching the header used in meson-i2cB.dtso) so the file is recognized and compiles as a plugin.patch/kernel/archive/meson64-7.1/overlay/meson-sm1-bananapi-uartA_cts_rts.dtso-11-14 (1)
11-14:⚠️ Potential issue | 🟠 Major | ⚡ Quick win
pinctrl-0is missinguart_a_pins, breaking basic UART TX/RX; also missinguart-has-rtsctsTwo issues in the
__overlay__:
Missing
uart_a_pins: The SM1uart_Anode requires both&uart_a_pins(TX/RX) and&uart_a_cts_rts_pins(flow-control) in a singlepinctrl-0list. As shown inmeson-sm1-ugoos-x3.dtslines 165–177, the correct configuration is:pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;This overlay sets only
uart_a_cts_rts_pins. When applied on top of the base DTS (or alongsidemeson-sm1-bananapi-uartA.dtsowhich setsuart_a_pins), the DT overlay merge will replacepinctrl-0entirely, leaving only the CTS/RTS pins and making TX/RX non-functional.Missing
uart-has-rtscts: Even with the pins muxed, the UART driver will not enable hardware flow control unlessuart-has-rtscts;is present (perDocumentation/devicetree/bindings/serial/serial.yaml). The referencemeson-sm1-ugoos-x3.dtsincludes this property together withuart_a_cts_rts_pins.🐛 Proposed fix
__overlay__ { status = "okay"; pinctrl-names = "default"; - pinctrl-0 = <&uart_a_cts_rts_pins>; + pinctrl-0 = <&uart_a_pins &uart_a_cts_rts_pins>; + uart-has-rtscts; };Based on learnings, DT node properties should be verified against the official kernel device tree binding documentation and compared with authoritative reference DTS files rather than relying solely on patterns in new files.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/overlay/meson-sm1-bananapi-uartA_cts_rts.dtso` around lines 11 - 14, The overlay's uart_A node only sets pinctrl-0 = <&uart_a_cts_rts_pins> causing TX/RX pins to be dropped and also omits uart-has-rtscts; fix by changing the uart_A node so pinctrl-0 contains both &uart_a_pins and &uart_a_cts_rts_pins (pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;), and add the uart-has-rtscts; boolean property to the same node (refer to the uart_a node, pinctrl-0, uart_a_pins, uart_a_cts_rts_pins, and uart-has-rtscts symbols when editing).patch/kernel/archive/meson64-7.1/overlay/meson-g12-pwm-gpiox-5-fan.dtso-24-26 (1)
24-26:⚠️ Potential issue | 🟠 Major | ⚡ Quick win
polling-delayis attached to the fragment, not tocpu_thermal
polling-delayon Line 25 should be inside__overlay__; otherwise it likely won’t be applied to&cpu_thermal.Suggested fix
fragment@1 { target = <&cpu_thermal>; - polling-delay = <2000>; __overlay__ { + polling-delay = <2000>; trips {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/overlay/meson-g12-pwm-gpiox-5-fan.dtso` around lines 24 - 26, The polling-delay property is currently placed outside the fragment overlay and therefore won't be applied to the &cpu_thermal node; move the polling-delay = <2000> entry inside the __overlay__ block so it becomes a child of the &cpu_thermal overlay. Locate the fragment that references &cpu_thermal (symbols: __overlay__, &cpu_thermal, polling-delay) and place the polling-delay property within the __overlay__ node alongside the target = <&cpu_thermal> and any other overlayed properties.patch/kernel/archive/meson64-7.1/board-odroid-sm1-reset.patch-22-30 (1)
22-30:⚠️ Potential issue | 🟠 Major | ⚡ Quick winDT node requires a driver patch that is currently disabled
The new
meson64,rebootnode on line 23 references themeson64,rebootcompatible string, which is only defined indriver-power-meson64-reset.patch.disabled. Since that driver patch is disabled and not being applied, this reset/poweroff wiring will not be functional at runtime.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/board-odroid-sm1-reset.patch` around lines 22 - 30, The device tree adds a reboot node named meson64-reboot with compatible = "meson64,reboot" but the corresponding driver is in driver-power-meson64-reset.patch.disabled and therefore not applied; to fix, either enable/apply the driver patch (rename/activate driver-power-meson64-reset.patch.disabled so the meson64 reset driver is built) or change the DT node to use a compatible string handled by an enabled driver on this board, and ensure the node fields (sys_reset, sys_poweroff, sd-vqen, sd-vqsw, sd-vmmc) match the driver’s expected bindings; specifically update the meson64-reboot node or enable driver-power-meson64-reset so the meson64,reboot compatible is supported at runtime.patch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-spi-spidev.dtso-14-19 (1)
14-19:⚠️ Potential issue | 🟠 Major | ⚡ Quick win
spidev@0nodes arestatus = "disabled"— overlay produces no/dev/spidev*devices.Both
spidev@0entries (infragment@0andfragment@1) are explicitly disabled. A user who enables this overlay inarmbianEnv.txtexpecting SPI userspace access will find no spidev devices at all, because thestatus = "disabled"property prevents the driver from probing.Compare with
meson-g12b-odroid-n2-plus-spidev.dts, wherespidev@0carries nostatus(defaults tookay). If the intent is to expose both SPI controllers as spidev, the nodes should beokay(or omit the property). If only one should be active at a time, consider separate overlay files per controller.🐛 Proposed fix
spidev@0 { compatible = "armbian,spi-dev"; - status = "disabled"; + status = "okay"; reg = <0>; spi-max-frequency = <10000000>; };Apply the same change to the
spidev@0node insidefragment@1.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-spi-spidev.dtso` around lines 14 - 19, The spidev@0 nodes in both fragment@0 and fragment@1 are marked status = "disabled", so enabling the overlay won't create /dev/spidev*; edit the meson-g12a-radxa-zero-spi-spidev.dtso overlay to either remove the status property or set status = "okay" for the spidev@0 node in fragment@1 (to match fragment@0 or the meson-g12b example), or alternatively split into separate overlays if only one SPI controller should be exposed at a time.patch/kernel/archive/meson64-7.1/driver-power-meson64-reset.patch.disabled-178-198 (1)
178-198:⚠️ Potential issue | 🟠 Major | ⚡ Quick winThe DT-configured PSCI hooks are parsed but never used.
sys_poweroffis stored inpsci_function_id_poweroff, but Line 182 still hardcodes0x82000042;sys_resetis assigned on Line 191 and then never read anywhere in this file. That makes the new DT contract misleading even after the GPIO API port.💡 Minimal direction for the poweroff path
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); }For symmetry, either consume
psci_function_id_restartin the restart path as well or dropsys_resetfrom the DT contract.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/driver-power-meson64-reset.patch.disabled` around lines 178 - 198, The DT properties are read into psci_function_id_poweroff and psci_function_id_restart but never used; update do_meson64_poweroff() to call __invoke_psci_fn_smc(psci_function_id_poweroff, 1, 0, 0) instead of the hardcoded 0x82000042 and ensure the restart path consumes psci_function_id_restart (have meson64_restart_handler invoke __invoke_psci_fn_smc(psci_function_id_restart, ...)) or, if you prefer not to support DT restart, remove the sys_reset handling from meson64_restart_probe and the psci_function_id_restart symbol to keep the DT contract consistent.patch/kernel/archive/meson64-7.1/driver-power-meson64-reset.patch.disabled-83-85 (1)
83-85:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftThe
meson64,rebootDT nodes remain orphaned while the driver patch stays disabled.Multiple board patches and DT files in this series define
compatible = "meson64,reboot"nodes, but the only driver implementation (driver-power-meson64-reset.patch.disabled) remains disabled. The patch depends on deprecated<linux/of_gpio.h>andof_get_named_gpio()API (lines 83-84, 202-209), which the PR already identifies as removed upstream. Until this driver is ported to the 7.1 kernel GPIO API, these nodes will not bind.Affected DT node locations
board-odroid-sm1-reset.patch:23board-bananapi-m2s.patch:37board-bananapi-cm4-cm4io.patch:54dt/meson-sm1-jethome-jethub-j200.dts:222🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/driver-power-meson64-reset.patch.disabled` around lines 83 - 85, The patch is disabled and still uses the removed of_gpio/of_get_named_gpio API, leaving meson64,reboot DT nodes unbound; update driver-power-meson64-reset.patch.disabled to use the modern gpiod consumer API (replace `#include` <linux/of_gpio.h> and `#include` <linux/gpio.h> with `#include` <linux/gpio/consumer.h> and use devm_gpiod_get_optional()/devm_gpiod_get(), or of_get_named_gpiod_flags()/devm_fwnode_gpiod_get_index as appropriate) wherever of_get_named_gpio() is called (the code around the existing of_get_named_gpio() usage at lines ~202-209), convert any numeric GPIO handling to gpiod_get/set/descriptor usage, adjust error handling accordingly, and then re-enable the driver patch so the meson64,reboot DT nodes can bind.patch/kernel/archive/meson64-7.1/dt/meson-g12b-a311d-cainiao-cniot-core.dts-36-42 (1)
36-42:⚠️ Potential issue | 🟠 Major | ⚡ Quick win
tach-gpiodoes not match thepwm-fanbinding.The official
pwm-fanschema only allows tach feedback viainterrupts(optionally withpulses-per-revolution), and it setsadditionalProperties: false. Thetach-gpioproperty will fail schema validation and won't be consumed by the driver. Use an interrupt-backed tach description here or drop the property.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/dt/meson-g12b-a311d-cainiao-cniot-core.dts` around lines 36 - 42, The device node fan0 uses the non-conformant property tach-gpio which doesn't match the pwm-fan binding; replace tach-gpio with an interrupt-backed tach description or remove it: update the fan0 node (pwm-fan compatible) to either remove the tach-gpio line entirely or add an interrupts entry plus optional pulses-per-revolution per the pwm-fan binding (use the same GPIO as an interrupt source) so schema validation succeeds and the driver can consume the tach information.patch/kernel/archive/meson64-7.1/dt/meson-sm1-jethome-jethub-j200.dts-221-229 (1)
221-229:⚠️ Potential issue | 🟠 Major | ⚡ Quick win
meson64-reboot:sd-vqenreferences wrong GPIO controller forGPIOE_2Line 226 uses
&gpio GPIOE_2, butGPIOE_2belongs to the AO GPIO bank — confirmed bymeson-g12a-gpio.hwhereGPIOE_0/GPIOE_1/GPIOE_2are enumerated as indices 12–14 of the first (AO) GPIO chip. The correct controller is&gpio_ao, exactly as used for the identical pin in thetf_ioregulator at line 66.This is the same class of bug that was patched for
meson-sm1-bananapi-m5upstream:GPIOE_2 is in AO domain and "<&gpio GPIOE_2 ...>"incorrectly changes the state of a power-enable pin on SM1 boards. Whendriver-power-meson64-reset.patchis re-enabled, the driver will either fail to acquire the GPIO or silently toggle the wrong pin.🐛 Proposed fix
- sd-vqen = <&gpio GPIOE_2 GPIO_ACTIVE_HIGH>; + sd-vqen = <&gpio_ao GPIOE_2 GPIO_ACTIVE_HIGH>;🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/dt/meson-sm1-jethome-jethub-j200.dts` around lines 221 - 229, The meson64-reboot node's sd-vqen property is referencing the wrong GPIO controller (&gpio) for GPIOE_2; change sd-vqen to use the AO controller (&gpio_ao) so it matches how GPIOE_2 is used elsewhere (e.g., the tf_io regulator) and the meson GPIO enumeration, ensuring the reset/power driver can acquire and toggle the correct AO pin (reference: meson64-reboot, sd-vqen, GPIOE_2, &gpio_ao).
🟡 Minor comments (15)
patch/kernel/archive/meson64-7.1/board-t95z-add-rc-remote-keymap.patch-25-32 (1)
25-32:⚠️ Potential issue | 🟡 Minor | ⚡ Quick win
rc-sunvell-t95z-plusinserted out of alphabetical order.In all three affected files (
rc.yaml, theMakefile, andrc-map.h) the new entry is placed beforerc-su3000, but alphabeticallysunvellsorts aftersu3000(since'n'>'3'in ASCII). The consistent convention in these files is strict alphabetical ordering.This doesn't affect build or runtime behaviour, but
dt-validateschema checks onrc.yamlmay flag unsorted enum values depending on schema tooling version.Also applies to: 50-57, 143-150
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/board-t95z-add-rc-remote-keymap.patch` around lines 25 - 32, The new enum entry rc-sunvell-t95z-plus was inserted in the wrong alphabetical spot; move every occurrence of "rc-sunvell-t95z-plus" in the affected lists (the rc.yaml enum, the Makefile list, and rc-map.h mapping array) so it appears after "rc-su3000" (i.e., in strict ASCII alphabetical order), repeat the same fix for the other similar blocks mentioned (lines around 50–57 and 143–150), ensure each list remains sorted after the change, and re-run the validation (dt-validate/build) to confirm ordering is accepted.patch/kernel/archive/meson64-7.1/board-t95z-add-rc-remote-keymap.patch-64-139 (1)
64-139:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winMissing
MODULE_DESCRIPTION()and unclosed>in copyright.Two minor nits in
rc-sunvell-t95z-plus.c:
- The copyright header on line 66 is missing the closing
>:<christianshewitt@gmail.com→<christianshewitt@gmail.com>.- The module is missing
MODULE_DESCRIPTION(), which is expected kernel style alongsideMODULE_LICENSEandMODULE_AUTHOR.🛠️ Proposed fix
-/* - * Copyright (c) 2023 Christian Hewitt <christianshewitt@gmail.com - */ +/* + * Copyright (c) 2023 Christian Hewitt <christianshewitt@gmail.com> + */MODULE_LICENSE("GPL"); MODULE_AUTHOR("Christian Hewitt <christianshewitt@gmail.com>"); +MODULE_DESCRIPTION("Keymap for the Sunvell T95Z Plus remote control");🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/board-t95z-add-rc-remote-keymap.patch` around lines 64 - 139, Fix two minor issues in the module header: close the missing '>' in the copyright line for the author email (change "<christianshewitt@gmail.com" to "<christianshewitt@gmail.com>") and add a MODULE_DESCRIPTION() entry (e.g. MODULE_DESCRIPTION("Sunvell T95Z Plus RC keymap")) alongside MODULE_LICENSE("GPL") and MODULE_AUTHOR(...) in the rc_map source (refer to symbols sunvell_t95z_plus_map, init_rc_map_sunvell_t95z_plus, and MODULE_LICENSE/MODULE_AUTHOR).patch/kernel/archive/meson64-7.1/meson-g12a-pinctrl-add-missing-ir-options.patch-38-44 (1)
38-44:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winAdd
remote_ao_outgroup and function to the AO pinctrl domain in the C driver.The DTS adds
remote_out_ao_pinsin the AO domain (lines 1545-1553) referencinggroups = "remote_ao_out"andfunction = "remote_ao_out", but the C driver patch only addsremote_inputto the periphs domain groups and functions. The correspondingremote_ao_outgroup and function must be added to the AO controller's group and function tables (likelymeson_g12a_aobus_groupsandmeson_g12a_aobus_functions), or the DTS node will fail to bind at runtime.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/meson-g12a-pinctrl-add-missing-ir-options.patch` around lines 38 - 44, The AO pinctrl domain is missing the "remote_ao_out" group and function used by the DTS; update the AO controller group and function tables by adding a new group named "remote_ao_out" (map it to the AO pin(s) used by remote_out_ao_pins, matching the pin identifiers used elsewhere) into meson_g12a_aobus_groups and add a corresponding function entry "remote_ao_out" in meson_g12a_aobus_functions that lists that group; also update any related group/function count arrays or enums so the new entries are included at build/runtime.patch/kernel/archive/meson64-7.1/board-radxa-zero2-arm64-dts-amlogic-Enable-the-npu-node-for-Radxa-Zero2.patch-17-23 (1)
17-23:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winRedundant duplicate
&npuenablement — verify against upstream 7.1 baseThe diff context (lines 17–19) shows an existing
&npu { status = "okay"; }block already at line 419 ofmeson-g12b-radxa-zero2.dts, and the patch unconditionally appends an identical second block. DTC silently merges multiple node references, so it compiles without error, but the second stanza is fully redundant.This pattern strongly suggests the NPU node was already enabled in the upstream 7.1 base DTS (perhaps upstreamed after the 7.0 patch was written). Please verify whether
meson-g12b-radxa-zero2.dtsin Linux 7.1-rc1 already has&npu { status = "okay"; }. If so, this patch should be dropped entirely rather than carried forward.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/board-radxa-zero2-arm64-dts-amlogic-Enable-the-npu-node-for-Radxa-Zero2.patch` around lines 17 - 23, The patch adds a duplicate &npu { status = "okay"; } stanza; verify whether the meson-g12b-radxa-zero2.dts in Linux 7.1 already contains an enabled &npu node and if so remove the added duplicate from the patch (drop the newly appended &npu stanza entirely); if upstream does not have it, keep a single &npu { status = "okay"; } entry and ensure only one such node reference exists in the patch to avoid redundancy.patch/kernel/archive/meson64-7.1/dt/meson-sm1-khadas-vim3l-spidev.dts-8-8 (1)
8-8:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winModel string lists both SDA and SCL as pin 23 — likely a copy-paste error.
"SDA pin 23, SCL pin 23"repeats the same pin number for both I2C signals. Since this overlay enables&i2c3withi2c3_sck_a_pins(GPIOA_14) andi2c3_sda_a_pins(GPIOA_15), one of the two pin numbers is wrong. Please verify the correct GPIO header pin numbers for both signals on the VIM3L and update the model string accordingly.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/dt/meson-sm1-khadas-vim3l-spidev.dts` at line 8, The model string incorrectly lists both I2C signals as "SDA pin 23, SCL pin 23"; verify the correct header pin numbers for SDA and SCL and update the model string accordingly so it matches the enabled &i2c3 block (i2c3_sck_a_pins and i2c3_sda_a_pins). Locate the model = "..." line in meson-sm1-khadas-vim3l-spidev.dts and replace the duplicated pin with the correct pin number for SCL/SDA after confirming the mapping for i2c3_sck_a_pins (GPIOA_14) and i2c3_sda_a_pins (GPIOA_15).patch/kernel/archive/meson64-7.1/board-odroidhc4-enable-fan1_input.patch-23-23 (1)
23-23:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix tach property name: use
pulses-per-revolution(singular).The patch uses
pulses-per-revolutions(plural), which is not a validpwm-fanbinding key and will not be interpreted. The official Linux binding expectspulses-per-revolution(singular).Proposed fix
- pulses-per-revolutions = <2>; + pulses-per-revolution = <2>;🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/board-odroidhc4-enable-fan1_input.patch` at line 23, The added device-tree property name is incorrect: replace the invalid key pulses-per-revolutions with the singular pulses-per-revolution in the patch (the line you added in board-odroidhc4-enable-fan1_input.patch that sets pulses-per-revolutions = <2>); update that property name so the pwm-fan binding recognizes the tachometer pulse count.patch/kernel/archive/meson64-7.1/jethome-0001-Fix-meson64-add-gpio-irq-patch-from-https-lkml.org-l.patch-52-52 (1)
52-52:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winReplace unconditional
printk()with device-scoped debug logging.This line can create noisy kernel logs during GPIO→IRQ mapping; prefer
dev_dbg()instead. The function already usesdev_warn()anddev_err()for error conditions, so this should follow the same device-scoped logging pattern.Proposed fix
- printk("gpio irq setup: hwirq: 0x%X irqfirst: 0x%X irqlast: 0x%X pin[%d]\n", hwirq, bank->irq_first, bank->irq_last, gpio); + 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);🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/jethome-0001-Fix-meson64-add-gpio-irq-patch-from-https-lkml.org-l.patch` at line 52, Replace the unconditional printk with device-scoped debug logging by calling dev_dbg(&bank->dev, ...) instead of printk; change the line that prints "gpio irq setup: hwirq: 0x%X irqfirst: 0x%X irqlast: 0x%X pin[%d]\n" to use dev_dbg(&bank->dev, "gpio irq setup: hwirq: 0x%X irqfirst: 0x%X irqlast: 0x%X pin[%d]\n", hwirq, bank->irq_first, bank->irq_last, gpio) so it follows the existing dev_warn()/dev_err() pattern and scopes noise to the device.patch/kernel/archive/meson64-7.1/general-driver-tm1628-auxdisplay-add-support-for-Titanmec-TM16.patch-75-81 (1)
75-81:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winDocument the sysfs filename that the driver actually creates.
The ABI doc says
display-text, butDEVICE_ATTR_RW(display_text)exposesdisplay_text. One of these needs to change or the documented interface will be wrong from day one.Also applies to: 406-432
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/general-driver-tm1628-auxdisplay-add-support-for-Titanmec-TM16.patch` around lines 75 - 81, The sysfs name in the ABI doc ("display-text") doesn't match the attribute exported by the driver (DEVICE_ATTR_RW(display_text)), so update either the driver or the documentation to match; specifically either change the driver to export DEVICE_ATTR_RW(display-text) (or create a device attribute named "display-text") or change the documentation lines that mention "display-text" to "display_text" (also apply the same change for the other occurrences around the 406-432 region), ensuring the symbol DEVICE_ATTR_RW(display_text) and the documented name are identical.patch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-uart-ee-c.dtso-9-13 (1)
9-13:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winMissing
uart-has-rtsctsproperty
uart_c_cts_rts_pinscorrectly pins the CTS/RTS lines, but withoutuart-has-rtscts;the UART driver won't enable hardware flow control (Documentation/devicetree/bindings/serial/serial.yaml). If hardware flow control is intentional here, add the property.🐛 Proposed fix
__overlay__ { status = "okay"; pinctrl-0 = <&uart_c_pins &uart_c_cts_rts_pins>; pinctrl-names = "default"; + uart-has-rtscts; };Based on learnings, DT node properties should be verified against the official kernel device tree binding documentation.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-uart-ee-c.dtso` around lines 9 - 13, The overlay enables UART C pins but omits the uart-has-rtscts property, so the kernel driver won't enable hardware RTS/CTS flow control; update the __overlay__ node that sets pinctrl-0 with &uart_c_pins &uart_c_cts_rts_pins to include the boolean property uart-has-rtscts; (i.e., add uart-has-rtscts; inside the same node) so the UART driver recognizes and enables hardware flow control.patch/kernel/archive/meson64-7.1/overlay/README.meson-overlays-78-80 (1)
78-80:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFan overlay description is technically inaccurate
On Line 79, this says “PWM-controlled fan,” but the overlay uses
gpio-fan(GPIO state/speed-map control). Please reword to avoid confusion.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/overlay/README.meson-overlays` around lines 78 - 80, The description for meson-g12-pwm-gpiox-5-fan is misleading: update the overlay blurb to state it uses the gpio-fan driver with GPIO state/speed-map control (not PWM), and keep the thermal control and target SoCs (A311D/G12A/G12B/SM1); e.g., replace “PWM-controlled fan” wording with “GPIO-controlled fan via gpio-fan with state/speed-map control” so the overlay name meson-g12-pwm-gpiox-5-fan and its behavior are correctly reflected.patch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-uart-ao-b-on-gpioao-8-gpioao-9.dtso-7-14 (1)
7-14:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winGPIOAO_8 conflict with the GPIO LED overlay — see note on
meson-g12a-radxa-zero-gpio-8-led.dtso.
uart_ao_b_8_9_pinsrequests GPIOAO_8 and GPIOAO_9 via pinctrl. This overlay is mutually exclusive withmeson-g12a-radxa-zero-gpio-8-led.dtso, which claims GPIOAO_8 as a GPIO LED output. Consider documenting this in the README to prevent simultaneous use.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-uart-ao-b-on-gpioao-8-gpioao-9.dtso` around lines 7 - 14, The uart AO B overlay fragment@0 (target = <&uart_AO_B>) configures pinctrl-0 = <&uart_ao_b_8_9_pins> which requests GPIOAO_8 and GPIOAO_9 and therefore conflicts with the GPIO LED overlay meson-g12a-radxa-zero-gpio-8-led.dtso that claims GPIOAO_8; update the repository README (or overlay documentation) to explicitly document this mutual exclusivity, mention the specific symbols uart_ao_b_8_9_pins, GPIOAO_8, GPIOAO_9 and the two dtso filenames, and add guidance to disable/unload the gpio-8-led overlay when enabling the uart AO B overlay (or vice versa).patch/kernel/archive/meson64-7.1/dt/meson-g12b-a311d-khadas-vim3-spidev.dts-8-8 (1)
8-8:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winModel string lists the same pin number for both SDA and SCL.
"SDA pin 23, SCL pin 23"is a copy-paste error — SDA and SCL cannot share the same physical header pin.i2c3_sda_a_pins(GPIOA_14) andi2c3_sck_a_pins(GPIOA_15) map to different pins on the 40-pin header; themeson-g12b-radxa-zero2-spidev.dtsequivalent in this same PR correctly lists different pins (SDA pin 3, SCL pin 5). Please correct the SCL pin number.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/dt/meson-g12b-a311d-khadas-vim3-spidev.dts` at line 8, The model string in meson-g12b-a311d-khadas-vim3-spidev.dts incorrectly lists SDA and SCL as the same pin; update the model line so it reflects the correct header pins for i2c3 (i2c3_sda_a_pins / GPIOA_14 -> SDA pin 3, and i2c3_sck_a_pins / GPIOA_15 -> SCL pin 5) instead of "SDA pin 23, SCL pin 23", and verify that the model string and any descriptive comments now match the actual pin mapping used by the device tree nodes.patch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-gpio-8-led.dtso-19-21 (1)
19-21:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winGPIOAO_8 is mutually exclusive with
meson-g12a-radxa-zero-uart-ao-b-on-gpioao-8-gpioao-9.dtso.
uart_ao_b_8_9_pinsclaims the same GPIOAO_8 (and GPIOAO_9) via the pinctrl subsystem. If both overlays are loaded simultaneously, the kernel will report a pin/GPIO resource conflict at probe time. Adding a comment (or an entry in the README) calling out the mutual exclusivity would prevent silent user-facing failures.💬 Suggested inline warning
linux,default-trigger = "heartbeat"; default-state = "on"; + /* NOTE: Mutually exclusive with meson-g12a-radxa-zero-uart-ao-b-on-gpioao-8-gpioao-9 overlay */🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-gpio-8-led.dtso` around lines 19 - 21, The overlay uses GPIOAO_8 for the LED (gpios = <&gpio_ao GPIOAO_8 ...>) which conflicts with the pinctrl binding declared by uart_ao_b_8_9_pins in meson-g12a-radxa-zero-uart-ao-b-on-gpioao-8-gpioao-9.dtso; add a clear mutual-exclusion note so users and maintainers know these two overlays must not be loaded together—update the meson-g12a-radxa-zero-gpio-8-led.dtso header comment (or the repository README/overlay index) to explicitly state that GPIOAO_8 (and GPIOAO_9) are shared with meson-g12a-radxa-zero-uart-ao-b-on-gpioao-8-gpioao-9.dtso and that only one of these overlays may be applied at a time.patch/kernel/archive/meson64-7.1/dt/meson-sm1-jethome-jethub-j200.dts-526-532 (1)
526-532:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winWrong vendor prefix on SPI NOR flash:
sst,w25q256should bewinbond,w25q256The W25Q256 is manufactured by Winbond (JEDEC manufacturer ID
0xEF), not SST (0xBF). The kernel'swinbond_nor_parts[]table listsw25q256with SNOR_ID(0xef, 0x40, 0x19), confirming the Winbond attribution. Thejedec,spi-norfallback means probing still works via JEDEC auto-detection, but the vendor-specific compatible is misleading and incorrect.🐛 Proposed fix
- compatible = "sst,w25q256", "jedec,spi-nor"; + compatible = "winbond,w25q256", "jedec,spi-nor";🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/dt/meson-sm1-jethome-jethub-j200.dts` around lines 526 - 532, The device-tree node flash: nor-flash@0 has an incorrect vendor compatible string "sst,w25q256"; replace it with the correct vendor prefix "winbond,w25q256" so the node's compatible becomes "winbond,w25q256", "jedec,spi-nor" (update the compatible property in the flash: nor-flash@0 node).patch/kernel/archive/meson64-7.1/dt/meson-sm1-jethome-jethub-j200.dts-559-564 (1)
559-564:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winStray
clock-frequencyin&uart_B— likely copy-paste from I2C nodes
clock-frequency = <400000>(400 kHz) is the standard I2C bus speed property and appears verbatim in every I2C node in this file. The Meson UART driver obtains its input clock from the clock framework, not from aclock-frequencyDT property, so this line is silently ignored but is misleading.🐛 Proposed fix
&uart_B { status = "okay"; pinctrl-0 = <&uart_b_pins>; pinctrl-names = "default"; - clock-frequency = <400000>; };🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/meson64-7.1/dt/meson-sm1-jethome-jethub-j200.dts` around lines 559 - 564, Remove the stray I2C-style property from the UART node: in the &uart_B node (symbol "&uart_B") delete the "clock-frequency = <400000>;" line since the Meson UART driver uses the clock framework, not a clock-frequency DT property; ensure the remaining properties (status, pinctrl-0, pinctrl-names) are unchanged and the node remains syntactically valid.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 59c9ed60-d7a5-428b-b412-8d8acede8316
📒 Files selected for processing (124)
config/kernel/linux-meson64-bleedingedge.configconfig/sources/families/include/meson64_common.inclib/functions/compilation/patch/drivers_network.shpatch/kernel/archive/meson64-7.1/0000.patching_config.yamlpatch/kernel/archive/meson64-7.1/board-bananapi-cm4-cm4io.patchpatch/kernel/archive/meson64-7.1/board-bananapi-m2s.patchpatch/kernel/archive/meson64-7.1/board-bananapim5-001-sd-use-270-mmc-clock-phase-via-dt.patchpatch/kernel/archive/meson64-7.1/board-bananapim5-002-add-wifi-bt-support.patchpatch/kernel/archive/meson64-7.1/board-bananapism1-add-uart_A-and-AO_B.patchpatch/kernel/archive/meson64-7.1/board-khadas-vim3-add-npu-node.patchpatch/kernel/archive/meson64-7.1/board-khadas-vim3-fix-missing-i2c3-nod.patchpatch/kernel/archive/meson64-7.1/board-khadas-vims-add-rtc-vrtc-aliases.patchpatch/kernel/archive/meson64-7.1/board-nanopi-k2-add-uartC-alias.patchpatch/kernel/archive/meson64-7.1/board-nanopi-k2-enable-emmc.patchpatch/kernel/archive/meson64-7.1/board-odroid-sm1-reset.patchpatch/kernel/archive/meson64-7.1/board-odroidc2-add-uartA-uartC.patchpatch/kernel/archive/meson64-7.1/board-odroidc2-enable-SPI.patchpatch/kernel/archive/meson64-7.1/board-odroidc2-enable-scpi-dvfs.patchpatch/kernel/archive/meson64-7.1/board-odroidc2-usb-hub-disable-autosuspend-for-Genesys-Logic-.patchpatch/kernel/archive/meson64-7.1/board-odroidhc4-enable-fan1_input.patchpatch/kernel/archive/meson64-7.1/board-odroidn2plus-Add-missing-CPU-opp.patchpatch/kernel/archive/meson64-7.1/board-radxa-zero-dts-add-aliases-for-serial-i2c-and-spi.patchpatch/kernel/archive/meson64-7.1/board-radxa-zero-dts-add-support-for-the-usb-c-controller.patchpatch/kernel/archive/meson64-7.1/board-radxa-zero-dts-slow-down-sdio-for-working-emmc.patchpatch/kernel/archive/meson64-7.1/board-radxa-zero-dts-slow-down-sdio-for-working-wifi.patchpatch/kernel/archive/meson64-7.1/board-radxa-zero2-arm64-dts-amlogic-Enable-the-npu-node-for-Radxa-Zero2.patchpatch/kernel/archive/meson64-7.1/board-t95z-add-rc-remote-keymap.patchpatch/kernel/archive/meson64-7.1/driver-power-meson64-reset.patch.disabledpatch/kernel/archive/meson64-7.1/drv-spi-spidev-remove-warnings.patchpatch/kernel/archive/meson64-7.1/dt/meson-axg-amper-gateway-am-gz80x.dtspatch/kernel/archive/meson64-7.1/dt/meson-axg-amper-gateway-gz80x.dtsipatch/kernel/archive/meson64-7.1/dt/meson-g12-enable-spinor.dtsipatch/kernel/archive/meson64-7.1/dt/meson-g12a-radxa-zero-spidev.dtspatch/kernel/archive/meson64-7.1/dt/meson-g12b-a311d-cainiao-cniot-core.dtspatch/kernel/archive/meson64-7.1/dt/meson-g12b-a311d-khadas-vim3-spidev.dtspatch/kernel/archive/meson64-7.1/dt/meson-g12b-a311d-khadas-vim3-spinor.dtspatch/kernel/archive/meson64-7.1/dt/meson-g12b-odroid-n2-plus-spidev.dtspatch/kernel/archive/meson64-7.1/dt/meson-g12b-odroid-n2-plus-spinor.dtspatch/kernel/archive/meson64-7.1/dt/meson-g12b-odroid-n2-spinor.dtspatch/kernel/archive/meson64-7.1/dt/meson-g12b-radxa-zero2-spidev.dtspatch/kernel/archive/meson64-7.1/dt/meson-g12b-waveshare-cm4-io-base-b.dtspatch/kernel/archive/meson64-7.1/dt/meson-gxl-s905x-bestv-r3300-l.dtspatch/kernel/archive/meson64-7.1/dt/meson-gxm-c400-plus.dtspatch/kernel/archive/meson64-7.1/dt/meson-gxm-mini-m8s-pro.dtspatch/kernel/archive/meson64-7.1/dt/meson-gxm-t95z-plus.dtspatch/kernel/archive/meson64-7.1/dt/meson-sm1-jethome-jethub-j200-spinor.dtspatch/kernel/archive/meson64-7.1/dt/meson-sm1-jethome-jethub-j200.dtspatch/kernel/archive/meson64-7.1/dt/meson-sm1-khadas-vim3l-spidev.dtspatch/kernel/archive/meson64-7.1/dt/meson-sm1-khadas-vim3l-spinor.dtspatch/kernel/archive/meson64-7.1/dt/meson-sm1-odroid-c4-spidev.dtspatch/kernel/archive/meson64-7.1/dt/meson-sm1-ugoos-x3.dtspatch/kernel/archive/meson64-7.1/general-add-Amlogic-Meson-GX-PM-Suspend.patchpatch/kernel/archive/meson64-7.1/general-add-overlay-compilation-support.patchpatch/kernel/archive/meson64-7.1/general-driver-tm1628-auxdisplay-add-support-for-Titanmec-TM16.patchpatch/kernel/archive/meson64-7.1/general-drm-dw-hdmi-call-hdmi_set_cts_n-after-clock.patchpatch/kernel/archive/meson64-7.1/general-fix-Kodi-sysinfo-CPU-information.patchpatch/kernel/archive/meson64-7.1/general-media-cec-silence-CEC-timeout-message-HACK.patchpatch/kernel/archive/meson64-7.1/general-meson-aiu-Fix-HDMI-codec-control-selection.patchpatch/kernel/archive/meson64-7.1/general-meson-mmc-1-arm64-amlogic-mmc-meson-gx-Add-core-tx-rx-eMMC-SD-SD.patchpatch/kernel/archive/meson64-7.1/general-meson-mmc-2-arm64-amlogic-dts-meson-update-meson-axg-device-tree.patchpatch/kernel/archive/meson64-7.1/general-meson-mmc-3-arm64-dts-docs-Update-mmc-meson-gx-documentation-for.patchpatch/kernel/archive/meson64-7.1/general-meson-vdec-add-HEVC-decode-codec.patchpatch/kernel/archive/meson64-7.1/general-meson-vdec-add-handling-to-HEVC-decoder-.patchpatch/kernel/archive/meson64-7.1/general-meson-vdec-check-if-parser-has-really-parser.patchpatch/kernel/archive/meson64-7.1/general-meson-vdec-improve-mmu-and-fbc-handling-.patchpatch/kernel/archive/meson64-7.1/general-meson64-overlays.patchpatch/kernel/archive/meson64-7.1/general-soc-0001-soc-amlogic-meson-gx-socinfo-move-common-code-to-hea.patchpatch/kernel/archive/meson64-7.1/general-soc-0002-soc-amlogic-meson-gx-socinfo-sm-Add-Amlogic-secure-m.patchpatch/kernel/archive/meson64-7.1/general-soc-0003-dt-bindings-arm-amlogic-amlogic-meson-gx-ao-secure-a.patchpatch/kernel/archive/meson64-7.1/general-soc-0004-arm64-dts-meson-add-dts-links-to-secure-monitor-for-.patchpatch/kernel/archive/meson64-7.1/general-sound-soc-remove-mono-channel-as-it-curren.patchpatch/kernel/archive/meson64-7.1/general-spi-nor-add-support-for-XT25F128B.patchpatch/kernel/archive/meson64-7.1/general-usb-core-improve-handling-of-hubs-with-no-ports.patchpatch/kernel/archive/meson64-7.1/hwmon-emc2305-fixups-for-driver.patchpatch/kernel/archive/meson64-7.1/jethome-0001-Fix-meson64-add-gpio-irq-patch-from-https-lkml.org-l.patchpatch/kernel/archive/meson64-7.1/jethome-0002-arm64-dts-jethub-j1xx-add-eeprom-node.patchpatch/kernel/archive/meson64-7.1/jethome-0003-arm64-dts-meson-add-dts-links-to-secure-monitor-for-jethub.patchpatch/kernel/archive/meson64-7.1/kernel-6.8-tools-cgroup-makefile.patchpatch/kernel/archive/meson64-7.1/meson-g12a-pinctrl-add-missing-ir-options.patchpatch/kernel/archive/meson64-7.1/meson-g12a-radxa-zero-gpio-pin-names.patchpatch/kernel/archive/meson64-7.1/meson-g12b-dt-Add-missing-pinmux-node-for-pwm.patchpatch/kernel/archive/meson64-7.1/meson-gx-dts-add-support-for-GX-PM-and-VRTC.patchpatch/kernel/archive/meson64-7.1/meson-gxbb-dts-i2cX-missing-pins.patchpatch/kernel/archive/meson64-7.1/meson-gxbb-vdec-add-HEVC-support-to-GXBB.patchpatch/kernel/archive/meson64-7.1/meson-gxl-gxm-arm64-dts-meson-set-p212-p23x-q20x-SDIO-to-100MH.patchpatch/kernel/archive/meson64-7.1/meson-gxm-vdec-add-VP9-support-to-GXM.patchpatch/kernel/archive/meson64-7.1/meson-sm1-dts-add-higher-clocks.patchpatch/kernel/archive/meson64-7.1/overlay/Makefilepatch/kernel/archive/meson64-7.1/overlay/README.meson-overlayspatch/kernel/archive/meson64-7.1/overlay/meson-fixup.scr-cmdpatch/kernel/archive/meson64-7.1/overlay/meson-g12-gxl-cma-pool-896MB.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12-pwm-gpiox-5-fan.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-gpio-10-led.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-gpio-8-led.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-i2c-ao-m0-gpioao-2-gpioao-3.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-i2c-ee-m1-gpioh-6-gpioh-7.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-i2c-ee-m1-gpiox-10-gpiox-11.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-i2c-ee-m3-gpioa-14-gpioa-15.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-pwm-c-on-gpiox-8.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-pwmao-a-on-gpioao-11.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-spi-spidev.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-uart-ao-a-on-gpioao-0-gpioao-1.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-uart-ao-b-on-gpioao-2-gpioao-3.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-uart-ao-b-on-gpioao-8-gpioao-9.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12a-radxa-zero-uart-ee-c.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12b-bananapi-cm4-i2c2.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12b-bananapi-cm4-pwm-gpioh-5-fan.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12b-bananapi-m2s-rtl8822cs.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12b-odroid-n2-spi.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-g12b-waveshare-cm4-io-base-usb.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-i2cA.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-i2cB.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-sm1-bananapi-m5-rtl8822cs.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-sm1-bananapi-uartA.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-sm1-bananapi-uartAO_B.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-sm1-bananapi-uartA_cts_rts.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-sm1-jethome-jethub-j200-spi.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-sm1-odroid-c4-i2c0.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-sm1-odroid-c4-i2c1.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-uartA.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-uartC.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-w1-gpio.dtsopatch/kernel/archive/meson64-7.1/overlay/meson-w1AB-gpio.dtsopatch/kernel/archive/meson64-7.1/x-PATCH-v7-2-2-PCI-dwc-Remove-redundant-MPS-configuration.patch
Signed-off-by: Viacheslav Bocharov <v@baodeep.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@lib/functions/compilation/patch/drivers_network.sh`:
- Around line 486-491: The conditional that enables driver_rtl88x2cs (the if
starting with "if linux-version compare \"${version}\" ge 5.9 && [[
\"$LINUXFAMILY\" == meson64 ]]") lacks the same bleedingedge guard used by other
drivers; update that condition to also require [[ "$BRANCH" != bleedingedge ]]
so the driver is skipped on bleedingedge builds (or alternatively verify and
document that driver_rtl88x2cs builds cleanly on kernel 7.1 before removing the
guard), ensuring the script won't abort under set -e on known-incompatible
kernels.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 88aa2d0f-9d41-4e51-85af-3d9970418140
📒 Files selected for processing (1)
lib/functions/compilation/patch/drivers_network.sh
|
Thank you @adeepn! ❤️ |
|
"Reenbale" 😅🙈 |
|
✅ This PR has been reviewed and approved — all set for merge! |
This is cosmetics only since kernel builds .dtso files as overlays either way. However it violates convention without.
github-actions
Bot
added
Needs review
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@config/sources/mainline-kernel.conf.sh`:
- Around line 31-33: The alert text is misleading: update the display_alert call
that logs the fallback (currently referencing "missing torvalds tag") to clearly
state that the upstream mirror tag was missing/delayed and therefore the script
is falling back to Torvalds; modify the message in the display_alert invocation
that uses KERNELSOURCE and KERNELBRANCH so it reads something like "upstream tag
missing/delayed — falling back to KERNELSOURCE='${KERNELSOURCE}' for
KERNELBRANCH='${KERNELBRANCH}'" while leaving the KERNELSOURCE and KERNELBRANCH
variables and the call to display_alert unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: bc6ec217-53cf-46da-8094-4a79d441b2d6
📒 Files selected for processing (1)
config/sources/mainline-kernel.conf.sh
|
rc1 boot test on odroidn2 was good: see initial PR description |
EvilOlaf
changed the title
bleedingedge BRANCH with 7.1-rc1bleedingedge BRANCH with 7.1-rc2
2 participants
Description
rtl88x2cs disabled due to upstream API changesrtl88x2cs updated for kernel 7.1+How Has This Been Tested?
Checklist:
Summary by CodeRabbit
New Features
Bug Fixes
Documentation