kernel/git/stable/linux.git/drivers/ieee1394/nodemgr.h, branch master

ieee1394: remove the old IEEE 1394 driver stack

2010-10-11T12:48:03+00:00

The drivers - ohci1394 (controller driver) - ieee1394 (core) - dv1394, raw1394, video1394 (userspace ABI) - eth1394, sbp2 (protocol drivers) are replaced by - firewire-ohci (controller driver) - firewire-core (core and userspace ABI) - firewire-net, firewire-sbp2 (protocol drivers) which are more featureful, better performing, and more secure than the older drivers; all with a smaller and more modern code base. The driver firedtv in drivers/media/dvb/firewire/ contains backends to both ieee1394 and firewire-core. Its ieee1394 backend code can be removed in an independent commit; firedtv as-is builds and works fine without ieee1394. The driver pcilynx (an incomplete controller driver) is deleted without replacement since PCILynx cards are extremely rare. Owners of these cards use them with the stand-alone bus sniffer driver nosy instead. The drivers nosy and init_ohci1394_dma which do not interact with either of the two IEEE 1394 stacks are not affected by the ieee1394 subsystem removal. There are still some issues with the newer firewire subsystem compared to the older one: - The rare and quirky controllers ALi M52xx, Apple UniNorth v1, NVIDIA NForce2 are even less well supported by firewire-ohci than by ohci1394. I am looking into the M52xx issue. - The experimental firewire-net is reportedly less stable than its experimental cousin eth1394. - Audio playback of a certain group of audio devices (ones based on DICE chipset with EAP; supported by prerelease FFADO code) does not work yet. This issue is still under investigation. - There were some ieee1394 based out-of-the-mainline drivers. Of them, only lisight, an audio driver for iSight webcams, seems still useful. Work is underway to reimplement it on top of firewire-core. All these remainig issues are minor; they should not stand in the way of overall better user experience of IEEE 1394 on Linux, together with a reduction in support efforts and maintenance burden. The coexistence of two IEEE 1394 kernel driver stacks in the mainline since 2.6.22 shall end now, as announced earlier this year. Signed-off-by: Stefan Richter

ieee1394: constify device ID tables

2009-03-24T19:56:53+00:00

Signed-off-by: Stefan Richter

ieee1394: add hpsb_node_read() and hpsb_node_lock()

2009-02-24T13:51:27+00:00

These will be used by the firedtv driver. Like hpsb_node_write() they are much better APIs for high-level drivers than hpsb_write() and its siblings --- easier to use correctly and also terser. Unlike hspb_node_write(), the two new functions will only be used by one call site. Hence make them static inline instead of exported symbols. Signed-off-by: Stefan Richter

ieee1394: consolidate uses of IEEE1934_BUSID_MAGIC

2009-01-04T22:50:34+00:00

Move the definition out of nodemgr.h and use it in csr.c/pcilynx.c Signed-off-by: Harvey Harrison Signed-off-by: Stefan Richter

ieee1394: survive a few seconds connection loss

2008-10-15T20:21:09+00:00

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

ieee1394: regression in 2.6.25: updates should happen before probes

2008-08-19T16:47:55+00:00

Regression since commit 73cf60232ef16e1f8a64defa97214a1722db1e6c, "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

ieee1394: convert ieee1394 from "struct class_device" to "struct device"

2007-07-09T22:07:39+00:00

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

ieee1394: sbp2: offer SAM-conforming target port ID in sysfs

2007-05-31T19:40:13+00:00

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

ieee1394: move some comments from declaration to definition

2007-04-29T22:00:28+00:00

Signed-off-by: Stefan Richter

ieee1394: remove declarations of nonexisting functions

2007-04-29T22:00:27+00:00

Signed-off-by: Stefan Richter