1. 02 Feb, 2015 1 commit
  2. 19 Jan, 2014 1 commit
    • Stefan Richter's avatar
      firewire: Enable remote DMA above 4 GB · fcd46b34
      Stefan Richter authored
      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 <peter@hurleysoftware.com> from March 27, 2013.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
  3. 14 Nov, 2013 1 commit
  4. 30 Jul, 2013 1 commit
  5. 28 Sep, 2012 2 commits
    • Stefan Richter's avatar
      firewire: addendum to address handler RCU conversion · 4d50c443
      Stefan Richter authored
      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: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Peter Hurley's avatar
      firewire: remove global lock around address handlers, convert to RCU · 35202f7d
      Peter Hurley authored
      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 ea102d0e "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
      (Changelog rewritten by Stefan R.)
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
  6. 27 May, 2012 1 commit
  7. 09 May, 2012 1 commit
    • Chris Boot's avatar
      firewire: Add function to get speed from opaque struct fw_request · 253d9237
      Chris Boot authored
      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: default avatarChris Boot <bootc@bootc.net>
      Acked-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Cc: Clemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
  8. 17 Apr, 2012 1 commit
  9. 22 Feb, 2012 4 commits
    • Stefan Richter's avatar
      firewire: core: convert AR-req handler lock from _irqsave to _bh · ea102d0e
      Stefan Richter authored
      fw_core_handle_request() is called by the low-level driver in tasklet
      context or process context, and fw_core_add/remove_address_handler() is
      called by mid- or high-level code in process context.  So convert
      address_handler_lock accesses from those which disable local IRQs to
      ones which just disable local softIRQs.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Stefan Richter's avatar
      firewire: core: fix race at address_handler unregistration · 90963f1c
      Stefan Richter authored
      Fix the following unlikely but possible race:
      CPU 1                             CPU 2
      AR-request tasklet
          lookup handler
                                        unregister handler
      				  free handler->callback_data or handler
          call handler->callback
      The application which registered the handler has no way to stop nodes
      sending new requests to their address range, hence cannot prevent this
      Fix it simply by extending the address_handler_lock-protected region
      from only around the lookup to around both lookup and call.  We only
      need to do so in the exclusive region handler; the FCP region handler
      already holds the lock around the handler->callback call.
      Alas this removes the current ability to execute the callback in
      parallel on different CPUs if it was called for different FireWire cards
      at the same time.  (For a single card, the handler is already
      serialized.)  If this loss of a rather obscure feature is not tolerable,
      a more complex fix would be required:  Add a handler reference counter;
      wait in fw_core_remove_address_handler() for this conter to become zero.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Stefan Richter's avatar
      firewire: core: remove obsolete comment · 280f64d4
      Stefan Richter authored
      Target-like applications or peer-to-peer-like applications require the
      global address handler registration which we have right now, or a per-
      card registration.  And node lookup, while it would be nice to have,
      would be impossible in the brief time between self-ID-complete event and
      completion of firewire-core's topology scanning.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Stefan Richter's avatar
      firewire: core: prefix log messages with card name · 26b4950d
      Stefan Richter authored
      Associate all log messages from firewire-core with the respective card
      because some people have more than one card.  E.g.
          firewire_ohci 0000:04:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0
          firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0
          firewire_core: created device fw0: GUID 0814438400000389, S800
          firewire_core: phy config: new root=ffc1, gap_count=5
          firewire_core: created device fw1: GUID 0814438400000388, S800
          firewire_core: created device fw2: GUID 0001d202e06800d1, S800
      turns into
          firewire_ohci 0000:04:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0
          firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0
          firewire_core 0000:04:00.0: created device fw0: GUID 0814438400000389, S800
          firewire_core 0000:04:00.0: phy config: new root=ffc1, gap_count=5
          firewire_core 0000:05:00.0: created device fw1: GUID 0814438400000388, S800
          firewire_core 0000:04:00.0: created device fw2: GUID 0001d202e06800d1, S800
      This increases the module size slightly; to keep this in check, turn the
      former printk wrapper macros into functions.  Their implementation is
      largely copied from driver core's dev_printk counterparts.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
  10. 09 Oct, 2011 1 commit
  11. 10 May, 2011 3 commits
    • Stefan Richter's avatar
      firewire: sbp2: parallelize login, reconnect, logout · 105e53f8
      Stefan Richter authored
      The struct sbp2_logical_unit.work items can all be executed in parallel
      but are not reentrant.  Furthermore, reconnect or re-login work must be
      executed in a WQ_MEM_RECLAIM workqueue.
      Hence replace the old single-threaded firewire-sbp2 workqueue by a
      concurrency-managed but non-reentrant workqueue with rescuer.
      firewire-core already maintains one, hence use this one.
      In earlier versions of this change, I observed occasional failures of
      parallel INQUIRY to an Initio INIC-2430 FireWire 800 to dual IDE bridge.
      More testing indicates that parallel INQUIRY is not actually a problem,
      but too quick successions of logout and login + INQUIRY, e.g. a quick
      sequence of cable plugout and plugin, can result in failed INQUIRY.
      This does not seem to be something that should or could be addressed by
      Another dual-LU device to which I currently have access to, an
      OXUF924DSB FireWire 800 to dual SATA bridge with firmware from MacPower,
      has been successfully tested with this too.
      This change is beneficial to environments with two or more FireWire
      storage devices, especially if they are located on the same bus.
      Management tasks that should be performed as soon and as quickly as
      possible, especially reconnect, are no longer held up by tasks on other
      devices that may take a long time, especially login with INQUIRY and sd
      or sr driver probe.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Stefan Richter's avatar
      firewire: core: use non-reentrant workqueue with rescuer · 6ea9e7bb
      Stefan Richter authored
      firewire-core manages the following types of work items:
        - resets the bus on a card and possibly sends a PHY packet before that
        - does not sleep for long or not at all
        - is scheduled via fw_schedule_bus_reset() by
            - firewire-ohci's pci_probe method
            - firewire-ohci's set_config_rom method, called by kernelspace
              protocol drivers and userspace drivers which add/remove
      	Configuration ROM descriptors
            - userspace drivers which use the bus reset ioctl
            - itself if the last reset happened less than 2 seconds ago
        - performs bus management duties
        - usually does not (but may in corner cases) sleep for long
        - is scheduled via fw_schedule_bm_work() by
            - firewire-ohci's self-ID-complete IRQ handler tasklet
            - firewire-core's fw_device.work instances whenever the root node
              device was (successfully or unsuccessfully) discovered,
      	refreshed, or rediscovered
            - itself in case of resource allocation failures or in order to
              obey the 125ms bus manager arbitration interval
        - performs node probe, update, shutdown, revival, removal; including
          kernel driver probe, update, shutdown and bus reset notification to
          userspace drivers
        - usually sleeps moderately long, in corner cases very long
        - is scheduled by
            - firewire-ohci's self-ID-complete IRQ handler tasklet via the
              core's fw_node_event
            - firewire-ohci's pci_remove method via core's fw_destroy_nodes/
            - itself during retries, e.g. while a node is powering up
        - accesses registers at the Isochronous Resource Manager node
        - usually does not (but may in corner cases) sleep for long
        - is scheduled via schedule_iso_resource() by
            - the owning userspace driver at addition and removal of the
            - firewire-core's fw_device.work instances after bus reset
            - itself in case of resource allocation if necessary to obey the
              1000ms reallocation period after bus reset
      fw_card.br_work instances should not, and instances of the others must
      not, be executed in parallel by multiple CPUs -- but were not protected
      against that.  Hence allocate a non-reentrant workqueue for them.
      fw_device.work may be used in the memory reclaim path in case of SBP-2
      device updates.  Hence we need a workqueue with rescuer and cannot use
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Reviewed-by: default avatarTejun Heo <tj@kernel.org>
    • Stefan Richter's avatar
      firewire: octlet AT payloads can be stack-allocated · f30e6d3e
      Stefan Richter authored
      We do not need slab allocations anymore in order to satisfy
      streaming DMA mapping constraints, thanks to commit da28947e
      "firewire: ohci: avoid separate DMA mapping for small AT payloads".
      (Besides, the slab-allocated buffers that firewire-core, firewire-sbp2,
      and firedtv used to provide for 8-byte write and lock requests were
      still not fully portable since they crossed cacheline boundaries or
      shared a cacheline with unrelated CPU-accessed data.  snd-firewire-lib
      got this aspect right by using an extra kmalloc/ kfree just for the
      8-byte transaction buffer.)
      This change replaces kmalloc'ed lock transaction scratch buffers in
      firewire-core, firedtv, and snd-firewire-lib by local stack allocations.
      Perhaps the most notable result of the change is simpler locking because
      there is no need to serialize usages of preallocated per-device buffers
      anymore.  Also, allocations and deallocations are simpler.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Acked-by: default avatarClemens Ladisch <clemens@ladisch.de>
  12. 04 Jan, 2011 1 commit
  13. 13 Dec, 2010 1 commit
  14. 12 Dec, 2010 1 commit
  15. 19 Aug, 2010 1 commit
  16. 23 Jul, 2010 3 commits
    • Stefan Richter's avatar
      firewire: core: fix upper bound of possible CSR allocations · 0c9ae701
      Stefan Richter authored
      region->end is defined as an upper bound of the requested address range,
      exclusive --- i.e. as an address outside of the range in which the
      requested CSR is to be placed.
      Hence 0x0001,0000,0000,0000 is the biggest valid region->end, not
      0x0000,ffff,ffff,fffc like the current check asserted.
      For simplicity, the fix drops the region->end & 3 test because there is
      no actual problem with these bits set in region->end.  The allocated
      address range will be quadlet aligned and of a size of multiple quadlets
      due to the checks for region->start & 3 and handler->length & 3 alone.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Stefan Richter's avatar
      firewire: cdev: add PHY packet reception · bf54e146
      Stefan Richter authored
      Add an FW_CDEV_IOC_RECEIVE_PHY_PACKETS ioctl() and
      FW_CDEV_EVENT_PHY_PACKET_RECEIVED poll()/read() event for /dev/fw*.
      This can be used to get information from remote PHYs by remote access
      PHY packets.
      This is also the 2nd half of the functionality (the receive part) to
      support a userspace implementation of a VersaPHY transaction layer.
      Safety considerations:
        - PHY packets are generally broadcasts, hence some kind of elevated
          privileges should be required of a process to be able to listen in
          on PHY packets.  This implementation assumes that a process that is
          allowed to open the /dev/fw* of a local node does have this
          There was an inconclusive discussion about introducing POSIX
          capabilities as a means to check for user privileges for these
          kinds of operations.
      Other limitations:
        - PHY packet reception may be switched on by ioctl() but cannot be
          switched off again.  It would be trivial to provide an off switch,
          but this is not worth the code.  The client should simply close()
          the fd then, or just ignore further events.
        - For sake of simplicity of API and kernel-side implementation, no
          filter per packet content is provided.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Stefan Richter's avatar
      firewire: normalize status values in packet callbacks · 18d0cdfd
      Stefan Richter authored
      core-transaction.c transmit_complete_callback() and close_transaction()
      expect packet callback status to be an ACK or RCODE, and ACKs get
      translated to RCODEs for transaction callbacks.
      An old comment on the packet callback API (been there from the initial
      submission of the stack) and the dummy_driver implementation of
      send_request/send_response deviated from this as they also included
      -ERRNO in the range of status values.
      Let's narrow status values down to ACK and RCODE to prevent surprises.
      RCODE_CANCELLED is chosen as the dummy_driver's RCODE as its meaning of
      "transaction timed out" comes closest to what happens when a transaction
      coincides with card removal.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
  17. 13 Jul, 2010 2 commits
    • Stefan Richter's avatar
      firewire: core: integrate software-forced bus resets with bus management · 02d37bed
      Stefan Richter authored
      Bus resets which are triggered
        - by the kernel drivers after updates of the local nodes' config ROM,
        - by userspace software via ioctl
      shall be deferred until after >=2 seconds after the last bus reset.
      If multiple modifications of the local nodes' config ROM happen in a row,
      only a single bus reset should happen after them.
      When the local node's link goes from inactive to active or vice versa,
      and at the two occasions of bus resets mentioned above --- and if the
      current gap count differs from 63 --- the bus reset should be preceded
      by a PHY configuration packet that reaffirms the gap count.  Otherwise a
      bus manager would have to reset the bus again right after that.
      This is necessary to promote bus stability, e.g. leave grace periods for
      allocations and reallocations of isochronous channels and bandwidth,
      SBP-2 reconnections etc.; see IEEE 1394 clause 8.2.1.
      This change implements all of the above by moving bus reset initiation
      into a delayed work (except for bus resets which are triggered by the
      bus manager workqueue job and are performed there immediately).  It
      comes with a necessary addition to the card driver methods that allows
      to get the current gap count from PHY registers.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Stefan Richter's avatar
      firewire: core: fix fw_send_request kerneldoc comment · 656b7afd
      Stefan Richter authored
      The present inline documentation of the fw_send_request() in-kernel API
      refers to userland code that is not applicable to kernel drivers at all.
      Reported-by: default avatarBen Gamari <bgamari.foss@gmail.com>
      While we are at fixing the whole documentation of fw_send_request(),
      also improve the rest of firewire-core's kerneldoc comments:
        - Add a bit of text concerning fw_run_transaction()'s call parameters.
        - Append () to function names and tab-align parameter descriptions as
          suggested by the example in Documentation/kernel-doc-nano-HOWTO.txt.
        - Remove kerneldoc markers from comments on static functions.
        - Remove outdated parameter descriptions at build_tree().
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
  18. 20 Jun, 2010 2 commits
    • Jay Fenlason's avatar
      firewire: expose extended tcode of incoming lock requests to (userspace) drivers · c82f91f2
      Jay Fenlason authored
      When a remote device does a LOCK_REQUEST, the core does not pass
      the extended tcode to userspace.  This patch makes it use the
      juju-specific tcodes listed in firewire-constants.h for incoming
      Signed-off-by: default avatarJay Fenlason <fenlason@redhat.com>
      This matches how tcode in the API for outbound requests is treated.
      Affects kernelspace and userspace drivers alike, but at the moment there
      are no kernespace drivers that receive lock requests.
      Split out from a combo patch, slightly reordered, changelog reworded.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Stefan Richter's avatar
      firewire: remove an unused function argument · 33e553fe
      Stefan Richter authored
      void (*fw_address_callback_t)(..., int speed, ...) is the speed that a
      remote node chose to transmit a request to us.  In case of split
      transactions, firewire-core will transmit the response at that speed.
      Upper layer drivers on the other hand (firewire-net, -sbp2, firedtv, and
      userspace drivers) cannot do anything useful with that speed datum,
      except log it for debug purposes.  But data that is merely potentially
      (not even actually) used for debug purposes does not belong into the API.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
  19. 19 Jun, 2010 6 commits
  20. 10 Jun, 2010 6 commits