aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/firewire
Commit message (Collapse)AuthorAge
* firewire: fw-ohci: fix IOMMU resource exhaustionStefan Richter2008-12-10
| | | | | | | | | | | | | | There is a DMA map/ unmap imbalance whenever a block write request packet is sent and then dequeued with ohci_cancel_packet. The latter may happen frequently if the AR resp tasklet is executed before the AT req tasklet for the same transaction. Add the missing dma_unmap_single. This fixes https://bugzilla.redhat.com/show_bug.cgi?id=475156 Reported-by: Emmanuel Kowalski Tested-by: Emmanuel Kowalski Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: fw-sbp2: another iPod mini quirk entryStefan Richter2008-11-25
| | | | | | | | 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>
* firewire: struct device - replace bus_id with dev_name(), dev_set_name()Kay Sievers2008-10-31
| | | | | | 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>
* firewire: fw-sbp2: fix racesJay Fenlason2008-10-26
| | | | | | | | | | | | | | | | | 1: There is a small race between queue_delayed_work() and its corresponding kref_get(). Do the kref_get first, and _put it again if the queue_delayed_work() failed, so there is no chance of the kref going to zero while the work is scheduled. 2: An SBP2_LOGOUT_REQUEST could be sent out with a login_id full of garbage. Initialize it to an invalid value so we can tell if we ever got a valid login_id. 3: The node ID and generation may have changed but the new values may not yet have been recorded in lu and tgt when the final logout is attempted. Use the latest values from the device in sbp2_release_target(). Signed-off-by: Jay Fenlason <fenlason@redhat.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: fw-sbp2: delay first login to avoid retriesStefan Richter2008-10-26
| | | | | | | | | | | | | | | | | | | | | | | This optimizes firewire-sbp2's device probe for the case that the local node and the SBP-2 node were discovered at the same time. In this case, fw-core's bus management work and fw-sbp2's login and SCSI probe work are scheduled in parallel (in the globally shared workqueue and in fw-sbp2's workqueue, respectively). The bus reset from fw-core may then disturb and extremely delay the login and SCSI probe because the latter fails with several command timeouts and retries and has to be retried from scratch. We avoid this particular situation of sbp2_login() and fw_card_bm_work() running in parallel by delaying the first sbp2_login() a little bit. This is meant to be a short-term fix for https://bugzilla.redhat.com/show_bug.cgi?id=466679. In the long run, the SCSI probe, i.e. fw-sbp2's call of __scsi_add_device(), should be parallelized with sbp2_reconnect(). Problem reported and fix tested and confirmed by Alex Kanavin. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: fw-ohci: initialization failure path fixesStefan Richter2008-10-26
| | | | | | Fix leaks when pci_probe fails. Simplify error log strings. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: fw-ohci: don't leak dma memory on module removalJay Fenlason2008-10-26
| | | | | | | | | | The transmit and receive context dma memory was not being freed on module removal. Neither was the config rom memory. Fix that. The ab->next assignment is pure paranoia. Signed-off-by: Jay Fenlason <fenlason@redhat.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: fix struct fw_node memory leakJay Fenlason2008-10-26
| | | | | | | | | With the bus_resets patch applied, it is easy to see this memory leak by repeatedly resetting the firewire bus while running slabtop in another window. Just watch kmalloc-32 grow and grow... Signed-off-by: Jay Fenlason <fenlason@redhat.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: Survive more than 256 bus resetsJay Fenlason2008-10-26
| | | | | | | | | | | | | The "color" is used during the topology building after a bus reset, hovever in "struct fw_node"s it is stored in a u8, but in struct fw_card it is stored in an int. When the value wraps in one struct, but not the other, disaster strikes. Signed-off-by: Jay Fenlason <fenlason@redhat.com> Fixes http://bugzilla.kernel.org/show_bug.cgi?id=10922. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: fix ioctl() return codeStefan Richter2008-10-15
| | | | | | | | Reported by Jay Fenlason: ioctl() did not return as intended - the size of data read into ioctl_send_request, - the number of datagrams enqueued by ioctl_queue_iso. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: fix setting tag and sy in iso transmissionStefan Richter2008-10-15
| | | | | | | Reported by Jay Fenlason: The iso packet control accessors in fw-cdev.c had bogus masks. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: fw-sbp2: fix another small generation access bugStefan Richter2008-10-15
| | | | | | | | | | | queuecommand() looked at the remote and local node IDs before it read the bus generation. The corresponding race with sbp2_reconnect updating these data was probably impossible to happen though because the current code blocks the SCSI layer during reconnection. However, better safe than sorry, especially if someone later improves the code to not block the SCSI layer. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: fw-sbp2: enforce s/g segment size limitStefan Richter2008-10-15
| | | | | | | | | | | | | | | | | | | | | | | | 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 firewire 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. Thanks to Grant Grundler and FUJITA Tomonori for advice. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: fw_send_request_sync()Jay Fenlason2008-10-15
| | | | | | | | | | | | | Share code between fw_send_request + wait_for_completion callers. Signed-off-by: Jay Fenlason <fenlason@redhat.com> Addendum: Removes an unnecessary struct and an ununsed retry loop. Calls it fw_run_transaction() instead of fw_send_request_sync(). Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Acked-by: Kristian Høgsberg <krh@redhat.com>
* firewire: Kconfig help updateStefan Richter2008-08-19
| | | | Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Merge branch 'for-linus' of ↵Linus Torvalds2008-08-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: firewire: Preserve response data alignment bug when it is harmless
| * firewire: Preserve response data alignment bug when it is harmlessDavid Moore2008-08-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Recently, a bug having to do with the alignment of transaction response data was fixed. However, some apps such as libdc1394 relied on the presence of that bug in order to function correctly. In order to stay compatible with old versions of those apps, this patch preserves the bug in cases where it is harmless to normal operation (such as the single quadlet read) due to a simple duplication of data. This guarantees maximum compatability for those users who are using the old app with the fixed kernel. Signed-off-by: David Moore <dcm@acm.org> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* | Merge branch 'for-linus' of ↵Linus Torvalds2008-07-27
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: state userland requirements in Kconfig help firewire: avoid memleak after phy config transmit failure firewire: fw-ohci: TSB43AB22/A dualbuffer workaround firewire: queue the right number of data firewire: warn on unfinished transactions during card removal firewire: small fw_fill_request cleanup firewire: fully initialize fw_transaction before marking it pending firewire: fix race of bus reset with request transmission
| * firewire: state userland requirements in Kconfig helpStefan Richter2008-07-25
| | | | | | | | Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: avoid memleak after phy config transmit failureStefan Richter2008-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use only statically allocated data for PHY config packet transmission. With the previous incarnation, some data wouldn't be freed if the packet transmit callback was never called. A theoretical drawback now is that, in PCs with more than one card, card A may complete() for a waiter on card B. But this is highly unlikely and its impact not serious. Bus manager B may reset bus B before the PHY config went out, but the next phy config on B should be fine. However, with a timeout of 100ms, this situation is close to impossible. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: fw-ohci: TSB43AB22/A dualbuffer workaroundStefan Richter2008-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Isochronous reception in dualbuffer mode is reportedly broken with TI TSB43AB22A on x86-64. Descriptor addresses above 2G have been determined as the trigger: https://bugzilla.redhat.com/show_bug.cgi?id=435550 Two fixes are possible: - pci_set_consistent_dma_mask(pdev, DMA_31BIT_MASK); at least when IR descriptors are allocated, or - simply don't use dualbuffer. This fix implements the latter workaround. But we keep using dualbuffer on x86-32 which won't give us highmen (and thus physical addresses outside the 31bit range) in coherent DMA memory allocations. Right now we could for example also whitelist PPC32, but DMA mapping implementation details are expected to change there. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Jarod Wilson <jwilson@redhat.com>
| * firewire: queue the right number of dataJiSheng Zhang2008-07-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There will be 4 padding bytes in struct fw_cdev_event_response on some platforms The member:__u32 data will point to these padding bytes. While queue the response and data in complete_transaction in fw-cdev.c, it will queue like this: |response(excluding padding bytes)|4 padding bytes|4 padding bytes|data. It queue 4 extra bytes. That is to say it use "&response + sizeof(response)" while other place of kernel and userspace library use "&response + offsetof (typeof(response), data)". So it will lost the last 4 bytes of data. This patch can fix it while not changing the struct definition. Signed-off-by: JiSheng Zhang <jszhang3@mail.ustc.edu.cn> This fixes responses to outbound block read requests on 64bit architectures. Tested on i686, x86-64, and x86-64 with i686 userland, using firecontrol and gscanbus. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: warn on unfinished transactions during card removalStefan Richter2008-07-14
| | | | | | | | | | | | | | | | | | | | | | | | After card->done and card->work are completed, any remaining pending request would be a bug. We cannot safely complete a transaction at that point anymore. IOW card users must not drop their last fw_card reference (usually indirect references through fw_device references) before their last outbound transaction through that card was finished. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: small fw_fill_request cleanupStefan Richter2008-07-14
| | | | | | | | | | | | | | | | - better name for a function argument - removal of a local variable which became unnecessary after "fully initialize fw_transaction before marking it pending" Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: fully initialize fw_transaction before marking it pendingStefan Richter2008-07-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In theory, card->flush_timer could already access a transaction between fw_send_request()'s spin_unlock_irqrestore and the rest of what happens in fw_send_request(). This would happen if the process which sends the request is preempted and put to sleep right after spin_unlock_irqrestore for longer than 100ms. Therefore we fill in everything in struct fw_transaction at which the flush_timer might look at before we lift the lock. To do: Ensure that the timer does not pick up the transaction before the time of the AT request event plus split transaction timeout. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * firewire: fix race of bus reset with request transmissionStefan Richter2008-07-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reported by Jay Fenlason: A bus reset tasklet may call fw_flush_transactions and touch transactions (call their callback which will free them) while the context which submitted the transaction is still inserting it into the transmission queue. A simple solution to this problem is to _not_ "flush" the transactions because of a bus reset (complete the transcations as 'cancelled'). They will now simply time out (completed as 'cancelled' by the split-timeout timer). Jay Fenlason thought of this fix too but I was quicker to type it out. :-) Background: Contexts which access an instance of struct fw_transaction are: 1. the submitter, until it inserted the packet which is embedded in the transaction into the AT req DMA, 2. the AsReqTrContext tasklet when the request packet was acked by the responder node or transmission to the responder failed, 3. the AsRspRcvContext tasklet when it found a request which matched an incoming response, 4. the card->flush_timer when it picks up timed-out transactions to cancel them, 5. the bus reset tasklet when it cancels transactions (this access is eliminated by this patch), 6. a process which shuts down an fw_card (unregisters it from fw-core when the controller is unbound from fw-ohci) --- although in this case there shouldn't really be any transactions anymore because we wait until all card users finished their business with the card. All of these contexts run concurrently (except for the 6th, presumably). The 1st is safe against the 2nd and 3rd because of the way how a request packet is carefully submitted to the hardware. A race between 2nd and 3rd has been fixed a while ago (bug 9617). The 4th is almost safe against 1st, 2nd, 3rd; there are issues with it if huge scheduling latencies occur, to be fixed separately. The 5th looks safe against 2nd, 3rd, and 4th but is unsafe against 1st. Maybe this could be fixed with an explicit state variable in struct fw_transaction. But this would require fw_transaction to be rewritten as only dynamically allocatable object with reference counting --- not a good solution if we also can simply kill this 5th accessing context (replace it by the 4th). Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* | dma-mapping: add the device argument to dma_mapping_error()FUJITA Tomonori2008-07-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER architecture does: This enables us to cleanly fix the Calgary IOMMU issue that some devices are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423). I think that per-device dma_mapping_ops support would be also helpful for KVM people to support PCI passthrough but Andi thinks that this makes it difficult to support the PCI passthrough (see the above thread). So I CC'ed this to KVM camp. Comments are appreciated. A pointer to dma_mapping_ops to struct dev_archdata is added. If the pointer is non NULL, DMA operations in asm/dma-mapping.h use it. If it's NULL, the system-wide dma_ops pointer is used as before. If it's useful for KVM people, I plan to implement a mechanism to register a hook called when a new pci (or dma capable) device is created (it works with hot plugging). It enables IOMMUs to set up an appropriate dma_mapping_ops per device. The major obstacle is that dma_mapping_error doesn't take a pointer to the device unlike other DMA operations. So x86 can't have dma_mapping_ops per device. Note all the POWER IOMMUs use the same dma_mapping_error function so this is not a problem for POWER but x86 IOMMUs use different dma_mapping_error functions. The first patch adds the device argument to dma_mapping_error. The patch is trivial but large since it touches lots of drivers and dma-mapping.h in all the architecture. This patch: dma_mapping_error() doesn't take a pointer to the device unlike other DMA operations. So we can't have dma_mapping_ops per device. Note that POWER already has dma_mapping_ops per device but all the POWER IOMMUs use the same dma_mapping_error function. x86 IOMMUs use device argument. [akpm@linux-foundation.org: fix sge] [akpm@linux-foundation.org: fix svc_rdma] [akpm@linux-foundation.org: build fix] [akpm@linux-foundation.org: fix bnx2x] [akpm@linux-foundation.org: fix s2io] [akpm@linux-foundation.org: fix pasemi_mac] [akpm@linux-foundation.org: fix sdhci] [akpm@linux-foundation.org: build fix] [akpm@linux-foundation.org: fix sparc] [akpm@linux-foundation.org: fix ibmvscsi] Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Muli Ben-Yehuda <muli@il.ibm.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Avi Kivity <avi@qumranet.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Merge branch 'sbp2-spindown' of ↵Linus Torvalds2008-07-15
|\ \ | |/ |/| | | | | | | | | | | | | | | | | 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
| * firewire: fw-sbp2: spin disks down on suspend and shutdownStefan Richter2008-07-14
| | | | | | | | | | | | | | | | | | | | | | 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> Tested-by: Tino Keitel <tino.keitel@gmx.de>
| * firewire: fw-sbp2: fix spindown for PL-3507 and TSB42AA9 firmwaresStefan Richter2008-07-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> Tested-by: Tino Keitel <tino.keitel@gmx.de>
* | firewire: don't respond to broadcast write requestsStefan Richter2008-07-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Contrary to a comment in the source, request->ack of a broadcast write request can be ACK_PENDING. Hence the existing check is insufficient. Debug dmesg before: AR spd 0 tl 00, ffc0 -> ffff, ack_pending , QW req, fffff0000234 = ffffffff AT spd 0 tl 00, ffff -> ffc0, ack_complete, W resp And the requesting node (linux1394) reports an unsolicited response. Debug dmesg after: AR spd 0 tl 00, ffc0 -> ffff, ack_pending , QW req, fffff0000234 = ffffffff Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* | firewire: clean up fw_card reference countingStefan Richter2008-07-14
| | | | | | | | | | | | | | | | | | | | | | | | | | This is a functionally equivalent replacement of the current reference counting of struct fw_card instances. It only converts it to common idioms as suggested by Kristian Høgsberg: - struct kref replaces atomic_t as the counter. - wait_for_completion is used to wait for all card users to complete. BTW, it may make sense to count card->flush_timer and card->work as card users too. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* | firewire: clean up some includesStefan Richter2008-07-14
| | | | | | | | Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* | firewire: remove unused struct membersStefan Richter2008-07-14
| | | | | | | | Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* | firewire: implement broadcast_channel CSR for 1394a complianceStefan Richter2008-07-14
|/ | | | | | See IEEE 1394a clause 8.3.2.3.11. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: fw-sbp2: fix parsing of logical unit directoriesRichard Sharpe2008-06-27
| | | | | | | | | | There is a small off-by-one bug in firewire-sbp2. This causes problems when a device exports multiple LUN Directories. I found it when trying to talk to a SONY DVD Jukebox. Signed-off-by: Richard Sharpe <realrichardsharpe@gmail.com> Acked-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (op. order, changelog)
* firewire: Kconfig menu touch-upStefan Richter2008-06-18
| | | | | | | Emphasize the recommendation to build only one stack. Trim the prompts to better fit into short attention spans. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: deadline for PHY config transmissionStefan Richter2008-06-18
| | | | | | | | | | | | | | | | | | | | | | | | | | If the low-level driver failed to initialize a card properly without noticing it, fw-core was blocked indefinitely when trying to send a PHY config packet. This hung up the events kernel thread, e.g. locked up keyboard input. https://bugzilla.redhat.com/show_bug.cgi?id=444694 https://bugzilla.redhat.com/show_bug.cgi?id=446763 This problem was introduced between 2.6.25 and 2.6.26-rc1 by commit 2a0a2590498be7b92e3e76409c9b8ee722e23c8f "firewire: wait until PHY configuration packet was transmitted (fix bus reset loop)". The solution is to wait with timeout. I tested it with 7 different working controllers and 1 non-working controller. On the working ones, the packet callback complete()s usually --- but not always --- before a timeout of 10ms. Hence I chose a safer timeout of 100ms. On the few tests with the non-working controller ALi M5271, PHY config packet transmission always timed out so far. (Fw-ohci needs to be fixed for this controller independently of this deadline fix. Often the core doesn't even attempt to send a phy config because not even self ID reception works.) Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: fw-ohci: unify printk prefixesStefan Richter2008-06-18
| | | | | | | | | The messages which can be enabled by fw-ohci's debug module parameter are changed from KERN_DEBUG to KERN_NOTICE level and uniformly prefixed with "firewire_ohci: ". This further simplifies communication with users when we ask them to capture debug messages. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: fill_bus_reset_event needs lock protectionStefan Richter2008-06-18
| | | | | | | | | | | | | | | | | | | | | Callers of fill_bus_reset_event() have to take card->lock. Otherwise access to node data may oops if node removal is in progress. A lockless alternative would be - event->local_node_id = card->local_node->node_id; + tmp = fw_node_get(card->local_node); + event->local_node_id = tmp->node_id; + fw_node_put(tmp); and ditto with the other node pointers which fill_bus_reset_event() accesses. But I went the locked route because one of the two callers already holds the lock. As a bonus, we don't need the memory barrier anymore because device->generation and device->node_id are written in a card->lock protected section. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Kristian Høgsberg <krh@redhat.com>
* firewire: fw-ohci: write selfIDBufferPtr before LinkControl.rcvSelfIDStefan Richter2008-06-18
| | | | | | | | | | | | | OHCI 1.1 clause 5.10 requires that selfIDBufferPtr is valid when a 1 is written into LinkControl.rcvSelfID. This driver bug has so far not been known to cause harm because most chips obviously accept a later selfIDBufferPtr write, at least before HCControl.linkEnable is written. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Jarod Wilson <jwilson@redhat.com> Signed-off-by: Kristian Høgsberg <krh@redhat.com>
* firewire: fw-ohci: disable PHY packet reception into AR contextStefan Richter2008-06-18
| | | | | | | | | | | | | We want the rcvPhyPkt bit in LinkControl off before we start using the chip. However, the spec says that the reset value of it is undefined. Hence switch it explicitly off. https://bugzilla.redhat.com/show_bug.cgi?id=244576#c48 shows that for example the nForce2 integrated FireWire controller seems to have it on by default. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Jarod Wilson <jwilson@redhat.com>
* firewire: fw-ohci: use of uninitialized data in AR handlerStefan Richter2008-06-18
| | | | | | | | | | | | header_length and payload_length are filled with random data if an unknown tcode was read from the AR buffer (i.e. if the AR buffer contained invalid data). We still need a better strategy to recover from this, but at least handle_ar_packet now doesn't return out of bound buffer addresses anymore. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: don't panic on invalid AR request bufferStefan Richter2008-06-18
| | | | | | | | | | | BUG() at this place is wrong. (Unless if the low level driver would already do higher-level input validation of incoming request headers.) Invalid incoming requests or bugs in the controller which corrupt the AR-req buffer needlessly crashed the box because this is run in tasklet context. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* firewire: prevent userspace from accessing shut down devicesJay Fenlason2008-05-20
| | | | | | | | | | | | | | | | If userspace ignores the POLLERR bit from poll(), and only attempts to read() the device when POLLIN is set, it can still make ioctl() calls on a device that has been removed from the system. The node_id and generation returned by GET_INFO will be outdated, but INITIATE_BUS_RESET would still cause a bus reset, and GET_CYCLE_TIMER will return data. And if you guess the correct generation to use, you can send requests to a different device on the bus, and get responses back. This patch prevents open, ioctl, compat_ioctl, and mmap against shutdown devices. Signed-off-by: Jay Fenlason <fenlason@redhat.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6Linus Torvalds2008-05-02
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: [SCSI] aic94xx: fix section mismatch [SCSI] u14-34f: Fix 32bit only problem [SCSI] dpt_i2o: sysfs code [SCSI] dpt_i2o: 64 bit support [SCSI] dpt_i2o: move from virt_to_bus/bus_to_virt to dma_alloc_coherent [SCSI] dpt_i2o: use standard __init / __exit code [SCSI] megaraid_sas: fix suspend/resume sections [SCSI] aacraid: Add Power Management support [SCSI] aacraid: Fix jbod operations scan issues [SCSI] aacraid: Fix warning about macro side-effects [SCSI] add support for variable length extended commands [SCSI] Let scsi_cmnd->cmnd use request->cmd buffer [SCSI] bsg: add large command support [SCSI] aacraid: Fix down_interruptible() to check the return value correctly [SCSI] megaraid_sas; Update the Version and Changelog [SCSI] ibmvscsi: Handle non SCSI error status [SCSI] bug fix for free list handling [SCSI] ipr: Rename ipr's state scsi host attribute to prevent collisions [SCSI] megaraid_mbox: fix Dell CERC firmware problem
| * [SCSI] Let scsi_cmnd->cmnd use request->cmd bufferBoaz Harrosh2008-05-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - struct scsi_cmnd had a 16 bytes command buffer of its own. This is an unnecessary duplication and copy of request's cmd. It is probably left overs from the time that scsi_cmnd could function without a request attached. So clean that up. - Once above is done, few places, apart from scsi-ml, needed adjustments due to changing the data type of scsi_cmnd->cmnd. - Lots of drivers still use MAX_COMMAND_SIZE. So I have left that #define but equate it to BLK_MAX_CDB. The way I see it and is reflected in the patch below is. MAX_COMMAND_SIZE - means: The longest fixed-length (*) SCSI CDB as per the SCSI standard and is not related to the implementation. BLK_MAX_CDB. - The allocated space at the request level - I have audit all ISA drivers and made sure none use ->cmnd in a DMA Operation. Same audit was done by Andi Kleen. (*)fixed-length here means commands that their size can be determined by their opcode and the CDB does not carry a length specifier, (unlike the VARIABLE_LENGTH_CMD(0x7f) command). This is actually not exactly true and the SCSI standard also defines extended commands and vendor specific commands that can be bigger than 16 bytes. The kernel will support these using the same infrastructure used for VARLEN CDB's. So in effect MAX_COMMAND_SIZE means the maximum size command scsi-ml supports without specifying a cmd_len by ULD's Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
* | Merge branch 'for-linus' of ↵Linus Torvalds2008-05-01
|\ \ | |/ |/| | | | | | | | | | | 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
| * firewire: fw-sbp2: log scsi_target ID at releaseStefan Richter2008-05-01
| | | | | | | | | | | | | | Makes the good-by message more informative. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Jarod Wilson <jwilson@redhat.com>
* | Convert asm/semaphore.h users to linux/semaphore.hMatthew Wilcox2008-04-18
| | | | | | | | Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
generated by cgit v1.2.2 (git 2.25.0) at 2024-12-22 09:53:02 -0500