diff for duplicates of <87r2ia28ii.fsf@toke.dk>

diff --git a/a/1.txt b/N1/1.txt
index 7c16348..21a7ace 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,98 +1,96 @@
 Anilkumar Kolli <akolli@codeaurora.org> writes:
 
-> On 2018-08-31 19:52, Toke Høiland-Jørgensen wrote:
+> On 2018-08-31 19:52, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
 >> Kalle Valo <kvalo@codeaurora.org> writes:
->> 
+>>=20
 >>> Anilkumar Kolli <akolli@codeaurora.org> writes:
->>> 
+>>>=20
 >>>> Mesh path metric needs txrate information from ieee80211_tx_status()
->>>> call but in ath10k there is no mechanism to report tx rate 
+>>>> call but in ath10k there is no mechanism to report tx rate=20
 >>>> information
 >>>> via ieee80211_tx_status(), the rate is only accessible via
 >>>> sta_statiscs() op.
->>>> 
+>>>>=20
 >>>> Per peer stats has tx rate info available, this patch stores per peer
->>>> last tx rate and updates the tx rate info structures in tx 
+>>>> last tx rate and updates the tx rate info structures in tx=20
 >>>> completition.
 >>>> The rate updated in ieee80211_tx_status() is not exactly for the last
->>>> transmitted frame instead the rate is from one of the previous 
+>>>> transmitted frame instead the rate is from one of the previous=20
 >>>> frames.
->>>> 
+>>>>=20
 >>>> Per peer txrate information is updated through per peer statistics
 >>>> and is available for QCA9888/QCA9984/QCA4019/QCA998X only
->>>> 
+>>>>=20
 >>>> Tested on QCA9984 with firmware-5.bin_10.4-3.5.3-00053
 >>>> Tested on QCA998X with firmware-5.bin_10.2.4-1.0-00036
->>>> 
+>>>>=20
 >>>> Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
->>> 
+>>>=20
 >>> This is a patch from last March, full patch here:
->>> 
+>>>=20
 >>> https://patchwork.kernel.org/patch/10267693/
->>> 
+>>>=20
 >>>> @@ -119,6 +122,18 @@ int ath10k_txrx_tx_unref(struct ath10k_htt *htt,
->>>>  			info->flags &= ~IEEE80211_TX_STAT_ACK;
+>>>>  			info->flags &=3D ~IEEE80211_TX_STAT_ACK;
 >>>>  	}
->>>> 
+>>>>=20
 >>>> +	if (sta) {
 >>>> +		spin_lock_bh(&ar->data_lock);
->>>> +		arsta = (struct ath10k_sta *)sta->drv_priv;
->>>> +		info->status.rates[0].idx =
+>>>> +		arsta =3D (struct ath10k_sta *)sta->drv_priv;
+>>>> +		info->status.rates[0].idx =3D
 >>>> +			arsta->tx_info.status.rates[0].idx;
->>>> +		info->status.rates[0].count =
+>>>> +		info->status.rates[0].count =3D
 >>>> +			arsta->tx_info.status.rates[0].count;
->>>> +		info->status.rates[0].flags =
+>>>> +		info->status.rates[0].flags =3D
 >>> <> +			arsta->tx_info.status.rates[0].flags;
 >>>> +		spin_unlock_bh(&ar->data_lock);
 >>>> +	}
 >>>> +
 >>>>  	ieee80211_tx_status(htt->ar->hw, msdu);
 >>>>  	/* we do not own the msdu anymore */
->>> 
->>> "is not exactly" is IMHO an understatement. What it means that with 
+>>>=20
+>>> "is not exactly" is IMHO an understatement. What it means that with=20
 >>> this
->>> patch ath10k reports the rate information from another frame instead 
+>>> patch ath10k reports the rate information from another frame instead=20
 >>> of
->>> the current skb, because the firmware provides the rate information 
+>>> the current skb, because the firmware provides the rate information=20
 >>> "out
 >>> of band". A simple example to clarify:
->>> 
+>>>=20
 >>>    Let's say ath10k transmits frames A, B and C. Then ath10k calls
 >>>    ieee80211_tx_status() for frame C the rate information could be for
->>>    frame A, or it could be the other around for frame A status the 
+>>>    frame A, or it could be the other around for frame A status the=20
 >>> rate
 >>>    information is from frame C.
->>> 
+>>>=20
 >>> In other words, there's no guarantee from what frame the rate
 >>> information is from.
->>> 
+>>>=20
 >>> Too me this feels like a bad idea but I'm not familiar enough with
->>> mac80211 to really comment on this. What kind of implications does 
+>>> mac80211 to really comment on this. What kind of implications does=20
 >>> this
 >>> have for Mesh or ATF, for example? Adding Johannes and Toke to hear
 >>> about their opinion about this.
->> 
+>>=20
 >> I was under the impression that the values gathered (at least for
 >> airtime) would be cumulative values? If it's just the airtime of a
 >> single random frame, which is what I understand from your example, it's
 >> not going to be terribly useful to provide ATF at least...
->> 
+>>=20
 >> -Toke
 >
 > The design:
-> Whenever radio transmits packet, firmware will record numbers of bytes 
-> sent, MSDU’s sent, TX duration, AMPDU information, ACK fail, BA fail, 
-> Rate at which packet is sent. This is recorded for 4 frames sent on that 
-> peer. Once 4 frames are sent for that peer, TX packet event is sent to 
-> ath10k driver with the recorded values. These rate values are updated to 
+> Whenever radio transmits packet, firmware will record numbers of bytes=20
+> sent, MSDU=E2=80=99s sent, TX duration, AMPDU information, ACK fail, BA f=
+ail,=20
+> Rate at which packet is sent. This is recorded for 4 frames sent on that=
+=20
+> peer. Once 4 frames are sent for that peer, TX packet event is sent to=20
+> ath10k driver with the recorded values. These rate values are updated to=
+=20
 > mac80211 using ieee80211_tx_status().
 
 So the values reported are the sums for all four packets? But the latest
 value for rate information?
 
 -Toke
-
-_______________________________________________
-ath10k mailing list
-ath10k@lists.infradead.org
-http://lists.infradead.org/mailman/listinfo/ath10k
diff --git a/a/content_digest b/N1/content_digest
index c33c23c..d79a56c 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -6,109 +6,107 @@
  "Subject\0Re: [RFC v2] ath10k: report tx rate using ieee80211_tx_status()\0"
  "Date\0Mon, 03 Sep 2018 12:13:57 +0200\0"
  "To\0Anilkumar Kolli <akolli@codeaurora.org>\0"
- "Cc\0Johannes Berg <johannes@sipsolutions.net>"
-  linux-wireless@vger.kernel.org
+ "Cc\0Kalle Valo <kvalo@codeaurora.org>"
   ath10k@lists.infradead.org
- " Kalle Valo <kvalo@codeaurora.org>\0"
+  linux-wireless@vger.kernel.org
+ " Johannes Berg <johannes@sipsolutions.net>\0"
  "\00:1\0"
  "b\0"
  "Anilkumar Kolli <akolli@codeaurora.org> writes:\n"
  "\n"
- "> On 2018-08-31 19:52, Toke H\303\270iland-J\303\270rgensen wrote:\n"
+ "> On 2018-08-31 19:52, Toke H=C3=B8iland-J=C3=B8rgensen wrote:\n"
  ">> Kalle Valo <kvalo@codeaurora.org> writes:\n"
- ">> \n"
+ ">>=20\n"
  ">>> Anilkumar Kolli <akolli@codeaurora.org> writes:\n"
- ">>> \n"
+ ">>>=20\n"
  ">>>> Mesh path metric needs txrate information from ieee80211_tx_status()\n"
- ">>>> call but in ath10k there is no mechanism to report tx rate \n"
+ ">>>> call but in ath10k there is no mechanism to report tx rate=20\n"
  ">>>> information\n"
  ">>>> via ieee80211_tx_status(), the rate is only accessible via\n"
  ">>>> sta_statiscs() op.\n"
- ">>>> \n"
+ ">>>>=20\n"
  ">>>> Per peer stats has tx rate info available, this patch stores per peer\n"
- ">>>> last tx rate and updates the tx rate info structures in tx \n"
+ ">>>> last tx rate and updates the tx rate info structures in tx=20\n"
  ">>>> completition.\n"
  ">>>> The rate updated in ieee80211_tx_status() is not exactly for the last\n"
- ">>>> transmitted frame instead the rate is from one of the previous \n"
+ ">>>> transmitted frame instead the rate is from one of the previous=20\n"
  ">>>> frames.\n"
- ">>>> \n"
+ ">>>>=20\n"
  ">>>> Per peer txrate information is updated through per peer statistics\n"
  ">>>> and is available for QCA9888/QCA9984/QCA4019/QCA998X only\n"
- ">>>> \n"
+ ">>>>=20\n"
  ">>>> Tested on QCA9984 with firmware-5.bin_10.4-3.5.3-00053\n"
  ">>>> Tested on QCA998X with firmware-5.bin_10.2.4-1.0-00036\n"
- ">>>> \n"
+ ">>>>=20\n"
  ">>>> Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>\n"
- ">>> \n"
+ ">>>=20\n"
  ">>> This is a patch from last March, full patch here:\n"
- ">>> \n"
+ ">>>=20\n"
  ">>> https://patchwork.kernel.org/patch/10267693/\n"
- ">>> \n"
+ ">>>=20\n"
  ">>>> @@ -119,6 +122,18 @@ int ath10k_txrx_tx_unref(struct ath10k_htt *htt,\n"
- ">>>>  \t\t\tinfo->flags &= ~IEEE80211_TX_STAT_ACK;\n"
+ ">>>>  \t\t\tinfo->flags &=3D ~IEEE80211_TX_STAT_ACK;\n"
  ">>>>  \t}\n"
- ">>>> \n"
+ ">>>>=20\n"
  ">>>> +\tif (sta) {\n"
  ">>>> +\t\tspin_lock_bh(&ar->data_lock);\n"
- ">>>> +\t\tarsta = (struct ath10k_sta *)sta->drv_priv;\n"
- ">>>> +\t\tinfo->status.rates[0].idx =\n"
+ ">>>> +\t\tarsta =3D (struct ath10k_sta *)sta->drv_priv;\n"
+ ">>>> +\t\tinfo->status.rates[0].idx =3D\n"
  ">>>> +\t\t\tarsta->tx_info.status.rates[0].idx;\n"
- ">>>> +\t\tinfo->status.rates[0].count =\n"
+ ">>>> +\t\tinfo->status.rates[0].count =3D\n"
  ">>>> +\t\t\tarsta->tx_info.status.rates[0].count;\n"
- ">>>> +\t\tinfo->status.rates[0].flags =\n"
+ ">>>> +\t\tinfo->status.rates[0].flags =3D\n"
  ">>> <> +\t\t\tarsta->tx_info.status.rates[0].flags;\n"
  ">>>> +\t\tspin_unlock_bh(&ar->data_lock);\n"
  ">>>> +\t}\n"
  ">>>> +\n"
  ">>>>  \tieee80211_tx_status(htt->ar->hw, msdu);\n"
  ">>>>  \t/* we do not own the msdu anymore */\n"
- ">>> \n"
- ">>> \"is not exactly\" is IMHO an understatement. What it means that with \n"
+ ">>>=20\n"
+ ">>> \"is not exactly\" is IMHO an understatement. What it means that with=20\n"
  ">>> this\n"
- ">>> patch ath10k reports the rate information from another frame instead \n"
+ ">>> patch ath10k reports the rate information from another frame instead=20\n"
  ">>> of\n"
- ">>> the current skb, because the firmware provides the rate information \n"
+ ">>> the current skb, because the firmware provides the rate information=20\n"
  ">>> \"out\n"
  ">>> of band\". A simple example to clarify:\n"
- ">>> \n"
+ ">>>=20\n"
  ">>>    Let's say ath10k transmits frames A, B and C. Then ath10k calls\n"
  ">>>    ieee80211_tx_status() for frame C the rate information could be for\n"
- ">>>    frame A, or it could be the other around for frame A status the \n"
+ ">>>    frame A, or it could be the other around for frame A status the=20\n"
  ">>> rate\n"
  ">>>    information is from frame C.\n"
- ">>> \n"
+ ">>>=20\n"
  ">>> In other words, there's no guarantee from what frame the rate\n"
  ">>> information is from.\n"
- ">>> \n"
+ ">>>=20\n"
  ">>> Too me this feels like a bad idea but I'm not familiar enough with\n"
- ">>> mac80211 to really comment on this. What kind of implications does \n"
+ ">>> mac80211 to really comment on this. What kind of implications does=20\n"
  ">>> this\n"
  ">>> have for Mesh or ATF, for example? Adding Johannes and Toke to hear\n"
  ">>> about their opinion about this.\n"
- ">> \n"
+ ">>=20\n"
  ">> I was under the impression that the values gathered (at least for\n"
  ">> airtime) would be cumulative values? If it's just the airtime of a\n"
  ">> single random frame, which is what I understand from your example, it's\n"
  ">> not going to be terribly useful to provide ATF at least...\n"
- ">> \n"
+ ">>=20\n"
  ">> -Toke\n"
  ">\n"
  "> The design:\n"
- "> Whenever radio transmits packet, firmware will record numbers of bytes \n"
- "> sent, MSDU\342\200\231s sent, TX duration, AMPDU information, ACK fail, BA fail, \n"
- "> Rate at which packet is sent. This is recorded for 4 frames sent on that \n"
- "> peer. Once 4 frames are sent for that peer, TX packet event is sent to \n"
- "> ath10k driver with the recorded values. These rate values are updated to \n"
+ "> Whenever radio transmits packet, firmware will record numbers of bytes=20\n"
+ "> sent, MSDU=E2=80=99s sent, TX duration, AMPDU information, ACK fail, BA f=\n"
+ "ail,=20\n"
+ "> Rate at which packet is sent. This is recorded for 4 frames sent on that=\n"
+ "=20\n"
+ "> peer. Once 4 frames are sent for that peer, TX packet event is sent to=20\n"
+ "> ath10k driver with the recorded values. These rate values are updated to=\n"
+ "=20\n"
  "> mac80211 using ieee80211_tx_status().\n"
  "\n"
  "So the values reported are the sums for all four packets? But the latest\n"
  "value for rate information?\n"
  "\n"
- "-Toke\n"
- "\n"
- "_______________________________________________\n"
- "ath10k mailing list\n"
- "ath10k@lists.infradead.org\n"
- http://lists.infradead.org/mailman/listinfo/ath10k
+ -Toke
 
-aedfe90bb1732c385ea29d62b5a6b7faef3eb7dd8e5399b052defe7e4fd60cfa
+50c25c52e422fe75b9072e4cf79cf8657477b7912345700ac3e8450ec138320c
