Morse driver compatibility with back ported cfg80211 API

Software Linux
1

Hi,

I’m currently integrating the GW16167 HaLow card into a Telit Cinterion SE250B4 SoM with a Qualcomm QCM2290, running embedded Linux built with Yocto.

The kernel is vendor kernel based on Linux 5.15.189.

The issue I’m seeing is that, although the kernel reports itself as Linux 5.15.189, its cfg80211 API has been back ported to the API level used around Linux 6.2–6.6. This includes the newer MLO links[] structures and the newer 5 argument cfg80211_port_authorized() interface.

The Morse driver uses LINUX_VERSION_CODE / MAC80211_VERSION_CODE to select between old and new cfg80211 APIs. Since the kernel reports version 5.15.189, the driver selects the old API paths, but those APIs are no longer present in the kernel headers, resulting in compilation errors.

I identified four affected areas in wiphy.c:

  1. wdev.ssid / wdev.ssid_len versus wdev.u.client.ssid / ssid_len
  2. cfg80211_connect_resp_params / cfg80211_roam_info using flat bssid / bss versus links[0].bssid / links[0].bss
  3. The old 3-argument versus newer 5-argument cfg80211_port_authorized()
  4. The get_channel callback is introduced the link_id parameter

The driver already contains the newer API implementation in its version-gated branches. I fixed the issue locally by forcing it to use the newer API by manipulating the preprocessor defines.

I also checked the similar version gates in mac.c. Those do not have the same issue because mac80211 does not appears to be backported like cfg80211 in this kernel

Could you please clarify whether this type of kernel configuration is expected to be supported by the Morse Micro driver?
If so, is there a recommended compatibility mechanism for handling this situation or should I stick to the small hack I made?

In summary, is the driver expected to support a kernel where:

  • The reported Linux version is 5.15.x
  • cfg80211 has been backported to the API level used around Linux 6.2–6.6
  • mac80211 remains at the older API level

Thanks,
Amit

2

I don’t think there’s a better way than what you’ve done. The driver does support CONFIG_BACKPORT_VERSION to specify the correct mac80211 version (it ends up in MAC80211_VERSION_CODE, as you noted). However, I don’t think there’s any support for a mixed cfg80211/mac80211 (I may be wrong!); it sounds like what you’ve done is appropriate.