diff for duplicates of <4B895602.6010801@bfs.de> diff --git a/a/1.txt b/N1/1.txt index 36ec57b..624bcbf 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -28,7 +28,8 @@ Benoit PAPILLAULT schrieb: >> > Note: normal hardware always report a tx_status->retry >= 1. There are 2 > code paths to initialize retry itself : either tx_status is NULL and -> then retry=1 (so we are safe), or tx_status is not NULL and retry > tx_status->retry + success >=1 (so we are safe again). +> then retry=1 (so we are safe), or tx_status is not NULL and retry = +> tx_status->retry + success >=1 (so we are safe again). > > However, I wonder how we should handle if it happens that the HW reports > a tx_status->retry = 0. I think ZD_ASSERT purpose is to catch @@ -49,7 +50,7 @@ just my 2 cents, >> info->status.rates[0].count = 1; // (retry > 1 ? 2 : 1); >> @@ -360,7 +360,7 @@ static void zd_mac_tx_status(struct ieee80211_hw >> *hw, struct sk_buff *skb, ->> info->status.rates[i].count = 1; // ((i=retry-1) && success +>> info->status.rates[i].count = 1; // ((i==retry-1) && success >> ? 1:2); >> } >> for (; i<IEEE80211_TX_MAX_RATES && i<retry; i++) { @@ -86,8 +87,4 @@ just my 2 cents, > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -> --- -To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html +> diff --git a/a/content_digest b/N1/content_digest index 5fbc360..c68d862 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,7 +2,7 @@ "ref\04B892A2F.2040307@free.fr\0" "From\0walter harms <wharms@bfs.de>\0" "Subject\0Re: [patch] zd1211rw: fix potential array underflow\0" - "Date\0Sat, 27 Feb 2010 17:27:30 +0000\0" + "Date\0Sat, 27 Feb 2010 18:27:30 +0100\0" "To\0Benoit PAPILLAULT <benoit.papillault@free.fr>\0" "Cc\0Dan Carpenter <error27@gmail.com>" Daniel Drake <dsd@gentoo.org> @@ -47,7 +47,8 @@ ">> \n" "> Note: normal hardware always report a tx_status->retry >= 1. There are 2\n" "> code paths to initialize retry itself : either tx_status is NULL and\n" - "> then retry=1 (so we are safe), or tx_status is not NULL and retry > tx_status->retry + success >=1 (so we are safe again).\n" + "> then retry=1 (so we are safe), or tx_status is not NULL and retry =\n" + "> tx_status->retry + success >=1 (so we are safe again).\n" "> \n" "> However, I wonder how we should handle if it happens that the HW reports\n" "> a tx_status->retry = 0. I think ZD_ASSERT purpose is to catch\n" @@ -68,7 +69,7 @@ ">> info->status.rates[0].count = 1; // (retry > 1 ? 2 : 1);\n" ">> @@ -360,7 +360,7 @@ static void zd_mac_tx_status(struct ieee80211_hw\n" ">> *hw, struct sk_buff *skb,\n" - ">> info->status.rates[i].count = 1; // ((i=retry-1) && success\n" + ">> info->status.rates[i].count = 1; // ((i==retry-1) && success\n" ">> ? 1:2);\n" ">> }\n" ">> for (; i<IEEE80211_TX_MAX_RATES && i<retry; i++) {\n" @@ -105,10 +106,6 @@ "> the body of a message to majordomo@vger.kernel.org\n" "> More majordomo info at http://vger.kernel.org/majordomo-info.html\n" "> \n" - "> \n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe kernel-janitors\" in\n" - "the body of a message to majordomo@vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + > -e23bfad56402abff6316a0785d0b999187218625703151968fb73929bfe3372c +6dbfa4a0f98f15777af4e7e260438a429b63cb8ce515962d577248dd204a426a
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.