For several years this note stood unchanged. It is hard to believe that
it still matters. With the inclusion of the driver to the Kernel it
became very unlikely that there will be a new version.
As usual, some code changes guarded by a preprocessor `if` were added.
Additionally, the Makefile had to be modified to replace all instances
of EXTRA_CFLAG with ccflags-y. Unlike usual, this change may affect the
building of the most recent version on an older kernel. However, initial
testing suggests that everything still works.
With both fixes the driver was able to run `apt full-upgrade` and to
push the result of the merge.
Linux Kernel commit e966ad0edd0056c7491b8f23992c11734ab61ddf removed
support for EXTRA_*FLAGS, including EXTRA_CFLAGS. It advertises to use
ccflags-y. THis commit blindly replaced all usages of EXTRA_CFLAGS with
ccflags-y.
With these changes, test builds were successful for Kernel v6.11 to
v6.14.
In Linux Kernel commit 8fa7292fee5c5240402371ea89ab285ec856c916 Thomas
Gleixner replaces all usages of del_timer_sync to be timer_delete_sync.
This has to be followed here.
The deploy.sh script now allows to install the driver for either
* all available kernels,
* a specific kernel, or
* the currently active kernel
In order to do so it got a small CLI that even prints a help text on
`--help`.
If, for whatever reason, this Kernel module is installed freshly, the
existing deploy script would not install the module for all available
Kernels. If a user would boot into another Kernel (e.g. 6.12.21-amd64
instead of 6.12.22-amd64) Wi-Fi would not be available. This can be
confusing and annoying.
The changes of this commit would prune the module from DKMS and then
install it for all available Kernels. This is much more convenient.
In Linux Kernel commit 7a53af85d3bbdbe06cd47b81a6d99a04dc0a3963 a new
argument is introduced to cfg80211_rtw_get_txpower. It seems to be only
introduced but unused. Therefore, this argument is added here too.
In Linux Kernel commit 9c4f83092775 a new argument is introduced to
cfg80211_rtw_set_monitor_channel. It seems to be only introduced but
unused. Therefore, this argument is added here too.
In Linux Kernel commit b82730bf57b54803ab94abbfd8c4422a7081886d the last
parameter was removed from two function signatures. Hence, it must not
be passed by the driver too. Fortunately these were plain `0` anyways.
GCC 13 complains about this. The committer does not have got enough
expertise to know how to fix that. Even the in the Linux kernel itself
there are no fixes that fit our case.
Therefore, the error gets suppressed.
GCC 13 complained about the usage of an enum in a boolean context. On
closer investigation it turned out that the value wasn't dynamic and the
if-guard always evaluated to true. By removing the guard the compile
blocker disappears.
With commit 0fcb70851fbfea1776ae62f67c503fef8f0292b9 in Linux Kernel
two new sanity checks were enabled. These cause build failures, because
somehow there are functions in *.c files that are not declared in *.h
files. (At least, that is my understanding.)
Unfortunately, it is very time consuming task to manually delete all
these functions. Also, it is not yet clear whether this indeed will
resolve the issue or just fail at some point.
In order to be able to follow the Kernel's development, these warnings
are just disabled. This allows to work against the most recent commits
when trying to remove problematic functions.
In Linux Kernel commit bb55441c57ccc5cc2eab44e1a97698b9d708871d a struct
is split. In our scenario, it is sufficient to follow the renames that
can be found as adaptions in the named commit as well.
Commit 66f85d57b7109baf8a7d5ee04049ac9412611d35 of the Linux Kernel
changed the type of one argument from cfg80211_beacon_data to
cfg80211_ap_settings. Inside the changed functions the beacon is
assigned to a local variable, so that subsequent usages do not have to
be adapted.
This commit follows the example. The type of the function argument is
changed and the beacon extracted.
Previously, a plain `>` redirect was used. However, that does not work
if the user cannot write to the destination. Since a redirect is a
separate process, prepending `sudo` does not help neither, as it would
only affect `echo`.
The appropriate solution under GNU/Linux is to use `tee`. This is what
is done here.
