- 28 Jan, 2008 40 commits
-
-
David Woodhouse authored
It replaces two lines of code. And even for those it has to make inferences about things (i.e. which device) which the caller would have just known. Signed-off-by:
David Woodhouse <dwmw2@infradead.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
David Woodhouse authored
Signed-off-by:
-
David Woodhouse authored
The function is only ever called if we're in rtap mode. So the bit in it which is conditional on rtap mode seems a little superfluous. Signed-off-by:
-
David Woodhouse authored
The locking issues with TX, especially TX from multiple netdevs, get _so_ much easier if you do it like this. Signed-off-by:
-
David Woodhouse authored
This was making my brain hurt. Signed-off-by:
-
David Woodhouse authored
I was so busy cleaning up the failure modes that I accidentally forgot to make sure we still free them in the success case. Oops. Signed-off-by:
-
David Woodhouse authored
Fix one of the barriers to simultaneous radiotap and normal operation -- stop misinterpreting the TX packets on the normal devices. We're also going to have to clone the incoming skbs and feed them into both devices, and there seem to be firmware problems with staying associated too. But this is a reasonable start... Signed-off-by:
-
David Woodhouse authored
This lets us bring it up, because eth_validate_addr() succeeds instead of returning -EINVAL. And finally monitor mode seems to (mostly) work. Signed-off-by:
-
David Woodhouse authored
There seems to be no point in doing it as an ieee80211 device instead of a normal netdev, and when we override its ->priv and then call free_ieee80211() it has a distressing tendency to crash horribly. Signed-off-by:
-
David Woodhouse authored
These wrappers only do two things. Firstly, they set the frame type, which isn't necessary since lbs_hard_start_xmit() gets to see which device it belongs to anyway. Secondly, they return -EOPNOTSUPP if the device is in monitor mode. Which is a strange thing to do and will provide nasty warnings from qdisc_restart(). And lbs_hard_start_xmit() seems to have code to cope with monitor mode anyway. Signed-off-by:
-
David Woodhouse authored
Having merged the nest of functions into one, now we can clean it up and fix the error handling, and the duplication -- and at least make a start on the locking. Signed-off-by:
-
David Woodhouse authored
Signed-off-by:
-
David Woodhouse authored
... where it can shortly be merged with lbs_process_tx()... Signed-off-by:
-
David Woodhouse authored
Make a start on reducing the number of pointless nested functions, starting with the StudlyCaps. No semantic changes (yet) -- we can sort out the now-obvious discrepancy in the failure paths in a separate commit. Signed-off-by:
-
David Woodhouse authored
It was buggy as hell anyway, since it was just spewing packets at the device when it wasn't necessarily ready for them (in the USB case, while the URB was still busy). We could probably do with a better way of flushing packets to the device _immediately_, before we stick it back into sleep mode. But we can no longer just dequeue packets directly, it seems. Signed-off-by:
-
David Woodhouse authored
It doesn't need to wait until no commands are pending anyway -- it only needs to wait until the scan is finished. We can hopefully find it something else to wait on too -- it's the only user of the cmd_pending waitqueue. Signed-off-by:
-
David Woodhouse authored
Signed-off-by:
-
David Woodhouse authored
Also attempt some locking in lbs_host_to_card_done() Signed-off-by:
-
David Woodhouse authored
There seems to be no reason for a separate structure; move it all into struct lbs_private. Signed-off-by:
-
David Woodhouse authored
We don't need this. We can use adapter->currenttxskb instead. Signed-off-by:
-
David Woodhouse authored
At least it doesn't oops when you attempt to read or write it now. Only when you enable it and then later turn it off. And when it's enabled I don't see how it actually works. But one fewer oops is good, for now... Signed-off-by:
-
David Woodhouse authored
No semantic changes. Signed-off-by:
-
David Woodhouse authored
All existing code which sends commands is set up to have some function called with the results, not to get data back. It's more versatile this way, and providing it with a callback function which involves memcpy() is hardly difficult. Signed-off-by:
-
David Woodhouse authored
Signed-off-by:
-
David Woodhouse authored
Signed-off-by:
-
David Woodhouse authored
Also clean up the double setting/clearing of IW_ENCODE_DISABLED. Signed-off-by:
-
Holger Schurig authored
Recently I found that that sparse by default doesn't endianness checks. So I changed my compilation habit to be make modules C=1 SUBDIRS=drivers/net/wireless/libertas CHECKFLAGS="-D__CHECK_ENDIAN__" so that I get the little-endian checks from sparse as well. That showed up a good bunch of problems. Signed-off-by:
Holger Schurig <hs4233@mail.mn-solutions.de> Signed-off-by:
-
David Woodhouse authored
Signed-off-by:
-
David Woodhouse authored
Signed-off-by:
-
Holger Schurig authored
This changes the code that is used for scanning and makes it hopefully easier to understand: * move function into logical blocks * create a bunch of lbs_scan_add_XXXX_tlv() functions, that help to create the TLV parameter of CMD_802_11_SCAN * all of them are now called from the much simpler lbs_do_scan() * no **puserscancfg double-pointers :-) Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
David Woodhouse authored
We read it from the card. We byte-swap it. We write it back to the card. D'oh. Signed-off-by:
-
David Woodhouse authored
And the death of libertas_prepare_and_send_command() starts... Signed-off-by:
-
David Woodhouse authored
Signed-off-by:
-
Holger Schurig authored
I wondered about junk bytes at the end when using "lbsdebug +hex +host" until I noticed that firmware for the CF card sends my extranous bytes. It says "I have 20 bytes", I take 20 bytes, but the last 8 bytes of this are just data junk. Also, in the new lbs_cmd() where was a size miscalulation that made itself clear after fixing this bug. Signed-off-by:
-
Li Zefan authored
Don't cast struct foo * to struct list_head *, it's safe only when the list member is the first member of struct foo. Also don't cast struct list_head * to struct foo *. Signed-off-by:
Li Zefan <lizf@cn.fujitsu.com> Signed-off-by:
-
David Woodhouse authored
Bad Holger. Always test on big-endian machines, if it's little-endian you need to be swapping to/from. Signed-off-by:
-
David Woodhouse authored
Otherwise, lbs_process_rx_command() will take the new path for lbs_cmd() responses, when it shouldn't. Signed-off-by:
-
David Woodhouse authored
This is meaningless for non-USB devices and unimplemented in their firmware. It's somewhat dubious for USB devices too, but that's a different story. Signed-off-by:
-
David Woodhouse authored
This explains why we never noticed the corruption of checksums on outgoing packets... we weren't actually checking them either. Signed-off-by:
-
Holger Schurig authored
Using an arbitrary firmware command was actually very painful. One had to change big switch() statements in cmd.c, cmdresp.c, add structs to the big union in "struct cmd_ds_command" and add the define for the CMD_802_11_xxx to the proper place. With this function, this is now much easier. For now, it implements a blocking (a.k.a. CMD_OPTION_WAITFORRSP) way where one deals directly with command requests and response buffers. You can do everything in one place: Signed-off-by:
-
