The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.

A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@ change_compare_np @
expression E;
@@

(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)

@ include depends on change_compare_np @
@@

#include <linux/jiffies.h>

@ no_include depends on !include && change_compare_np @
@@

  #include <linux/...>
+ #include <linux/jiffies.h>
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The functions time_before, time_before_eq, time_after, and time_after_eq
are more robust for comparing jiffies against other values.

A simplified version of the semantic patch making this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@ change_compare_np @
expression E;
@@

(
- jiffies <= E
+ time_before_eq(jiffies,E)
|
- jiffies >= E
+ time_after_eq(jiffies,E)
|
- jiffies < E
+ time_before(jiffies,E)
|
- jiffies > E
+ time_after(jiffies,E)
)

@ include depends on change_compare_np @
@@

#include <linux/jiffies.h>

@ no_include depends on !include && change_compare_np @
@@

  #include <linux/...>
+ #include <linux/jiffies.h>
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

hci_usb: do not initialize static variables to 0.
Signed-off-by: NPavel Machek <pavel@suse.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Herbert Xu's commit fb93134d, entitled
"[TCP]: Fix size calculation in sk_stream_alloc_pskb", has triggered a
bug in the 5701 where the 5701 DMA engine will corrupt outgoing
packets.  This problem only happens when the starting address of the
packet matches a certain range of offsets and only when the 5701 is
placed downstream of a particular Intel bridge.

This patch detects the problematic bridge and if present, readjusts the
starting address of the packet data to a dword aligned boundary.
Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Code within NS_DEBUG_SPINLOCKS contained deprecated cli()/sti()
function calls.  NS_DEBUG_SPINLOCKS and the associated code seems to
be of little use these days so the strategy of removing this code
rather then updating it to use spinlocks has been taken.
Signed-off-by: NMark Asselstine <mark.asselstine@windriver.com>
Reviewed-by: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Reportred by Ingo Molnar:

drivers/net/wireless/iwlwifi/iwl-debugfs.c: In function 'iwl_dbgfs_stations_read':
drivers/net/wireless/iwlwifi/iwl-debugfs.c:256: error: 'struct iwl4965_tid_data' has no member named 'agg'

Needs CONFIG_IWL4965_HT protection.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The kernel now panics reliably on boot if you have a SATAPI device
connected.

The problem was introduced by the libata merge trying to pull out all
the SFF code into a separate module.  Unfortunately, if you're a satapi
device you usually need to call atapi_request_sense, which has a bare
invocation of a SFF callback which is NULL on non-SFF HBAs.  Fix this by
making the call conditional.
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

access the right scsi_in() and/or scsi_out() side of things.
also for resid
Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
Reviewed-by: NPete Wyckoff <pw@osc.edu>
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

- prepare the additional bidi_read rlength header.
- access the right scsi_in() and/or scsi_out() side of things.
  also for resid.
- Handle BIDI underflow overflow from target
Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
Reviewed-by: NPete Wyckoff <pw@osc.edu>
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

Support for extended CDBs in iscsi.
All we need is to check if command spills over 16 bytes then allocate
an iscsi-extended-header for the leftovers.
Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
Reviewed-by: NPete Wyckoff <pw@osc.edu>
Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

In the case the unit is blocked, zfcp_unit_get has not been called
yet, so the error handling path should not call zfcp_unit_put.
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NMartin Peschke <mp3@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

The testcase
# chchp -v 0 0.da && sleep 59 && chchp -v 1 0.da
results in this deadlock situation:

STACK TRACE FOR TASK: 0x7e9a2048 (zfcperp0.0.c613)
0 schedule+816 [0x356b3c]
1 schedule_timeout+172 [0x357340]
2 wait_for_common+192 [0x3565fc]
3 flush_cpu_workqueue+116 [0x52af0]
4 flush_workqueue+116 [0x533b8]
5 fc_remote_port_add+64 [0x1c83ec]
6 zfcp_erp_thread+4534 [0x26585a]
7 kernel_thread_starter+6 [0x195d2]

STACK TRACE FOR TASK: 0x7f8ec048 (fc_wq_0)
0 schedule+816 [0x356b3c]
1 zfcp_erp_wait+104 [0x264568]
2 zfcp_scsi_slave_destroy+64 [0x261b24]
3 __scsi_remove_device+154 [0x1c24ba]
4 scsi_remove_device+62 [0x1c2512]
5 __scsi_remove_target+198 [0x1c25ea]
6 __remove_child+58 [0x1c26d6]
7 device_for_each_child+66 [0x1ab566]
8 scsi_remove_target+98 [0x1c268a]
9 run_workqueue+200 [0x5272c]
10 worker_thread+146 [0x52882]
11 kthread+140 [0x58360]
12 kernel_thread_starter+6 [0x195d2]

Remove the zfcp_erp_wait call that is not required here to prevent the
deadlock situation.
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NMartin Peschke <mp3@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

drivers/s390/scsi/zfcp_aux.c: In function ‘zfcp_fsf_incoming_els_rscn’:
drivers/s390/scsi/zfcp_aux.c:1379: warning: cast from pointer to integer of
different size
drivers/s390/scsi/zfcp_aux.c: In function ‘zfcp_fsf_incoming_els_plogi’:
drivers/s390/scsi/zfcp_aux.c:1432: warning: cast from pointer to integer of
different size
drivers/s390/scsi/zfcp_aux.c: In function ‘zfcp_fsf_incoming_els_logo’:
drivers/s390/scsi/zfcp_aux.c:1457: warning: cast from pointer to integer of
different size
..

Just passing pointers rids us of these warnings and improves readability.
Signed-off-by: NMartin Peschke <mp3@de.ibm.com>
Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

This patch contains the following cleanups:
- #if 0 the following unused structs:
  - fw-transaction.c:fw_low_memory_region
  - fw-transaction.c:fw_private_region
  - fw-transaction.c:fw_csr_region
  - fw-transaction.c:fw_unit_space_region
- remove the following unused EXPORT_SYMBOL's:
  - fw-card.c:fw_core_add_descriptor
  - fw-card.c:fw_core_remove_descriptor
  - fw-iso.c:fw_iso_context_create
  - fw-iso.c:fw_iso_context_destroy
  - fw-iso.c:fw_iso_context_start
  - fw-iso.c:fw_iso_context_queue
  - fw-iso.c:fw_iso_context_stop
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Fix:  The fact that nodes had different gap counts would be overlooked
if the bus manager code would pick gap count 63 because of beta
repeaters or because of very large hop counts.  In this case, the bus
manager code would miss that it actually has to send the PHY config
packet with gap count 63.

Related trivial changes:  Use bool for an int used as bool, touch up
some comments.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

We now exit fw_send_phy_config /after/ the PHY config packet has been
transmitted, instead of before.  A subsequent fw_core_initiate_bus_reset
will therefore not overlap with the transmission.  This is meant to make
the send PHY config packet + reset bus routine more deterministic.

Fixes bus reset loop and eventual panic with
  - VIA VT6307 + IOGEAR hub + Unibrain Fire-i camera
    http://bugzilla.kernel.org/show_bug.cgi?id=10128
  - JMicron card
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NJarod Wilson <jwilson@redhat.com>

request_generation is internal to fw-ohci and unneeded in fw_card.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

for code efficiency.
Signed-off-by: NJarod Wilson <jwilson@redhat.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Trivial change to replace more meaningless (to the untrained eye) hex
values with defined CSR constants.
Signed-off-by: NJarod Wilson <jwilson@redhat.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

When a device changes its configuration ROM, it announces this with a
bus reset.  firewire-core has to check which node initiated a bus reset
and whether any unit directories went away or were added on this node.

Tested with an IOI FWB-IDE01AB which has its link-on bit set if bus
power is available but does not respond to ROM read requests if self
power is off.  This implements
  - recognition of the units if self power is switched on after fw-core
    gave up the initial attempt to read the config ROM,
  - shutdown of the units when self power is switched off.

Also tested with a second PC running Linux/ieee1394.  When the eth1394
driver is inserted and removed on that node, fw-core now notices the
addition and removal of the IPv4 unit on the ieee1394 node.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

read_bus_info_block() is repeatedly called by workqueue jobs.
These will step on each others toes eventually if there are multiple
workqueue threads, and we end up with corrupt config ROM images.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Unlike the ohci1394 driver, fw-ohci uses the selfIDGeneration field of
bus reset packets to determine the generation of incoming requests as
per OHCI 1.1 clause 8.4.2.3.  This is more precise --- provided that the
controller inserts the correct generation.  Texas Instruments chips
often don't.

This prevented the transmission of response packets, which for example
broke AV/C transactions as used when communicating with miniDV cameras
and any other AV/C devices.

There is apparently no way to detect and adjust incorrect generations.
Therefore we ignore the generation of bus reset packets from TI chips
and use the generation of the self ID buffer instead.  Alas this is
received at a slightly wrong time.  In rare cases, this could cause us
to not respond to legitimate requests or to respond to expired requests.
(The latter is less likely because the bus reset packet AR event is
typically handled before the self ID complete event.)

Bug reported by Mladen Kuntner, who was extraordinarily patient while
dealing with the driver maintainers.  Fix confirmed to be required and
effective for TSB82AA2 and a TSB43AB22 or TSB43AB22A.
https://bugzilla.redhat.com/show_bug.cgi?id=243081Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NJarod Wilson <jwilson@redhat.com>

Extend the logging of "AR evt_bus_reset, link internal" to "AR
evt_bus_reset, generation ${selfIDGeneration}".  That way we can check
whether this generation matches the one seen in self ID complete event
logging.  See OHCI 1.1 clause 8.4.2.3.

Also extend logging of "firewire_ohci: * selfIDs, generation *" by
"local node ID ffc*" in self ID logging to make the local node in AT/AR
event logs more obvious.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NJarod Wilson <jwilson@redhat.com>

Add a debug option to watch bus reset interrupt events.  Half of this
patch is taken from Jarod Wilson's first version of the JMicron fix.

BusReset interrupts are only generated if the respective module
parameter flag was set before the controller is being initialized.
Else we keep this event masked to reduce IRQ load in normal operation
and to avoid potential problems with buggy chips.

Note, this is unlike the other IRQ events whose logging can be enabled
any time after chip initialization.  This and the influence on what
interrupts the chip generates is why I added an extra flag for it.

Also, reorder the debug parameter flags according to their perceived
usefulness.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NJarod Wilson <jwilson@redhat.com>

I finally tracked down the issues with this JMicron PCI-e card in my
possession to a failure to comply with section 7.2.3.2 of the OHCI 1.1
specification (thanks to Kristian for the pointer to illustrate that it
is indeed a flaw in this card, not the driver). The controller should
simply flush the packets we've appended to its AT queue if a bus reset
occurs before they've been transmitted and we'll try again, but
something goes wrong and the controller winds up hung.

However, we can avoid the problem by simply checking if the
IntEvent.busReset register had been set before we try appending to the
AT context. When busReset is set, the AT context is completely halted
until busReset is cleared, so there's no point in appending AT packets
until the register is cleared. So at_context_queue_packet() now checks
for busReset being set, and bails with an RCODE_GENERATION packet ack,
which results in us trying to append the packet again after recognizing
the fact there has been a bus reset, and clearing busReset.
Signed-off-by: NJarod Wilson <jwilson@redhat.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

While trying to debug this piece of crap JMicron PCI-e controller in my
possession, one thought was that perhaps I was encountering register access
failures. I'm not, but logging them would be good, so we can see if they
are a real problem we should be taking into account anywhere in the code.
Signed-off-by: NJarod Wilson <jwilson@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (added list contact)

I've now witnessed multiple occasions where one of my controllers (a very
poorly working JMicron PCIe card) fails to get its registers properly set
up in ohci_enable(), apparently due to an occasionally very slow to
initiate SClk. The easy fix for this problem is to add a tiny while loop
to try again a time or three after initially enabling LPS before we
move on (or give up).

Of course, the card still isn't fully functional yet, but this gets it at
least one tiny step closer...
Signed-off-by: NJarod Wilson <jwilson@redhat.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Balance ohci_pmac_on and ohci_pmac_off if pci_driver.probe fails.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

and make another expression more readable.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This adds debug printks for asynchronous transmission and reception and
for self ID reception.  They can be enabled at module load time, and at
runtime via /sys/module/firewire_ohci/parameters/debug.
Signed-off-by: NJarod Wilson <jwilson@redhat.com>

Also added:  Logging of interrupt event codes and of cancelled AT
packets.

The code now depends on a Kconfig variable.  This makes it easier to
build firewire-ohci without the feature or to make it an option in the
future.  The variable is currently hidden and always on.

This feature inflates firewire-ohci.ko by 7 kB = 27% on x86-64 and by
4 kB = 23% on i686.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

fw_core_handle_bus_reset() incorrectly relied on the assumption that
self_id_count > 0.

We check early in fw-ohci and discard the self ID complete event if
self_id_count == 0 because a valid event always has at least one self ID
packet in it (the one of the local node).  Hence treat self_id_count ==
0 like any other kind of invalid self ID buffer.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NJarod Wilson <jwilson@redhat.com>

Discard self ID buffer contents if
  - the selfIDError flag is set,
  - any of the self ID packets has bit errors.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NJarod Wilson <jwilson@redhat.com>

Clean up shared code and variable names.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The platform feature calls in the suspend method switched off cable
power, but the calls in the resume method did not switch it back on.

Add the necessary feature call to .resume.  Also add the corresponding
call to .suspend to make .suspend's behavior explicitly the same on all
PMacs.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This way firewire-ohci can be used for remote debugging like ohci1394.
Version with amendment from Fri, 11 Apr 2008 00:08:08 +0200.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Acked-by: NBernhard Kaindl <bk@suse.de>

Try to write dual-phase retry protocol limits to BUSY_TIMEOUT register.
- The dual-phase retry protocol is optional to implement, and if not 
  supported, writes to the dual-phase portion of the register will be
  ignored. We try to write the original 1394-1995 default here.
- In the case of devices that are also SBP-3-compliant, all writes are 
  ignored, as the register is read-only, but contains single-phase retry of
  15, which is what we're trying to set for all SBP-2 device anyway, so this
  write attempt is safe and yields more consistent behavior for all devices.

See section 8.3.2.3.5 of the 1394-1995 spec, section 6.2 of the SBP-2 spec,
and section 6.4 of the SBP-3 spec for further details.
Signed-off-by: NJarod Wilson <jwilson@redhat.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The block/unblock logic is now sufficiently tested.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

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

How hard can it be to switch on one bit? :-)
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Write directly in big endian instead of byte-swapping after the fact.
This saves a few conversions, lets gcc use constant endianess
conversions where possible, and enables deeper endianess annotation.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>