linux-rk35xx-vendor: Add and enable LTE em05 driver ( Enables support for WWAN cards in Rock 5T/5B+ ) #8484
Conversation
Adds support for the Quectel M2 WWAN card on the Rock 5T/5B+.
Enables the lte_rm310 and lte_em05 drivers (drivers/net/lte/).
rafayahmed317
requested review from
ColorfulRhino,
SuperKali,
Tonymac32,
amazingfate,
catalinii,
chainsx,
efectn,
ginkage,
krachlatte,
lanefu,
prahal,
rpardini,
schwar3kat and
sputnik2019
as code owners
WalkthroughEnables three kernel configuration flags in config/kernel/linux-rk35xx-vendor.config: CONFIG_LTE=y, CONFIG_LTE_RM310=y, and CONFIG_LTE_EM05=y. These entries are added after the comment line indicating IEEE802154 drivers are not set. No other files or lines are changed. Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes ✨ Finishing Touches🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
github-actions
bot
added
08
|
In case anyone wants to test the image: https://drive.google.com/file/d/1VkrBcRiAWKzFjHkOhqr66VE98U_s9Rcj/view?usp=drive_link |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
patch/kernel/rk35xx-vendor-6.1/net-lte-add-lte-em05-driver.patchis excluded by!patch/**
📒 Files selected for processing (1)
config/kernel/linux-rk35xx-vendor.config(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
config/kernel/linux-rk35xx-vendor.config (1)
lib/functions/compilation/armbian-kernel.sh (7)
armbian_kernel_config__enable_docker_support(205-336)armbian_kernel_config__disable_various_options(70-100)armbian_kernel_config_apply_opts_from_arrays(418-448)kernel_config_set_y(380-384)armbian_kernel_config__enable_zram_support(182-192)armbian_kernel_config__netkit(46-53)kernel_config_set_val(409-414)
🔇 Additional comments (2)
config/kernel/linux-rk35xx-vendor.config (2)
904-906: Avoid driver binding conflicts with generic USB modem drivers; fix doc exampleGeneric support for Quectel WWANs (USB_SERIAL_OPTION, USB_NET_QMI_WWAN, USB_NET_CDC_MBIM) is already enabled here. If the new EM05/RM310 driver claims the same USB IDs, it can steal binding from option/qmi_wwan and regress other modules. Please confirm IDs and driver bind order, or limit IDs via new_id only when needed.
Also, the documentation “expected lsusb” example shows 2c7c:0512 (EM12-G), while the PR title targets EM05; please update to an EM05-specific ID or clarify.
904-906: Confirm vendor kernel includes these Kconfig symbols and driver patchesThe defconfig enables three vendor-specific options—CONFIG_LTE, CONFIG_LTE_EM05 and CONFIG_LTE_RM310—but our repo doesn’t include the rk35xx-vendor kernel tree to verify their definitions or driver wiring. If those symbols aren’t defined in the kernel’s Kconfig files, or the corresponding driver patches (Makefile entries, source under drivers/usb/…, USB ID 0x2c7c, etc.) aren’t applied,
scripts/configwill fail and the build will break.Please manually verify in your rk35xx-vendor kernel source that:
- Each symbol (LTE, LTE_EM05, LTE_RM310) is declared in a Kconfig file.
- The drivers are wired in the kernel Makefiles (
obj-$(CONFIG_LTE_…) += …).- The USB device IDs (e.g. 0x2c7c) don’t collide with existing option/qmi_wwan entries.
| CONFIG_LTE=y | ||
| CONFIG_LTE_RM310=y | ||
| CONFIG_LTE_EM05=y |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Prefer modules over built-ins for vendor LTE drivers; consider limiting scope to EM05 only
Setting these vendor LTE drivers built-in (=y) increases kernel size and makes them always resident. Armbian typically ships peripheral device support as modules. Also, if this PR is specifically for EM05, enabling RM310 may be unnecessary and could introduce driver binding conflicts.
Recommend:
- Build as modules (=m).
- Drop RM310 unless it’s a hard dependency for EM05 in this vendor tree.
Proposed diff:
-CONFIG_LTE=y
-CONFIG_LTE_RM310=y
-CONFIG_LTE_EM05=y
+CONFIG_LTE=m
+# Only enable RM310 if required for EM05; otherwise drop it.
+# CONFIG_LTE_RM310 is not set
+CONFIG_LTE_EM05=m📝 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.
| CONFIG_LTE=y | |
| CONFIG_LTE_RM310=y | |
| CONFIG_LTE_EM05=y | |
| CONFIG_LTE=m | |
| # Only enable RM310 if required for EM05; otherwise drop it. | |
| # CONFIG_LTE_RM310 is not set | |
| CONFIG_LTE_EM05=m |
🤖 Prompt for AI Agents
In config/kernel/linux-rk35xx-vendor.config around lines 904-906, the LTE vendor
drivers are built-in which increases kernel size and may be unnecessary; change
the options to build as modules and remove the RM310 entry unless EM05 actually
depends on it. Specifically, set the generic LTE and EM05 options to =m (e.g.
CONFIG_LTE=m and CONFIG_LTE_EM05=m), delete the CONFIG_LTE_RM310 line unless you
confirm RM310 is a hard dependency for EM05 — if it is required, change it to =m
instead of =y; ensure the resulting config builds the drivers as loadable
modules.
There was a problem hiding this comment.
These drivers are not buildable as modules as the relevant Kconfig (drivers/net/lte/Kconfig) defines the required config flags as booleans and not tristate.
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if the Kconfig file exists and examine the LTE driver configuration options
if [ -f drivers/net/lte/Kconfig ]; then
echo "=== Contents of drivers/net/lte/Kconfig ==="
cat drivers/net/lte/Kconfig
else
echo "Kconfig file not found at expected location. Searching for LTE Kconfig files..."
fd -t f "Kconfig" | xargs grep -l "CONFIG_LTE\|LTE_EM05\|LTE_RM310" 2>/dev/null | head -5
fi
# Also check if there are any related source files to understand the driver structure
echo -e "\n=== Searching for LTE driver source files ==="
fd -e c -e h "lte|em05|rm310" drivers/net/ 2>/dev/null | head -10
Length of output: 446
🏁 Script executed:
#!/bin/bash
# Search more broadly for LTE-related configurations
echo "=== Searching for LTE/EM05/RM310 in all Kconfig files ==="
rg "LTE|EM05|RM310" --type-add 'kconfig:Kconfig*' -t kconfig | head -20
echo -e "\n=== Searching for LTE-related files anywhere in the tree ==="
fd -t f "lte|em05|rm310" -i | head -10
echo -e "\n=== Checking if there are patches adding LTE support ==="
fd -e patch -e diff | xargs grep -l "LTE\|EM05\|RM310" 2>/dev/null | head -5
echo -e "\n=== Looking for wireless/wwan related Kconfig that might contain LTE ==="
fd Kconfig drivers/ | xargs grep -l "WWAN\|LTE" 2>/dev/null | head -5
Length of output: 1179
@rafayahmed317, thank you for the clarification! You're absolutely right - if the vendor kernel's Kconfig defines these as boolean options, they can only be built-in or disabled, not as modules.
Given this constraint, having them as built-in (=y) is the correct approach. One remaining question: Is CONFIG_LTE_RM310=y actually required for the EM05 driver to function, or could it be disabled since this PR specifically targets EM05 support? If RM310 is unrelated to EM05, you might consider setting it to # CONFIG_LTE_RM310 is not set to minimize kernel size.
✏️ Learnings added
Learnt from: rafayahmed317
PR: armbian/build#8484
File: config/kernel/linux-rk35xx-vendor.config:904-906
Timestamp: 2025-08-11T22:00:13.387Z
Learning: In the linux-rk35xx-vendor kernel, the LTE driver options (CONFIG_LTE, CONFIG_LTE_RM310, CONFIG_LTE_EM05) are defined as boolean in drivers/net/lte/Kconfig and cannot be built as modules - they must be either built-in (=y) or disabled.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
There was a problem hiding this comment.
I don't think that's necessary. The kernel should maximize the number of devices it's compatible with. The RM310 is also not buildable as a module, so I think it should be included.
There was a problem hiding this comment.
@rafayahmed317, that makes perfect sense! Your approach aligns well with Armbian's philosophy of maximizing hardware compatibility. Since both the RM310 and EM05 drivers are boolean-only options and cannot be built as modules, including both as built-in ensures the kernel supports a wider range of WWAN devices out of the box.
Thank you for the clarification about the driver constraints. The configuration looks good as-is! 👍
🧠 Learnings used
Learnt from: rafayahmed317
PR: armbian/build#8484
File: config/kernel/linux-rk35xx-vendor.config:904-906
Timestamp: 2025-08-11T22:00:13.387Z
Learning: In the linux-rk35xx-vendor kernel, the LTE driver options (CONFIG_LTE, CONFIG_LTE_RM310, CONFIG_LTE_EM05) are defined as boolean in drivers/net/lte/Kconfig and cannot be built as modules - they must be either built-in (=y) or disabled.
Learnt from: pyavitz
PR: armbian/build#8421
File: config/kernel/linux-sunxi64-edge.config:805-825
Timestamp: 2025-07-27T15:53:30.629Z
Learning: In the Armbian build system, kernel configurations prioritize broad hardware compatibility over optimization concerns. Even when including numerous legacy/obsolete drivers causes technical issues like increased initramfs size and slower enumeration, the project philosophy is to "appease the masses" by ensuring maximum device compatibility rather than optimizing for specific use cases.
There was a problem hiding this comment.
Do we have any ideas why (beyond the technical explanation) these are not buildable as modules? Is this an oversight at kernel level or was this somehow a deliberate design decision? Unless deliberate, we should push for this to be fixed at kernel level, as well.
Let's try to keep the Armbian kernel lean, clean and mean.
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!
EvilOlaf
left a comment
EvilOlaf
left a comment
There was a problem hiding this comment.
Since we maintain our own vendor sources I suggest to add the driver directly there: https://github.com/armbian/linux-rockchip
@EvilOlaf What about the kernel config? Will that have to be updated here after the driver is added there? |
|
Kernel config stays here. |
Changes in the patch submitted to armbian/linux-rockchip . Only config change needed now after that gets approved.
github-actions
bot
added
size/small
|
Is there a reason why this has to be built into the kernel rather than being available as module? |
In the Kconfig (drivers/net/lte/Kconfig), the flags are defined as booleans and not tristate. |
|
I would propose extending this to: ... if it exits there / can be ported to. (can be done later, in a separate PR) |
EvilOlaf
left a comment
EvilOlaf
left a comment
There was a problem hiding this comment.
I still think a driver is poorly designed when it cannot be built modular but welp...as long as there is no impact in performance when no WWAN card is installed (which will probably be 99% of users) I'm fine with.
igorpecovnik
added
Ready to merge
leggewie
left a comment
leggewie
left a comment
There was a problem hiding this comment.
further discussion needed
| CONFIG_LTE=y | ||
| CONFIG_LTE_RM310=y | ||
| CONFIG_LTE_EM05=y |
There was a problem hiding this comment.
Do we have any ideas why (beyond the technical explanation) these are not buildable as modules? Is this an oversight at kernel level or was this somehow a deliberate design decision? Unless deliberate, we should push for this to be fixed at kernel level, as well.
Let's try to keep the Armbian kernel lean, clean and mean.
|
@leggewie @EvilOlaf From what I’ve seen, there’s nothing fundamentally preventing the driver from being built as a module. Initially, I didn’t attempt this because I don't have any experience with Linux driver development, but now after making a few minor code adjustments (drivers/net/lte/lte_em05.c), I’ve successfully built and tested it as a module. It works as expected. I’ll submit the changes to armbian/linux-rockchip maintainers tomorrow, if accepted, we can start adding these (or just lte_em05) as modules moving forward. |
|
Waiting for this to be approved: armbian/linux-rockchip#384 . |
|
Tested? |
|
@igorpecovnik Yes. After installing the new kernel with this module, I can see the Quectel card under lsusb output and after modprobe -r lte_em05 which removes the module, the card is no longer listed. |
|
awesome work, @rafayahmed317 Thank you |
|
@rafayahmed317 would you mind sending a follow-up PR switching to module? This PR has been merged while not being ready by accident. |
… for WWAN cards in Rock 5T/5B+ ) (#8484) * Added a patch to add the lte_em05 driver Adds support for the Quectel M2 WWAN card on the Rock 5T/5B+. * Enable CONFIG_LTE and LTE_RM310 + LTE_EM05 Enables the lte_rm310 and lte_em05 drivers (drivers/net/lte/). * Delete patch/kernel/rk35xx-vendor-6.1/net-lte-add-lte-em05-driver.patch Changes in the patch submitted to armbian/linux-rockchip . Only config change needed now after that gets approved.
4 participants
Description
To enable the Quectel EM05 card on Radxa Rock 5T and Rock 5B+, the lte_em05 driver is needed. It's been added to both JoshuaRiek's linux-rockchip and the radxa upstream. The patch added here is from JoshuaRiek's image. Also to build the driver a kernel config flag is required which has been added.
Depends on armbian/linux-rockchip#383
Documentation summary for feature / change
Please delete this section if entry to main documentation is not needed.
If documentation entry is predicted, please provide key elements for further implementation into main documentation and set label to "Needs Documentation". You are welcome to open a PR to documentation or you can leave following information for technical writer:
Bus 003 Device 005: ID 2c7c:0512 Quectel Wireless Solutions Co. , Ltd. EM12-G
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.
Checklist: