Linux kernel stable tree https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=master 2010-10-11T12:48:03+00:00 2010-10-11T12:48:03+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2010-10-09T22:12:20+00:00 urn:sha1:66fa12c571d35e3cd62574c65f1785a460105397 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 <stefanr@s5r6.in-berlin.de> 2010-07-13T07:59:32+00:00 Joe Perches joe@perches.com 2010-07-12T20:50:00+00:00 urn:sha1:80792d182e43bee89fce509e64fdea27e600530f Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2010-06-19T11:01:41+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2010-06-15T00:00:11+00:00 urn:sha1:5030c807907ae90ad21e9220c1a9d592558deba2 which caused gcc 4.6 to warn about variable 'XYZ' set but not used. sbp2.c, unit_characteristics: The underlying problem which was spotted here --- an incomplete implementation --- is already 50% fixed in drivers/firewire/sbp2.c which observes mgt_ORB_timeout but not yet ORB_size. raw1394.c, length_conflict; dv1394.c, ts_off: Impossible to tell why these variables are there. We can safely remove them though because we don't need a compiler warning to realize that we are dealing with (at least stylistically) flawed code here. dv1394.c, packet_time: This was used in debug macro that is only compiled in with DV1394_DEBUG_LEVEL >= 2 defined at compile-time. Just drop it since nobody debugs dv1394 anymore. Avoids noise in regular kernel builds. dv1394.c, ohci; eth1394.c, priv: These variables clearly can go away. Somebody wanted to use them but then didn't (or not anymore). Note, all of this code is considered to be at its end of life and is thus not really meant to receive janitorial updates anymore. But if we can easily remove noisy warnings from kernel builds, we should. Reported-by: Justin P. Mattock <justinmattock@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2010-04-10T14:51:15+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2010-04-10T15:47:18+00:00 urn:sha1:7cfe21aae155c26193fde617dc61d37a79a63f86 The - raw1394 (/dev/raw1394), - video1394 (/dev/video1394/*), - dv1394 (/dev/dv1394/*) character device file ABIs do not make any use of lseek(), pread(), or pwrite(). Therefore use nonseekable_open() and, redundantly, set file_operations.llseek to no_llseek to remove any doubt whether the BKL- grabbing default_llseek handler is used. Although all this is legacy code which should be left in peace until it is eventually removed (as it is superseded by firewire-core's <linux/firewire-cdev.h> ABI), this change seems still worth doing to further minimize the presence of BKL usage in the kernel. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2009-12-04T14:39:55+00:00 André Goddard Rosa andre.goddard@gmail.com 2009-11-14T15:09:05+00:00 urn:sha1:af901ca181d92aac3a7dc265144a9081a86d8f39 That is "success", "unknown", "through", "performance", "[re|un]mapping" , "access", "default", "reasonable", "[con]currently", "temperature" , "channel", "[un]used", "application", "example","hierarchy", "therefore" , "[over|under]flow", "contiguous", "threshold", "enough" and others. Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> 2009-06-12T01:36:09+00:00 Theodore Ts'o tytso@mit.edu 2009-05-21T20:01:00+00:00 urn:sha1:9fd5746fd3d7838bf6ff991d50f1257057d1156f The only user of the i_cindex element in the inode structure is used is by the firewire drivers. As part of an attempt to slim down the inode structure to save memory --- since a typical Linux system will have hundreds of thousands if not millions of inodes cached, a reduction in the size inode has high leverage. The firewire driver does not need i_cindex in any fast path, so it's simple enough to calculate when it is needed, instead of wasting space in the inode structure. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Cc: krh@redhat.com Cc: stefanr@s5r6.in-berlin.de Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 2009-03-28T01:33:56+00:00 Linus Torvalds torvalds@linux-foundation.org 2009-03-28T01:33:56+00:00 urn:sha1:febb02bdfe5e2c6ceaa0a38d8b7afca3d98f415a * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6: (53 commits) DVB: firedtv: FireDTV S2 problems with tuning solved DVB: firedtv: fix printk format mismatch ieee1394: constify device ID tables ieee1394: raw1394: add sparse annotations to raw1394_compat_write ieee1394: Storage class should be before const qualifier ieee1394: sbp2: follow up on "ieee1394: inherit ud vendor_id from node vendor_id" firewire: core: optimize propagation of BROADCAST_CHANNEL firewire: core: simplify broadcast channel allocation firewire: core: increase bus manager grace period firewire: core: drop unused call parameters of close_transaction firewire: cdev: add closure to async stream ioctl firewire: cdev: simplify FW_CDEV_IOC_SEND_REQUEST return value firewire: cdev: fix race of ioctl_send_request with bus reset firewire: cdev: secure add_descriptor ioctl firewire: cdev: amendment to "add ioctl to query maximum transmission speed" firewire: broadcast channel support firewire: implement asynchronous stream transmission firewire: core: normalize a function argument name firewire: normalize a variable name firewire: core: remove condition which is always false ... 2009-03-24T19:56:53+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2009-02-15T22:11:38+00:00 urn:sha1:c64094684dad4a903099f1ff83b7db9b62782adc Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> 2009-03-16T14:34:35+00:00 Jonathan Corbet corbet@lwn.net 2009-02-01T21:52:56+00:00 urn:sha1:60aa49243d09afc873f082567d2e3c16634ced84 Most fasync implementations do something like: return fasync_helper(...); But fasync_helper() will return a positive value at times - a feature used in at least one place. Thus, a number of other drivers do: err = fasync_helper(...); if (err < 0) return err; return 0; In the interests of consistency and more concise code, it makes sense to map positive return values onto zero where ->fasync() is called. Cc: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Jonathan Corbet <corbet@lwn.net> 2009-02-06T14:52:28+00:00 Stefan Richter stefanr@s5r6.in-berlin.de 2009-02-03T16:54:31+00:00 urn:sha1:86431532ec4311dccd0d7513cebae6ffc762756b On many Linux installations, the dv1394 driver will be auto-loaded whenever an AV/C device (e.g. camcorder or audio device) is plugged in. An irritating message would then appear in the kernel log. Defer this message to until a dv1394 character device file is actually used by a program. Also include the program name in the message and update the message slightly. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>