1. 29 Dec, 2009 8 commits
    • Stefan Richter's avatar
      firewire: qualify config ROM cache pointers as const pointers · 13b302d0
      Stefan Richter authored
      Several config ROM related functions only peek at the ROM cache; mark
      their arguments as const pointers.  Ditto fw_device.config_rom and
      fw_unit.directory, as the memory behind them is meant to be write-once.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      13b302d0
    • Stefan Richter's avatar
      firewire: core: fw_csr_string addendum · 3c2c58cb
      Stefan Richter authored
      Witespace and comment changes, and a different way to say i + 1 < end.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      3c2c58cb
    • Clemens Ladisch's avatar
      firewire: add fw_csr_string() helper function · 1f8fef7b
      Clemens Ladisch authored
      The core (sysfs attributes), the firedtv driver, and possible future
      drivers all read strings from some configuration ROM directory.  Factor
      out the generic code from show_text_leaf() into a new helper function,
      modified slightly to handle arbitrary buffer sizes.
      Signed-off-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      1f8fef7b
    • Stefan Richter's avatar
      firewire, ieee1394: update Kconfig help · 5d7db049
      Stefan Richter authored
      Update the Kconfig help texts of both stacks to encourage a general move
      from the older to the newer drivers.  However, do not label ieee1394 as
      "Obsolete" yet, as the newer drivers have not been deployed as default
      stack in the majority of Linux distributions yet, and those who start
      doing so now may still want to install the old drivers as fallback for
      unforeseen issues.
      
      Since Linux 2.6.32, FireWire audio devices can be driven by the newer
      firewire driver stack too, hence remove an outdated comment about audio
      devices.  Also remove comments about library versions since the 2nd
      generation of libraw1394 and libdc1394 is now in common use; details on
      library versions can be read at the wiki link from the help texts.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      5d7db049
    • Stefan Richter's avatar
      firewire, ieee1394: update MAINTAINERS entries · 958a29cb
      Stefan Richter authored
      Ben and Kristian have not been involved in maintenance of the IEEE 1394
      drivers for quite some time; submitters are not required to Cc them on
      patches.
      
      The linux1394.org domain has been dead for a while and is no longer
      under control of a Linux developer.  The current web site of the
      Linux 1394 project is http://ieee1394.wiki.kernel.org/.
      
      The classic drivers/ieee1394/ stack is now obsolete from the development
      point of view, though still a useful alternative in productive use.  But
      nobody should attempt to submit style cleanup patches for it or to
      develop new drivers on top of this stack, hence mark its MAINTAINERS
      entry as Obsolete.
      
      drivers/ieee1394/raw1394*, like the rest of the old stack, does not
      receive bigger code changes anymore, hence shrink the MAINTAINERS
      database a bit by dropping raw1394's special entry.  If something
      important and urgent is going to come up for raw1394, I will make sure
      that Dan will be notified of it besides via linux1394-devel.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: default avatarDan Dennedy <dan@dennedy.org>
      Cc: Ben Collins <ben.collins@ubuntu.com>
      Cc: Kristian Hoegsberg <krh@bitplanet.net>
      958a29cb
    • 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 32 commits