fix build compatibility with Linux 6.12+ and hardened kernels with strict type checks

[govindsi]

This patch updates the Morse driver to build successfully with Linux kernel version 6.12 and later, addressing API changes and stricter type checks introduced in newer kernel releases.

Key changes:

• Fixed morse_firmware_init() enum–int type mismatch causing -Werror=enum-int-mismatch failures.
• Updated mac80211 compatibility for new API signatures:
  • sta_rc_update now uses ieee80211_link_sta (6.13+)
  • set_frag_threshold and set_rts_threshold updated to accept (struct ieee80211_hw *, int, u32)
  • Added support for morse_mac_ops_config() and morse_wiphy_set_wiphy_params() variants with radio_idx argument (6.17+)
• Adjusted get_elements_from_s1g_beacon() and related logic to align with new ieee80211_is_s1g_short_beacon() behavior (requires variable_len in 6.12+).
• Replaced deprecated timer APIs (del_timer_sync) with timer_delete_sync where required (6.15+), and introduced timer_container_of() for 6.16+.
• Fixed missing mmrc_osal.h include error by adding APF stub functions when CONFIG_ANDROID is disabled.
• Added kernel version guards and minor cleanup for conditional compilation across 6.12–6.17 transitions.

This ensures forward compatibility while maintaining backward support for older kernel versions.

[govindsi]

@morse-arienjudge Can we have this patch merged in the next version of the Morse driver?
It’s hard to maintain Morse driver across newer kernel versions, as we keep updating the BSP to later kernels and the Morse driver needs some adaptation.

[govindsi]

Also i am curious if there is a roadmap to have this up streamed in Linux kernel.
If morse_driver driver is upstreamed into the Linux kernel(like atheros, bcm etc), it will benefit from ongoing maintenance and updates by kernel developers through future refactoring changes. This would help prevent issues where the driver becomes unusable between major kernel releases, as has occasionally happened in the past. It would also make it easier for developers and manufacturers to use your device with newer hardware that supports only in-tree drivers on recent kernels, reducing integration challenges and improving overall usability.

[morse-arienjudge]

Hi @govindsi

Thanks for raising this fix - many members of the community have been asking about it.
Unfortunately we aren't accepting patches to our core software via GitHub at this time (including this driver). The workflows aren't yet set up for external contributions, we don't have an appropriate CLA for these projects at this time, and we primarily use GitHub for public delivery. However I have shared this pull request with the team and will leave it open on GitHub for others to find!

It's unlikely this will make it into the next release (which was tagged internally a little while ago), but I've notified the responsible teams and hope to improve the process so subsequent driver releases consider latest versions of LTS kernels, rather than the tagged versions you may see in https://github.com/MorseMicro/rpi-linux and https://github.com/MorseMicro/linux

Regarding our upstream efforts. We're working on this and we had started with kernel changes first. We have enough S1G support in the kernel now to begin pushing a basic, minimal driver. There isn't a hard timeline on this, but we're aiming to submit a driver to the kernel staging directory before the end of the year. This will need to be supported by accompanying changes to hostap/wpa_supplicant which will follow shortly after. This driver will only support basic functionality at first as per kernel requirements.

[aanon4]

Just wanted to thank you for this. I've been keeping my own patch for the AREDN Project (arednmesh.org) which uses the latest OpenWRT builds. But this is much nicer than what I've been doing.

One question - should you be using MAC80211_VERSION_CODE rather than LINUX_VERSION_CODE in some places? In the latest OpenWRT I needed to make a couple of these changes to get it to compile.

[govindsi]

Thanks @aanon4 for the feedback.
Yes, I agree that some of the mac80211-specific ops and callbacks should use MAC80211_VERSION_CODE, while the generic platform delta should use LINUX_VERSION_CODE.

[Mic92]

@govindsi why was the behavior negated for new kernel versions?

[govindsi]

@Mic92 , yes, this shall be corrected. Thanks for pointing out

[donnaskiez]

Hi,

We are looking at this internally. Unfortunately the changes in this patchset incorrectly parse the beacons and will lead to a failure during association.

#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 12, 0)
	return (u8 *)bcn->u.s1g_beacon.variable;
#else
	return ieee80211_is_s1g_short_beacon(bcn->frame_control)
           ? (u8 *)bcn->u.s1g_short_beacon.variable
           : (u8 *)bcn->u.s1g_beacon.variable;
#endif

The above does not take into account optional elements in S1G beacon that may precede the elements based on the flags set in the frame control. For more information on this please see the following patch, which was backported to 6.12.34. For this to be done right it should make use of ieee80211_s1g_optional_len and perform the following arithmetic to ensure the optional elements are processed accordingly.

variable = ext->u.s1g_beacon.variable + ieee80211_s1g_optional_len(ext->frame_control);

where variable then points to the true start of the elements.

Additionally, as @Mic92 pointed out - the inversion of the ieee80211_is_s1g_short_beacon does not seem right. Not only that but the API has been changed and backported once again (see patch). 6.12 did not actually change the API so there should not be any changes required there, but for 6.12.39 it requires a pointer to the MPDU to make the correct determination.

lachlan

[aanon4]

@donnaskiez Does this mean we might be looking at the 2.10-dev release shortly with these patches?

[govindsi]

Hi,

We are looking at this internally. Unfortunately the changes in this patchset incorrectly parse the beacons and will lead to a failure during association.

#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 12, 0)
	return (u8 *)bcn->u.s1g_beacon.variable;
#else
	return ieee80211_is_s1g_short_beacon(bcn->frame_control)
           ? (u8 *)bcn->u.s1g_short_beacon.variable
           : (u8 *)bcn->u.s1g_beacon.variable;
#endif

The above does not take into account optional elements in S1G beacon that may precede the elements based on the flags set in the frame control. For more information on this please see the following patch, which was backported to 6.12.34. For this to be done right it should make use of ieee80211_s1g_optional_len and perform the following arithmetic to ensure the optional elements are processed accordingly.

variable = ext->u.s1g_beacon.variable + ieee80211_s1g_optional_len(ext->frame_control);

where variable then points to the true start of the elements.

Additionally, as @Mic92 pointed out - the inversion of the ieee80211_is_s1g_short_beacon does not seem right. Not only that but the API has been changed and backported once again (see patch). 6.12 did not actually change the API so there should not be any changes required there, but for 6.12.39 it requires a pointer to the MPDU to make the correct determination.

lachlan

@donnaskiez , thanks for review comments. Is there a release timeline when we can expect all compatibility fixes.

[Gateworks]

@donnaskiez,

for what its worth, I have a set of patches for 1.16 at https://github.com/Gateworks/morse_driver/tree/1.16.4-gateworks which are compatible to 6.18. Much of them are similar to yours but I did handle the changes to ieee80211_is_s1g_short_beacon differently due to just not being able to get an adaptation to the upstream changes to work and also to make it more kernel version agnostic due to the upstream patches being backported to 6.12.y and 6.15.y. I also have a different solution to the crc7_be_byte API going away as your solution is not endianness safe and failed for my le platform.

I'm told from MorseMicro that 6.18 support won't come until their 1.18 release but I have no idea what the timeline is on that (I assume not for a while as they are currently validated 1.17)

Tim