Hi Kuba! > On Wed, 1 May 2013 17:17:29 +0200, Gabor Juhos wrote: >> The TX data queue is initialized already when >> the rt2x00lib_probe_hw() function is called. >> >> Fetch the number of the queue entries from that >> instead of using the entry_num field of the data >> queue descriptor. >> >> The two values are the same, and the use of the >> rt2x00dev->tx->limit value allows us to get rid >> of a superfluous pointer dereference. >> >> Signed-off-by: Gabor Juhos <juhosg@xxxxxxxxxxx> >> --- >> drivers/net/wireless/rt2x00/rt2x00dev.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c >> index 90dc143..b287467 100644 >> --- a/drivers/net/wireless/rt2x00/rt2x00dev.c >> +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c >> @@ -1077,7 +1077,7 @@ static int rt2x00lib_probe_hw(struct rt2x00_dev *rt2x00dev) >> */ >> int kfifo_size = >> roundup_pow_of_two(rt2x00dev->ops->tx_queues * >> - rt2x00dev->ops->tx->entry_num * >> + rt2x00dev->tx->limit * >> sizeof(u32)); >> >> status = kfifo_alloc(&rt2x00dev->txstatus_fifo, kfifo_size, > > Unfortunately this does not work without your "get rid of > static data queue descriptors" series as well. > > queue->limit is set when rt2x00lib_start is called, not on > probe. kfifo_alloc will fail with EINVAL here. You are right. I should have been more careful while I have tested this patch-set. > As a result support for all rt2x00 devices is broken on wireless-testing. Only rt2800 devices are affected. The offending code runs only if REQUIRE_TXSTATUS_FIFO is set in rt2x00dev->cap_flags which is not set for older chips. > Maybe you can just post the mentioned series for inclusion? I will post a fix for the actual problem first, and will rebase the series on top of that. > I have been running with it since you posted it as RFC and > I did not notice any problems so far... Great! -Gabor -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
