summaryrefslogtreecommitdiffstats
path: root/drivers/ieee1394 (follow)
Commit message (Collapse)AuthorAgeFilesLines
* ieee1394: add quirk fix for Freecom HDDStefan Richter2008-12-141-0/+6
| | | | | | | | | | 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>
* ieee1394: node manager causes up to ~3.25s delay in freezing tasksNigel Cunningham2008-12-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ieee1394: sbp2: fix race condition in state changeStefan Richter2008-11-291-4/+5
| | | | | | | An intermediate transition from _RUNNING to _IN_SHUTDOWN could have been missed by the former code. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: fix list corruption (reported at module removal)Stefan Richter2008-11-292-13/+16
| | | | | | | | | | | | | | If there is more than one FireWire controller present, dummy_zero_addr and dummy_max_addr were added multiple times to different lists, thus corrupting the lists. Fix this by allocating them dynamically per host instead of just once globally. (Perhaps a better address space allocation algorithm could rid us of the two dummy address spaces.) Fixes http://bugzilla.kernel.org/show_bug.cgi?id=10129 . Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: sbp2: another iPod mini quirk entryStefan Richter2008-11-251-0/+5
| | | | | | | | Add another model ID of a broken firmware to prevent early I/O errors by acesses at the end of the disk. Reported at linux1394-user, http://marc.info/?t=122670842900002 Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Merge branch 'for-linus' of ↵Linus Torvalds2008-11-074-16/+21
|\ | | | | | | | | | | | | | | | | | | 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: dv1394: fix possible deadlock in multithreaded clientsStefan Richter2008-10-311-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a possible though highly unlikely deadlock: Thread A: Thread B: - acquire mmap_sem - dv1394_ioctl/read/write() - dv1394_mmap() - acquire video->mtx - acquire video->mtx - copy_to/from_user(), possible page fault: acquire mmap_sem The simplest fix is to use mutex_trylock() instead of mutex_lock() in dv1394_mmap(). This changes the behavior under contention in a way which is visible to userspace clients. However, my guess is that no clients exist which use mmap vs. ioctl/read/write on the dv1394 character device file interface in concurrent threads. Reported-by: Johannes Weiner <hannes@saeurebad.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * ieee1394: raw1394: fix possible deadlock in multithreaded clientsStefan Richter2008-10-311-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ieee1394: struct device - replace bus_id with dev_name(), dev_set_name()Kay Sievers2008-10-312-11/+7
| | | | | | | | | | | | 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>
* | saner FASYNC handling on file closeAl Viro2008-11-011-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | As it is, all instances of ->release() for files that have ->fasync() need to remember to evict file from fasync lists; forgetting that creates a hole and we actually have a bunch that *does* forget. So let's keep our lives simple - let __fput() check FASYNC in file->f_flags and call ->fasync() there if it's been set. And lose that crap in ->release() instances - leaving it there is still valid, but we don't have to bother anymore. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Merge branch 'for-linus' of ↵Linus Torvalds2008-10-1710-431/+346
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: survive a few seconds connection lossStefan Richter2008-10-152-98/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ieee1394: nodemgr clean up class iteratorsStefan Richter2008-10-151-97/+81
| | | | | | | | | | | | | | | | | | 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>
| * ieee1394: dv1394, video1394: remove unnecessary expressionsStefan Richter2008-10-152-5/+5
| | | | | | | | | | | | | | | | init->channel and v.buffer are unsigned and tests for < 0 therefore always false. gcc knows this and eliminates the code, but anyway... Reported by Roel Kluin. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * ieee1394: raw1394: make write() thread-safeStefan Richter2008-10-151-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-151-101/+110
| | | | | | | | | | | | | | | | | | | | 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-152-6/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ieee1394: sbp2: enforce s/g segment size limitStefan Richter2008-10-152-92/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. We don't need to round the SBP-2 segment size limit down to a multiple of 4 kB (0xffff -> 0xf000). It is only necessary to ensure quadlet alignment (0xffff -> 0xfffc). 2. Use dma_set_max_seg_size() to tell the DMA mapping infrastructure and the block IO layer about the restriction. This way we can remove the size checks and segment splitting in the queuecommand path. This assumes that no other code in the ieee1394 stack uses dma_map_sg() with conflicting requirements. It furthermore assumes that the controller device's platform actually allows us to set the segment size to our liking. Assert the latter with a BUG_ON(). 3. Also use blk_queue_max_segment_size() to tell the block IO layer about it. It cannot know it because our scsi_add_host() does not point to the FireWire controller's device. We can also uniformly use dma_map_sg() for the single segment case just like for the multi segment case, to further simplify the code. Also clean up how the page table is converted to big endian. Thanks to Grant Grundler and FUJITA Tomonori for advice. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * ieee1394: sbp2: check for DMA mapping failuresStefan Richter2008-10-151-35/+59
| | | | | | | | Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * ieee1394: sbp2: stricter dma_syncStefan Richter2008-10-151-34/+16
| | | | | | | | | | | | | | | | | | | | | | Two dma_sync_single_for_cpu() were called in the wrong place. Luckily they were merely for DMA_TO_DEVICE, hence nobody noticed. Also reorder the matching dma_sync_single_for_device() a little bit so that they reside in the same functions as their counterparts. This also avoids syncing the s/g table for requests which don't use it. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * ieee1394: Use DIV_ROUND_UPJulia Lawall2008-10-152-2/+2
| | | | | | | | | | Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* | device create: ieee1394: convert device_create_drvdata to device_createGreg Kroah-Hartman2008-10-163-11/+10
|/ | | | | | | | | | 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>
* ieee1394: sbp2: let nodemgr retry node updates during bus reset seriesStefan Richter2008-08-191-7/+18
| | | | | | | | | | | | | | | | | | sbp2 was too quick to report .update() to the ieee1394 core as failed. (Logged as "Failed to reconnect to sbp2 device!".) The core would then unbind sbp2 from the device. This is not justified if the .update() failed because another bus reset happened. We check this and tell the ieee1394 that .update() succeeded, and the core will call sbp2's .update() for the new bus reset as well. This improves reconnection/re-login especially on buses with several disks as they may issue bus resets in close succession when they come online. Tested by Damien Benoist. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: don't drop nodes during bus reset seriesStefan Richter2008-08-191-19/+21
| | | | | | | | | | 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>
* ieee1394: regression in 2.6.25: updates should happen before probesStefan Richter2008-08-192-15/+16
| | | | | | | | | | | | | | 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 <stefanr@s5r6.in-berlin.de>
* PAGE_ALIGN(): correctly handle 64-bit values on 32-bit architecturesAndrea Righi2008-07-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On 32-bit architectures PAGE_ALIGN() truncates 64-bit values to the 32-bit boundary. For example: u64 val = PAGE_ALIGN(size); always returns a value < 4GB even if size is greater than 4GB. The problem resides in PAGE_MASK definition (from include/asm-x86/page.h for example): #define PAGE_SHIFT 12 #define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT) #define PAGE_MASK (~(PAGE_SIZE-1)) ... #define PAGE_ALIGN(addr) (((addr)+PAGE_SIZE-1)&PAGE_MASK) The "~" is performed on a 32-bit value, so everything in "and" with PAGE_MASK greater than 4GB will be truncated to the 32-bit boundary. Using the ALIGN() macro seems to be the right way, because it uses typeof(addr) for the mask. Also move the PAGE_ALIGN() definitions out of include/asm-*/page.h in include/linux/mm.h. See also lkml discussion: http://lkml.org/lkml/2008/6/11/237 [akpm@linux-foundation.org: fix drivers/media/video/uvc/uvc_queue.c] [akpm@linux-foundation.org: fix v850] [akpm@linux-foundation.org: fix powerpc] [akpm@linux-foundation.org: fix arm] [akpm@linux-foundation.org: fix mips] [akpm@linux-foundation.org: fix drivers/media/video/pvrusb2/pvrusb2-dvb.c] [akpm@linux-foundation.org: fix drivers/mtd/maps/uclinux.c] [akpm@linux-foundation.org: fix powerpc] Signed-off-by: Andrea Righi <righi.andrea@gmail.com> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Driver Core: add ability for class_find_device to start in middle of listGreg Kroah-Hartman2008-07-221-3/+6
| | | | | | | | | | | | | | | 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>
* Driver Core: add ability for class_for_each_device to start in middle of listGreg Kroah-Hartman2008-07-221-5/+9
| | | | | | | | | | | | | | | 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>
* device create: ieee1394: convert device_create to device_create_drvdataGreg Kroah-Hartman2008-07-223-8/+9
| | | | | | | | | 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>
* Merge branch 'sbp2-spindown' of ↵Linus Torvalds2008-07-152-2/+21
|\ | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6 * 'sbp2-spindown' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6: ieee1394: sbp2: spin disks down on suspend and shutdown firewire: fw-sbp2: spin disks down on suspend and shutdown ieee1394: sbp2: fix spindown for PL-3507 and TSB42AA9 firmwares firewire: fw-sbp2: fix spindown for PL-3507 and TSB42AA9 firmwares scsi: sd: optionally set power condition in START STOP UNIT
| * ieee1394: sbp2: spin disks down on suspend and shutdownStefan Richter2008-07-141-0/+2
| | | | | | | | | | | | | | | | | | | | This instructs sd_mod to send START STOP UNIT on suspend and resume, and on driver unbinding or unloading (including when the system is shut down). We don't do this though if multiple initiators may log in to the target. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * ieee1394: sbp2: fix spindown for PL-3507 and TSB42AA9 firmwaresStefan Richter2008-07-142-2/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | Reported by Tino Keitel: PL-3507 with firmware from Prolific does not spin down the disk on START STOP UNIT with power condition = 0 and start = 0. It does however work with power condition = 2 or 3. Also found while investigating this: DViCO Momobay CX-1 and FX-3A (TI TSB42AA9/A based) become unresponsive after START STOP UNIT with power condition = 0 and start = 0. They stay responsive if power condition is set when stopping the motor. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* | ieee1394: dump mmapped iso buffers in core filesPhilippe De Muyter2008-07-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, core files do not contain the mmapped memory of the video1394 or dv1394 devices, which contain the actual video input, making it impossible to analyse the cause of abnormal program termination for image analysis or (de)compression software. Fix that. Signed-off-by: Philippe De Muyter <phdm@macqel.be> Also affects users of the rawiso ioctl API of raw1394. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* | ieee1394: raw1394: Push the BKL down into the driver ioctlsAlan Cox2008-07-141-5/+15
| | | | | | | | | | | | | | | | | | | | 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: video1394: reorder module init, prepare BKL removalStefan Richter2008-07-143-4/+15
| | | | | | | | | | | | | | | | This prepares video1394 for removal of the BKL (big kernel lock): It allows video1394_open() to be called while video1394_init_module() is still in progress. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* | ieee1394: reduce log noise about config ROM CRC errorsStefan Richter2008-07-141-10/+22
|/ | | | | | | This avoids redundant messages about a special and usually harmless firmware flaw. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: Kconfig menu touch-upStefan Richter2008-06-191-52/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rename and reorder some prompts and modify some help texts. The result: -------------------- IEEE 1394 (FireWire) support -------------------- *** Enable only one of the two stacks, unless you know what you are doing *** New FireWire stack, EXPERIMENTAL OHCI-1394 controllers Storage devices (SBP-2 protocol) Stable FireWire stack OHCI-1394 controllers PCILynx controller Storage devices (SBP-2 protocol) Enable replacement for physical DMA in SBP2 IP over 1394 raw1394 userspace interface video1394 userspace interface dv1394 userspace interface (deprecated) Excessive debugging output The old prompts for reference: -------------------- IEEE 1394 (FireWire) support -------------------- IEEE 1394 (FireWire) support - alternative stack, EXPERIMENTAL Support for OHCI FireWire host controllers Support for storage devices (SBP-2 protocol driver) IEEE 1394 (FireWire) support *** Subsystem Options *** Excessive debugging output *** Controllers *** Texas Instruments PCILynx support OHCI-1394 support *** Protocols *** OHCI-1394 Video support SBP-2 support (Harddisks etc.) Enable replacement for physical DMA in SBP2 IP over 1394 OHCI-DV I/O support (deprecated) Raw IEEE1394 I/O support Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: sbp2: use correct size of command descriptor blockStefan Richter2008-05-201-12/+8
| | | | | | | | | Boaz Harrosh wrote: > cmd->cmd_len is now guarantied to be set properly at all cases. > And some commands you want to support will not be set correctly > by COMMAND_SIZE(). Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Merge branch 'for-linus' of ↵Linus Torvalds2008-05-011-1/+4
|\ | | | | | | | | | | | | | | 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
| * ieee1394: fix NULL pointer dereference in sysfs accessStefan Richter2008-05-011-1/+4
| | | | | | | | | | | | | | | | | | | | | | Regression since "ieee1394: prevent device binding of raw1394, video1394, dv1394", commit d2ace29fa44589da51fedc06a67b3f05301f3bfd: $ 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>
* | Merge branch 'for-linus' of ↵Linus Torvalds2008-04-255-1/+48
|\| | | | | | | | | | | | | | | 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: silence defined but not used warning in non-modular builds ieee1394: rawiso: requeue packet for transmission after skipped cycle
| * ieee1394: silence defined but not used warning in non-modular buildsTony Breeds2008-04-253-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | 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-253-1/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Convert asm/semaphore.h users to linux/semaphore.hMatthew Wilcox2008-04-191-1/+1
|/ | | | Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
* ieee1394: limit early node speed to host interface speedPhilippe De Muyter2008-04-181-0/+2
| | | | | | | | | | | | | | | The following patch limits the node speed to the host interface speed, before using it. Signed-off-by: Philippe De Muyter <phdm@macqel.be> It should actually suffice to do this only for the local node's speedcap[]. But there is another bug in the speed calculation: The local node's speed is not correctly propagated to the speeds which are to be used to access remote nodes. http://thread.gmane.org/gmane.linux.kernel.firewire.devel/11772/focus=12024 Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: Remove superfluous calls to kobject_set_name().Robert P. J. Day2008-04-183-3/+0
| | | | | | | | 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: ohci1394: missing PPC PMac feature calls in failure pathStefan Richter2008-04-181-3/+3
| | | | | | | | The failure path of ohci1394_pci_probe() reuses ohci1394_pci_remove(). Doing so it missed to call ohci1394_pmac_off() in a few unlikely early error cases. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: ohci1394: refactor some printk format stringsStefan Richter2008-04-181-15/+15
| | | | | | to reduce the size of ohci1394.ko. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: ohci1394: unroll a macro with returnStefan Richter2008-04-181-38/+54
| | | | | | | | We don't want to hide something like return in a preprocessor macro. Unroll the macro and use a goto, which also reduces the size of ohci1394.ko. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* ieee1394: Use shorter list_splice_init() for brevity.Robert P. J. Day2008-04-182-6/+3
| | | | | Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-18 20:50:52 +0100