Re: [ath9k-devel] BUG?

2010-12-20 Thread Mohammed Shafi
In the hostapd config file hostapd.conf can you please try with hw_mode=b and hw_mode=g Also can you please send your configuration file of hostapd. thanks, shafi On Tue, Dec 21, 2010 at 10:10 AM, Masahiro Inoue wrote: > Mr. Mohammed > > Thank you for the reply. > > I'm sorry. > It had been forgo

Re: [ath9k-devel] smatch stuff: potential read past the end of the buffer

2010-12-20 Thread Vasanthakumar Thiagarajan
On Mon, Dec 20, 2010 at 02:00:41PM +0530, Dan Carpenter wrote: > Hello Vasanthakumar, > > Smatch complains that in linux-next 60e0c3a7 "ath9k_hw: Eeeprom changes > for AR9485" means there is a potential read past the end of the buffer > int ar9300_eeprom_restore_internal(). > > drivers/net/wirele

Re: [ath9k-devel] BUG?

2010-12-20 Thread Masahiro Inoue
Mr. Mohammed Thank you for the reply. I'm sorry. It had been forgotten to apply ath9k-devel@lists.ath9k.org to cc in mail last time. It examined it. compat-wireless-2010-02-15 - OK compat-wireless-2010-02-20 - NG The recent correction only added rateidx by the ath_beacon_setup function of beac

[ath9k-devel] [patch -next] ath9k: unlock on error path in ath9k_change_interface()

2010-12-20 Thread Dan Carpenter
There is a missing unlock when we hit the "No beacon slot available" error condition. Signed-off-by: Dan Carpenter diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c index cb53fbb..0ffa115 100644 --- a/drivers/net/wireless/ath/ath9k/main.c +++ b/drivers/n

Re: [ath9k-devel] ar9223 with caldata on flash (no eeprom) under openwrt

2010-12-20 Thread Luca Olivetti
En/na Adrian Chadd ha escrit: > I think a large part of the problem here is that the focus of the > active technical developers is elsewhere. Where? > You should see what trouble > I've had getting questions answered here for the pre-AR9200 stuff. :-) > > Eg, trying to figure out the above - I h

Re: [ath9k-devel] smatch stuff: potential read past the end of the buffer

2010-12-20 Thread Arend Van Spriel
Hi Dan, Agreed. But maybe there is no usage scenario in which the boundary is actually crossed. Have to wait for ath9k developers to answer that. Gr. AvS From: Dan Carpenter [erro...@gmail.com] Sent: Monday, December 20, 2010 1:42 PM To: Arend Van Spriel

Re: [ath9k-devel] smatch stuff: potential read past the end of the buffer

2010-12-20 Thread Dan Carpenter
On Mon, Dec 20, 2010 at 02:16:56AM -0800, Arend Van Spriel wrote: > Hi Dan, > > Why not use min() function? > index = min(COMP_HDR_LEN + osize, 2046); > mchecksum = word[index] | > (word[index + 1] << 8); > > Or would smatch miss this in its analysis? That would silen

Re: [ath9k-devel] smatch stuff: potential read past the end of the buffer

2010-12-20 Thread Arend Van Spriel
Hi Dan, Why not use min() function? index = min(COMP_HDR_LEN + osize, 2046); mchecksum = word[index] | (word[index + 1] << 8); Or would smatch miss this in its analysis? Gr. AvS From: linux-wireless-ow...@vger.kernel.org [linu

Re: [ath9k-devel] smatch stuff: potential read past the end of the buffer

2010-12-20 Thread Senthil Balasubramanian
On Mon, Dec 20, 2010 at 02:00:41PM +0530, Dan Carpenter wrote: > Hello Vasanthakumar, > > Smatch complains that in linux-next 60e0c3a7 "ath9k_hw: Eeeprom changes > for AR9485" means there is a potential read past the end of the buffer > int ar9300_eeprom_restore_internal(). > > drivers/net/wirele

[ath9k-devel] smatch stuff: potential read past the end of the buffer

2010-12-20 Thread Dan Carpenter
Hello Vasanthakumar, Smatch complains that in linux-next 60e0c3a7 "ath9k_hw: Eeeprom changes for AR9485" means there is a potential read past the end of the buffer int ar9300_eeprom_restore_internal(). drivers/net/wireless/ath/ath9k/ar9003_eeprom.c +3381 ar9300_eeprom_restore_internal(81)