This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3301: kernel 5.x

Part Number: CC3301

Tool/software:

The cc3301 linux release 1.0.0.0/1.0.0.1 is patch files for kernel 5.10, which works on our third party embedded linux MPU. However, the cc3301 release 1.0.0.3/1.0.0.4 have changed to kernel 6.1, which failed to be applied into our 5.10 kernel. Please keep supporting kernel 5.10.

I have to say, using patch files for specific kernel version does limit the embedded linux MPU platform selection. On the contrary, take the old RTL8188 as an example. It provides standalone, out of kernel tree, source code.

It can be compiled without kernel source code, just needs kernel header files. It can be compiled with kernel from 2.6 to 5.x.

Please keep supporting kernel 5.10. Our linux BSP doesn't upgrade kernel version continuously. Although TI's linux MPU seems to keep upgrading kernel version, many other linux MPUs don't. 

  • Hello,

    On the contrary, take the old RTL8188 as an example. It provides standalone, out of kernel tree, source code.

    My understanding is that RTL8188 has its driver in kernel tree. Can you point me to where they are out of kernel tree? Anyways, we are working on integrating cc33xx drivers into mainline kernel. So that going forward for new BSPs/kernels the cc33xx will be supported for free without any need for kernel patches. 

    However, the cc3301 release 1.0.0.3/1.0.0.4 have changed to kernel 6.1, which failed to be applied into our 5.10 kernel. Please keep supporting kernel 5.10.

    We chose kernel 6.1 because in the past year, new projects and MPU SOC vendors (TI, NXP, ST, etc.) have switched to using kernel 6.1. So kernel development will continue to move forward.

    However, we understand that customers may want to use older kernels due to hardware or vendor restrictions, software familiarity, etc. Therefore, we are working with customers to provide backports for their dependent kernel version. We are working on a strategy such that by customer request can backport cc33xx linux driver to older linux kernel versions. 

    I will take this thread as a request, so let me get back to you next week and I will see how and when we can provide kernel backport for you. 

  • The RTL8188 driver is indeed kernel module (.ko). I mean it can be built(compiled) out of tree, outside the kernel directory.

    It still needs to reference kernel source(header files), but doesn't need to patch(modify) the kernel. We only need to assign some variables in the makefile, like CROSS_COMPILE and KSRC.

    The point is, when it adds support for newer kernel version, it doesn't abandon older version. Furthermore, it is one same package for all kernel version. In case someone wonder how it does that, it uses these blocks inside it's source code:
    #if LINUX_VERSION_CODE [>|<|=] KERNEL_VERSION(x,x,x)

    Bt the way, this is our kernel source:
    https://github.com/OpenNuvoton/NUC980-linux-5.10.y

  • The RTL8188 is a big family. And Realtek does not show all models on the web site now.

    Linux kernel has contains some version of RTL8188, but not all models share this common driver.

    Years ago, we use RTL8188FU, it is one of the models need different driver at that time.

  • Hi,
    I understand the concern. Let me discuss this internally and I will see how I can deliver the patches to you for kernel 5.10. 

  • Hi,

    Sorry for the delay, I am still working on this. I will get back to you later this week. 

  • Any updates, any news?

  • Hello,

    Sorry for the delay. Attached is the patch for the kernel 5.10 backport. Apply the patch from CC33xx Linux SDK 1.0.0.6 like usual. You may find some patching errors, but the following patch should account for it. 

    0001-backport-k5.10.patch

  • Thank you for your patch.

    By the way, how should your customers upgrade the driver?
    For me, my kernel has already applied the patch 1.0.0.0, I can't apply the patch 1.0.0.6 again. In order to apply 1.0.0.6, I need to use the original unmodified kernel. And I need to redo all the other cc33xx-unrelated modifications. It is really not convenient. Many of your customers will have the same issue, they have their own PCBA design, cc33xx is not the only thing be modified in kernel.

    However, if cc33xx can be provided as a standalone, out of tree, driver package. We just need to compile the newer driver, replace the .ko file. It will be convenient.

  • Hi,

    While I recognize the convenience of out of tree modules, it will not be suitable for TI long term support. Customers have many different requirements, be it on kernel 5.10, 6.1, 6.6, and more going forward. It is actually a goal for TI to then upstream the driver into the kernel and then provide backports for older kernels. 

    Here is the latest on upstreaming progress: https://lore.kernel.org/linux-wireless/20240806170018.638585-1-michael.nemanov@ti.com/ 

    For changing the patch, I would recommend using git rebase or creating a diff of the two patch files of the CC33xx linux patches from within the SDK.