On 02/24/2013 11:21 AM, Arend Van Spriel wrote:

On Sunday, February 24, 2013 2:05 AM, Hauke Mehrtens wrote:

quoted

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.

quoted

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?

quoted

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

quoted

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.

quoted

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