1. 20 Mar, 2011 1 commit
    • Clemens Ladisch's avatar
      firewire: core: increase default SPLIT_TIMEOUT value · dd5eeb99
      Clemens Ladisch authored
      The SPLIT_TIMEOUT mechanism is intended to detect requests that somehow
      got lost.  However, when the timeout value is too low, transactions that
      could have been completed successfully will be cancelled.  Furthermore,
      there are chips whose firmwares ignore the configured split timeout and
      send late split response; known examples are the DM1x00 (BeBoB), TCD22x0
      (DICE), and some OXUF936QSE firmwares.
      
      This patch changes the default timeout to two seconds, which happens to
      be the default on other OSes, too.
      
      Actual lost requests are extremely rare, so there should be no practical
      downside to increasing the split timeout even on devices that work
      correctly.
      Signed-off-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      dd5eeb99
  2. 14 Mar, 2011 2 commits
  3. 26 Feb, 2011 4 commits
  4. 23 Jan, 2011 5 commits
  5. 20 Jan, 2011 1 commit
    • Stefan Richter's avatar
      firewire: core: fix unstable I/O with Canon camcorder · 6044565a
      Stefan Richter authored
      Regression since commit 10389536, "firewire: core: check for 1394a
      compliant IRM, fix inaccessibility of Sony camcorder":
      
      The camcorder Canon MV5i generates lots of bus resets when asynchronous
      requests are sent to it (e.g. Config ROM read requests or FCP Command
      write requests) if the camcorder is not root node.  This causes drop-
      outs in videos or makes the camcorder entirely inaccessible.
      https://bugzilla.redhat.com/show_bug.cgi?id=633260
      
      Fix this by allowing any Canon device, even if it is a pre-1394a IRM
      like MV5i are, to remain root node (if it is at least Cycle Master
      capable).  With the FireWire controller cards that I tested, MV5i always
      becomes root node when plugged in and left to its own devices.
      
      Reported-by: Ralf Lange
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Cc: <stable@kernel.org> # 2.6.32.y and newer
      6044565a
  6. 13 Jan, 2011 1 commit
    • Clemens Ladisch's avatar
      firewire: ohci: fix compilation on arches without PAGE_KERNEL_RO · 14271304
      Clemens Ladisch authored
      PAGE_KERNEL_RO is not available on all architectures, so its use
      in the new AR code broke compilation on sparc64.
      
      Because the read-only mapping was just a debugging aid, just use
      PAGE_KERNEL instead.
      Signed-off-by: default avatarClemens Ladisch <clemens@ladisch.de>
      
      James Bottomley wrote:
      > On Thu, 2011-01-13 at 08:27 +0100, Clemens Ladisch wrote:
      >> firewire: ohci: fix compilation on arches without PAGE_KERNEL_RO, e.g. sparc
      >>
      >> PAGE_KERNEL_RO is not available on all architectures, so its use in the
      >> new AR code broke compilation on sparc64.
      >>
      >> Because the R/O mapping is only used to catch drivers that try to write
      >> to the reception buffer and not actually required for correct operation,
      >> we can just use a normal PAGE_KERNEL mapping where _RO is not available.
      [...]
      >> +/*
      >> + * For archs where PAGE_KERNEL_RO is not supported;
      >> + * mapping the AR buffers readonly for the CPU is just a debugging aid.
      >> + */
      >> +#ifndef PAGE_KERNEL_RO
      >> +#define PAGE_KERNEL_RO PAGE_KERNEL
      >> +#endif
      >
      > This might cause interesting issues on sparc64 if it ever acquired a
      > PAGE_KERNEL_RO.  Sparc64 has extern pgprot_t for it's PAGE_KERNEL types
      > rather than #defines, so the #ifdef check wouldn't see this.
      >
      > I think either PAGE_PROT_RO becomes part of our arch API (so all
      > architectures are forced to add it), or, if it's not part of the API,
      > ohci isn't entitled to use it.  The latter seems simplest since you have
      > no real use for write protection anyway.
      Reported-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      14271304
  7. 04 Jan, 2011 4 commits
  8. 03 Jan, 2011 1 commit
  9. 19 Dec, 2010 2 commits
    • Stefan Richter's avatar
      firewire: net: set carrier state at ifup · c1671470
      Stefan Richter authored
      At ifup, carrier status would be shown on even if it actually was off.
      Also add an include for ethtool_ops rather than to rely on the one from
      netdevice.h.
      
      Note, we can alas not use fwnet_device_mutex to serialize access to
      dev->peer_count (as I originally wanted).  This would cause a lock
      inversion:
        - fwnet_probe | takes fwnet_device_mutex
            + register_netdev | takes rtnl_mutex
        - devinet_ioctl | takes rtnl_mutex
            + fwnet_open | ...must not take fwnet_device_mutex
      
      Hence use the dev->lock spinlock for serialization.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      c1671470
    • Maxim Levitsky's avatar
      firewire: net: add carrier detection · 18bb36f9
      Maxim Levitsky authored
      To make userland, e.g. NetworkManager work with firewire, we need to
      detect whether cable is plugged or not.  Simple and correct way of doing
      that is just counting number of peers.  No peers - no link and vice
      versa.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      18bb36f9
  10. 13 Dec, 2010 10 commits
  11. 12 Dec, 2010 4 commits
  12. 07 Dec, 2010 3 commits
  13. 06 Dec, 2010 2 commits