diff --git a/packages/linux/patches/3.16.3/linux-999.05-fix_ath9k_htc.patch b/packages/linux/patches/3.16.3/linux-999.05-fix_ath9k_htc.patch
new file mode 100644
index 0000000000..edaac73b35
--- /dev/null
+++ b/packages/linux/patches/3.16.3/linux-999.05-fix_ath9k_htc.patch
@@ -0,0 +1,35 @@
+see https://bugzilla.kernel.org/show_bug.cgi?id=78581
+
+I read a bit through the code and found one thing which explains
+both the issue and the random reproducibility behaviour in
+comment 14 and 16.  Currently I can't reboot to fully confirm,
+only did the speed test as in comment 16. (After overhight
+hibernate I'm back to the state as in comment 14.)
+
+This one change on top of v3.16 seems to fix it.
+
+Another thing caught my eye, it is unrelated to this bug but
+I'm reporting it here for my convenience ;-)
+In ath9k_cmn_rx_skb_postprocess():
+
+        hdrlen = ieee80211_get_hdrlen_from_skb(skb);
+        fc = hdr->frame_control;
+        padpos = ieee80211_hdrlen(fc);
+
+Now padpos == hdrlen, except ieee80211_get_hdrlen_from_skb()
+checks the skb->len and might fail.  This is confused.  If the
+skb->len check is needed, shouldn't it be done before calling
+ath9k_cmn_rx_accept()?
+
+diff -Naur linux-3.16.3/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c linux-3.16.3.patch/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+--- linux-3.16.3/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c	2014-09-17 19:22:16.000000000 +0200
++++ linux-3.16.3.patch/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c	2014-09-30 02:58:30.750915927 +0200
+@@ -978,7 +978,7 @@
+ 	struct ath_hw *ah = common->ah;
+ 	struct ath_htc_rx_status *rxstatus;
+ 	struct ath_rx_status rx_stats;
+-	bool decrypt_error;
++	bool decrypt_error = false;
+ 
+ 	if (skb->len < HTC_RX_FRAME_HEADER_SIZE) {
+ 		ath_err(common, "Corrupted RX frame, dropping (len: %d)\n",