BUG() at this place is wrong.  (Unless if the low level driver would
already do higher-level input validation of incoming request headers.)

Invalid incoming requests or bugs in the controller which corrupt the
AR-req buffer needlessly crashed the box because this is run in tasklet
context.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

If userspace ignores the POLLERR bit from poll(), and only attempts to
read() the device when POLLIN is set, it can still make ioctl() calls on
a device that has been removed from the system.  The node_id and
generation returned by GET_INFO will be outdated, but INITIATE_BUS_RESET
would still cause a bus reset, and GET_CYCLE_TIMER will return data.
And if you guess the correct generation to use, you can send requests to
a different device on the bus, and get responses back.

This patch prevents open, ioctl, compat_ioctl, and mmap against shutdown
devices.
Signed-off-by: NJay Fenlason <fenlason@redhat.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

 - struct scsi_cmnd had a 16 bytes command buffer of its own.
   This is an unnecessary duplication and copy of request's
   cmd. It is probably left overs from the time that scsi_cmnd
   could function without a request attached. So clean that up.

 - Once above is done, few places, apart from scsi-ml, needed
   adjustments due to changing the data type of scsi_cmnd->cmnd.

 - Lots of drivers still use MAX_COMMAND_SIZE. So I have left
   that #define but equate it to BLK_MAX_CDB. The way I see it
   and is reflected in the patch below is.
   MAX_COMMAND_SIZE - means: The longest fixed-length (*) SCSI CDB
                      as per the SCSI standard and is not related
                      to the implementation.
   BLK_MAX_CDB.     - The allocated space at the request level

 - I have audit all ISA drivers and made sure none use ->cmnd in a DMA
   Operation. Same audit was done by Andi Kleen.

(*)fixed-length here means commands that their size can be determined
   by their opcode and the CDB does not carry a length specifier, (unlike
   the VARIABLE_LENGTH_CMD(0x7f) command). This is actually not exactly
   true and the SCSI standard also defines extended commands and
   vendor specific commands that can be bigger than 16 bytes. The kernel
   will support these using the same infrastructure used for VARLEN CDB's.
   So in effect MAX_COMMAND_SIZE means the maximum size command
   scsi-ml supports without specifying a cmd_len by ULD's
Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

Makes the good-by message more informative.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NJarod Wilson <jwilson@redhat.com>

Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>

None of these files use any of the functionality promised by
asm/semaphore.h.  It's possible that they rely on it dragging in some
unrelated header file, but I can't build all these files, so we'll have
fix any build failures as they come up.
Signed-off-by: NMatthew Wilcox <willy@linux.intel.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>

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

Add wrappers for getting and putting a unit.
Remove some line breaks.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NJarod Wilson <jwilson@redhat.com>

The reference count of the unit dropped too low in an error path in
sbp2_probe.  Fixed by moving the _get further up.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NJarod Wilson <jwilson@redhat.com>

The card->kref became obsolete since patch "firewire: fix crash in
automatic module unloading" added another counter of card users.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NJarod Wilson <jwilson@redhat.com>

There's an ugly little memory leak in firewire-ohci's
ar_context_tasklet(), where we're not freeing up some of the memory we
use for each ar_buffer, due to a moving pointer. The problem has been
there for a while, but didn't get noticed until after converting the AR
routines over to use coherent DMA and I started running into I/O stall-
outs with the following message output repeatedly to the console:

PCI-DMA: Out of IOMMU space for 53248 bytes at device 0000:04:09.0

Plugging this leak is definitely necessary, but unfortunately, isn't the
entire answer to my problem, it only increases the amount of I/O that I
can do before hitting the problem. Still working on tracking down the
root cause..
Signed-off-by: NJarod Wilson <jwilson@redhat.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This fixes a use-after-free bug in the handling of split transactions.
The AT DMA handler of the request was occasionally executed after the
AR DMA handler of the response.  The AT DMA handler then accessed an
already freed packet.

Reported by Johannes Berg.
http://bugzilla.kernel.org/show_bug.cgi?id=9617Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Tested-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJarod Wilson <jwilson@redhat.com>

Shut up "may be used uninitialised in this function" warnings due to
PPC32's implementation of dma_alloc_coherent().
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>