Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

bus_info_block was treated as a be32 everywhere, annotate
as such.  Removes plenty of sparse warnings.
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NStefan Richter <stefanr@s5r6.in-berlin.de>

Move the definition out of nodemgr.h and use it in csr.c/pcilynx.c
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

and replace busy-wait by msleep.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

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

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: NFrans 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: NStefan Richter <stefanr@s5r6.in-berlin.de>

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

All callers of hpsb_register_addrspace() can sleep.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NChristian Mueller <cm1@mumac.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NNigel 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: NStefan Richter <stefanr@s5r6.in-berlin.de>

An intermediate transition from _RUNNING to _IN_SHUTDOWN could have been
missed by the former code.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NStefan Richter <stefanr@s5r6.in-berlin.de>

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=122670842900002Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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: NJohannes Weiner <hannes@saeurebad.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NJohannes Weiner <hannes@saeurebad.de>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NStefan Richter <stefanr@s5r6.in-berlin.de>

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

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: NStefan Richter <stefanr@s5r6.in-berlin.de>

Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NStefan Richter <stefanr@s5r6.in-berlin.de>

nodemgr_node_probe checked for generation increments too late and
therefore prematurely reported nodes as "suspended".

Fixes http://bugzilla.kernel.org/show_bug.cgi?id=11349.  Reported and
tested by Damien Benoist.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Regression since commit 73cf6023,
"ieee1394: use class iteration api":  The two loops for (1.) driver
updates and (2.) driver probes were replaced by a single loop with
bogus needs_probe checks.  Hence updates and probes were now intermixed,
and especially sbp2 updates (reconnects) held up longer than necessary.

While we fix it, change the needs_probe flag to bool type for clarity.

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

On 32-bit architectures PAGE_ALIGN() truncates 64-bit values to the 32-bit
boundary. For example:

	u64 val = PAGE_ALIGN(size);

always returns a value < 4GB even if size is greater than 4GB.

The problem resides in PAGE_MASK definition (from include/asm-x86/page.h for
example):

#define PAGE_SHIFT      12
#define PAGE_SIZE       (_AC(1,UL) << PAGE_SHIFT)
#define PAGE_MASK       (~(PAGE_SIZE-1))
...
#define PAGE_ALIGN(addr)       (((addr)+PAGE_SIZE-1)&PAGE_MASK)

The "~" is performed on a 32-bit value, so everything in "and" with
PAGE_MASK greater than 4GB will be truncated to the 32-bit boundary.
Using the ALIGN() macro seems to be the right way, because it uses
typeof(addr) for the mask.

Also move the PAGE_ALIGN() definitions out of include/asm-*/page.h in
include/linux/mm.h.

See also lkml discussion: http://lkml.org/lkml/2008/6/11/237

[akpm@linux-foundation.org: fix drivers/media/video/uvc/uvc_queue.c]
[akpm@linux-foundation.org: fix v850]
[akpm@linux-foundation.org: fix powerpc]
[akpm@linux-foundation.org: fix arm]
[akpm@linux-foundation.org: fix mips]
[akpm@linux-foundation.org: fix drivers/media/video/pvrusb2/pvrusb2-dvb.c]
[akpm@linux-foundation.org: fix drivers/mtd/maps/uclinux.c]
[akpm@linux-foundation.org: fix powerpc]
Signed-off-by: NAndrea Righi <righi.andrea@gmail.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This mirrors the functionality that driver_find_device has as well.

We add a start variable, and all callers of the function are fixed up at
the same time.

The block layer will be using this new functionality in a follow-on
patch.


Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This mirrors the functionality that driver_for_each_device has as well.

We add a start variable, and all callers of the function are fixed up at
the same time.

The block layer will be using this new functionality in a follow-on
patch.


Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

device_create() is race-prone, so use the race-free
device_create_drvdata() instead as device_create() is going away.

Cc: Ben Collins <ben.collins@ubuntu.com>
Acked-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Currently, core files do not contain the mmapped memory of the video1394
or dv1394 devices, which contain the actual video input, making it
impossible to analyse the cause of abnormal program termination for
image analysis or (de)compression software.  Fix that.
Signed-off-by: NPhilippe De Muyter <phdm@macqel.be>

Also affects users of the rawiso ioctl API of raw1394.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Actually in this case wrap the function for now.
Signed-off-by: NAlan Cox <alan@redhat.com>

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

This prepares video1394 for removal of the BKL (big kernel lock):
It allows video1394_open() to be called while video1394_init_module()
is still in progress.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This avoids redundant messages about a special and usually harmless
firmware flaw.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>