Based on a patch by Miguel.
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Cc: Miguel Boton <mboton.lkml@gmail.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reviewing the semaphore usage I noticed these down_interruptible calls. Most
of these aren't returning anything, so a caller can't tell if the operation
completed or not. prism54_wpa_bss_ie_get() returns zero, but it's treated as
the function failing which doesn't seem correct.
Signed-off-by: Daniel Walker <dwalker@mvista.com>
Cc: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This reverts commit e4128a54d790658ab265c915e5da9153ff74af97.
On Sunday 02 December 2007 17:17:51 Michael Wu wrote:
> CCK and OFDM power levels are stored in adjacent bytes, not nibbles.
>
This turns out to be true only for rtl8180. On rtl8187, power levels are
indeed stored in nibbles, so this patch is wrong. Please revert this patch.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
keep it little-endian, update places that use its members
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
->ring_control_dma is dma_addr_t, needs conversion to little-endian
before __raw_writel()...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Just leave hfa384x_info_frame as-is, don't convert in place.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Don't byteswap any fields, annotate. That has caught a bug,
BTW - will be handled in the next patch.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
don't byteswap, update users to match that, annotate.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Stop byteswap-in-place in readBSSListRid(), annotate the sucker.
BTW, that had immediately found a bug - another codepath fetching
the same struct from card did _not_ byteswap, but used ->dBm the
same as everything else - host-endian. Fix in the next patch...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* store SSID_rid without conversions
* sanitize proc_SSID_on_close() (and avoid access past the end of
buffer, while we are at it)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We'd just set tfd->u.data.chunk_len[i] to cpu_to_le16(remaining_bytes);
passing it to pci_map_single() is a bad idea - it expects host-endian.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
A couple of places forgot cpu_to_le16() in assignments to
that field, even though right next to those in other branches
of if-else we do it correctly.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
bugs galore:
* 0xf380 instead of htons(ETH_P_AARP), etc. Works only on l-e.
* back in 2.3.20 driver got readb() and friends instead of
direct dereferencing of iomem. Somebody got too enthusiatic and replaced
ntohs(p->mrx_overflow)
with
ntohs(read(&p->mrx_overflow)
without noticing that (a) the sucker is 16bit and (b) that expression can't possibly
be portable anyway (hell, on l-e it's always less than 256, on b-e it's always a
multiple of 256). Proper fix is
swab16(readw(&p->mrx_overflow)
taking into account the conversion done by readw() itself. That crap happened
in several places; the same fix applies.
* untranslate() assumes little-endian almost everywhere, except for
the code checking for IPX/AARP packets; there we forgot ntohs(), so that part
only works on big-endian.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ->exp_id in bootrec_exp_if is __le16; missing conversion in its use
* !(x & y) misspelled as !x & y
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
in writerids() we do _not_ byteswap, so we want to access
->opmode as little-endian.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
never had been byteswapped, used as host-endian...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On big-endian we end up with swapped first two bytes in packet,
due to earlier conversion to host-endian and forgotten conversion
back.
The code we calculated that host-endian for had been duplicated
several time - it finds the 802.11 MAC header length by the first
two bytes of packet; taken into a new helper (header_len(__le16 ctl)).
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
airo_translate_scan() reads BSSListRid directly, does _not_ byteswap
and uses ->dBm (__le16) as host-endian.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
a) gaplen would better be stored little-endian
b) for control packets (shorter than 24-byte header) we ended up with
bap_write(ai, hdrlen == 30 ?
(const u16*)&gap.gaplen : (const u16*)&gap, 38 - hdrlen, BAP1);
passing to card the data past the end of gap (i.e. random stuff from stack)
and did _not_ feed the gaplen at the right offset.
c) sending the contents of uninitialized fields of struct is Not Nice(tm) either
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Make it match the on-the-wire endianness, eliminate byteswapping.
The only driver that used this sucker (ipw2200) updated.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch skips mac80211 configuration setting during a hardware scan
and replays it afterwards for the iwlwifi drivers.
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch changes the iwlwifi driver to properly support
monitor interfaces after the filter flags change.
The patch is originally created by Johannes Berg for iwl4965. I fixed some
of the comments and created a similar patch for iwl3945.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
sizeof(*cmd) is going to give the total size of the data structure that
we allocated, more often than not. But the size of the command to be
_sent_ could be a lot smaller, as it is in the KEY_MATERIAL and
SUBSCRIBE_EVENT commands for example. So swap them round; let the caller
set the _command_ size explicitly in the header, and infer the
maximum response size from the data structure.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We don't necessarily want to reset the device on a TX timeout. But more
often than not, the real cause is that the firmware has crapped itself,
not just that the network is busy. So submit any harmless command, and
if _that_ times out, then the error handling code will reset the module,
as appropriate.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Even if it fails, we want to wait a while and try again, with an
ultimate timeout if it the condition persists. So again, just use the
standard command timeout behaviour.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the firmware returns 0x0004, it wants us to try again later. We can
achieve that simply by throwing out the response and letting the command
timeout code kick in.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If we don't scribble over the command we sent, then we can retry it when
the firmware responds with 0x0004 (which means -EAGAIN).
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We have a local variable 'resp' which we use for this. So use it,
instead of typing the whole thing.
In preparation for actually using priv->upld_buf for the responses
instead...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move the various firmware setup bits into a separate function, which
used to do just boot2 version.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Otherwise, we go into an endless busy loop trying to enable PS mode when
the command queue is empty, dealing with the error response, and then
trying to enable PS mode again because the command queue is empty.... it
doesn't really save much power.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
lbs_send_confirmwake() is a bit ugly but matches the way we confirm
sleep. We'll deal with that whole thing later.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
DNLD_RES_RECEIVED is a bit of a misnomer -- we never wait for the result
to be received; it's purely representing the state of the TX path, and
in this case the TX path is definitely busy.
Of course, that means that we don't actually care about DATA_SENT vs.
CMD_SENT either, but that's a can of worms for another day...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit 5b8845345e7385d2eb37fac22ba9ab6905988be5 (or, in case the git
workflow is broken and patches get recommitted, the commit entitled
'libertas: rename and re-type bufvirtualaddr to cmdbuf' by dcbw),
introduced a number of bugs where we once had a pointer to a command
_payload_, but now we use the pointer to the command header instead.
The fix isn't wonderfully pretty for now, but it'll get better when we
finish converting all commands so the structures include the header.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If we return the channel number in a 'ret' variable where anything
non-zero is later interpreted as an error, that isn't nice. It breaks
WPA, for a start. OLPC trac #5485
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
And handle the case where it times out more than once, too, instead of
locking up for ever.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We can use the callback_arg for it; that's the way we're heading anyway...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move the wakeup into lbs_complete_command(), and leave the other bits
in __lbs_cleanup_and_insert_cmd() which was the only caller now anyway.
There are two remaining direct callers of lbs_cleanup_and_insert_cmd(),
and they are both fine without the wakeup.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We initialise it when we add it to the queue. No need to do it again.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We allocate them all at the same time, at startup. If they go missing,
we have more serious things to worry about, and the resulting oops will
be a perfectly acceptable result.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We're about to change semantics, leaving callers of
lbs_prepare_and_send_command() with the old broken priv->cur_cmd_retcode
crap. The existence of the callback command will be the trigger for the
new semantics when handling the response.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Call it lbs_submit_command(), remove a bunch of things which can be (or,
in the case of zeroing ->cmdwaitqwoken, already are) done elsewhere.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It wasn't working anyway -- by the time we get into if_usb_disconnect()
the USB core has already stopped us talking to the thing; even if it's
just on unload and the device still exists.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The kthread code can't cope with a thread exiting of its own accord and
then someone calling kthread_stop() for it. When the thread detects that
it needs to die, make it wait for kthread_stop() to be called.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This fixes Bug #9414 for b43legacy. This patch is the equivalent of one
submitted earlier for b43.
Since addition of the rfkill callback, the LED associated with the off
switch on the radio has not worked for several reasons:
(1) Essential data in the rfkill structure were missing.
(2) The rfkill structure was initialized after the LED initialization.
(3) There was a minor memory leak if the radio LED structure was inited.
Once the above problems were fixed, additional difficulties were noted:
(4) The radio LED was in the wrong state at startup.
(5) The radio switch had to be manipulated twice for each state change.
(6) A circular mutex locking situation existed.
(7) If rfkill-input is built as a module, it is not automatically loaded.
This patch fixes all of the above and removes a couple of sparse warnings.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Stefano Brivio <stefano.brivio@polimi.it>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We get scary warnings on UP if we use spin_trylock() and find, as we
hoped, that the lock in question is already locked.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There is weirdness here; the firmware seems to refuse to change channels
at will.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Also, check that suspend is refused if HOST_SLEEP_CFG hasn't been done.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We (ab)use priv->fw_ready to stop the worker thread from sending more
commands or data after the response to the HOST_SLEEP_ACTIVATE command
comes in. And we set it from the callback function _directly_ to ensure
that the worker thread sees it immediately; if we did it in
lbs_suspend() after waking up, that might be too late.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We want it to send the HOST_SLEEP_ACTIVATE command on the way down...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This way, it looks more like a normal function.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In particular, we shouldn't be waking the queues in lbs_host_to_card_done()
any more.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Especially in the light of OLPC trac #5461, in which the firmware starts
sending us seemingly random command responses which bear little relation
to the command we sent it.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Otherwise the device won't let us change channels.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If stupid people like me give it arguments with the wrong type (like a
pointer to the structure, for example, instead of the structure itself),
then we should probably notice that at compile time. Otherwise, much
confusion ensues.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bad dcbw. Always test on big-endian, or at least use sparse.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Make it a struct cmd_header, since that's what it is, and clean up
the places that it's used.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This prevents us from trying to remove it when it didn't exist, in the
error case.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Amazing what interesting things the compiler will tell you if you let it
know what types you expect to be passing around.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
A simple callback which copies the response back into the
command buffer that was used to send the command to the
card. Will allow for direct command processing outside
the mega-switches in cmd.c and cmdresp.c.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move direct command handling through __lbs_cmd() over to using the
header as the first member of the command structure, and only define
the __lbs_cmd() callback in one place rather than 3. Convert boot2
version command to new usage.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
No need to busy-wait, even if we did have a 100ms delay in the loop.
This makes it easier to support the new 'firmware ready' event which is
in the new firmware, too.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Increase the delay between issuing the RESET command and the usb reset,
and be prepared to discard more than one 'normal' packet from it before
it resets.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Total overkill to have an array when there's only one command in it.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The firmware is always initialised before we register the netdevices.
It's not possible for pre_open_check() to fail.
One day we might try loading firmware in ->open(), but still it won't be
just a _check_, like this.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Define a macro that relieves the caller from having to use sizeof on
the command structure when calling lbs_cmd(), and move the prototype
of __lbs_cmd() to a new cmd.h file.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Make it take struct lbs_private as argument; that's all it wants anyway,
and all callers were starting off from that. Don't wake the netif
queues, because those should be handled elsewhere. And sort out the
locking, with a big nasty warning for those who don't have the
driver_lock locked when they call it.
Oh, and fix if_cs.c to lock the driver_lock before calling it.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This will be useful for letting callbacks do stuff like copying the
response into a buffer provided by the caller of lbs_cmd()
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Previously, the display of subscribed events could be wrong.
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
No need for these any more. We've collapsed all the unneeded nests of
functions which needed to keep track of which device the skb belonged to.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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>
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 <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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 <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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 <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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 <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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 <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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 <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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 <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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 <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
... where it can shortly be merged with lbs_process_tx()...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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 <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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 <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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 <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Also attempt some locking in lbs_host_to_card_done()
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There seems to be no reason for a separate structure; move it all
into struct lbs_private.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We don't need this. We can use adapter->currenttxskb instead.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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 <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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 <dwmw2@infradead.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
