iwlwifi: adjust to make d3.c compile

[bz]

Summary

struct iwl_mvm_wep_key_cmd ends in a variable sized array but later
is included in another struct followed by the actual
struct iwl_mvm_wep_key in d3.c. Make the array[0] instead of []
to avoid the warning about it being a GNU-extension.
Also include string.h explicitly for memset_after().

MFC after: 3 days

iwlwifi: add the d3 (PM) bits to the Makefile (disabled)

Add the logic to conditionally enable PM for iwlwifi.
This should help suspend/resume in the future.
For now leave it disabled until other preconditional problems are
sorted.

Sponsored by: The FreeBSD Foundation (2023)
MFC after: 3 days

[cc]

I see two "MFC after" in the summary section, and the summary section seems to contain two parts that it looks you are going to split this patch into two when you MFC it. Am I understanding correctly? Are you going to manually MFC the two parts?

sys/modules/iwlwifi/Makefile

43 ↗

(On Diff #133495)

typo: "CFGLAS" ==> "CFLAGS"

[bz]

Fix CFLAGS spelling

[bz]

In D43647#995353, @cc wrote:

I see two "MFC after" in the summary section, and the summary section seems to contain two parts that it looks you are going to split this patch into two when you MFC it. Am I understanding correctly? Are you going to manually MFC the two parts?

It's acutally two commits. One for the driver and one for the Makefile. Sorry, should have annotated the description given arc just combines them.

sys/modules/iwlwifi/Makefile

43 ↗

(On Diff #133495)

Good catch!

[emaste]

sys/contrib/dev/iwlwifi/fw/api/sta.h

483

Do you know if there's any appetite for this sort of change upstream? Or maybe they are fully invested in GCC extensions.

[bz]

sys/contrib/dev/iwlwifi/fw/api/sta.h

483

I cannot remember which way round they went in the entire Linux Kernel as a semi-policy a year or two ago; there was a lot of [0] -> [] churn I think (or the other way round).

I figured after the next update cycle I should go and check how many of the local changes we can (a) ditch (#includes maybe etc), and (b) what we can (try to) push upstream again.

[cc]

sys/contrib/dev/iwlwifi/fw/api/sta.h

483

I cannot remember which way round they went in the entire Linux Kernel as a semi-policy a year or two ago; there was a lot of [0] -> [] churn I think (or the other way round).

I figured after the next update cycle I should go and check how many of the local changes we can (a) ditch (#includes maybe etc), and (b) what we can (try to) push upstream again.

If the Linux kernel follows newer C standards (C99), I am not sure if we shall upstream this. Here is a discussion about "a flexible array".
it was standardized in C99