On 02/24/2013 12:38 PM, Hauke Mehrtens wrote: > On 02/24/2013 11:21 AM, Arend Van Spriel wrote: >> On Sunday, February 24, 2013 2:05 AM, Hauke Mehrtens wrote: >>> This patch series contains some cleanup patches for brcmsmac and then >>> adds beacon and probe response template upload. >>> With these features AP mode support is added in the last patch. >> >> Someone was bound to start on this and we are lately too focussed on >> brcmfmac. We will review the patches and found out whether our test >> framework can cover AP mode. > > Yes this needs some review and more testing, I hope this also works with > power saving stations and so on. > >>> When running AP mode in 5GHz band on my BCM43224 I get the following >>> errors, and I do not see the network with my Intel IWL6300, the >>> regulation restrictions in channel.c where changed before: >> >> 5GHz is a bit tricky. I will need to find out whether AP mode can work with >> the current ucode. > > Currently brcmsmac completely denies beaconing on 5GHz in channel.c, how > could that be changed and still compatible with the interpretation of > the regulation rules by your lawyers? > >>> [ 829.608000] brcmsmac bcma1:0: wl0: wlc_suspend_mac_and_wait: >>> waited 83000 uS and MI_MACSSPNDD is still not on. >>> [ 829.616000] brcmsmac bcma1:0: wl0: psmdebug 0x00ff808d, phydebug >>> 0x0000000d, psm_brc 0x0000 >> >> It generally indicates a hang in the ucode. Are you using the firmware from >> the linux-firmware repository? > > Instead of these error messages I also got a complete system hang when > compiling a kernel without lock debugging, the difference between this > result with lock debugging and the hang without lock debugging is > probably resulted from different timings. > > I used the ucode extracted from the proprietary driver, because only > this ucode works with my BCM4716, this is ucode 666.2 from driver > 5.100.138. I will try the ucode from linux-firmware today. I just tried the firmware version 610.812 from linux-firmware and there I do not get an error message or hang when starting the AP in 5GHz mode, but my iwl6300 card is unable to find this network. >>> The probe responses are currently send by the ucode based on the >>> template and by mac80211. I was searching for a switch so disable probe >>> request forwarding from the ucode to the driver. >> >> I am pretty sure there is. I will look into this and let you know. > > That would be nice. > >>> The structure of brcmsmac is pretty complicated, because it copies many >>> addresses into its own structs and does not use mac80211 structs in >>> main.c. >> >> Yeah. Basically, a lot of conversions are done at mac80211 interface to keep >> the low-level driver code similar to the code base it came from. That is the >> path taken. I would like to see a replacement driver some day that shares more >> structure definitions with the linux wireless subsystem, but for now that is just >> me daydreaming ;-) > > I saw your code for beaconing and probe response templates, but I mostly > replaced it with a new version because this architecture was not > compatible with mac80211. For the Phy code it makes sense and it is > probably not so hard to stay near your proprietary code base, but I do > not think this works very well with the rest of the code mostly in main.c. > > Hauke > -- 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
