Rename two .patch files to .patch.NEED_FIX so the patch driver
skips them on apply. Both are drm/xe kernel patches that stopped
applying cleanly after an upstream rebase and haven't been
refreshed yet:
- 0002-drm-xe-guc-use-GUC_SIZE-SZ_4K-for-alignment.patch
- 0005-drm-xe-query-use-PAGE_SIZE-as-the-minimum-page-align.patch
Kernels that were picking these up need them re-based against
current upstream drm/xe before re-enabling. Not a behaviour
change on its own — the patches were already failing the apply
step — but stops the noise in build logs and makes it obvious
at a glance which patches need maintainer attention.
Compute the relevant PCI_EXP_DEVCTL change mask before clearing the
RC-mode forbidden bits from the local write value. Otherwise a change in
DEVCTL.{CERE,NFERE,FERE} may be missed and the corresponding IRQ mask
update deferred until some later config-space write.
Also restrict the PCI_EXP_RTCTL-triggered IRQ mask update to PMEIE.
mvebu_pcie_handle_irq_change() only uses rootctl.PMEIE, so reacting to
SECEE/SENFEE/SEFEE changes only reruns the helper without affecting the
hardware interrupt mask.
Assisted-by: Claude:claude-opus-4-7
Patch 10-mvebu-clearfog-pcie-updates.patch (Russell King, Nov 2016) was
restored from mvebu-6.6/ to mvebu-6.18/ alongside three other lost
patches. It bundled together two distinct kinds of changes:
1. Functional AER/PME plumbing for the mvebu PCIe controller:
- mvebu_pcie_handle_irq_change() in pci-mvebu.c, which syncs the
hardware PCIE_INT_UNMASK_OFF mask (BIT 8/9/10/16/17/18) with the
emulated bridge config space whenever AER-related bits in
PCI_COMMAND.SERR, BRIDGE_CTL.SERR, DEVCTL.{CERE,NFERE,FERE,URRE}
or RTCTL.{SECEE,SENFEE,SEFEE,PMEIE} change
- Armada 370 erratum: clamp DEVCTL.{URRE,FERE,NFERE,CERE} to 0 in
Root Complex mode
- pci-bridge-emul.c: default bridge->conf.bridgectrl to
PCI_BRIDGE_CTL_SERR (precondition for AER reporting)
2. Two debug hunks: dev_info() probes added during clearfog bring-up:
- drivers/pci/pcie/aspm.c (6 lines): print upstream/downstream ASPM
LNKCAP/LNKCTL on every pcie_aspm_cap_init() call
- drivers/pci/pcie/portdrv.c (2 lines): print PCIe capabilities and
init_service_irqs() return on every port device register
Drop the debug hunks. They were ad-hoc bring-up traces from 2016, never
useful in production, and just noise in dmesg on every boot. The aspm.c
hunk also no longer applies cleanly to 6.18 (function moved from line
617 to 814) — fixing the offset just to keep dev_info() spam is not
worthwhile.
Functional hunks (pci-mvebu.c, pci-bridge-emul.c) keep the original
intent: without them mvebu's hardware AER/PME interrupt masks stay off,
so corrected/uncorrected PCIe errors and PME wake events go undetected
on clearfog boards (NAS use case with NVMe/SATA cards in mPCIe slots).
Mainline still does not have this plumbing — Marek Behún's 2021 rewrite
around pci-bridge-emul did not close this gap.
Assisted-by: Claude:claude-opus-4-7
#9694 split mvebu edge into per-board kernel versions: helios4 on 6.18 LTS,
clearfogpro/clearfogbase on 6.15. Both share LINUXCONFIG=linux-mvebu-edge
and ARMBIAN_KERNEL_DEB_NAME=mvebu-edge, so building both produced
"Duplicate LINUXCONFIG's found!" — two source trees compete for the same
package name.
Per @igorpecovnik in #9694: "kernel can't be per board". Bump the rest of
the mvebu (armhf) family to 6.18 too. mvebu64 and other families are
untouched.
The mvebu-6.18 patch directory is already in the tree from #9694, so the
remaining boards (clearfogpro, clearfogbase) get the same patch set.
Affected boards: clearfogpro, helios4, clearfogbase (csc). espressobin
and macchiatobin (eos) are mvebu64, not affected.
I do not have non-helios4 mvebu hardware; build verified, runtime not.
Assisted-by: Claude:claude-opus-4-7
Commit 2f852e68e bumped mvebu edge KERNEL_MAJOR_MINOR from 6.12 to 6.15
but did not rename patch/kernel/archive/mvebu-6.12/, so KERNELPATCHDIR
pointed to a non-existent directory and all helios4-specific kernel
patches (GPIO wake, Wake-on-LAN, atheros regd, DMA, SPI-flash) were
silently skipped.
6.15 is not an LTS kernel; 6.18 is. Bump only helios4 to 6.18 (LTS, EOL
2028-12), keeping the rest of the mvebu family at 6.15 until their
maintainers verify the upgrade on their own boards.
Rename the archive directory to mvebu-6.18 so the patches apply again,
verified by a full kernel build against 6.18.23.
The Rock 5 ITX DTB defines the PWM fan as /pwm-fan without a labelled
phandle, so the existing rockchip-rk3588-fanctrl overlay (which targets
&fan) has no effect on this board.
The default cooling-levels in the Rock 5 ITX DTB start at 0, which means
the fan receives no PWM signal at idle and falls back to running at full
speed regardless of temperature.
This overlay patches /pwm-fan directly using target-path, replacing the
cooling-levels with a curve that starts at 1 (near-silent at idle) and
adds rockchip,temp-trips to ramp the fan gradually across four steps
at 45°C, 50°C, 55°C, and 65°C.
Tested on Rock 5 ITX running Armbian with linux-vendor-rk35xx 6.1.
glibc 2.42+ (Ubuntu Resolute and later) ships const-aware strstr/strchr
declarations in <string.h>. Assigning their results to non-const char*
triggers -Werror=discarded-qualifiers in tools/bpf/resolve_btfids,
which is compiled by the linux-headers .deb postinst on the build host.
Fix by declaring the receiving variables as const char* in two places
in tools/lib/bpf/libbpf.c. Matches the upstream 6.13+ fix, backported
to the NXP lf-6.12.y SDK kernel (which NXP has moved off for 6.18+).
Patches 1100 (2nd HDMI) and 1101 (HDMI sound) are now fully covered by
the upstream Linux 7.0 DTS, which was refactored to use
rk3588-orangepi-5-compact.dtsi. The patches no longer apply and were
silently skipped during builds.
The sff,sfp DT binding has additionalProperties: false, so our custom
leds property on SFP nodes violates the schema. Move LED-to-SFP
association into per-port child nodes of the sfp_led_controller.
DTS: sfp_led_controller now has port@0/port@1 sub-nodes, each with
sfp phandle and leds list. SFP nodes no longer carry leds property.
Driver: sfp_led_probe() iterates child nodes instead of sfp-ports
phandle array. sfp_led_register_port() receives the port child node,
parses the sfp phandle from it, and reads LEDs from the child node
instead of from the SFP node.
The board has a power-hold circuit controlled by GPIO3_21 (DT label &gpio2,
pin 21): driving it high cuts power. Add a gpio-poweroff node and enable
the driver so 'systemctl poweroff' actually turns the device off instead
of halting the CPU in an undefined state.
- DTS: gpio-poweroff node on &gpio2 21 active-high, 1s timeout
- Kernel: CONFIG_POWER_RESET_GPIO=y (must be builtin, not module)
- Remove vim from family_tweaks (user preference, not board dep)
- Move board-specific BSP (fan control) from family to board config
- Consolidate LED module-load into single gateway-dk-leds.conf
- Make BOOTSOURCE/ATFSOURCE/RCW_SOURCE overridable via ${VAR:-default}
- Replace echo-return pattern with declare -g in ensure_fman_ucode_cached
- Replace custom ask_ensure_cached with fetch_from_repo in post_family_config
- Use mktemp -d instead of /tmp/ask-build-$$
- Add proper git-format headers and Signed-off-by to DTS patch
- Fix DTS Makefile alphabetical ordering (after fsl-ls1046a, not fsl-ls1012a)
- Fix copyright year to 2026
- Document board-specific ethact/ethprime in bootenv
- Document apt-mark hold rationale for patched ASK libraries
- Add comment explaining NXP LS1043A platform ID for DPAA1 SoCs
- Remove iproute2 from CLAUDE.md (no patches exist in ASK repo)
The chraac BSP patch (driver-allwinner-h618-emac / 0203) introduced
conflicting out-of-tree drivers (sunxi-gmac, sunxi-ephy, sunxi-ac200)
that clash with the correct mainline AC200 stack already in place:
- sunxi-ac200.c conflicts with the mainline ac200.c (0201)
- sunxi-ephy.c conflicts with the mainline ac200-phy.c (0202)
- sunxi-gmac.c is an unnecessary BSP replacement for dwmac-sun8i
- removes of_gpio_flags enum from gpiolib-of.c, breaking other drivers
- depends on PWM_SUNXI_ENHANCE which doesn't exist in mainline
H6 internal EMAC is correctly handled by the mainline stack:
ac200.c + ac200-ephy-ctl.c (ac200-v3) + ac200-phy.c + DTS patches.
H618 EMAC is covered by dwmac-sun8i + drv-net-stmmac-dwmac-sun8i-
add-second-emac-clock patch.
Remove the patch from sunxi-6.12, 6.18 and 7.0, and drop the leftover
CONFIG_SUNXI_GMAC=m from the legacy kernel config. Also align
CONFIG_SUN4I_EMAC to =m (matching current/edge) in legacy config.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
Fix ethernet PHY not being detected on the NanoPi Zero2. The MDIO bus
scan was failing because the PHY reset GPIO was only defined on the
PHY child node inside the MDIO bus. The kernel processes this reset
after the MDIO scan, but the PHY needs reset released before it will
respond on the bus.
Move the reset control to the gmac1 node using snps,reset-gpios and
snps,reset-delays-us properties. The stmmac driver handles these
during MDIO bus registration, before scanning for PHY devices.
Also change CONFIG_MOTORCOMM_PHY from module (m) to built-in (y) in
the rockchip64 kernel config. As a module, the PHY driver loads too
late for the MDIO bus scan to find the PHY during boot.
Tested on hardware: ethernet link at 1000Mbps full duplex confirmed.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
