In fw_device_init() and fw_device_refresh(), if a call to
read_cofig_rom() fails, the operation is retried a few times, with
these retries being controlled by the MAX_RETRIES and RETRY_DELAY
symbols.

fw_device_refresh() also reads part of the config rom by calling
reread_config_rom().  Any errors from this call resulted in retries
with MAX_RETRIES/2 and RETRY_DELAY/2.

There is no reason to require that a device that has initiated a bus
reset must react faster to read requests than a device that has just
been plugged in.  Furthermore, if the config rom has changed, any
errors from the following read_config_rom() call are then handled
with the normal retry count and delay.

Remove this inconsistency by always using the normal retry count and
delay.  (This also makes the two error handlers identical and allows
merging them.)
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

If reading or refreshing a config rom fails, also log the actual error
that caused it to fail.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

If the lock access to the bus manager register fails, also log the
actual error that caused it to fail.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

There is nothing audio-specific about the rcode_string() helper, so move
it from snd-firewire-lib into firewire-core to allow other code to use it.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (fixed sound/firewire/cmp.c)

The return value of reread_config_rom() was a mixture of two pieces of
information: whether the function succeeded, and whether the config rom
had changed.

To clarify the semantics, and to allow returning the actual error code,
split the second information into a new output parameter.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

When reread_config_rom() encountered a config rom that was marked as not
yet accessible, that device would be treated as "gone".  This would mean
that that device would effectively vanish until the next bus reset.

The correct way to handle this situation is the same as in
read_config_rom(), to treat this like other errors and to retry the read
later, when the (possibly changed) config rom is available.  The device
is marked "gone" only if it continues to return zero values after these
retries.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

bus_reset_work() is only called from workqueue thread context.

ohci_set_config_rom() and ohci_allocate_iso_context() perform GFP_KERNEL
memory allocations, therefore they must be called with interrupts
enabled.

Hence these functions may disable and enable local IRQs without having
to track IRQ state.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

bus_reset_work's reg is a bitfield.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Seen with recent libdc1394:  If a client mmap()s the buffer of an
isochronous reception buffer with PROT_READ|PROT_WRITE instead of just
PROT_READ, firewire-core sets the wrong DMA mapping direction during
buffer initialization.

The fix is to split fw_iso_buffer_init() into allocation and DMA mapping
and to perform the latter after both buffer and DMA context were
allocated.  Buffer allocation and context allocation may happen in any
order, but we need the context type (reception or transmission) in order
to set the DMA direction of the buffer.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This patch converts the drivers in drivers/firewire/* to use module_pci_driver()
macro which makes the code smaller and a bit simpler.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Remove all #inclusions of asm/system.h preparatory to splitting and killing
it.  Performed with the following command:

perl -p -i -e 's!^#\s*include\s*<asm/system[.]h>.*\n!!' `grep -Irl '^#\s*include\s*<asm/system[.]h>' *`
Signed-off-by: NDavid Howells <dhowells@redhat.com>

Extend the kernel and userspace APIs to allow reporting all currently
completed isochronous packets, even if the next interrupt packet has not
yet been reached.  This is required to determine the status of the
packets at the end of a paused or stopped stream, and useful for more
precise synchronization of audio streams.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The buffer for the header data of completed iso packets has a fixed
size, so it is possible to configure a stream with a big interval
between interrupt packets or with big headers so that this buffer would
overflow.  Previously, ohci.c would drop any data that would not fit,
but this could make unsuspecting applications believe that fewer than
the actual number of packets have completed.

Instead of dropping data, add calls to flush_iso_completion() so that
there are as many events as needed to report all of the data.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

In preparation for the following patches that add more flushing, move
the code for flushing accumulated header data into a common function.
The timestamp of the last completed packed is passed through the context
structure instead of a function parameter to allow accessing this value
later outside of the handle_i?_packet functions.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

When storing the header data of completed iso packets, we effectively
treat the buffers as arrays of quadlets.  Actually declaring the
pointers as u32* avoids repetitive pointer arithmetic, removes the
unhelpfully named "i" variables, and thus makes the code clearer.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Doing the endian conversion on the constant instead of the memory
field allows the compiler to do the conversion at compile time.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Commit 6498ba04 (remove unused dualbuffer IR code) overlooked
a field in struct iso_context.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The comment incorrectly talked about one little-endian quadlet, while
there are actually two.  Furthermore, the endianness of the remaining
headers depends on whatever protocol is used, so don't mention them.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

handle_ir_buffer_fill() assumed that a completed descriptor would be
indicated by a non-zero transfer_status (as in most other descriptors).
However, this field is written by the controller as soon as (the end of)
the first packet has been written into the buffer.  As a consequence, if
we happen to run into such a descriptor when the interrupt handler is
executed after such a packet has completed, the descriptor would be
taken out of the list of active descriptors as soon as the buffer had
been partially filled, so the event for the buffer being completely
filled would never be sent.

To fix this, handle descriptors only when they have been completely
filled, i.e., when res_count == 0.  (This also matches the condition
that is reported by the controller with an interrupt.)
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Cc: 2.6.36+ <stable@vger.kernel.org>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

CONFIG_FIREWIRE_OHCI_DEBUG could have been exposed to kernel tweakers
if CONFIG_EXPERT was set.  But in hindsight, this stuff is far too
useful to omit it.  So get rid of two #else branches that are only
going to bitrot otherwise.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The "skipped bus generations" message was added together with the
respective fw_device retaining/ reviving code in order to see how it all
works out.  It did well, so don't spam the log anymore.

The "register access failure" situation still needs an actual handler.
But at this point it makes less sense to ask folks to send mails about
it.  We now have a pretty good picture of what controllers emit this and
when:

Texas Instruments PCIxx21 FireWire + CardBus + flash memory card
controller:
https://bugzilla.redhat.com/show_bug.cgi?id=608544

O2 Micro FireWire + flash memory card controller:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801719
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/881688
http://marc.info/?l=linux1394-devel&m=132309283531423
http://marc.info/?l=linux1394-devel&m=132368567907469
http://marc.info/?l=linux1394-devel&m=132516165727468
http://marc.info/?l=linux1394-devel&m=133006486927699

Pinnacle Movieboard:
commit 7f7e3711
http://marc.info/?l=linux1394-devel&m=130714243325962Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

sbp2_send_management_orb() is called by sbp2_login, sbp2_reconnect, and
sbp2_remove, all which are able to sleep during memory allocations.
Actually, sbp2_send_management_orb() itself is a sleeping function.

Login and remove could allocate with GFP_KERNEL but reconnect needs
GFP_NOIO to ensure progress in low memory situations.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

SCSI sense data in SBP-2/3 is carried in an unusual format that means we
have to un-mangle it on our end before we pass it to the SCSI subsystem.
Currently our un-mangling code doesn't quite follow the SBP-2 standard
in that we always assume Current and never Deferred error types, we
never set the VALID bit, and we mishandle the FILEMARK, EOM and ILI
bits.

This patch fixes the sense un-mangling to correctly handle those and
follow the spec.
Signed-off-by: NChris Boot <bootc@bootc.net>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The firewire-sbp2 module tries to login to an SBP-2/3 target even when
it is running on the local node, which fails because of the inability to
fetch data from DMA mapped regions using firewire transactions on the
local node. It also doesn't make much sense to have the initiator and
target on the same node, so this patch prevents this behaviour.
Signed-off-by: NChris Boot <bootc@bootc.net>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changed the comment)

If the target's unit directory contains a Unit_Unique_ID entry, we
should use that as the target's GUID for identification purposes. The
SBP-2 standards document says:

"Although the node unique ID (EUI-64) present in the bus information
block is sufficient to uniquely identify nodes attached to Serial Bus,
it is insufficient to identify a target when a vendor implements a
device with multiple Serial Bus node connections. In this case initiator
software requires information by which a particular target may be
uniquely identified, regardless of the Serial Bus access path used."

[ IEEE T10 P1155D Revision 4, Section 7.6 (page 51) ] and
[ IEEE T10 P1467D Revision 5, Section 7.9 (page 74) ]
Signed-off-by: NChris Boot <bootc@bootc.net>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Use the macro DMA_BIT_MASK instead of the constant  0xffffffff
Signed-off-by: NSantosh Nayak <santoshprasadnayak@gmail.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

fw_core_handle_request() is called by the low-level driver in tasklet
context or process context, and fw_core_add/remove_address_handler() is
called by mid- or high-level code in process context.  So convert
address_handler_lock accesses from those which disable local IRQs to
ones which just disable local softIRQs.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Fix the following unlikely but possible race:

CPU 1                             CPU 2
------------------------------------------------------------------------
AR-request tasklet
    lookup handler
                                  unregister handler
				  free handler->callback_data or handler
    call handler->callback

The application which registered the handler has no way to stop nodes
sending new requests to their address range, hence cannot prevent this
race.

Fix it simply by extending the address_handler_lock-protected region
from only around the lookup to around both lookup and call.  We only
need to do so in the exclusive region handler; the FCP region handler
already holds the lock around the handler->callback call.

Alas this removes the current ability to execute the callback in
parallel on different CPUs if it was called for different FireWire cards
at the same time.  (For a single card, the handler is already
serialized.)  If this loss of a rather obscure feature is not tolerable,
a more complex fix would be required:  Add a handler reference counter;
wait in fw_core_remove_address_handler() for this conter to become zero.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Target-like applications or peer-to-peer-like applications require the
global address handler registration which we have right now, or a per-
card registration.  And node lookup, while it would be nice to have,
would be impossible in the brief time between self-ID-complete event and
completion of firewire-core's topology scanning.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Associate all log messages from firewire-core with the respective card
because some people have more than one card.  E.g.
    firewire_ohci 0000:04:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0
    firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0
    firewire_core: created device fw0: GUID 0814438400000389, S800
    firewire_core: phy config: new root=ffc1, gap_count=5
    firewire_core: created device fw1: GUID 0814438400000388, S800
    firewire_core: created device fw2: GUID 0001d202e06800d1, S800
turns into
    firewire_ohci 0000:04:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0
    firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0
    firewire_core 0000:04:00.0: created device fw0: GUID 0814438400000389, S800
    firewire_core 0000:04:00.0: phy config: new root=ffc1, gap_count=5
    firewire_core 0000:05:00.0: created device fw1: GUID 0814438400000388, S800
    firewire_core 0000:04:00.0: created device fw2: GUID 0001d202e06800d1, S800

This increases the module size slightly; to keep this in check, turn the
former printk wrapper macros into functions.  Their implementation is
largely copied from driver core's dev_printk counterparts.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Change the log line prefix from "firewire_net: " to "net firewire0: "
etc. for the case that several RFC 2734 interfaces are being used in the
same machine.

Note, the netdev_printk API is not very useful to firewire-net.
netdev_notice(net, "abc\n") would result in irritating messages like
"firewire_ohci 0000:0a:00.0: firewire0: abc".  Nor would a dev_printk on
the fw_unit.device to which firewire-net is being bound be useful,
because there are generally multiple ones of those per interface (from
all RFC 2734 peers on the bus, the local node being only one of them).

In the initialization message of each interface, log the PCI device
name of the card which is parent of the netdevice instead of the GUID
of the peer which was semi-randomly used to establish the netdevice.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

On second thought, there is little reason to have driver name differ
from module name.  Therefore, change
    /sys/bus/firewire/drivers/net
    /sys/bus/firewire/devices/fw0.0/driver -> [...]/net
    /sys/module/firewire_net/drivers/firewire:net
to
    /sys/bus/firewire/drivers/firewire_net
    /sys/bus/firewire/devices/fw0.0/driver -> [...]/firewire_net
    /sys/module/firewire_net/drivers/firewire:firewire_net
It is redundant but consistent with firewire-sbp2's recently changed
driver name.

I don't see this anywhere used, so it should not matter either way.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Commit eba9ebaa "firewire: sbp2: use dev_printk API" changed
messages from e.g.
    firewire_sbp2: fw3.0: logged in to LUN 0000 (0 retries)
to
    sbp2 fw3.0: logged in to LUN 0000 (0 retries)
because the driver calls itself as "sbp2" when registering with driver
core and with SCSI core.  This is of course confusing, so switch to the
name "firewire_sbp2" for driver core in order to match what lsmod and
/sys/module/ show.  So we are back to
    firewire_sbp2 fw3.0: logged in to LUN 0000 (0 retries)
in the kernel log.

This also changes
    /sys/bus/firewire/drivers/sbp2
    /sys/bus/firewire/devices/fw3.0/driver -> [...]/sbp2
    /sys/module/firewire_sbp2/drivers/firewire:sbp2
to
    /sys/bus/firewire/drivers/firewire_sbp2
    /sys/bus/firewire/devices/fw3.0/driver -> [...]/firewire_sbp2
    /sys/module/firewire_sbp2/drivers/firewire:firewire_sbp2

but "cat /sys/class/scsi_host/host27/proc_name" stays "sbp2" just in
case that proc_name is used by any userland.

The transport detection in lsscsi is not affected.  (Tested with lsscsi
version 0.25.)  Udev's /dev/disk/by-id and by-path symlinks are not
affected either.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The PCIe device

    FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd FireWire Host Controller
    [1180:e832] (prog-if 10 [OHCI])

is unable to access attached FireWire devices when MSI is enabled but
works if MSI is disabled.
http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28251.html

Hence add the "disable MSI" quirks flag for this device, or in fact for
safety and simplicity for all current (R5U230, R5U231, R5U240) and
future Ricoh PCIe 1394 controllers.
Reported-by: NStefan Thomas <kontrapunktstefan@googlemail.com>
Cc: 2.6.36+ <stable@vger.kernel.org>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The Audigy's SB1394 controller is actually from Texas Instruments
and has the same bus reset packet generation bug, so it needs the
same quirk entry.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Cc: 2.6.36+ <stable@vger.kernel.org>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

All messages are uniformly prefixed by driver name and device name now.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

All messages are uniformly prefixed by driver name and device name now.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

fw_unit device drivers invariably need to talk to the fw_unit's parent
(an fw_device) and grandparent (an fw_card).  firewire-core already
maintains an fw_card reference for the entire lifetime of an fw_device.
Likewise, let firewire-core maintain an fw_device reference for the
entire lifetime of an fw_unit so that fw_unit drivers don't have to.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

module_param(bool) used to counter-intuitively take an int.  In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.

It's time to remove the int/unsigned int option.  For this version
it'll simply give a warning, but it'll break next kernel version.
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Ensure that the EXPORT_SYMBOL macros are present for when we clean up
the "module.h" is everywhere situation, to prevent build failures.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>