Skip to content

rtl8188eus-openipc: build against the 3.0 kernels - #2726

Merged
openipc-ai merged 1 commit into
masterfrom
rtl8188eus-kernel-3.0
Oct 29, 2026
Merged

openipc-ai merged 1 commit into
masterfrom
rtl8188eus-kernel-3.0

Conversation

@openipc-ai

@openipc-ai openipc-ai commented Oct 29, 2026 •

Copy link
Copy Markdown
Collaborator

rtw_cfg80211_init_wiphy() fills in band->vht_cap unconditionally, and struct ieee80211_sta_vht_cap does not exist before Linux 3.6. This puts rtw_cfg80211_create_vht_cap() and its one 2.4 GHz call behind the same >= 3.6 check the file already uses for rtw_cfg80211_init_vht_capab() (line 8919). RTL8188EU is an 802.11n part, so nothing is lost on any kernel, and kernels >= 3.6 (e.g. hi3516ev300_dev, the only current user) compile exactly as before.

Needed for the hi3516cv100 family (Linux 3.0.8). First user: the D-Link DCS-2330L in OpenIPC/builder#216, which pairs a Hi3518CV100 with an RTL8188EU (0bda:8179).

Verified locally on the hi3518cv100_lite toolchain/kernel:

  • without the patch: ioctl_cfg80211.c:8926: error: invalid use of undefined type 'struct ieee80211_sta_vht_cap', plus IEEE80211_VHT_CAP_RXLDPC / IEEE80211_VHT_MCS_SUPPORT_0_9 undeclared
  • with it: 8188eu.ko builds and the full image assembles (rootfs 4904/5120 KB, uImage 1821/1983 KB)

The fix matches what the reporter of builder#216 applied by hand to get Wi-Fi working on their camera.

Hardware

Not tested on a camera by me — I have no hi3516cv100-family board with an RTL8188EU. The evidence there is:

  • Same change on hardware: builder#216 reports Wi-Fi association working on a DCS-2330L rev A with the same driver commit and the same two >= 3.6 guards applied by hand, built for 3.0.8 with this toolchain. That module was built outside Buildroot; the image from this patch has not been booted yet. A hardware run is requested from the reporter in hi3518cv100_lite_dlink-dcs-2330l: D-Link DCS-2330L rev A builder#217.
  • No effect on existing images: on any kernel >= 3.6 both #ifs are true, so the preprocessed source is identical to today's. No board that currently enables RTL8188EUS_OPENIPC (only hi3516ev300_dev, 4.9) builds different code, and no cv100 image enables the driver yet, so merging this changes no shipped image.

rtw_cfg80211_init_wiphy() fills in band->vht_cap unconditionally, and
struct ieee80211_sta_vht_cap does not exist before Linux 3.6. Every other
VHT use in ioctl_cfg80211.c already sits behind a >= 3.6 check; this
puts the 2.4 GHz helper and its one call behind the same check. The
RTL8188EU is an 802.11n part, so nothing is lost on any kernel.

Needed for the hi3516cv100 family (Linux 3.0.8), e.g. the D-Link
DCS-2330L (OpenIPC/builder#216).
@qodo-free-for-open-source-projects

Copy link
Copy Markdown

PR Summary by Qodo

Build rtl8188eus-openipc against Linux 3.0 kernels

🐞 Bug fix 🕐 Less than 10 minutes

Grey Divider

AI Description

• Guard VHT capability code unavailable before Linux 3.6, fixing RTL8188EU builds on Linux 3.0.
• Preserve the existing build behavior on newer kernels.
Diagram

graph TD
  Build["Driver build"] --> HT["2.4 GHz setup"] --> Version{"Kernel >= 3.6?"} -->|yes| VHT["VHT capability"] --> Module["8188eu.ko"]
  Version -->|no| Module
Loading
High-Level Assessment

Keep the targeted kernel-version guards. Removing VHT initialization altogether would also avoid the Linux 3.0 build failure, but would unnecessarily change behavior on newer kernels.

Files changed (1) +31 / -0

Bug fix (1) +31 / -0
0003-vht-cap-kernel-3.0.patchGuard VHT initialization for pre-3.6 kernels +31/-0

Guard VHT initialization for pre-3.6 kernels

• Adds a package patch that compiles the VHT helper and its 2.4 GHz call only against Linux 3.6 or newer. This avoids references to VHT types and constants absent from Linux 3.0 while retaining the existing path on newer kernels.

general/package/rtl8188eus-openipc/0003-vht-cap-kernel-3.0.patch

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented Oct 29, 2026 •

Copy link
Copy Markdown

Code Review by Qodo

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

Grey Divider


Action required

1. Camera behavior remains unverified 📘 Rule violation ≡ Correctness
Description
The added kernel-driver patch changes the Wi-Fi code shipped in the firmware, but the validation
reports only toolchain builds and image assembly rather than boot or streaming results from a real
affected camera. The hi3518cv100 image and RTL8188EU path therefore have no hardware evidence
showing that Wi-Fi works after the change.
Code

general/package/rtl8188eus-openipc/0003-vht-cap-kernel-3.0.patch[R9-17]

++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 6, 0))
+ static void rtw_cfg80211_create_vht_cap(struct ieee80211_sta_vht_cap *vht_cap)
+ {
+ 	u16 mcs_map;
+@@ -8934,6 +8935,7 @@ static void rtw_cfg80211_create_vht_cap(struct ieee80211_sta_vht_cap *vht_cap)
+ 	vht_cap->vht_mcs.rx_mcs_map = cpu_to_le16(mcs_map);
+ 	vht_cap->vht_mcs.tx_mcs_map = cpu_to_le16(mcs_map);
+ }
++#endif
Evidence
The changed patch modifies the RTL8188EU driver code included in the image, so the change can affect
camera behavior. The checklist requires real-camera boot or streaming evidence for image-affecting
changes; the supplied validation describes compilation and image assembly only, with no hardware
output.

Rule 3: Hardware evidence is present and honest
general/package/rtl8188eus-openipc/0003-vht-cap-kernel-3.0.patch[9-17]

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 PR changes a driver shipped in the firmware, but the validation evidence covers only compilation and image assembly; it does not show the affected camera booting and using Wi-Fi.
## Fix Focus Areas
- general/package/rtl8188eus-openipc/0003-vht-cap-kernel-3.0.patch[9-17]
## Recommended Fix
Test the generated image on the affected hi3518cv100 or hi3516cv100 camera and add before/after evidence showing boot, RTL8188EU detection, association, and usable network or stream behavior. If hardware testing is unavailable, state that limitation plainly and provide the strongest applicable non-hardware evidence instead.

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


Grey Divider

Tip of the day
💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Grey Divider

Qodo Logo

@openipc-ai
openipc-ai enabled auto-merge (squash) October 29, 2026 11:53
@openipc-ai
openipc-ai merged commit 2fa602f into master Oct 29, 2026
51 of 57 checks passed
@openipc-ai
openipc-ai deleted the rtl8188eus-kernel-3.0 branch October 29, 2026 11:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant