Patches to Sierra Linux QMI drivers version S2.39N2.60

I am glad to see that my previous patch to the Makefile for the Linux QMI driver ver. S2.37N2.57 has been included into ver. S2.38N2.59. However a new build artifact has been introduced that is not cleaned up.
I am attaching the patch for it here.

My work is an attempt to create a DKMS module for the Linux Qmi drivers so that I don’t have to recompile the module every time I update my kernel on Ubuntu (bionic). It can be found at https://github.com/samveen/MC7710_driver_builder
Regards,
Samveen

SierraLinuxQMIdriversS2.39N2.60.patch.gz (306 Bytes)

While building the module out-of-kernel-tree for a kernel version that is installed, but not the running kernel, the DKMS build fails as the Makefiles for the GobiNet and the GobiSerial drivers use the current kernel version using uname. This leads to issues with DKMS post-install auto-triggered builds, as expected. A 2nd patch to fix this issue (that implements using the variables that are provided by DKMS) is attached below.

SierraLinuxQMIdriversS2.39N2.60-2.patch.gz (513 Bytes)

Hi @samveen
I’ve passed on your patched to our dev team for review. Thank you.
Regards
Alan

Hi @samveen

We’ll be pulling in the changes that you’ve shared to support DKMS with the next release. FYI, below is a conf file that we’ll also be providing:

PACKAGE_NAME=SierraLinuxQMIdrivers
PACKAGE_VERSION=Sx.xxNx.xx
MAKE=“make -C GobiSerial && make -C GobiNet”
CLEAN=“make -C GobiSerial clean; make -C GobiNet clean”

BUILT_MODULE_NAME[0]=GobiSerial
BUILT_MODULE_LOCATION[0]=GobiSerial/
BUILT_MODULE_NAME[1]=GobiNet
BUILT_MODULE_LOCATION[1]=GobiNet/
AUTOINSTALL=“YES”

“x” will be actual release numbers.

Let us know if you have any comments. Thank you for your support.

Regards
Alan

Hi Alan,

First apologies on the late reply. It’s been a world changing time :wink:.

DKMS is built to be triggered automagically. This means that it can be triggered in 4 cases:

  1. DKMS Package install time - for the currently running kernel; auto-magically
  2. Kernel package install time - a new kernel; auto-magically
  3. User request to DKMS for currently kernels
  4. User request to DKMS for installed alternate kernels

The DKMS conf provided above and the existing makefiles (as of S2.39N260) WILL FAIL FOR CASE 2 and CASE 4 above. The reason is that the makefiles use the current running version of the kernel as the base for the kernel source directory, while DKMS expects that the module build framework should use the kernel version provided by DKMS as part of the MAKE= entry of the dkms conf file.

An example is

MAKE="bash build.sh --kver $kernelver"

In fact, the module source of the Sierra modules actually requires manual editing in the kernel includes tree to build correctly, name in the file memcontrol.h. Quoting directly from GobiNet/GobiUSBNet.c

#ifdef CONFIG_MEMCG
#define MEMCG_NOT_FIX
#ifdef MEMCG_NOT_FIX
#if (LINUX_VERSION_CODE >= KERNEL_VERSION( 3,13,0 ) &&\
       LINUX_VERSION_CODE < KERNEL_VERSION( 4,4,0 ))
#warning "Remove memcontrol.h task_in_memcg_oom warning : replace 'return p->memcg_oom.memcg;' to 'return p->memcg_oom.memcg==NULL ? 0 : 1;' in function task_in_memcg_oom"
#warning "Commnet '#define MEMCG_NOT_FIX' above after fix applied."
#elif (LINUX_VERSION_CODE >= KERNEL_VERSION( 4,4,0 ) )
#warning "Remove memcontrol.h task_in_memcg_oom warning : replace 'return p->memcg_in_oom;' to 'return p->memcg_in_oom==NULL ? 0 : 1;' in function task_in_memcg_oom"
#warning "Commnet '#define MEMCG_NOT_FIX' above after fix applied."
#endif
#endif
#endif

With this, it is not even possible to get the module under DKMS unless I add a whole framework around it to do this editing in an automated way (I did that at https://github.com/samveen/MC7710_driver_builder ).

With disappointment and regards,
Samveen

Hi @samveen
I will certainly share your feedback with our R&D.
Regards
Alan