Re: [ath5k-devel] [PATCH v2 1/7] ath5k: optimize tx descriptor setup

2011-04-12 Thread Sedat Dilek
On Wed, Apr 13, 2011 at 12:07 AM, Felix Fietkau wrote: > Use local variables to reduce the number of load/store operations on uncached > memory. > > Signed-off-by: Felix Fietkau > --- >  drivers/net/wireless/ath/ath5k/desc.c |   45 > +++-- >  1 files changed, 26 inser

Re: [ath5k-devel] [PATCH 5/7] ath5k: remove ts_retry from ath5k_tx_status

2011-04-12 Thread Felix Fietkau
On 2011-04-12 9:04 AM, 海藻敬之 wrote: > Hi, > > Isn't there any chance in which info->status.rates[x].count has >different retry-count value from the one which the firmware actually did. > >For example, driver requests invalid value of retry count and firmware > rejects it (take other value).

[ath5k-devel] [PATCH v2 1/7] ath5k: optimize tx descriptor setup

2011-04-12 Thread Felix Fietkau
Use local variables to reduce the number of load/store operations on uncached memory. Signed-off-by: Felix Fietkau --- drivers/net/wireless/ath/ath5k/desc.c | 45 +++-- 1 files changed, 26 insertions(+), 19 deletions(-) diff --git a/drivers/net/wireless/ath/ath5k/d

[ath5k-devel] [PATCH v2 1/7] ath5k: optimize tx descriptor setup

2011-04-12 Thread Felix Fietkau
Use local variables to reduce the number of load/store operations on uncached memory. Signed-off-by: Felix Fietkau --- drivers/net/wireless/ath/ath5k/desc.c | 45 +++-- 1 files changed, 26 insertions(+), 19 deletions(-) diff --git a/drivers/net/wireless/ath/ath5k/d

Re: [ath5k-devel] [PATCH 1/7] ath5k: optimize tx descriptor setup

2011-04-12 Thread Felix Fietkau
On 2011-04-11 8:29 AM, Kalle Valo wrote: > Felix Fietkau writes: > >> Use local variables to reduce the number of load/store operations on >> uncached >> memory. > > A comment in the code would be nice as well. Otherwise later on > someone decides to "optimise" and remove the local variables :)

Re: [ath5k-devel] [PATCH 5/7] ath5k: remove ts_retry from ath5k_tx_status

2011-04-12 Thread 海藻敬之
Hi, Isn't there any chance in which info->status.rates[x].count has different retry-count value from the one which the firmware actually did. For example, driver requests invalid value of retry count and firmware rejects it (take other value). no such chance ? Thanks Takayuki Kaiso > Re