Fixes http://bugzilla.kernel.org/show_bug.cgi?id=7431
iBook G3 threw a machine check exception and put the display backlight
to full brightness after ohci1394 was unloaded and reloaded.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Move the body of a function into its only caller.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Some people actually look at those comments.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

It's OK to reorder list_del() and sbp2util_free_command_dma() here.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

"struct scsi_id_instance_data" represents a logical unit.
Rename it to "struct sbp2_lu", and "scsi_id" to "lu".
Rename some other variables too.
Wrap almost all lines after at most 80 columns.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

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

It's 2^20 bit/s, not 0.001 bit.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Prepend sbp2*_ to anything globally defined in sbp2.c except for some
macros.  Strip sbp2_ from names of struct members.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

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

And update and reformat remaining comments.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This work is not delayed.

Also bring the code format in a state which reduces my work to merge
pending sbp2 patchs.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Adjust parentheses, indentation, line lengths.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

No need to keep them in released sources.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Replace some calls to SBP2_ERR and SBP2_WARN by SBP2_INFO.
Remove logging macros SBP2_NOTICE and SBP2_WARN.
Remove direct usage of HPSB_ logging macros.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The same case is handled further below in sbp2scsi_complete_command.
Note, the second version behaves slightly different but looks
preferable.  It's an extremely unlikely case by the way.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This has been within #if 0 for a long time and is wrong anyway.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Remove unnecessary function prototypes.
Remove variable names from function prototypes.
Move declarations from sbp2.h to sbp2.c.
Move definitions of driver templates together near the top of sbp2.c.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

The queue depth can be read from /sys/bus/scsi/devices/*/queue_depth,
so don't log it.  And the hint about speed improvements is misleading,
at least under current kernels.  If serialization is switched off, read
performance is typically increased by less than 10%.  (I did not test
write performance recently.)  On the other hand, serialize_io=0 is not
yet safe due to some implementation issues that are not trivial to fix.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

To print irq number no need to transform to string using %d, then print
using %s. Just use %d.
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>

This happens.  No need to log a BUG trace.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Signed-off-by: NEric Sesterhenn <snakebyte@gmx.de>
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

 - correct thinko in one of my last commits: cannot use PRINT macro with
   ohci == NULL
 - add log messages on ohci == NULL and on pci_enable_device != 0
 - update log macros from patch "revert fail on error in suspend" to use
   PRINT and DBGMSG where possible
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Some errors during preparation for suspended state can be skipped with a
warning instead of a failure of the whole suspend transition, notably an
error in pci_set_power_state.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Only build IEEE1394 OUI database files if the config option is enabled.
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Fix printk format warning:
drivers/ieee1394/nodemgr.c:364: warning: long long unsigned int format, u64 arg (arg 3)
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

 - The list "struct class.children" is supposed to be protected by
   class.sem, not by class.subsys.rwsem.

 - nodemgr_remove_uds() iterated over nodemgr_ud_class.children without
   proper protection.  This was never observed as a bug since the code
   is usually only accessed by knodemgrd.  All knodemgrds are currently
   globally serialized.  But userspace can trigger this code too by
   writing to /sys/bus/ieee1394/destroy_node.

 - Clean up access to the FireWire bus type's subsys.rwsem:  Access it
   uniformly via ieee1394_bus_type.  Shrink rwsem protected regions
   where possible.  Expand them where necessary.  The latter wasn't a
   problem so far because knodemgr is globally serialized.

This should harden the interaction of ieee1394 with sysfs and lay ground
for deserialized operation of multiple knodemgrds and for implementation
of subthreads for parallelized scanning and probing.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Give better names to local variables.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

One hunk in "ieee1394: handle sysfs errors" was wrong.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Purges the one remaining call to lock_kernel() from the 1394 subsystem.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

video1394 does not need to take the BKL. The data structures shared between
file_operations and interrupts are already protected through context-specific
spinlocks.

The only other danger is video1394_release() being called during another
operation, however this cannot happen because release is only ever invoked
when the last thread has closed the fd.
Signed-off-by: NDaniel Drake <ddrake@brontes3d.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Add some GCC branch prediction optimizations to unlikely error/safety
conditions in the ioctl handling code commonly called during an application's
capture loop.
Signed-off-by: NDaniel Drake <ddrake@brontes3d.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Handle driver core errors with as much care as appropriate.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Some 80-columns pedantry, and touch up of a // comment.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

We need the mutex only around the iteration over existing hosts.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

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

Reorder the definitions of ohci1394_pci_suspend and _resume.  Remove
redundant comments.  Beautify return statements.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

I did a quick shot on what I described and the appended patch
does the first thing needed for working suspend/resume
in ohci1394 which is HW de- and re-initialisation.

It works with suspend2disk on my Ricoh R5C552 IEEE 1394 Controller
with the 2.6.17 kernel to the extent that if I call dvgrab --interactive
after suspend2disk without unloading ohci1394, it does not lock up
dvgrab with 100% CPU but properly connects to the camera, given
that I first unplug and plug the camera after coming back from
suspend.

I guess that could be fixed by forcing a bus reset in the resume
function.

I cannot test suspend to RAM here at the moment and should
follow the guidelines in Documentation/power/pci.txt also,
so this is rather a quick report than a finished patch and
there are some rough edges:

However, with this patch, I have to unload at least some in-kernel
users of ohci1394 like dv1394 or video1394 before suspending.

Not doing that caused an Oops and a bad tasklet error, probably from
not handling ISO tasklets during suspend/resume properly.

Maybe these can be temporarily cleared or unregistered and
re-registered for suspend/resume with help from the other
layers or from the highlevel 1394 core, but I do not really
know what these do.

But this patch provides a useful base to start from and is
already of much help for people which do not need dv1394
and video1394 or can unload them at least during suspend.

I cannot test function with sbp2 at the moment, but raw1394
seems to work fine.
Signed-off-by: NBernhard Kaindl <bk@fsfe.org>

Update 1: merge with previous two ohci1394 suspend/resume patches
Update 2: version for application on top of Linux 2.6.19-rc4
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Add a who-is-who about some locks and list heads in raw1394's struct
definitions.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Put the target's fetch agent into reset state before the underlying ORB
DMA is unmapped and the ->done handler is called.  It is highly unlikely
but the target could access that ORB right before sbp2 sends the reset
request.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

struct hpsb_highlevel's struct module *owner is neither used by the IEEE
1394 core nor set by any of the in-tree drivers or the two out-of-tree
highlevel drivers I know about (dfg1394, mem1394) --- nor is this member
documented.  An unscheduled removal seems acceptable.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>