user/sven/linux.git/drivers/firewire/core-transaction.c, branch v4.4.294

firewire: core: use correct vendor/model IDs

2015-02-02T20:56:03Z

The kernel was using the vendor ID 0xd00d1e, which was inherited from the old ieee1394 driver stack. However, this ID was not registered, and invalid. Instead, use the vendor/model IDs that are now officially assigned to the kernel: https://ieee1394.wiki.kernel.org/index.php/IEEE_OUI_Assignments [stefanr: - The vendor ID 001f11 is Openmoko, Inc.'s identifier, registered at IEEE Registration Authority. - The range of model IDs 023900...0239ff are the Linux kernel 1394 subsystem's identifiers, registered at Openmoko. - Model ID 023901 is picked by the subsystem developers as firewire-core's model ID.] Signed-off-by: Clemens Ladisch Signed-off-by: Stefan Richter

firewire: Enable remote DMA above 4 GB

2014-01-20T00:11:13Z

This makes all of a machine's memory accessible to remote debugging via FireWire, using the physical response unit (i.e. RDMA) of OHCI-1394 link layer controllers. This requires actual support by the controller. The only ones currently known to support it are Agere/LSI FW643. Most if not all other OHCI-1394 controllers do not implement the optional Physical Upper Bound register. With them, RDMA will continue to be limited to the lowermost 4 GB. firewire-ohci's startup message in the kernel log is augmented to tell whether the controller does expose more than 4 GB to RDMA. While OHCI-1394 allows for a maximum Physical Upper Bound of 0xffff'0000'0000 (near 256 TB), this implementation sets it to 0x8000'0000'0000 (128 TB) in order to avoid interference with applications that require interrupt-served asynchronous request reception at respectively low addresses. Note, this change does not switch remote DMA on. It only increases the range of remote access to all memory (instead of just 4 GB) whenever remote DMA was switched on by other means. The latter is achieved by setting firewire-ohci's remote_dma parameter, or if the physical DMA filter is opened through firewire-sbp2. Derived from patch "firewire: Enable physical DMA above 4GB" by Peter Hurley from March 27, 2013. Signed-off-by: Stefan Richter

tree-wide: use reinit_completion instead of INIT_COMPLETION

2013-11-15T00:32:21Z

Use this new function to make code more comprehensible, since we are reinitialzing the completion, not initializing. [akpm@linux-foundation.org: linux-next resyncs] Signed-off-by: Wolfram Sang Acked-by: Linus Walleij (personally at LCE13) Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

firewire: WQ_NON_REENTRANT is meaningless and going away

2013-07-30T13:46:18Z

dbf2576e37 ("workqueue: make all workqueues non-reentrant") made WQ_NON_REENTRANT no-op and the flag is going away. Remove its usages. This patch doesn't introduce any behavior changes. Signed-off-by: Tejun Heo Signed-off-by: Stefan Richter

firewire: addendum to address handler RCU conversion

2012-09-28T09:47:42Z

Follow up on commit c285f6ff6787 "firewire: remove global lock around address handlers, convert to RCU": - address_handler_lock no longer serializes the address handler, only its function to serialize updates to the list of handlers remains. Rename the lock to address_handler_list_lock. - Callers of fw_core_remove_address_handler() must be able to sleep. Comment on this in the API documentation. - The counterpart fw_core_add_address_handler() is by nature something which is used in process context. Replace spin_lock_bh() by spin_lock() in fw_core_add_address_handler() and in fw_core_remove_address_handler(), and document that process context is now required for fw_core_add_address_handler(). - Extend the documentation of fw_address_callback_t. Signed-off-by: Stefan Richter

firewire: remove global lock around address handlers, convert to RCU

2012-09-28T09:47:41Z

Upper-layer handlers for inbound requests were called with a spinlock held by firewire-core. Calling into upper layers with a lower layer lock held is generally a bad idea. What's more, since commit ea102d0ec475 "firewire: core: convert AR-req handler lock from _irqsave to _bh", a caller of fw_send_request() i.e. initiator of outbound request could no longer do that while having interrupts disabled, if the local node was addressed by that request. In order to make all this more flexible, convert the management of address ranges and handlers from a global lock around readers and writers to RCU (and a remaining global lock for writers). As a minor side effect, handling of inbound requests at different cards and of local requests is now no longer serialized. (There is still per-card serialization of remote requests since firewire-ohci uses a single DMA tasklet for inbound request events.) In other words, address handlers are now called in an RCU read-side critical section instead of from within a spin_lock_bh serialized section. (Changelog rewritten by Stefan R.) Signed-off-by: Peter Hurley Signed-off-by: Stefan Richter

Merge tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394

2012-07-30T16:32:39Z

Pull firewire updates from Stefan Richter: - Small fixes and optimizations. - A new sysfs attribute to tell local and remote nodes apart. Useful to set special permissions/ ownership of local nodes' /dev/fw*, to start daemons on them (for diagnostics, management, AV targets, VersaPHY initiator or targets...), to pick up their GUID to use it as GUID of an SBP2 target instance, and of course for informational purposes. * tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: core: document is_local sysfs attribute firewire: core: add is_local sysfs device attribute firewire: ohci: initialize multiChanMode bits after reset firewire: core: fix multichannel IR with buffers larger than 2 GB firewire: ohci: sanity-check MMIO resource firewire: ohci: lazy bus time initialization firewire: core: allocate the low memory region firewire: core: make address handler length 64 bits

firewire: core: allocate the low memory region

2012-05-27T10:31:11Z

Prevent userspace applications from allocating low memory address ranges. Otherwise, if some application happens to allocate such a range and intends for a remote node to access it, and if that node also implements SBP-2 (which will become more likely with the upcoming SBP-2 target support), these accesses would be routed by the physical DMA unit to some wrong memory address. Signed-off-by: Clemens Ladisch Signed-off-by: Stefan Richter

Merge tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394

2012-05-24T19:57:47Z

Pull IEEE 1394 (FireWire) subsystem updates from Stefan Richter: - Fix mismatch between DMA mapping direction (was wrong) and DMA synchronization direction (was correct) of isochronous reception buffers of userspace drivers if vma-mapped for R/W access. For example, libdc1394 was affected. - more consistent retry stategy in device discovery/ rediscovery, and improved failure diagnostics - various small cleanups, e.g. use SCSI layer's DMA mapping API in firewire-sbp2 * tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: firewire: sbp2: document the absence of alignment requirements firewire: sbp2: remove superfluous blk_queue_max_segment_size() call firewire: sbp2: use scsi_dma_(un)map firewire: sbp2: give correct DMA device to scsi framework firewire: core: fw_device_refresh(): clean up error handling firewire: core: log config rom reading errors firewire: core: log error in case of failed bus manager lock firewire: move rcode_string() to core firewire: core: improve reread_config_rom() interface firewire: core: wait for inaccessible devices after bus reset firewire: ohci: omit spinlock IRQ flags where possible firewire: ohci: correct signedness of a local variable firewire: core: fix DMA mapping direction firewire: use module_pci_driver

firewire: Add function to get speed from opaque struct fw_request

2012-05-09T22:25:17Z

Sometimes it's useful to know the FireWire speed of the request that has just come in to a fw_address_handler callback. As struct fw_request is opaque we can't peek inside to get the speed out of the struct fw_packet that's just inside. For example, the SBP-2 spec says: "The speed at which the block write request to the MANAGEMENT_AGENT register is received shall determine the speed used by the target for all subsequent requests to read the initiator’s configuration ROM, fetch ORB’s from initiator memory or store status at the initiator’s status_FIFO. Command block ORB’s separately specify the speed for requests addressed to the data buffer or page table." [ ANSI T10/1155D Revision 4 page 53/54 ] Signed-off-by: Chris Boot Acked-by: Stefan Richter Cc: Clemens Ladisch Signed-off-by: Nicholas Bellinger