update rtw_regd_init for kernel v6.4.4

[5kft]

Kernel v6.4.4 backported the change from mainline v6.5 that removes REGULATORY_IGNORE_STALE_KICKOFF; this change updates rtw_regd_init in this driver accordingly.

[morrownr]

I'm sure glad you are keeping up with this. I'm neck deep in trying to get another Realtek driver available. It is the rtl8852bu.

[5kft]

Happy to contribute (even if they are microscopic changes like this) 👍 Thanks so much for creating and maintaining this driver repository...you've made Linux Wi-Fi on these adapters usable and stable, and it is hugely appreciated!

[morrownr]

@5kft

I have applied this patch to all of the drivers here. Today I got a report that is interesting. Here it is:

https://github.com/morrownr/88x2bu-20210702/issues/165

This makes me wonder if the backport was taken all the way back into the last LTS. That would not be cool unless there is a really good reason for it but that is all I can come up with to explain this.

@morrownr

[5kft]

Indeed, it appears that this change was taken all the way back to 6.1.39 (!). Odd indeed, but I guess someone had a reason for it. I only tested it back to 6.4...

[morrownr]

I'm going to do some testing here to see if we can find where this backport is and where it isn't. I can see this turning into a mess. Think about it. It would not have been backported to kernel 6.2 as it is not supported anymore... except kernel 6.2 is the kernel Ubuntu 23.04. That means it is in all of the other Buntu's. Will Ubuntu pick the backport up? Do they even know they need to do so.

This is not good at all. Tell me what you think?

[5kft]

Indeed, REGULATORY_IGNORE_STALE_KICKOFF is still present in 6.2.16, but it is not present in 6.3.13 (it is present in 6.3.12). One idea - what if we change the code to something like this:

  #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0)) && defined(REGULATORY_IGNORE_STALE_KICKOFF)
      wiphy->regulatory_flags |= REGULATORY_IGNORE_STALE_KICKOFF;
  #endif

I haven't tried this yet, but it seems like this should work. For drivers that have this statement present, if the kernel version defines the enum, then it will use it, and otherwise it won't (because it doesn't exist). Thoughts?

[morrownr]

I haven't tried this yet, but it seems like this should work. For drivers that have this statement present, if the kernel version defines the enum, then it will use it, and otherwise it won't (because it doesn't exist). Thoughts?

It will take something like this. We'll just have to test. It is a good place to start. I'll do some testing as I have some extra time this afternoon. Let me know what you find out.

On a separate subject: Do you mind telling me what country you live in? What I am thinking about doing is offering to send you a rtl8832bu based adapter so that as you have time, you can look the repo over and suggest improvements. I will probably turn the repo public soon but it will not have all of the info available in the docs as wifi 6 is a big addition to deal with.

[5kft]

Unfortunately this won't work as (not surprisingly) the preprocessor doesn't understand language constructs like enums...oh well...

One thought: Now for all longterm+stable non-EOL kernels >= v6.1 this mode has effectively been removed, which then changes regulatory behavior so that the core enforces interface wiphy operation only on allowed channels (i.e., this behavior can no longer be temporarily disabled). Given this behavior now, perhaps the cleanest solution to this version problem would be as simple as disabling this statement for kernel versions >= v6.1.39. (This would also address the potential Ubuntu kernel v6.2 upleveling situation.)

(Re: rtl8832bu - unfortunately it's unlikely I'd have any bandwidth to help with this any time soon, apologies...)