aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/ieee1394/raw1394.c
Commit message (Collapse)AuthorAge
* ieee1394: remove the old IEEE 1394 driver stackStefan Richter2010-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ieee1394: Remove unnecessary casts of private_dataJoe Perches2010-07-13
| | | | | Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: remove unused variablesStefan Richter2010-06-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ieee1394: mark char device files as not seekableStefan Richter2010-04-10
| | | | | | | | | | | | | | | | | | 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>
* headers: remove sched.h from interrupt.hAlexey Dobriyan2009-10-11
| | | | | | | | After m68k's task_thread_info() doesn't refer to current, it's possible to remove sched.h from interrupt.h and not break m68k! Many thanks to Heiko Carstens for allowing this. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
* ieee1394: raw1394: Do not leak memory on failed trylock.Michael Buesch2009-09-12
| | | | | | | | | | | | | Do not leak the allocated memory in case the mutex_trylock() failed to acquire the lock. Signed-off-by: Michael Buesch <mb@bu3sch.de> This bug does not happen in practice: All raw1394 clients use libraw1394, and accesses to a libraw1394 handle need to be serialized by the client. This is documented in libraw1394's API reference. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: constify device ID tablesStefan Richter2009-03-24
| | | | Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: raw1394: add sparse annotations to raw1394_compat_writeStefan Richter2009-03-24
| | | | | | | | | | | | | | | | | Eliminate the following warnings in raw1394_compat_write()'s error return path, seen on x86-64 with CONFIG_COMPAT=y: drivers/ieee1394/raw1394.c:381:17: warning: incorrect type in return expression (different address spaces) drivers/ieee1394/raw1394.c:381:17: expected char const [noderef] <asn:1>* drivers/ieee1394/raw1394.c:381:17: got void * drivers/ieee1394/raw1394.c:2252:14: warning: incorrect type in argument 1 (different address spaces) drivers/ieee1394/raw1394.c:2252:14: expected void const *ptr drivers/ieee1394/raw1394.c:2252:14: got char const [noderef] <asn:1>*[assigned] buffer drivers/ieee1394/raw1394.c:2253:19: warning: incorrect type in argument 1 (different address spaces) drivers/ieee1394/raw1394.c:2253:19: expected void const *ptr drivers/ieee1394/raw1394.c:2253:19: got char const [noderef] <asn:1>*[assigned] buffer Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: Storage class should be before const qualifierTobias Klauser2009-03-24
| | | | | | | | | | | The C99 specification states in section 6.11.5: The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: mark all hpsb_address_ops instances as constStefan Richter2009-01-04
| | | | | | These are never modified. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Merge branch 'for-linus' of ↵Linus Torvalds2008-11-06
|\ | | | | | | | | | | | | | | | | | | 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: ieee1394: dv1394: fix possible deadlock in multithreaded clients ieee1394: raw1394: fix possible deadlock in multithreaded clients ieee1394: struct device - replace bus_id with dev_name(), dev_set_name() firewire: struct device - replace bus_id with dev_name(), dev_set_name()
| * ieee1394: raw1394: fix possible deadlock in multithreaded clientsStefan Richter2008-10-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Regression in 2.6.28-rc1: When I added the new state_mutex which prevents corruption of raw1394's internal state when accessed by multithreaded client applications, the following possible though highly unlikely deadlock slipped in: Thread A: Thread B: - acquire mmap_sem - raw1394_write() or raw1394_ioctl() - raw1394_mmap() - acquire state_mutex - acquire state_mutex - copy_to/from_user(), possible page fault: acquire mmap_sem The simplest fix is to use mutex_trylock() instead of mutex_lock() in raw1394_mmap(). This changes the behavior under contention in a way which is visible to userspace clients. However, since multithreaded access was entirely buggy before state_mutex was added and libraw1394's documentation advised application programmers to use a handle only in a single thread, this change in behaviour should not be an issue in practice at all. Since we have to use mutex_trylock() in raw1394_mmap() regardless whether /dev/raw1394 was opened with O_NONBLOCK or not, we now use mutex_trylock() unconditionally everywhere for state_mutex, just to have consistent behavior. Reported-by: Johannes Weiner <hannes@saeurebad.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* | Merge branch 'for-linus' of ↵Linus Torvalds2008-10-16
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Add more documentation to firewire-cdev.h firewire: fix ioctl() return code firewire: fix setting tag and sy in iso transmission firewire: fw-sbp2: fix another small generation access bug firewire: fw-sbp2: enforce s/g segment size limit firewire: fw_send_request_sync() ieee1394: survive a few seconds connection loss ieee1394: nodemgr clean up class iterators ieee1394: dv1394, video1394: remove unnecessary expressions ieee1394: raw1394: make write() thread-safe ieee1394: raw1394: narrow down the state_mutex protected region ieee1394: raw1394: replace BKL by local mutex, make ioctl() and mmap() thread-safe ieee1394: sbp2: enforce s/g segment size limit ieee1394: sbp2: check for DMA mapping failures ieee1394: sbp2: stricter dma_sync ieee1394: Use DIV_ROUND_UP
| * ieee1394: raw1394: make write() thread-safeStefan Richter2008-10-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Application programs should use a libraw1394 handle only in a single thread. The raw1394 driver was apparently relying on this, because it did nothing to protect its fi->state variable from corruption due to concurrent accesses. We now serialize the fi->state accesses. This affects the write() path. We re-use the state_mutex which was introduced to protect fi->iso_state accesses in the ioctl() path. These paths and accesses are independent of each other, hence separate mutexes could be used. But I don't see much benefit in that. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * ieee1394: raw1394: narrow down the state_mutex protected regionStefan Richter2008-10-15
| | | | | | | | | | | | | | | | | | | | Refactor the ioctl dispatcher in order to move a fraction of it out of the section which is serialized by fi->state_mutex. This is not so much about performance but more about self-documentation: The mutex_lock()/ mutex_unlock() calls are now closer to the data accesses which the mutex protects, i.e. to the iso_state switch. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * ieee1394: raw1394: replace BKL by local mutex, make ioctl() and mmap() ↵Stefan Richter2008-10-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | thread-safe This removes the last usage of the Big Kernel Lock from the ieee1394 stack, i.e. from raw1394's (unlocked_)ioctl and compat_ioctl. The ioctl()s don't need to take the BKL, but they need to be serialized per struct file *. In particular, accesses to ->iso_state need to be serial. We simply use a blocking mutex for this purpose because libraw1394 does not use O_NONBLOCK. In practice, there is no lock contention anyway because most if not all libraw1394 clients use a libraw1394 handle only in a single thread. mmap() also accesses ->iso_state. Until now this was unprotected against concurrent changes by ioctls. Fix this bug while we are at it. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* | device create: ieee1394: convert device_create_drvdata to device_createGreg Kroah-Hartman2008-10-16
|/ | | | | | | | | | Now that device_create() has been audited, rename things back to the original call to be sane. Cc: Ben Collins <ben.collins@ubuntu.com> Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* device create: ieee1394: convert device_create to device_create_drvdataGreg Kroah-Hartman2008-07-22
| | | | | | | | | device_create() is race-prone, so use the race-free device_create_drvdata() instead as device_create() is going away. Cc: Ben Collins <ben.collins@ubuntu.com> Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* ieee1394: raw1394: Push the BKL down into the driver ioctlsAlan Cox2008-07-14
| | | | | | | | | | Actually in this case wrap the function for now. Signed-off-by: Alan Cox <alan@redhat.com> Added raw1394_compat_ioctl hunk. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: silence defined but not used warning in non-modular buildsTony Breeds2008-04-25
| | | | | | | | | | | | Currently the kernel will issue the following warning: drivers/ieee1394/raw1394.c:2938: warning: 'raw1394_id_table' defined but not used Add #ifdef MODULE guards around the declaration. Signed-off-by: Tony Breeds <tony@bakeyournoodle.com> Ditto with dv1394_id_table and video1394_id_table. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: rawiso: requeue packet for transmission after skipped cyclePieter Palmers2008-04-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As it seems, some host controllers have issues that can cause them to skip cycles now and then when using large packets. I suspect that this is due to DMA not succeeding in time. If the transmit fifo can't contain more than one packet (big packets), the DMA should provide a new packet each cycle (125us). I am under the impression that my current PCI express test system can't guarantee this. In any case, the patch tries to provide a workaround as follows: The DMA program descriptors are modified such that when an error occurs, the DMA engine retries the descriptor the next cycle instead of stalling. This way no data is lost. The side effect of this is that packets are sent with one cycle delay. This however might not be that much of a problem for certain protocols (e.g. AM824). If they use padding packets for e.g. rate matching they can drop one of those to resync the streams. The amount of skips between two userspace wakeups is counted. This number is then propagated to userspace through the upper 16 bits of the 'dropped' parameter. This allows unmodified userspace applications due to the following: 1) libraw simply passes this dropped parameter to the user application 2) the meaning of the dropped parameter is: if it's nonzero, something bad has happened. The actual value of the parameter at this moment does not have a specific meaning. A libraw client can then retrieve the number of skipped cycles and account for them if needed. Signed-off-by: Pieter Palmers <pieterp@joow.be> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: Remove superfluous calls to kobject_set_name().Robert P. J. Day2008-04-18
| | | | | | | | Unless you're adding a kobject to the sysfs hierarchy, there is no point setting its kobject name. Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: prevent device binding of raw1394, video1394, dv1394Stefan Richter2008-04-18
| | | | | | | | | | | | 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>
* ieee1394: Add missing "space"Joe Perches2008-01-30
| | | | | Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* raw1394 __user annotationAl Viro2007-07-26
| | | | | Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* ieee1394: remove old isochronous ABIStefan Richter2007-07-09
| | | | | | | | | | | | | | | | | | | Based on patch "the scheduled removal of RAW1394_REQ_ISO_{SEND,LISTEN}" from Adrian Bunk, November 20 2006. This patch also removes the underlying facilities in ohci1394 and disables them in pcilynx. That is, hpsb_host_driver.devctl() and hpsb_host_driver.transmit_packet() are no longer used for iso reception and transmission. Since video1394 and dv1394 only work with ohci1394 and raw1394's rawiso interface has never been implemented in pcilynx, pcilynx is now no longer useful for isochronous applications. raw1394 will still handle the request types but will complete the requests with errors that indicate API version conflicts. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: convert ieee1394 from "struct class_device" to "struct device"Kay Sievers2007-07-09
| | | | | | | | | | 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>
* ieee1394: raw1394: fix a 32/64-bits compat fixStefan Richter2007-07-09
| | | | | | | | I was told that only i386 aligns 64 bit integers at 4 bytes boundaries while all other architectures (32 bit architectures with 64 bit siblings) align it on 8 bytes boundaries. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: raw1394: Add ioctl() for 32bit userland on 64bit kernel, amendmentStefan Richter2007-07-09
| | | | | | | | Pointed out by Arnd Bergmann: PPC32 aligns this at 64bit, IA32 packs it. A kernel-wide available __compat_u64 which is 4-byte aligned on AMD64 and IA64 would be nicer though. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: raw1394: Add ioctl() for 32bit userland on 64bit kernelPetr Vandrovec2007-07-09
| | | | | | | | | | | | Add compat_ioctl. Although all structures are more or less same, raw1394_iso_packets got pointer inside, and raw1394_cycle_timer got unwanted padding in the middle. I did not add any translation for ioctls passing array of integers around as integers seem to have same size (32 bits) on all architectures supported by Linux. Signed-off-by: Petr Vandrovec <petr@vandrovec.name> Acked-by: Dan Dennedy <dan@dennedy.org> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (split into 3 patches)
* ieee1394: raw1394: Fix write() for 32bit userland on 64bit kernelPetr Vandrovec2007-07-09
| | | | | | | | | | | | | | | | | | * write(fd, buf, 52) from 32bit app was returning 56. Most of callers did not care, but some (arm registration) did, and anyway it looks bad if request for writing 52 bytes returns 56. And returning sizeof anything in 'int' is not good as well. So all functions now return '0' instead of sizeof(struct raw1394_request) on success, and write() itself provides correct return value (it just returns value it was asked to write on success as raw1394 does not do any partial writes at all). * Related to this was problem that write() could have returned 0 when kernel state would become corrupted and moved to different state than opened/initialized/connected. Now it returns -EBADFD which seemed appropriate. Signed-off-by: Petr Vandrovec <petr@vandrovec.name> Acked-by: Dan Dennedy <dan@dennedy.org> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (split into 3 patches)
* ieee1394: raw1394: Fix read() for 32bit userland on 64bit kernelPetr Vandrovec2007-07-09
| | | | | | | | | | | read() always failed with -EFAULT. This was happening due to raw1394_compat_read copying data to wrong location - access_ok always failed as 'r' is kernel address, not user. Whole function just tried to copy data from 'r' to 'r', which is not good. Signed-off-by: Petr Vandrovec <petr@vandrovec.name> Acked-by: Dan Dennedy <dan@dennedy.org> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (split into 3 patches)
* ieee1394: raw1394: Fix async sendPetr Vandrovec2007-05-27
| | | | | | | | | | | While playing with libiec61883 I've noticed that async_send is broken because it was doing copy_from_user(...., packet->data_size) before packet->data_size was set to any useful value. It got broken when packet->allocated_data_size got introduced, as hpsb_alloc_packet does not set packet->data_size anymore. (Regression in 2.6.22-rc1) Signed-off-by: Petr Vandrovec <petr@vandrovec.name> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* header cleaning: don't include smp_lock.h when not usedRandy Dunlap2007-05-08
| | | | | | | | | | | | Remove includes of <linux/smp_lock.h> where it is not used/needed. Suggested by Al Viro. Builds cleanly on x86_64, i386, alpha, ia64, powerpc, sparc, sparc64, and arm (all 59 defconfigs). Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* ieee1394: remove usage of skb_queue as packet queueStefan Richter2007-04-29
| | | | | | | This considerably reduces the memory requirements for a packet and eliminates ieee1394's dependency on CONFIG_NET. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Merge branch 'for-linus' of ↵Linus Torvalds2007-02-19
|\ | | | | | | | | | | | | | | ssh://master.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6 * 'for-linus' of ssh://master.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6: ieee1394: fix another deadlock in nodemgr ieee1394: cycle timer read extension for raw1394
| * ieee1394: cycle timer read extension for raw1394Pieter Palmers2007-02-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the simultaneous read of the isochronous cycle timer and the system clock (in usecs). This allows to express the exact receive time of an ISO packet as a system time with microsecond accuracy. http://bugzilla.kernel.org/show_bug.cgi?id=7773 The counterpart patch for libraw1394 can be found at http://thread.gmane.org/gmane.linux.kernel.firewire.devel/8934 Patch update (Stefan R.): Disable preemption and local interrupts. Prevent integer overflow. Add paranoid error checks and kerneldoc to hpsb_read_cycle_timer. Move it to other ieee1394_core high-level API functions. Change comments. Adjust whitespace. Rename struct _raw1394_cycle_timer. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Acked-by: Pieter Palmers <pieterp@joow.be> Acked-by: Dan Dennedy <dan@dennedy.org>
* | [PATCH] mark struct file_operations const 3Arjan van de Ven2007-02-12
|/ | | | | | | | | | | Many struct file_operations in the kernel can be "const". Marking them const moves these to the .rodata section, which avoids false sharing with potential dirty data. In addition it'll catch accidental writes at compile time to these shared resources. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* ieee1394: raw1394: prevent unloading of low-level driverStefan Richter2007-02-08
| | | | | | | | | | | | | | | Unloading the low-level driver module of a FireWire host can lead to all sorts of trouble if a raw1394 userspace client is using the host. Just disallow it by incrementing the LLD's module reference count on a RAW1394_REQ_SET_CARD write operation. Decrement it when the file is closed. This feature wouldn't be relevant if "modprobe -r video1394" or "modprobe -r dv1394" didn't automatically unload ohci1394 too. http://bugzilla.kernel.org/show_bug.cgi?id=7701 Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Dan Dennedy <dan@dennedy.org>
* ieee1394: Consolidate driver registeringBen Collins2006-12-07
| | | | | | | | | | | | | 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>
* ieee1394: raw1394: defer feature removal of old isoch interfaceStefan Richter2006-12-07
| | | | | | | | | Known to be affected: - libdc1394: prefers video1394 for now, old-style raw1394 support might be dropped eventually - OpenH323 PWLib, AVC video input module: uses libraw1394's old API Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* [PATCH] slab: remove SLAB_KERNELChristoph Lameter2006-12-07
| | | | | | | | SLAB_KERNEL is an alias of GFP_KERNEL. Signed-off-by: Christoph Lameter <clameter@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] slab: remove SLAB_ATOMICChristoph Lameter2006-12-07
| | | | | | | | SLAB_ATOMIC is an alias of GFP_ATOMIC Signed-off-by: Christoph Lameter <clameter@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* ieee1394: raw1394: arm functions slept in atomic contextStefan Richter2006-09-23
| | | | | | | | | | Sleeping functions like copy_to_user were accessed inside spinlocks in raw1394's arm_register, arm_unregister, arm_get_buf, arm_set_buf. http://bugzilla.kernel.org/show_bug.cgi?id=7120 Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Tested-by: David Trent <DTrent@piacton.com> (cherry picked from e575953ec17c3f5c1e738847d2d16c241bb99783 commit)
* ieee1394: safer definition of empty macrosStefan Richter2006-09-17
| | | | | | | | | A deactivated macro, defined as "#define foo(bar)", will result in silent corruption if somebody forgets a semicolon after a call to foo. Replace it by "#define foo(bar) do {} while (0)" which will reveal any respective syntax errors. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* [PATCH] ieee1394: raw1394: remove redundant counting semaphoreStefan Richter2006-07-03
| | | | | | | | | | | | | | | | | | | | | | | | | An already existing wait queue replaces raw1394's complete_sem which was maintained in parallel to the wait queue. The role of the semaphore's counter is taken over by a direct check of what was really counted: The presence of items in the list of completed requests. Notes: - raw1394_release() sleeps uninterruptibly until all requests were completed. This is the same behaviour as before the patch. - The macros wait_event and wait_event_interruptible are called with a condition argument which has a side effect, i.e. manipulation of the requests list. This side effect happens only if the condition is true. The patch relies on the fact that wait_event[_interruptible] does not evaluate the condition again after it became true. - The diffstat looks unfavorable with respect to added lines of code. However 19 of them are comments, and some are due to separation of existing code blocks into two small helper functions. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Ben Collins <bcollins@ubuntu.com>
* [PATCH] ieee1394: update #include directives in midlayer header filesStefan Richter2006-07-03
| | | | | | | | Remove unnecessary includes, add missing includes. Use forward type declarations for some structs. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Ben Collins <bcollins@ubuntu.com>
* [PATCH] drivers: use list_move()Akinobu Mita2006-06-26
| | | | | | | | | | | | | | | | | | | | This patch converts the combination of list_del(A) and list_add(A, B) to list_move(A, B) under drivers/. Acked-by: Corey Minyard <minyard@mvista.com> Cc: Ben Collins <bcollins@debian.org> Acked-by: Roland Dreier <rolandd@cisco.com> Cc: Alasdair Kergon <dm-devel@redhat.com> Cc: Gerd Knorr <kraxel@bytesex.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Frank Pavlic <fpavlic@de.ibm.com> Acked-by: Matthew Wilcox <matthew@wil.cx> Cc: Andrew Vasquez <linux-driver@qlogic.com> Cc: Mikael Starvik <starvik@axis.com> Cc: Greg Kroah-Hartman <greg@kroah.com> Signed-off-by: Akinobu Mita <mita@miraclelinux.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* raw1394: fix whitespace after x86_64 compat patchBen Collins2006-06-12
| | | | | Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Ben Collins <bcollins@ubuntu.com>
* ieee1394: remove devfs supportStefan Richter2006-03-28
| | | | | | | | | | Devfs has been disabled in the last kernel releases, so let's remove it from ieee1394core, raw1394, video1394, dv1394. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Cc: Dan Dennedy <dan@dennedy.org> Signed-off-by: Jody McIntyre <scjody@modernduck.com>
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-01 21:15:52 -0400