Commit graph

87 commits

Author SHA1 Message Date
Vegard Nossum
004cdb5a71 ieee1394: annotate bitfield
Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
2009-06-15 15:49:29 +02:00
Stefan Richter
c64094684d ieee1394: constify device ID tables
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-03-24 20:56:53 +01:00
Stefan Richter
9c939e4df4 ieee1394: inherit ud vendor_id from node vendor_id
While Module_Vendor_ID in the configuration ROM's root directory is
mandatory, there often aren't vendor IDs in unit directories.  This
affects the new firedtv driver which is meant to be auto-loaded and
matched only for vendor-specific devices.

We now always copy ne->vendor_id into ud->vendor_id before we scan a
unit directory (and fill in a possibly present vendor ID from there).
This way, the root directory's vendor ID is used as fallback in the
"uevent" environment for modprobe'ing per module alias when a node was
plugged in, and in the driver match routine when protocol drivers are
bound to unit directories.  It will however not be used as sysfs
attribute of a unit directory device.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-02-24 14:51:27 +01:00
Stefan Richter
29f8ea8ab0 ieee1394: use correct barrier types between accesses of nodeid and generation
A compiler barrier (explicit on the read side, implicit on the write
side) is not quite enough for what has to be accomplished here.  Use
hardware memory barriers on systems which need them.

(Of course a full fix of generation handling would require much more
than this.  The ieee1394 core's bus generation counter had to be tied to
the controller's bus generation counter; cf. Kristian's stack.  It's
just that I have other current business with the code around these
barrier()s, so why not do at least this small fix.)

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-02-24 14:51:26 +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
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
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
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
c921a97457 ieee1394: don't drop nodes during bus reset series
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: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-08-19 18:47:55 +02:00
Stefan Richter
6848408abf ieee1394: regression in 2.6.25: updates should happen before probes
Regression since commit 73cf60232e,
"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: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-08-19 18:47:55 +02:00
Greg Kroah-Hartman
695794ae0c Driver Core: add ability for class_find_device to start in middle of list
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: Greg Kroah-Hartman <gregkh@suse.de>
2008-07-21 21:54:47 -07:00
Greg Kroah-Hartman
93562b5376 Driver Core: add ability for class_for_each_device to start in middle of list
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: Greg Kroah-Hartman <gregkh@suse.de>
2008-07-21 21:54:47 -07:00
Linus Torvalds
886c35fbcf 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: fw-sbp2: log scsi_target ID at release
  ieee1394: fix NULL pointer dereference in sysfs access
2008-05-01 11:31:38 -07:00
Stefan Richter
07c7224cf7 ieee1394: fix NULL pointer dereference in sysfs access
Regression since "ieee1394: prevent device binding of raw1394,
video1394, dv1394", commit d2ace29fa4:
$ cat /sys/bus/ieee1394/drivers/raw1394/device_ids
triggers a NULL pointer dereference in fw_show_drv_device_ids.
Reported by Miles Lane.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Tested-by: Miles Lane <miles.lane@gmail.com>
2008-05-01 19:55:23 +02:00
Matthew Wilcox
6188e10d38 Convert asm/semaphore.h users to linux/semaphore.h
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
2008-04-18 22:22:54 -04:00
Stefan Richter
d2ace29fa4 ieee1394: prevent device binding of raw1394, video1394, dv1394
These drivers don't need to match any unit_directory type device.
They just need the id_table for module autoloading per module alias.

Not binding any of these drivers allows special-purpose drivers with
similar or same IDs to bind to devices.  This currently only benefits
out-of-tree drivers; on the other hand it is in no way detrimental to
in-tree drivers.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-04-18 17:55:29 +02:00
Dave Young
73cf60232e ieee1394: use class iteration api
Convert to use the class iteration api.

Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-01-24 20:40:44 -08:00
Stefan Richter
17a19b795e ieee1394: csr1212: proper refcounting
At least since nodemgr got rid of coarse global locking, accesses to
struct csr1212_keyval's reference counter should be atomic and coupled
with proper barriers.  Also, calls to csr1212_keep_keyval(kv) should
occur before kv is being used.

(We probably should convert refcnt to struct kref, but how to keep
csr1212_destroy_keyval's implementation non-recursively then?)

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-10-16 23:59:59 +02:00
Stefan Richter
638d5bb816 ieee1394: nodemgr: fix leak of struct csr1212_keyval
csr1212_keep_keyval(kv) in nodemgr_process_root_directory was
unbalanced if ne->vendor_name_kv already exists.  This happens for
example if eth1394 or raw1394 modify the local config ROM and it is
parsed again.

As a bonus, the attempt to add the vendor_name_kv sysfs attribute
when it already exists is now fixed for good.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-10-16 23:59:58 +02:00
Satyam Sharma
69e2b60296 ieee1394: Fix kthread stopping in nodemgr_host_thread
The nodemgr host thread can exit on its own even when kthread_should_stop
is not true, on receiving a signal (might never happen in practice, as
it ignores signals). But considering kthread_stop() must not be mixed with
kthreads that can exit on their own, I think changing the code like this
is clearer. This change means the thread can cut its sleep short when
receive a signal but looking at the code around, that sounds okay (and
again, it might never actually recieve a signal in practice).

Signed-off-by: Satyam Sharma <satyam@infradead.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-10-16 23:59:56 +02:00
Kay Sievers
7eff2e7a8b Driver core: change add_uevent_var to use a struct
This changes the uevent buffer functions to use a struct instead of a
long list of parameters. It does no longer require the caller to do the
proper buffer termination and size accounting, which is currently wrong
in some places. It fixes a known bug where parts of the uevent
environment are overwritten because of wrong index calculations.

Many thanks to Mathieu Desnoyers for finding bugs and improving the
error handling.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-10-12 14:51:01 -07:00
Rafael J. Wysocki
8314418629 Freezer: make kernel threads nonfreezable by default
Currently, the freezer treats all tasks as freezable, except for the kernel
threads that explicitly set the PF_NOFREEZE flag for themselves.  This
approach is problematic, since it requires every kernel thread to either
set PF_NOFREEZE explicitly, or call try_to_freeze(), even if it doesn't
care for the freezing of tasks at all.

It seems better to only require the kernel threads that want to or need to
be frozen to use some freezer-related code and to remove any
freezer-related code from the other (nonfreezable) kernel threads, which is
done in this patch.

The patch causes all kernel threads to be nonfreezable by default (ie.  to
have PF_NOFREEZE set by default) and introduces the set_freezable()
function that should be called by the freezable kernel threads in order to
unset PF_NOFREEZE.  It also makes all of the currently freezable kernel
threads call set_freezable(), so it shouldn't cause any (intentional)
change of behaviour to appear.  Additionally, it updates documentation to
describe the freezing of tasks more accurately.

[akpm@linux-foundation.org: build fixes]
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Nigel Cunningham <nigel@nigel.suspend2.net>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Gautham R Shenoy <ego@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-17 10:23:02 -07:00
Al Viro
51ec138c64 ieee1394: forgotten dereference...
Going through the string and waiting for _pointer_ to become '\0'
is not what the authors meant...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Ben Collins <ben.collins@ubuntu.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-15 16:40:51 -07:00
Stefan Richter
a0e857eeff ieee1394: nodemgr: parallelize between several hosts
Remove the global nodemgr_serialize mutex which enclosed most of the
host thread event loop.  This allows for parallelism between several
host adapter cards.

Properly serialize the driver hooks .update(), .suspend(), .resume(),
and .remove() by means of device->sem.  These hooks can be called from
outside the host threads' contexts.

Get() and put() the device.driver when calling its hooks.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-07-10 00:07:39 +02:00
Kay Sievers
dd7f2928d8 ieee1394: convert ieee1394 from "struct class_device" to "struct device"
Here is a straightforward conversion to "struct device". The "struct
class_device" will be removed from the kernel.

It seems to work fine for me with and without CONFIG_SYSFS_DEPRECATED
set.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-07-10 00:07:39 +02:00
Stefan Richter
d7794c8668 ieee1394: sbp2: offer SAM-conforming target port ID in sysfs
With "modprobe sbp2 long_ieee1394_id=y", the format of
/sys/bus/scsi/devices/*:*:*:*/ieee1394_id is changed from e.g.
0001041010004beb:0:0 to 0001041010004beb:00042c:0000.

The longer format fully conforms to object identifier sizes as per
SAM(-2...4) and reflects what the SAM target port identifier is meant to
contain:  A Discovery ID allegedly specified by ISO/IEC 13213:1994 ---
however there is no such thing; the authors of SAM probably meant
Directory ID).  Especially target nodes with multiple dynamically added
targets may use Directory IDs to persistently identify target ports.

The new format is independent of implementation details of nodemgr.
Thus the same ieee1394_id attribute format can be implemented in the new
firewire stack.

The ieee1394_id is typically used to create persistently named links in
/dev/disk/by-id.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-05-31 21:40:13 +02:00
Stefan Richter
a52938f3e2 ieee1394: fix calculation of sysfs attribute "address"
struct csr1212_keyval.offset is relative to 0xffff f000 0000 rather than
0xffff f000 0400.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-05-31 21:40:13 +02:00
Michael Opdenacker
59c51591a0 Fix occurrences of "the the "
Signed-off-by: Michael Opdenacker <michael@free-electrons.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
2007-05-09 08:57:56 +02:00
Stefan Richter
9be51c5d78 ieee1394: nodemgr: unify some error messages
Shrinks object file size a little bit.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-04-30 00:00:30 +02:00
Stefan Richter
9324547235 ieee1394: nodemgr: less noise in dmesg
Everytime when eth1394 or a libraw1394 client updates the configuration
ROM, a certain sysfs attribute cannot be added since it already exists.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-04-30 00:00:29 +02:00
Stefan Richter
9543a931dc ieee1394: some more includes
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-04-30 00:00:29 +02:00
Stefan Richter
7fb9addba8 ieee1394: drop csr1212's support for external compilation
csr1212 was written to be compiled either as part of the ieee1394 kernel
driver or of an anticipated IEEE 1212 userspace library.  We now drop
support for the latter.  The costs in terms of code footprint and depth
of abstraction are not countered by any actual benefit.

Also remove some obsolete #includes.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-04-30 00:00:28 +02:00
Stefan Richter
afd6546d8d ieee1394: move some comments from declaration to definition
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-04-30 00:00:28 +02:00
Stefan Richter
ef8153348f ieee1394: remove declarations of nonexisting functions
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-04-30 00:00:27 +02:00
Greg Kroah-Hartman
a2a0f74dc1 IEEE1394: remove rwsem use from ieee1394 core
The subsystem rwsem is not used by the driver core at all, so the use of
it in the ieee1394 code doesn't make any sense.  They might possibly
want to use a local lock, but as most of these operations are already
protected by a local lock, it really doesn't look like it would be
needed.

Cc: Ben Collins <bcollins@debian.org>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: linux1394-devel <linux1394-devel@lists.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-04-27 10:57:30 -07:00
Eric Rannaud
bf62456eb9 uevent: use add_uevent_var() instead of open coding it
Make use of add_uevent_var() instead of (often incorrectly) open coding it.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Eric Rannaud <eric.rannaud@gmail.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-04-27 10:57:29 -07:00
Stefan Richter
a65421ea3f ieee1394: fix another deadlock in nodemgr
A "modprobe ohci1394; sleep 1.5; modprobe -r ohci1394" could get stuck
in uninterruptible state, especially if an external node was connected.
http://bugzilla.kernel.org/show_bug.cgi?id=7792

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-02-17 14:41:18 +01:00
Stefan Richter
91efa46205 ieee1394: fix host device registering when nodemgr disabled
Since my commit 8252bbb136 in 2.6.20-rc1,
host devices have a dummy driver attached.  Alas the driver was not
registered before use if ieee1394 was loaded with disable_nodemgr=1.

This resulted in non-functional FireWire drivers or kernel lockup.
http://bugzilla.kernel.org/show_bug.cgi?id=7942

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-02-08 21:36:22 +01:00
Adrian Bunk
e658bc556b the scheduled IEEE1394_OUI_DB removal
This patch contains the scheduled IEEE1394_OUI_DB removal.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

Update: Also remove drivers/ieee1394/.gitignore.
Remove now unused struct members in drivers/ieee1394/nodemgr.h.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-02-08 20:57:43 +01:00
Stefan Richter
1e4f7bc8f8 ieee1394: nodemgr: remove a kcalloc
Was I sleepwalking when I wrote this?

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2006-12-07 23:12:16 +01:00
Ben Collins
ed30c26ee8 ieee1394: Consolidate driver registering
This patch consolidates some bookkeeping for driver registering. It
closely models what pci_register_driver() does. The main addition is
that the owner of the driver is set, so we get a proper symlink
for /sys/bus/ieee1394/driver/*/module.

Also moves setting of name and bus type into nodemgr. Because of this,
we can remove the EXPORT_SYMBOL for ieee1394_bus_type, since it's now
only used in ieee1394.ko.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2006-12-07 23:11:55 +01:00
Stefan Richter
d41bba2d3a ieee1394: nodemgr: spaces to tabs
whitespace pedantry

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2006-12-07 23:11:28 +01:00
Stefan Richter
8252bbb136 ieee1394: nodemgr: fix deadlock in shutdown
If "modprobe ohci1394" was quickly followed by "modprobe -r ohci1394",
say with 1 second pause in between, the modprobe -r got stuck in
uninterruptible sleep in kthread_stop.  At the same time the knodemgrd
slept uninterruptibly in bus_rescan_devices_helper.  That's because
driver_detach took the semaphore of the PCI device and
bus_rescan_devices_helper wanted to take the semaphore of the FireWire
host device's parent, which is the same semaphore. This was a regression
since Linux 2.6.16, commit bf74ad5bc4,
"Hold the device's parent's lock during probe and remove".

The fix (or workaround) adds a dummy driver to the hpsb_host device. Now
bus_rescan_devices_helper won't scan the host device anymore.  This
doesn't hurt since we have no drivers which will bind to these devices
and it is unlikely that there will ever be such a driver.  The dummy
driver is befittingly presented as a representation of ieee1394 itself.

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

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2006-12-07 23:10:23 +01:00
Stefan Richter
cec1a31196 ieee1394: nodemgr: remove duplicate assignment
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2006-12-07 23:06:05 +01:00
Stefan Richter
1f72cf5251 ieee1394: nodemgr: take it easy if bus_rescan_devices fails
This happens.  No need to log a BUG trace.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2006-12-07 21:44:15 +01:00
Eric Sesterhenn
bfe89d7245 drivers/ieee1394/*: use kmemdup()
Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2006-12-07 21:43:02 +01:00
Randy Dunlap
7f5880394c ieee1394: fix printk format warning
Fix printk format warning:
drivers/ieee1394/nodemgr.c:364: warning: long long unsigned int format, u64 arg (arg 3)

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2006-12-07 21:32:19 +01:00
Stefan Richter
b07375b155 ieee1394: nodemgr: revise semaphore protection of driver core data
- 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: Stefan Richter <stefanr@s5r6.in-berlin.de>
2006-12-07 21:32:10 +01:00