hi3519v101: drop the Wi-Fi driver with no firmware, and build mac80211's crypto in

[widgetii]

What broke

hi3519v101_lite fails the rootfs cap on master:

hi3519v101_lite
  - uImage:           [1806KB/2048KB]
  - rootfs.squashfs:  [5128KB/5120KB]
  -- size exceeded by: 8KB

Nothing in this repository grew to do it. The failing master nightly sits on
d87dae1, and #2401's build on the same base commit passed this board at
11:36 UTC and failed at 19:16 UTC with byte-identical numbers. majestic and
majestic-webui are unpinned moving refs — MAJESTIC_SITE has no version in
the URL — so the growth lands with no pull request to point at. Exactly the
shape of #2397 and #2399 one nightly earlier.

This board has been living on the line for a while: the CHECK_SIZE headroom
comment in the Makefile is written about it ("sat at exactly 5120KB of a
5120KB cap for weeks"), and #2308/#2309/#2310 bought its last reprieve.

What changes

One file, hi3519v101.generic.config, which backs exactly one defconfig
(hi3519v101_lite_defconfig — grep -rl over br-ext-chip-*/configs).

1. The in-kernel Realtek USB Wi-Fi stack is dropped. rtl8192cu asks for
rtlwifi/rtl8192cufw{,_A,_B,_TMSC}.bin. Nothing in this tree installs any of
those on any board — grep -rn 8192cufw over the repository returns nothing —
and the only firmware this board ships is mediatek/mt7601u.bin, because
hi3519v101_lite_defconfig selects ..._MEDIATEK_MT7601U and not
..._RTL_8188EU. So /lib/firmware/rtlwifi does not exist in the image and
the driver could never finish probing. In the built baseline rootfs it cost:

module	bytes
rtl8192cu.ko	104,420
rtlwifi.ko	95,644
rtl8192c-common.ko	63,660
rtl_usb.ko	17,220
total	280,944 (274KB)

CONFIG_RTLWIFI_DEBUG=y was set, which is why rtlwifi.ko was that large.
Same argument and same shape as #2376 and #2399. There is no wlandev profile
for this family in general/overlay/etc/wireless/usb at all, so nothing in the
tree modprobes any of these names.

2. ccm, ctr, seqiv and arc4 are built in instead of shipping as
modules. These are the algorithms mac80211 selects, so they are resident
whenever a dongle is and idle code the rest of the time either way — this moves
29KB from the size-capped rootfs into the uImage, which has 238KB of headroom.
The #2397 trade, and the same reason FAT is built in on this board already.
After the build, modules.builtin carries crypto/{ccm,ctr,arc4,seqiv}.ko and
modules.dep for mac80211.ko lists only cfg80211.ko.

CONFIG_CRYPTO_{AEAD,BLKCIPHER,RNG} follow to =y; that is what
olddefconfig derives, not a hand edit.

What deliberately does not change

CONFIG_R8188EU stays, even though the staging driver cannot load its
firmware either (rtlwifi/rtl8188eufw.bin, ships only when
BR2_PACKAGE_LINUX_FIRMWARE_OPENIPC_RTL_8188EU is selected, which this board
does not do) and /etc/wireless/usb's rtl8188eu-generic profile modprobes
the out-of-tree 8188eu, not r8188eu. It is 461KB — by far the biggest
single item — and dropping it would be wrong anyway:

$ grep -rn "select WIRELESS_EXT" drivers/staging/rtl8188eu/Kconfig
4:	select WIRELESS_EXT

WIRELESS_EXT is a prompt-less bool reachable only by select, and on this
board R8188EU is the only thing selecting it. olddefconfig confirms it:
drop R8188EU and CONFIG_WIRELESS_EXT, WEXT_CORE, WEXT_PROC and
WEXT_PRIV all go with it, taking net/wireless/wext-core.o and the
net_device.wireless_handlers field out of the kernel. That is the ioctl ABI
iwconfig (this board ships wireless-tools), wpa_supplicant's wext driver
(selected here via the MT7601U firmware option) and every out-of-tree Realtek
driver in general/package/ are built against. CONFIG_CFG80211_WEXT=y is not
a substitute — it gives WEXT_CORE but not CONFIG_WIRELESS_EXT. Both
hi3518ev200 and hi3518ev300 keep WIRELESS_EXT the same accidental way,
which is presumably why #2399 left R8188EU alone there too.

mac80211 and cfg80211 stay modular for the same reason: they are what an
out-of-tree driver added downstream would sit on.

Evidence

Full clean builds of hi3519v101_lite, before and after, same tree, same hour:

before   - uImage:          [1805KB/2048KB]
         - rootfs.squashfs: [5124KB/5120KB]
         -- size exceeded by: 4KB

after    - uImage:          [1809KB/2048KB]
         - rootfs.squashfs: [5028KB/5120KB]

(Local baseline reads 5124KB against CI's 5128KB; both overflow, and the delta
is what matters.) CI on this branch, run 34718966712, agrees:

hi3519v101_lite   - uImage:          [1809KB/2048KB]
                  - rootfs.squashfs: [5036KB/5120KB]

— 84KB under the cap, no headroom warning, and hi3516av200_{lite,neo,ultimate}
(the rest of the matrix this file selects) pass unchanged.

make BOARD=hi3519v101_lite size-report after:

packages=33 modules=59 removed=65
rootfs=5148672B (uncompressed 13587069B, ratio 0.3789)
headroom: kernel=238KB rootfs=92KB

Module count 63 → 59. In the built tree
kernel/drivers/net/wireless/ and kernel/crypto/ are gone from
/lib/modules, while r8188eu.ko (461,524), mac80211.ko (322,708),
cfg80211.ko (214,592), wireguard.ko and the 30 hisilicon/ vendor modules
are all still there. CONFIG_WIRELESS_EXT=y, WEXT_CORE=y, WEXT_PROC=y and
WEXT_PRIV=y survive in the built .config.

The committed file derives exactly the .config that was built — copying it
over build/linux-custom/.config and running olddefconfig produces a
byte-identical file, so nothing was re-enabled behind the change.

Checks run:

bash .github/scripts/test_load_hisilicon.sh                  OK
bash .github/scripts/test_sysupgrade.sh                      OK
bash .github/scripts/test_excludes_report.sh                 OK
STRICT=1 bash .github/scripts/test_shell_parse.sh            OK (144 scripts)
STRICT=1 bash .github/scripts/test_strip_shell_comments.sh   OK
python3 .github/scripts/ci-matrix.py --self-test             OK (99 boards)
python3 .github/scripts/lint-workflow-shell.py --self-test   OK
python3 general/scripts/tests/test_kconfig_graph.py          OK
bash .github/scripts/check_target_modules.sh <built tree>    OK (wireguard.ko present)

Not tested on hardware

There is no hi3519v101 unit on the bench, so this is measured from builds only.
Both moves are the ones #2376, #2397 and #2399 already made on Goke,
hi3518ev300 and hi3518ev200, and the reasoning for each dropped symbol is
stated above so it can be checked rather than taken on trust. Worth exercising
on a real camera before this is trusted:

• the board still boots and streams — the crypto move changes when ccm/arc4
  register, not whether;
• if anyone has a hi3519v101 camera with a USB dongle working through the
  in-kernel rtl8192cu (which would mean they are supplying
  /lib/firmware/rtlwifi/ from outside this tree), say so and I will keep
  CONFIG_RTL_CARDS.

Follow-up, not in this PR

Twenty other board configs still carry CONFIG_RTL_CARDS=m with the same
missing firmware, including hi3516av200.generic.config next door. That is a
fleet-wide sweep that would widen the CI matrix to most of the tree, so it is
better done deliberately than smuggled into a red-master fix.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Trim hi3519v101 rootfs and build mac80211 crypto into kernel

🐞 Bug fix ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Removes unusable rtl8192cu modules to restore hi3519v101_lite rootfs headroom.
• Builds mac80211 crypto dependencies into uImage, shifting 29KB outside the capped rootfs.
• Preserves R8188EU and modular wireless infrastructure required for WEXT compatibility.

Diagram

graph TD
  CFG["Board config"] --> KCFG["Kernel Kconfig"] --> WIFI["Exclude rtl8192cu"] --> ROOT["Rootfs modules"] --> CAP["Size check"]
  KCFG --> CRYPTO["Built-in crypto"] --> IMAGE["uImage"] --> CAP

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Pin moving runtime dependencies

• ➕ Makes image growth reproducible and attributable.
• ➕ Prevents unreviewed majestic or web UI changes from breaking size caps.
• ➖ Does not reclaim enough space from the currently oversized image.
• ➖ Requires a broader dependency-versioning and update policy.

2. Increase or repartition the rootfs cap

• ➕ Retains all existing kernel modules.
• ➕ Provides more tolerance for future userspace growth.
• ➖ May be incompatible with deployed flash layouts and upgrade paths.
• ➖ Preserves 274KB of drivers that cannot probe without missing firmware.

3. Remove R8188EU as well

• ➕ Would reclaim substantially more rootfs space.
• ➖ Removes the board's only selector for WIRELESS_EXT.
• ➖ Risks breaking wireless-tools, wpa_supplicant WEXT support, and downstream Realtek drivers.

Recommendation: Use the PR's targeted configuration change: it removes modules that are unusable with the shipped firmware and shifts always-required crypto into available kernel headroom without sacrificing downstream wireless compatibility. Pinning moving package references is a valuable follow-up for reproducibility, but it does not replace the immediate rootfs reduction.

Files changed (1) +22 / -13

Other (1) +22 / -13

hi3519v101.generic.configRebalance hi3519v101 Wi-Fi and crypto features across image limits +22/-13

Rebalance hi3519v101 Wi-Fi and crypto features across image limits

• Disables the rtl8192cu/rtlwifi module stack because its required firmware is absent, while documenting why R8188EU and WEXT support remain. Builds CCM, CTR, SEQIV, ARC4, and derived crypto helpers into the kernel to move module payload from rootfs.squashfs into uImage headroom.

br-ext-chip-hisilicon/board/hi3519v101/hi3519v101.generic.config

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Camera operation remains unverified 📘 Rule violation ☼ Reliability

Description

The PR changes the hi3519v101_lite image by disabling CONFIG_RTL_CARDS and changing several
crypto algorithms from modules to built-ins, but reports only clean-build and image-size results
rather than real-camera validation. Because that board consumes this kernel configuration directly,
the changes reach boot, streaming, wireless initialization, and kernel/module behavior without
corresponding physical-hardware evidence.

Code

br-ext-chip-hisilicon/board/hi3519v101/hi3519v101.generic.config[1199]

+# CONFIG_RTL_CARDS is not set

Evidence

The cited configuration is consumed directly by the sole affected board defconfig, and the changed
lines disable a wireless driver family and alter crypto linkage. Repository standards distinguish
successful image generation from runtime validation and require image behavior changes that reach a
camera to be tested on real hardware, while the supplied PR evidence is explicitly limited to
clean-build and size measurements.

Rule 1: Hardware evidence is present and honest
br-ext-chip-hisilicon/board/hi3519v101/hi3519v101.generic.config[1189-1199]
br-ext-chip-hisilicon/configs/hi3519v101_lite_defconfig[18-24]
br-ext-chip-hisilicon/board/hi3519v101/hi3519v101.generic.config[2363-2369]
best_practices.md[276-280]
best_practices.md[307-313]
.github/PULL_REQUEST_TEMPLATE.md[18-25]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The kernel configuration changes the `hi3519v101_lite` image's shipped wireless support and built-in crypto implementation, but the pull request provides only image-build and size results. Repository policy requires behavior-changing firmware to be exercised on physical hardware before merge.
## Fix Focus Areas
- br-ext-chip-hisilicon/board/hi3519v101/hi3519v101.generic.config[1189-1199]
- br-ext-chip-hisilicon/board/hi3519v101/hi3519v101.generic.config[2363-2369]
- br-ext-chip-hisilicon/board/hi3519v101/hi3519v101.generic.config[2388-2400]
## Recommended Fix
Flash before-and-after images on a physical `hi3519v101` camera and update the pull request description with raw evidence identifying the tested board and showing successful boot, boot logs or dmesg, video streaming, wireless initialization and relevant Wi-Fi behavior, kernel/module output, and observed before-and-after behavior. If hardware is unavailable, keep the pull request as a draft rather than changing code to manufacture evidence.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can start a comment with 'qodo' or '@qodo' to chat about any finding

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗