The problem is that priv->assoc_id is set when assoc. resp frame is
received. But, when it is set, LQ cmd is still not sent to the uCode, it is
done from bg_post_assoc, which is called through a workqueue.

On the other hand, when a tx arrives at the moment when this flag is set,
but LQ is still not sent, the if condition in tx_skb will not hold and
the frame will not be dropped.  Thus, it will be sent through
which is still not in the sta table in the uCoded.
Signed-off-by: NGregory Greenman <gregory.greenman@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The nic controller's scheduler interrupt (CSR_INT_BIT_SCD) indicates
to the driver that scheduler finished to transmit the frame/frames.
This bit is not used and the tasklet should thus not be scheduled upon
its receipt.
Signed-off-by: NJoonwoo Park <joonwpark81@gmail.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Be consistent when using inline functions. If the function only used
once we move it to where it is used - no need for externs.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The geo/channel information is obtained from the EEPROM, which is read
during probe. We can thus set up channel information at this time. This
helps us to support ioctl commands that rely on this before the interface
is brought up.

Clearly matches _init_channel_map with _free_channel_map and _init_geos
with _free_geos to ensure functions calling these routines can also call
their cleanup routines.

Fixes a few bugs:
- if channel information is not available when ioctl commands are
  issued then we get a NULL pointer oops. Having channel information
  set up during probe we can deal with ioctl commands without requiring
  interface to be brought up.
  This fixes bug: http://www.bughost.org/bugzilla/show_bug.cgi?id=1552
- Fix potential problem if user triggers probe/remove/probe sequence. The
  value of priv->channel_count was used to determine if channel map is
  set up. This value was never reset when channel map was removed.
- Fix memory leak: priv->modes need to be freed when device removed.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is a fix to patch "iwlwifi: fix iwl_mac_add_interface handler".
In that patch the return code was corrected for iwl3945, but not for
iwl4965.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Cc: Tomas Carnecky <tom@dbservice.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NMaarten Lankhorst <m.b.lankhorst@gmail.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

I have been using the rtl8180 driver via the git kernel route for a while now and would like to suggest that the following local ammendment is included in the development tree in order to support the PCI device 1799:700f.

This device is found on the 'Belkin Wireless G Desktop Card' product, model 'F5D7000uk'.  From memory, the chip on the card is inscribed RTL8185L;  (I don't know the significance of the 'L', I'm afraid).
Signed-off-by: NAdrian Bassett <adrian.bassett@hotmail.co.uk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This zeros out all microcode related memory before loading
the microcode.

This also fixes initialization of the MAC control register.
The _only_ place where we overwrite the contents of the MAC control
register is at the beginning of b43_chip_init().
All other places must do read() -> mask/set -> write() to not
overwrite existing bits.

This also adds a longer delay for waiting for the microcode
to initialize itself. It seems that the current timeout is sufficient
on all available devices, but there's no real reason why we shouldn't
wait for up to one second. Slow embedded devices might exist.
Better safe than sorry.

While at it, fix naming of MACCTL values.

This patch by Michael Buesch has been ported to b43legacy.
Signed-off-by: NStefano Brivio <stefano.brivio@polimi.it>
Acked-by: NMichael Buesch <mb@bu3sch.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We must kill rfkill in any error paths that trigger after rfkill init.
Signed-off-by: NMichael Buesch <mb@bu3sch.de>
Acked-by: NStefano Brivio <stefano.brivio@polimi.it>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We must kill rfkill in any error paths that trigger after rfkill init.
Signed-off-by: NMichael Buesch <mb@bu3sch.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

* use only one debug level for beacon debugging: unify ATH5K_DEBUG_BEACON and
ATH5K_DEBUG_BEACON_PROC.

* remove debug level ATH5K_DEBUG_FATAL. doesn't make sense as a debug level -
if it's fatal it should be logged as an error.

* fancier printing of debug levels. cat /debugfs/ath5k/phy0/debug.

* allow debug levels to be changed by echoing their name into
/debugfs/ath5k/phy0/debug. this will toggle the state, when it was off it will
be turned on and vice versa.

* use copy_from_user() when reading from the debug files. use unsigned int for
better optimization. reduce buffer sizes on stack.

drivers/net/wireless/ath5k/base.c:      Changes-licensed-under: 3-Clause-BSD
drivers/net/wireless/ath5k/debug.c:     Changes-licensed-under: GPL
drivers/net/wireless/ath5k/debug.h:     Changes-licensed-under: GPL
Signed-off-by: NBruno Randolf <bruno@thinktube.com>
Acked-by: NLuis R. Rodriguez <mcgrof@winlab.rutgers.edu>
Acked-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A subtle merge error was introduced after re-queueing a patch for 2.6.24
instead of 2.6.25...
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This header file exists only for some hacks to adapt alsa-driver
tree.  It's useless for building in the kernel.  Let's move a few
lines in it to sound/core.h and remove it.
With this patch, sound/driver.h isn't removed but has just a single
compile warning to include it.  This should be really killed in
future.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NJaroslav Kysela <perex@perex.cz>

drivers/lguest/x86/core.c: In function ‘copy_in_guest_info’:
drivers/lguest/x86/core.c:97: error: ‘struct x86_hw_tss’ has no member named ‘esp1’
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix kernel-doc empty line warning:
Warning(linux-2.6.24-git8//drivers/base/class.c:866): bad line:
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

To be more compliant with section 7.4.8 of the SBP-2 specification,
use the mgt_ORB_timeout specified in the SBP-2 device's config rom
for login ORB attempts (though with some sanity checks). A happy
side-effect is that certain device and controller combinations that
sometimes take more than 20 seconds to get synced up (like my laptop
with just about any SBP-2 device) now function more reliably.
Signed-off-by: NJarod Wilson <jwilson@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (silenced sparse)

Increase (and rename) the login orb reply timeout value to 20s
to match that of the old firewire stack. 2s simply didn't give
many devices enough time to spin up and reply.

Fixes inability to recognize some devices.
Failure mode was "orb reply timed out"/"failed to login".
Signed-off-by: NJarod Wilson <jwilson@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (style, comments, changelog)

Replace an unnecessary subtraction with a bitwise AND when determining the
value of ext_tcode in fw_fill_transaction() to save a cpu cycle or two in a
somewhat critical path.
Signed-off-by: NJarod Wilson <jwilson@redhat.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

read_rom() obtained a fresh new fw_device.generation for each read
transaction.  Hence it was able to continue reading in the middle of the
ROM even if a bus reset happened.  However the device may have modified
the ROM during the reset.  We would end up with a corrupt fetched ROM
image then.

Although all of this is quite unlikely, it is not impossible.
Therefore we now restart reading the ROM if the bus generation changed.

Note, the memory barrier in read_rom() is still necessary according to
tests by Jarod Wilson, despite of the ->generation access being moved up
in the call chain.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This is essentially what I've been beating on locally, and I've yet to hit
another config rom read failure with it.
Signed-off-by: NJarod Wilson <jwilson@redhat.com>

fw_device.node_id and fw_device.generation are accessed without mutexes.
We have to ensure that all readers will get to see node_id updates
before generation updates.

Fixes an inability to recognize devices after "giving up on config rom",
https://bugzilla.redhat.com/show_bug.cgi?id=429950Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Reviewed by Nick Piggin <nickpiggin@yahoo.com.au>.

Verified to fix 'giving up on config rom' issues on multiple system and
drive combinations that were previously affected.
Signed-off-by: NJarod Wilson <jwilson@redhat.com>
Signed-off-by: NKristian Høgsberg <krh@redhat.com>

We have to use the fw_device.generation here, not the fw_card.generation,
because the generation must never be newer than the node ID when we emit
a transaction.  This cannot be guaranteed with fw_card.generation.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Verified in concert with subsequent memory barriers patch to fix 'giving
up on config rom' issues on multiple system and drive combinations that
were previously affected.
Signed-off-by: NJarod Wilson <jwilson@redhat.com>

There was a small window where a login or reconnect job could use an
already updated card generation with an outdated node ID.  We have to
use the fw_device.generation here, not the fw_card.generation, because
the generation must never be newer than the node ID when we emit a
transaction.  This cannot be guaranteed with fw_card.generation.

Furthermore, the target's and initiator's node IDs can be obtained from
fw_device and fw_card.  Dereferencing their underlying topology objects
is not necessary.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Verified in concert with subsequent memory barriers patch to fix 'giving
up on config rom' issues on multiple system and drive combinations that
were previously affected.
Signed-off-by: NJarod Wilson <jwilson@redhat.com>

Ask the target to grant 4 seconds instead of the standard and minimum of
1 second window after bus reset for reconnection.  This accelerates
reconnection if there are more than one targets on the bus:  If a login
and inquiry to one target blocks the fw-sbp2 workqueue for more than 1s
after bus reset, we now still can reconnect to the other target.

Before that, fw-sbp2's reconnect attempts would be rejected with "error
status: 0:9" (function rejected), and fw-sbp2 would finally re-login.
All those futile reconnect attemps cost extra time until the target
which needs re-login is ready for I/O again.

The reconnect timeout field in the login ORB doesn't have to be honored
by the target though.  I found that we could get up to
  - allegedly 32768s from an old OXFW911 firmware
  - 256s from LSI bridges
  - 4s from OXUF922 and OXFW912 bridges,
  - 2s from TI bridges,
  - only the standard 1s from Initio and Prolific bridges and from
    Apple OpenFirmware in target mode.

We just try to get 4 seconds which already covers the case of a few
HDDs on the same bus quite nicely.

A minor drawback occurs in the following (rare and impractical) border
case:
  - two initiators are there, initiator 1 holds an exclusive login to
    a target,
  - initiator 1 goes off the bus,
  - target refuses login attempts from initiator 2 until reconnect_hold
    seconds after bus reset.

An alternative approach to the issue at hand would be to parallelize
fw-sbp2's reconnect and login work.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Acked-by: NJarod Wilson <jwilson@redhat.com>

Don't attempt to send a logout ORB if the target was already unplugged
or had its link switched off.  If two targets are attached, this
enhances the chance to quickly reconnect to the remaining target when
one target is plugged out.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Acked-by: NJarod Wilson <jwilson@redhat.com>

Previously, the fw-ohci driver used fixed-length buffers for storing
descriptors for isochronous receive DMA programs.  If an application
(such as libdc1394) generated a DMA program that was too large, fw-ohci
would reach the limit of its fixed-sized buffer and return an error to
userspace.

This patch replaces the fixed-length ring-buffer with a linked-list of
page-sized buffers.  Additional buffers can be dynamically allocated and
appended to the list when necessary.  For a particular context, buffers
are kept around after use and reused as necessary, so there is no
allocation taking place after the DMA program is generated for the first
time.

In addition, the buffers it uses are coherent for DMA so there is no
syncing required before and after writes.  This syncing wasn't properly
done in the previous version of the code.

-

This is the fourth version of my patch that replaces a fixed-length
buffer for DMA descriptors with a dynamically allocated linked-list of
buffers.

As we discovered with the last attempt, new context programs are
sometimes queued from interrupt context, making it unacceptable to call
tasklet_disable() from context_get_descriptors().

This version of the patch uses ohci->lock for all locking needs instead
of tasklet_disable/enable.  There is a new requirement that
context_get_descriptors() be called while holding ohci->lock.  It was
already held for the AT context, so adding the requirement for the iso
context did not seem particularly onerous.  In addition, this has the
side benefit of allowing iso queue to be safely called from concurrent
user-space threads, which previously was not safe.
Signed-off-by: NDavid Moore <dcm@acm.org>
Signed-off-by: NKristian Høgsberg <krh@redhat.com>
Signed-off-by: NJarod Wilson <jwilson@redhat.com>

-

Fixes the following issues:
  - Isochronous reception stopped prematurely if an application used a
    larger buffer.  (Reproduced with coriander.)
  - Isochronous reception stopped after one or a few frames on VT630x
    in OHCI 1.0 mode.  (Fixes reception in coriander, but dvgrab still
    doesn't work with these chips.)

Patch update: struct member alignment, whitespace nits
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The firewire-ohci driver so far lacked the ability to resume cycle
master duty after that condition happened, as added to ohci1394 in Linux
2.6.18 by commit 57fdb58f.  This ports
this patch to fw-ohci.

The "cycle too long" condition has been seen in practice
  - with IIDC cameras if a mode with packets too large for a speed is
    chosen,
  - sporadically when capturing DV on a VIA VT6306 card with ohci1394/
    ieee1394/ raw1394/ dvgrab 2.
    https://bugzilla.redhat.com/show_bug.cgi?id=415841#c7
(This does not fix Fedora bug 415841.)
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Fix extraction of the source node id from the packet header.
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This patch corrects a number of bugs in the current OHCI 1.0
packet-per-buffer support:

1. Correctly deal with payloads that cross a page boundary.  The
previous version would not split the descriptor at such a boundary,
potentially corrupting unrelated memory.

2. Allow user-space to specify multiple packets per struct
fw_cdev_iso_packet in the same way that dual-buffer allows.  This is
signaled by header_length being a multiple of header_size.  This
multiple determines the number of packets.  The payload size allocated
per packet is determined by dividing the total payload size by the
number of packets.

3. Make sync support work properly for packet-per-buffer.

I have tested this patch with libdc1394 by forcing my OHCI 1.1
controller to use the packet-per-buffer support instead of dual-buffer.

I would greatly appreciate testing by those who have a DV devices and
other types of iso streamers to make sure I didn't cause any
regressions.

Stefan, with this patch, I'm hoping that libdc1394 will work with all
your OHCI 1.0 controllers now.

The one bit of future work that remains for packet-per-buffer support is
the automatic compaction of short payloads that I discussed with
Kristian.
Signed-off-by: NDavid Moore <dcm@acm.org>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This patch fixes the problem where different OHCI 1.1 controllers behave
differently when a received iso packet straddles three or more buffers
when using the dual-buffer receive mode.  Two changes are made in order
to handle this situation:

1. The packet sync DMA descriptor is given a non-zero header length and
non-zero payload length.  This is because zero-payload descriptors are
not discussed in the OHCI 1.1 specs and their behavior is thus
undefined.  Instead we use a header size just large enough for a single
header and a payload length of 4 bytes for this first descriptor.

2. As we process received packets in the context's tasklet, read the
packet length out of the headers.  Keep track of the running total of
the packet length as "excess_bytes", so we can ignore any descriptors
where no packet starts or ends.  These descriptors may not have had
their first_res_count or second_res_count fields updated by the
controller so we cannot rely on those values.

The main drawback of this patch is that the excess_bytes value might get
"out of sync" with the packet descriptors if something strange happens
to the DMA program.  I'm not if such a thing could ever happen, but I
appreciate any suggestions in making it more robust.

Also, the packet-per-buffer support may need a similar fix to deal with
issue 1, but I haven't done any work on that yet.

Stefan, I'm hoping that with this patch, all your OHCI 1.1 controllers
will work properly with an unmodified version of libdc1394.
Signed-off-by: NDavid Moore <dcm@acm.org>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

SBP2_MAX_SECTORS is nowhere used in fw-sbp2.
It merely got copied over from sbp2 where it played a role in the past.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This somewhat reduces the size of firewire-sbp2.ko.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Bug noted by Pieter Palmers:  Isochronous transmit tasklets were
scheduled on isochronous receive events, in addition to the proper
isochronous receive tasklets.

http://marc.info/?l=linux1394-devel&m=119783196222802Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This patch speeds up sbp2 a little bit --- but more importantly, it
brings the behavior of sbp2 and fw-sbp2 closer to each other.  Like
fw-sbp2, sbp2 now does not limit the size of single transfers to 255
sectors anymore, unless told so by a blacklist flag or by module load
parameters.

Only very old bridge chips have been known to need the 255 sectors
limit, and we have got one such chip in our hardwired blacklist.  There
certainly is a danger that more bridges need that limit; but I prefer to
have this issue present in both fw-sbp2 and sbp2 rather than just one of
them.

An OXUF922 with 400GB 7200RPM disk on an S400 controller is sped up by
this patch from 22.9 to 23.5 MB/s according to hdparm.  The same effect
could be achieved before by setting a higher max_sectors module
parameter.  On buses which use 1394b beta mode, sbp2 and fw-sbp2 will
now achieve virtually the same bandwidth.  Fw-sbp2 only remains faster
on 1394a buses due to fw-core's gap count optimization.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The code has been in "#if 0 - #endif" since Linux 2.6.12.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Convert ieee1394 from nopage to fault.
Remove redundant vma range checks (correct resource range check is retained).
Signed-off-by: NNick Piggin <npiggin@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Replace sg->length by sg_dma_len(sg).  Rename a variable for shorter
line lengths and eliminate some superfluous local variables.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>