iwlwifi: "Unandled alg" should be squelched or improved

[Tobias Klausmann <klausman@schwarzvogel.de>]

Hi,

at the moment, there are two places in the iwlwifi driver that produce
"Unhandled alg" messages:

drivers/net/wireless/intel/iwlwifi/mvm/rx.c:

static u32 iwl_mvm_set_mac80211_rx_flag(struct iwl_mvm *mvm, ...) {
      [...]
      switch (rx_pkt_status & RX_MPDU_RES_STATUS_SEC_ENC_MSK) {
	  [...]
      default:
          /* Expected in monitor (not having the keys) */
          if (!mvm->monitor_on)
              IWL_WARN(mvm, "Unhandled alg: 0x%x\n", rx_pkt_status);
      }

	  return 0;
}

and drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:

static int iwl_mvm_rx_crypto(struct iwl_mvm *mvm,...) {
      [...]
      switch (status & IWL_RX_MPDU_STATUS_SEC_MASK) {
      [...]
      default:
          /*
           * Sometimes we can get frames that were not decrypted
           * because the firmware didn't have the keys yet. This can
           * happen after connection where we can get multicast frames
           * before the GTK is installed.
           * Silently drop those frames.
           * Also drop un-decrypted frames in monitor mode.
           */
          if (!is_multicast_ether_addr(hdr->addr1) &&
              !mvm->monitor_on && net_ratelimit())
              IWL_WARN(mvm, "Unhandled alg: 0x%x\n", status);
      }

      return 0;
}

This results in message in kmsg like:

[   16.972247] iwlwifi 0000:01:00.0: Unhandled alg: 0x4000707

These messgaes are not really actionable (they don't even log what the
origin for the packets is), and even for competent sysadmins, are at
best opaque as to what is going on.

As a result, there are various "fixes" mentioned on the web that do
stuff like adding swcrypto=0 to the module options, which seems
ill-advised to me.

So I think that they should not be emitted by default. I tried switching
them ot IWL_INFO (hoping that at INFO level, nothing is logged by
default), but alas, that makes no real difference in the default setup.

I would have sent along a patch that just drops them, but they're both
sitting in default branches of switch statements, and it feels vaguely
wrong to have empty or nonexistent default sections, so I am unsure what
the right thing to do here would be. Plus, the second file has an
explanatory comment that would have nowhere to go.

Best,
Tobias

PS: I am not subscribed to linux-wireless@, so pleas CC me on replies
there. Thanks!

-- 
Sent from aboard the Culture ship
	GCU Sacrificial Victim