1. 29 Dec, 2009 3 commits
    • Stefan Richter's avatar
      firewire: ohci: always use packet-per-buffer mode for isochronous reception · 090699c0
      Stefan Richter authored
      This is a minimal change meant for the short term:  Never set the
      ohci->use_dualbuffer flag to true.
      
      There are two reasons to do so:
      
        - Packet-per-buffer mode and dual-buffer mode do not behave the same
          under certain circumstances, notably if several packets are covered
          by a single fw_cdev_iso_packet descriptor.
          http://marc.info/?l=linux1394-devel&m=124965653718313
          Therefore the driver stack should not silently choose one or the
          other mode but should leave the choice to the high-level driver
          (regardless if kernel driver or userspace driver).  Or simply always
          only offer packet-per-buffer mode, since a considerable number of
          controllers, even current ones, does not offer dual-buffer support.
      
        - Even under circumstances where packet-per-buffer mode and
          dual-buffer mode behave exactly the same --- notably when used
          through libraw1394, libdc1394, as well as the current two kernel
          drivers which use isochronous reception (firewire-net and firedtv)
          --- we are still faced with the problem that several OHCI 1.1
          controllers have bugs in dual-buffer mode.  Although it looks like
          we have identified most of those buggy controllers by now, we
          cannot be quite sure about that.
      
      So, use packet-per-buffer by default from now on.  This change should
      be followed up by a more complete solution:  Either extend the
      in-kernel API and the userspace ABI by a choice between the two IR modes
      or remove all dual-buffer related code from firewire-ohci.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      090699c0
    • Stefan Richter's avatar
      firewire: cdev: fix another memory leak in an error path · cf0e575d
      Stefan Richter authored
      If copy_from_user in an FW_CDEV_IOC_SEND_RESPONSE ioctl failed, the
      fw_request pointed to by the inbound_transaction_resource is no
      longer referenced and needs to be freed.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      cf0e575d
    • Clemens Ladisch's avatar
      firewire: fix use of multiple AV/C devices, allow multiple FCP listeners · db5d247a
      Clemens Ladisch authored
      Control of more than one AV/C device at once --- e.g. camcorders, tape
      decks, audio devices, TV tuners --- failed or worked only unreliably,
      depending on driver implementation.  This affected kernelspace and
      userspace drivers alike and was caused by firewire-core's inability to
      accept multiple registrations of FCP listeners.
      
      The fix allows multiple address handlers to be registered for the FCP
      command and response registers.  When a request for these registers is
      received, all handlers are invoked, and the Firewire response is
      generated by the core and not by any handler.
      
      The cdev API does not change, i.e., userspace is still expected to send
      a response for FCP requests; this response is silently ignored.
      Signed-off-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog, rebased, whitespace)
      db5d247a
  2. 24 Dec, 2009 37 commits