Commit Graph

524 Commits

Author SHA1 Message Date
Linus Torvalds
5e3bd4e4b1 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
  ieee1394: dv1394: move deprecation message from module init to file open
  firewire: core: Remove card from list of cards when enable fails
2009-02-06 08:48:16 -08:00
Stefan Richter
86431532ec ieee1394: dv1394: move deprecation message from module init to file open
On many Linux installations, the dv1394 driver will be auto-loaded
whenever an AV/C device (e.g. camcorder or audio device) is plugged in.
An irritating message would then appear in the kernel log.

Defer this message to until a dv1394 character device file is actually
used by a program.  Also include the program name in the message and
update the message slightly.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-02-06 15:52:28 +01:00
Linus Torvalds
ceb5eb0cb3 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
  ieee1394: sbp2: add workarounds for 2nd and 3rd generation iPods
  firewire: sbp2: add workarounds for 2nd and 3rd generation iPods
  firewire: sbp2: fix DMA mapping leak on the failure path
  firewire: sbp2: define some magic numbers as macros
  firewire: sbp2: fix payload limit at S1600 and S3200
  ieee1394: sbp2: don't assume zero model_id or firmware_revision if there is none
  ieee1394: sbp2: fix payload limit at S1600 and S3200
  ieee1394: sbp2: update a help string
  ieee1394: support for speeds greater than S800
  firewire: core: optimize card shutdown
  ieee1394: ohci1394: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others
  firewire: ohci: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others
  firewire: ohci: change "context_stop: still active" log message
  firewire: keep highlevel drivers attached during brief connection loss
  firewire: unnecessary BM delay after generation rollover
  firewire: insist on successive self ID complete events
2009-01-29 18:09:41 -08:00
Stefan Richter
1448d7c6a2 ieee1394: sbp2: add workarounds for 2nd and 3rd generation iPods
as per https://bugs.launchpad.net/bugs/294391.  These got one sample of
each iPod generation going.  However there still occurred I/O stalls
with the 3rd generation iPod which remain undiagnosed at the time of
this writing.

Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-29 20:19:49 +01:00
Stefan Richter
c1fbdd7851 ieee1394: sbp2: don't assume zero model_id or firmware_revision if there is none
This makes sbp2 behave more like firewire-sbp2 which reports 0xff000000
as immediate value if there are no unit directory entries for model_id
or firmware_revision.

It does not reduce matches with the currently existing quirks table; the
only zero entry there is for a device which actually does have a zero
model_id.  It only changes how model_id and firmware_revision are logged
if they are missing.

Other functionally unrelated changes:  The model_id member of quirks
list entries is renamed to model;  the value (but not the effect) of
SBP2_ROM_VALUE_WILDCARD is changed.  Now this part of the source is
identical with firewire-sbp2 for easier maintenance.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-28 20:31:06 +01:00
Stefan Richter
d3e3e970e3 ieee1394: sbp2: fix payload limit at S1600 and S3200
1394-2008 clause 16.3.4.1 (1394b-2002 clause 16.3.1.1) defines tighter
limits than 1394-2008 clause 6.2.2.3 (1394a-2000 clause 6.2.2.3).

Our previously too large limit doesn't matter though if the controller
reports its max_receive correctly.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-28 20:31:06 +01:00
Stefan Richter
4106ceff15 ieee1394: sbp2: update a help string
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-28 20:31:06 +01:00
Stefan Richter
82d4b90deb ieee1394: support for speeds greater than S800
The hard-wired configuration of the top speed (until now S800) was
unnecessary, remove it.

If the local link layer controller supports S1600 or S3200, we now
assume this speed for all present 1394b PHYs (except if they are
behind 1394a repeaters) until nodemgr figured out the actual speed
while fetching the config ROM.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-28 20:31:05 +01:00
Jean Delvare
1745522ccb i2c: Delete many unused adapter IDs
Signed-off-by: Jean Delvare <khali@linux-fr.org>
2009-01-26 21:19:52 +01:00
Stefan Richter
64c634ef83 ieee1394: ohci1394: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others
Camcorders have a tendency to fail read requests to their config ROM and
write request to their FCP command register with ack_busy_X.  This has
become a problem with newer kernels and especially Panasonic camcorders,
causing AV/C in dvgrab and kino to fail.  Dvgrab for example frequently
logs "send oops"; kino reports loss of AV/C control.  I suspect that
lower CPU scheduling latencies in newer kernels made this issue more
prominent now.

According to
https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103
this can be fixed by configuring the FireWire controller for more
hardware retries for request transmission; these retries are evidently
more successful than libavc1394's own retry loop (typically 3 tries on
top of hardware retries).

Presumably the same issue has been reported at
https://bugzilla.redhat.com/show_bug.cgi?id=449252 and
https://bugzilla.redhat.com/show_bug.cgi?id=477279 .

Tested-by: Mathias Beilstein
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-24 11:17:28 +01:00
David S. Miller
7f46b1343f Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6 2009-01-08 11:05:59 -08:00
Stephen Hemminger
92dc8cc317 ieee1394: use internal network device stats
Use the network_device_stats field in network_device.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-01-06 16:49:02 -08:00
Stephen Hemminger
464f4daae7 ieee1394: remove unneeded last_rx
Last_rx is now done if needed inside bonding.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-01-06 16:48:46 -08:00
Stephen Hemminger
79994c9906 ieee1394: convert to net_device_ops
Convert to net_device_ops.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-01-06 16:48:30 -08:00
Harvey Harrison
c82cdea1e1 ieee1934: dv1394: interrupt enabling/disabling broken on big-endian
After annotating the frame structs, this was left:
drivers/ieee1394/dv1394.c:2113:23: warning: invalid assignment: |=
drivers/ieee1394/dv1394.c:2113:23:    left side has type restricted __le32
drivers/ieee1394/dv1394.c:2113:23:    right side has type int
drivers/ieee1394/dv1394.c:2121:24: warning: invalid assignment: &=
drivers/ieee1394/dv1394.c:2121:24:    left side has type restricted __le32
drivers/ieee1394/dv1394.c:2121:24:    right side has type int
drivers/ieee1394/dv1394.c:2123:24: warning: invalid assignment: |=
drivers/ieee1394/dv1394.c:2123:24:    left side has type restricted __le32
drivers/ieee1394/dv1394.c:2123:24:    right side has type int

Which looks like a real bug on a big-endian arch as it would set/clear
the wrong bit.

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>

Bill Fink writes:

I finally got a chance to test the patch on my kernel, and live DV
viewing using xine still worked fine.  Although I admit to being
mystified how it works both before and after the patch, since the
cpu_to_le32() calls that were added should result in byte swapping on
PPC that wasn't being done before.  I guess that either the code paths
involved aren't actually being triggered by my xine DV viewing, or
there's some fortuitous palindromic setting of bits.

Tested-by: Bill Fink <billfink@mindspring.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-04 23:50:36 +01:00
Harvey Harrison
7d7039d365 ieee1394: dv1394: annotate frame input/output structs as little endian
No Functional changes.

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-04 23:50:36 +01:00
Harvey Harrison
faf26bcc47 ieee1394: eth1394: trivial sparse annotations
Mostly annotations of ether_type as a be16.

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-04 23:50:35 +01:00
Harvey Harrison
debb48063a ieee1394: mark bus_info_data as a __be32 array
Two access functions get_max_rom and set_hw_config_rom are
changed to take __be32 as well.  Only bus_info_data was
ever passed in so this is OK.  All other uses of bus_info_data
treated it as a be32 value already.

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-04 23:50:35 +01:00
Harvey Harrison
a5e6f64dda ieee1394: replace CSR_SET_BUS_INFO_GENERATION macro
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-04 23:50:35 +01:00
Harvey Harrison
c816015860 ieee1394: pcilynx: trivial endian annotation
bus_info_block was treated as a be32 everywhere, annotate
as such.  Removes plenty of sparse warnings.

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-04 23:50:34 +01:00
Stefan Richter
0bed181968 ieee1394: ignore nonzero Bus_Info_Block.max_rom, fetch config ROM in quadlets
It is already known that buggy firmwares exist which report a bogus
link_spd in their config ROM bus info block.  We now got the first
report of a bogus max_rom too (Freecom FireWire Hard Drive 1TB,
http://bugzilla.kernel.org/show_bug.cgi?id=12206).

I suspect other OSs only use quadlet reads to fetch the config ROM,
otherwise the firmware authors would have noticed their mistake.
Hence limit ieee1394's config ROM fetching routine to quadlets as the
safe minimum regardless of what the bus info block says.

This will potentially slow the bus reset handling by nodemgr somewhat
down.  But most existing devices support only quadlet reads anyway,
hence there will often be no actual difference to before this change.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-04 23:50:34 +01:00
Harvey Harrison
c1fc58d63d ieee1394: consolidate uses of IEEE1934_BUSID_MAGIC
Move the definition out of nodemgr.h and use it in csr.c/pcilynx.c

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-04 23:50:34 +01:00
Stefan Richter
cbe7dd699e ieee1394: ohci1394: flush MMIO writes before delay in initialization
and replace busy-wait by msleep.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-04 23:50:33 +01:00
Stefan Richter
9e234faf98 ieee1394: ohci1394: pass error codes from request_irq through
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-04 23:50:33 +01:00
Frans Pop
d1069aea68 ieee1394: ohci1394: don't leave interrupts enabled during suspend/resume
On my HP 2510p I get the following in dmesg during near the end of most
resumes from suspend to RAM:

irq 19: nobody cared (try booting with the "irqpoll" option)
Pid: 0, comm: swapper Not tainted 2.6.28-rc7 #67
Call Trace:
 <IRQ>  [<ffffffffa00ee9e1>] ? ohci_irq_handler+0x60/0x7e9 [ohci1394]
 [<ffffffff8026aa4d>] __report_bad_irq+0x38/0x87
 [<ffffffff8026abaa>] note_interrupt+0x10e/0x174
 [<ffffffff8026b262>] handle_fasteoi_irq+0xa7/0xd1
 [<ffffffff8020eb87>] do_IRQ+0x73/0xe4
 [<ffffffff8020c626>] ret_from_intr+0x0/0xa
 <EOI>  [<ffffffffa0012606>] ? acpi_idle_enter_bm+0x26b/0x2b2 [processor]
 [<ffffffffa00125fc>] ? acpi_idle_enter_bm+0x261/0x2b2 [processor]
 [<ffffffff8024f30f>] ? notifier_call_chain+0x33/0x5b
 [<ffffffff803b9c64>] ? cpuidle_idle_call+0x8c/0xc4
 [<ffffffff8020b312>] ? cpu_idle+0x4a/0x9a
 [<ffffffff8042c5c8>] ? rest_init+0x5c/0x5e
handlers:
[<ffffffffa00ee981>] (ohci_irq_handler+0x0/0x7e9 [ohci1394])
Disabling IRQ #19

There also seems to be an interrupt storm during suspend/resume when this
happens:
 19:      99968         33   IO-APIC-fasteoi   ohci1394

This patch gets rid of both issues and makes the resume as a whole
significantly faster.

Signed-off-by: Frans Pop <elendil@planet.nl>

As was pointed out in http://lkml.org/lkml/2008/12/6/127, this does not
fix the cause of the interrupt storm.  However, since the source of the
interrupts could not be determined yet, we make the system at least more
usable with this change.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-04 23:50:33 +01:00
Stefan Richter
b17a550960 ieee1394: mark all hpsb_address_ops instances as const
These are never modified.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-04 23:50:32 +01:00
Stefan Richter
adb0a61681 ieee1394: replace a GFP_ATOMIC by GFP_KERNEL allocation
All callers of hpsb_register_addrspace() can sleep.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-04 23:50:32 +01:00
Stefan Richter
25a41b2800 ieee1394: add quirk fix for Freecom HDD
According to http://bugzilla.kernel.org/show_bug.cgi?id=12206, Freecom
FireWire Hard Drive 1TB reports max_rom=2 but returns garbage if block
read requests are used to read the config ROM.  Force max_rom=0 to limit
them to quadlet read requests.

Reported-by: Christian Mueller <cm1@mumac.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-12-14 01:13:13 +01:00
Nigel Cunningham
ec9a13cdbf ieee1394: node manager causes up to ~3.25s delay in freezing tasks
The firewire nodemanager function "nodemgr_host_thread" contains a loop
that calls try_to_freeze near the top of the loop, but then delays for
up to 3.25 seconds (plus time to do work) before getting back to the top
of the loop. When starting a cycle post-boot, this doesn't seem to bite,
but it is causing a noticeable delay at boot time, when freezing
processes prior to starting to read the image.

The following patch adds invocation of try_to_freeze to the subloops
that are used in the body of this function. With these additions, the
time to freeze when starting to resume at boot time is virtually zero.
I'm no expert on firewire, and so don't know that we shouldn't check
the return value and jump back to the top of the loop or such like after
being frozen, but I submit it for your consideration.

Signed-off-by: Nigel Cunningham <nigel@tuxonice.net>

The delay until nodemgr freezes was up to 0.25s (plus time for node
probes) in Linux 2.6.27 and older and up to 3.25s (plus ~) since Linux
2.6.28-rc1, hence much more noticeable.

try_to_freeze() without any jump is correct.  The surrounding code in
the respective loops will catch whether another bus reset happens during
the freeze and handle it.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-12-09 19:34:33 +01:00
Stefan Richter
2642b11295 ieee1394: sbp2: fix race condition in state change
An intermediate transition from _RUNNING to _IN_SHUTDOWN could have been
missed by the former code.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-11-29 17:07:56 +01:00
Stefan Richter
e47c1feb17 ieee1394: fix list corruption (reported at module removal)
If there is more than one FireWire controller present, dummy_zero_addr
and dummy_max_addr were added multiple times to different lists, thus
corrupting the lists.  Fix this by allocating them dynamically per host
instead of just once globally.

(Perhaps a better address space allocation algorithm could rid us of the
two dummy address spaces.)

Fixes http://bugzilla.kernel.org/show_bug.cgi?id=10129 .

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-11-29 17:07:56 +01:00
Stefan Richter
9e0de91011 ieee1394: sbp2: another iPod mini quirk entry
Add another model ID of a broken firmware to prevent early I/O errors
by acesses at the end of the disk.  Reported at linux1394-user,
http://marc.info/?t=122670842900002

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-11-25 21:38:31 +01:00
Linus Torvalds
6572a281cf Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
  ieee1394: dv1394: fix possible deadlock in multithreaded clients
  ieee1394: raw1394: fix possible deadlock in multithreaded clients
  ieee1394: struct device - replace bus_id with dev_name(), dev_set_name()
  firewire: struct device - replace bus_id with dev_name(), dev_set_name()
2008-11-06 15:55:34 -08:00
Al Viro
233e70f422 saner FASYNC handling on file close
As it is, all instances of ->release() for files that have ->fasync()
need to remember to evict file from fasync lists; forgetting that
creates a hole and we actually have a bunch that *does* forget.

So let's keep our lives simple - let __fput() check FASYNC in
file->f_flags and call ->fasync() there if it's been set.  And lose that
crap in ->release() instances - leaving it there is still valid, but we
don't have to bother anymore.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-11-01 09:49:46 -07:00
Stefan Richter
8449fc3ae5 ieee1394: dv1394: fix possible deadlock in multithreaded clients
Fix a possible though highly unlikely deadlock:

Thread A:                  Thread B:
 - acquire mmap_sem         - dv1394_ioctl/read/write()
 - dv1394_mmap()            - acquire video->mtx
 - acquire video->mtx       - copy_to/from_user(), possible page fault:
                              acquire mmap_sem

The simplest fix is to use mutex_trylock() instead of mutex_lock() in
dv1394_mmap().  This changes the behavior under contention in a way
which is visible to userspace clients.  However, my guess is that no
clients exist which use mmap vs. ioctl/read/write on the dv1394
character device file interface in concurrent threads.

Reported-by: Johannes Weiner <hannes@saeurebad.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-10-31 08:48:26 +01:00
Stefan Richter
638570b543 ieee1394: raw1394: fix possible deadlock in multithreaded clients
Regression in 2.6.28-rc1:  When I added the new state_mutex which
prevents corruption of raw1394's internal state when accessed by
multithreaded client applications, the following possible though
highly unlikely deadlock slipped in:

Thread A:                  Thread B:
 - acquire mmap_sem         - raw1394_write() or raw1394_ioctl()
 - raw1394_mmap()           - acquire state_mutex
 - acquire state_mutex      - copy_to/from_user(), possible page fault:
                              acquire mmap_sem

The simplest fix is to use mutex_trylock() instead of mutex_lock() in
raw1394_mmap().  This changes the behavior under contention in a way
which is visible to userspace clients.  However, since multithreaded
access was entirely buggy before state_mutex was added and libraw1394's
documentation advised application programmers to use a handle only in a
single thread, this change in behaviour should not be an issue in
practice at all.

Since we have to use mutex_trylock() in raw1394_mmap() regardless
whether /dev/raw1394 was opened with O_NONBLOCK or not, we now use
mutex_trylock() unconditionally everywhere for state_mutex, just to have
consistent behavior.

Reported-by: Johannes Weiner <hannes@saeurebad.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-10-31 08:48:26 +01:00
Kay Sievers
233976e539 ieee1394: struct device - replace bus_id with dev_name(), dev_set_name()
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-10-31 08:48:25 +01:00
Linus Torvalds
1eee21abaf Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
  firewire: Add more documentation to firewire-cdev.h
  firewire: fix ioctl() return code
  firewire: fix setting tag and sy in iso transmission
  firewire: fw-sbp2: fix another small generation access bug
  firewire: fw-sbp2: enforce s/g segment size limit
  firewire: fw_send_request_sync()
  ieee1394: survive a few seconds connection loss
  ieee1394: nodemgr clean up class iterators
  ieee1394: dv1394, video1394: remove unnecessary expressions
  ieee1394: raw1394: make write() thread-safe
  ieee1394: raw1394: narrow down the state_mutex protected region
  ieee1394: raw1394: replace BKL by local mutex, make ioctl() and mmap() thread-safe
  ieee1394: sbp2: enforce s/g segment size limit
  ieee1394: sbp2: check for DMA mapping failures
  ieee1394: sbp2: stricter dma_sync
  ieee1394: Use DIV_ROUND_UP
2008-10-16 15:02:24 -07:00
Greg Kroah-Hartman
6229df31b9 device create: ieee1394: convert device_create_drvdata to device_create
Now that device_create() has been audited, rename things back to the
original call to be sane.

Cc: Ben Collins <ben.collins@ubuntu.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-10-16 09:24:42 -07:00
Stefan Richter
fc392fe831 ieee1394: survive a few seconds connection loss
There are situations when nodes vanish from the bus and come back in
quickly thereafter:
  - When certain bus-powered hubs are plugged in,
  - when certain disk enclosures are switched from self-power to bus
    power or vice versa and break the daisy chain during the transition,
  - when the user plugs a cable out and quickly plugs it back in, e.g.
    to reorder a daisy chain (works on Mac OS X if done quickly enough),
  - when certain hubs temporarily malfunction during high bus traffic.

The ieee1394 driver's nodemgr already contained a function to set
vanished nodes aside into "limbo"; i.e. they wouldn't actually be
deleted right away.  (In fact, only unloading the driver or writing into
an obscure sysfs attribute would delete them eventually.)  If nodes
reappeared later, they would be resurrected out of limbo.

Moving nodes into and out of limbo was accompanied with calling the
.suspend() and .resume() driver methods of the drivers which were bound
to a respective node's unit directories.  Not only is this somewhat
strange due to the intended use of these driver methods for power
management, also the sbp2 driver in particular does not implement
.suspend() and .resume().  Hence sbp2 would be disconnected from devices
in situations as listed above.

We now:
  - leave drivers bound when nodes go into limbo,
  - call the drivers' .update() when nodes come out of limbo,
  - automatically delete in-limbo nodes 3 seconds after the last
    bus reset and bus rescan.
  - Because of the automatic removal, the now obsolete bus attribute
    /sys/bus/ieee1394/destroy_node is removed.

This especially lets sbp2 survive brief disconnections.  You can for
example yank a disk's cable and plug it back in while reading the
respective disk with dd, but dd will happily continue as if nothing
happened.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-10-15 22:21:09 +02:00
Stefan Richter
11305c3eda ieee1394: nodemgr clean up class iterators
Remove useless pointer type casts.
Remove unnecessary hi->host indirection where only host is used.
Remove an unnecessary WARN_ON.
Change a few names.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-10-15 22:21:09 +02:00
Stefan Richter
d98562d12f ieee1394: dv1394, video1394: remove unnecessary expressions
init->channel and v.buffer are unsigned and tests for < 0 therefore
always false.  gcc knows this and eliminates the code, but anyway...
Reported by Roel Kluin.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-10-15 22:21:09 +02:00
Stefan Richter
f22e52b89e ieee1394: raw1394: make write() thread-safe
Application programs should use a libraw1394 handle only in a single
thread.  The raw1394 driver was apparently relying on this, because it
did nothing to protect its fi->state variable from corruption due to
concurrent accesses.

We now serialize the fi->state accesses.  This affects the write() path.
We re-use the state_mutex which was introduced to protect fi->iso_state
accesses in the ioctl() path.  These paths and accesses are independent
of each other, hence separate mutexes could be used.  But I don't see
much benefit in that.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-10-15 22:21:08 +02:00
Stefan Richter
ddfb908d3f ieee1394: raw1394: narrow down the state_mutex protected region
Refactor the ioctl dispatcher in order to move a fraction of it out of
the section which is serialized by fi->state_mutex.  This is not so much
about performance but more about self-documentation:  The mutex_lock()/
mutex_unlock() calls are now closer to the data accesses which the mutex
protects, i.e. to the iso_state switch.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-10-15 22:21:08 +02:00
Stefan Richter
10963ea1bd ieee1394: raw1394: replace BKL by local mutex, make ioctl() and mmap() thread-safe
This removes the last usage of the Big Kernel Lock from the ieee1394
stack, i.e. from raw1394's (unlocked_)ioctl and compat_ioctl.

The ioctl()s don't need to take the BKL, but they need to be serialized
per struct file *.  In particular, accesses to ->iso_state need to be
serial.  We simply use a blocking mutex for this purpose because
libraw1394 does not use O_NONBLOCK.  In practice, there is no lock
contention anyway because most if not all libraw1394 clients use a
libraw1394 handle only in a single thread.

mmap() also accesses ->iso_state.  Until now this was unprotected
against concurrent changes by ioctls.  Fix this bug while we are at it.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-10-15 22:21:08 +02:00
Stefan Richter
ed6ffd0808 ieee1394: sbp2: enforce s/g segment size limit
1. We don't need to round the SBP-2 segment size limit down to a
   multiple of 4 kB (0xffff -> 0xf000).  It is only necessary to
   ensure quadlet alignment (0xffff -> 0xfffc).

2. Use dma_set_max_seg_size() to tell the DMA mapping infrastructure
   and the block IO layer about the restriction.  This way we can
   remove the size checks and segment splitting in the queuecommand
   path.

   This assumes that no other code in the ieee1394 stack uses
   dma_map_sg() with conflicting requirements.  It furthermore assumes
   that the controller device's platform actually allows us to set the
   segment size to our liking.  Assert the latter with a BUG_ON().

3. Also use blk_queue_max_segment_size() to tell the block IO layer
   about it.  It cannot know it because our scsi_add_host() does not
   point to the FireWire controller's device.

We can also uniformly use dma_map_sg() for the single segment case just
like for the multi segment case, to further simplify the code.

Also clean up how the page table is converted to big endian.

Thanks to Grant Grundler and FUJITA Tomonori for advice.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-10-15 22:21:07 +02:00
Stefan Richter
cd8c79f17a ieee1394: sbp2: check for DMA mapping failures
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-10-15 22:21:07 +02:00
Stefan Richter
0a77b17c85 ieee1394: sbp2: stricter dma_sync
Two dma_sync_single_for_cpu() were called in the wrong place.
Luckily they were merely for DMA_TO_DEVICE, hence nobody noticed.

Also reorder the matching dma_sync_single_for_device() a little bit
so that they reside in the same functions as their counterparts.
This also avoids syncing the s/g table for requests which don't use it.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-10-15 22:21:07 +02:00
Julia Lawall
68e2aa793e ieee1394: Use DIV_ROUND_UP
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-10-15 22:21:07 +02:00
Stefan Richter
a3384067fb ieee1394: sbp2: let nodemgr retry node updates during bus reset series
sbp2 was too quick to report .update() to the ieee1394 core as failed.
(Logged as "Failed to reconnect to sbp2 device!".)  The core would then
unbind sbp2 from the device.

This is not justified if the .update() failed because another bus reset
happened.  We check this and tell the ieee1394 that .update() succeeded,
and the core will call sbp2's .update() for the new bus reset as well.

This improves reconnection/re-login especially on buses with several
disks as they may issue bus resets in close succession when they come
online.

Tested by Damien Benoist.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-08-19 18:47:56 +02:00