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. >> 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
