lets hold off on removing the /HAL/ support just right now. If we start stripping this stuff out then i'll make it harder to sync this code up with what I'm slowly hacking up in netbsd...

fiiine :-P

Hi! I know this is a long shot, but if someone wants to do AR9271/AR7010 support (which is USB) it'll need this bus abstraction still.

i know this keeps happening for unaligned-unhappy platforms, but can we please at least try to "fix" this in the L3 path too? Do an explicit pull-up and counter on the input path just in case something sneaks through?

nice!

I think having a separate dedicated allocator for netlink messages is the better call. Don't make your control plane reliant on your data plane's memory management.

ping! what's left before we can have a lwjgl3 port landed?

In D39476#899586, @misha wrote:

In D39476#899553, @adrian wrote:

oh wait err, i recall when bernard and i were debugging this in 2010/2011 time we found that "what the spec said" and "what devices actually needed because of bugs" were very different. so let's be careful with these.

(gosh I wish we had all of that in the commit logs or bug report logs somewhere..)

I think that adjusting to bugs of some devices in cost of contradicting to the standard for every device around is counter-productive, especially considering time which has passed since 2010.

What were consequences of these bugs and what were the vendors?

oh wait err, i recall when bernard and i were debugging this in 2010/2011 time we found that "what the spec said" and "what devices actually needed because of bugs" were very different. so let's be careful with these.

oh hm! good catch, let's see!

i understand the fix, but the whole code layout for rtwn is to avoid the HW code knowing too much about the bus/transport.

(also I thought we had a program somewhere in tools/tools/net80211 that would listen to the routing socket for all net80211 messages, to make debugging this easier? if not, we should write one :-)

iirc, and don't quote me on this, the "scan done + restart" stuff can happen when the software scanner is doing things like background scans (which break softmac 11n/11ac/etc devices, sigh, someone needs to employ me for 6 months to properly fix that for softmac devices already) it can start and stop a scan, push up scan results, but not complete it. background scans can be interrupted by active traffic, which means it'll try to do a piecemeal scan before pushing things up.

ok, try this one!

oops

corrections!

addressed nits

amusingly I'm actually neck deep in figuring it out for my macbook air, so sure. Why not. ;)

Thanks for the cleanup!

They're all used in the ath10k driver port I'm working on. They're available in the linuxkpi for liinux drivers too :-)

i think it's fine to nuke it?

update

update

update

update

update

address comments from imp

update

nice catch!

hi! I think this looks ready to land, right?

In D36183#821399, @emaste wrote:

Presumably this results in identical object code?

Rebase

looks good!

nice work!

I wonder if this is how it used to be in the deep, distant past. ok, this is right!

why? it's designed to be used as an emulator / virtual 802.11 interface for building tests. :-) So it should be wlanX.

hey nice catch!

I think it's okay to remove it. Just make sure it doesn't break adhoc mode 11n rate "negotiation" stuff.