kernel/git/stable/linux.git/drivers/ieee1394/nodemgr.c, 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

Driver core: create lock/unlock functions for struct device

2010-03-08T01:04:52+00:00

In the future, we are going to be changing the lock type for struct device (once we get the lockdep infrastructure properly worked out) To make that changeover easier, and to possibly burry the lock in a different part of struct device, let's create some functions to lock and unlock a device so that no out-of-core code needs to be changed in the future. This patch creates the device_lock/unlock/trylock() functions, and converts all in-tree users to them. Cc: Thomas Gleixner Cc: Jean Delvare Cc: Dave Young Cc: Ming Lei Cc: Jiri Kosina Cc: Phil Carmody Cc: Arjan van de Ven Cc: Cornelia Huck Cc: Rafael J. Wysocki Cc: Pavel Machek Cc: Len Brown Cc: Magnus Damm Cc: Alan Stern Cc: Randy Dunlap Cc: Stefan Richter Cc: David Brownell Cc: Vegard Nossum Cc: Jesse Barnes Cc: Alex Chiang Cc: Kenji Kaneshige Cc: Andrew Morton Cc: Andrew Patterson Cc: Yu Zhao Cc: Dominik Brodowski Cc: Samuel Ortiz Cc: Wolfram Sang Cc: CHENG Renquan Cc: Oliver Neukum Cc: Frans Pop Cc: David Vrabel Cc: Kay Sievers Cc: Sarah Sharp Signed-off-by: Greg Kroah-Hartman

ieee1394: annotate bitfield

2009-06-15T13:49:29+00:00

Signed-off-by: Vegard Nossum

ieee1394: constify device ID tables

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

Signed-off-by: Stefan Richter

ieee1394: inherit ud vendor_id from node vendor_id

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

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

ieee1394: use correct barrier types between accesses of nodeid and generation

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

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

ieee1394: ignore nonzero Bus_Info_Block.max_rom, fetch config ROM in quadlets

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

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

ieee1394: add quirk fix for Freecom HDD

2008-12-14T00:13:13+00:00

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 Signed-off-by: Stefan Richter

ieee1394: node manager causes up to ~3.25s delay in freezing tasks

2008-12-09T18:34:33+00:00

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 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

ieee1394: struct device - replace bus_id with dev_name(), dev_set_name()

2008-10-31T07:48:25+00:00

Acked-by: Greg Kroah-Hartman Signed-off-by: Kay Sievers Signed-off-by: Stefan Richter