1. 24 2月, 2009 5 次提交
    • S
      ieee1394: remove superfluous assertions · 00fc3072
      Stefan Richter 提交于
      hpsb_read, hpsb_write, hpsb_lock are sleeping functions which nobody is
      in danger to use in atomic context.  Besides, in_interrupt does not
      cover all types of atomic context.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      00fc3072
    • S
      ieee1394: inherit ud vendor_id from node vendor_id · 9c939e4d
      Stefan Richter 提交于
      While Module_Vendor_ID in the configuration ROM's root directory is
      mandatory, there often aren't vendor IDs in unit directories.  This
      affects the new firedtv driver which is meant to be auto-loaded and
      matched only for vendor-specific devices.
      
      We now always copy ne->vendor_id into ud->vendor_id before we scan a
      unit directory (and fill in a possibly present vendor ID from there).
      This way, the root directory's vendor ID is used as fallback in the
      "uevent" environment for modprobe'ing per module alias when a node was
      plugged in, and in the driver match routine when protocol drivers are
      bound to unit directories.  It will however not be used as sysfs
      attribute of a unit directory device.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      9c939e4d
    • S
      ieee1394: add hpsb_node_read() and hpsb_node_lock() · b33fdd6c
      Stefan Richter 提交于
      These will be used by the firedtv driver.  Like hpsb_node_write() they
      are much better APIs for high-level drivers than hpsb_write() and its
      siblings --- easier to use correctly and also terser.
      
      Unlike hspb_node_write(), the two new functions will only be used by
      one call site.  Hence make them static inline instead of exported
      symbols.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      b33fdd6c
    • S
      ieee1394: use correct barrier types between accesses of nodeid and generation · 29f8ea8a
      Stefan Richter 提交于
      A compiler barrier (explicit on the read side, implicit on the write
      side) is not quite enough for what has to be accomplished here.  Use
      hardware memory barriers on systems which need them.
      
      (Of course a full fix of generation handling would require much more
      than this.  The ieee1394 core's bus generation counter had to be tied to
      the controller's bus generation counter; cf. Kristian's stack.  It's
      just that I have other current business with the code around these
      barrier()s, so why not do at least this small fix.)
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      29f8ea8a
    • S
      firesat: copyrights, rename to firedtv, API conversions, fix remote control input · 612262a5
      Stefan Richter 提交于
      Combination of the following changes:
      
      Tue, 26 Aug 2008 00:17:30 +0200 (CEST)
      firedtv: fix remote control input
      
          and update the scancode-to-keycode mapping to a current model.  Per
          default, various media key keycodes are emitted which closely match what
          is printed on the remote.  Userland can modify the mapping by means of
          evdev ioctls.  (Not tested.)
      
          The old scancode-to-keycode mapping is left in the driver but cannot be
          modified by ioctls.  This preserves status quo for old remotes.
      
      Tue, 26 Aug 2008 00:11:28 +0200 (CEST)
      firedtv: replace tasklet by workqueue job
      
          Non-atomic context is a lot nicer to work with.
      
      Sun, 24 Aug 2008 23:30:00 +0200 (CEST)
      firedtv: move some code back to ieee1394 core
      
          Partially reverts "ieee1394: remove unused code" of Linux 2.6.25.
      
      Sun, 24 Aug 2008 23:29:30 +0200 (CEST)
      firedtv: replace semaphore by mutex
      
          firesat->avc_sem and ->demux_sem have been used exactly like a mutex.
          The only exception is the schedule_remotecontrol tasklet which did a
          down_trylock in atomic context.  This is not possible with
          mutex_trylock; however the whole remote control related code is
          non-functional anyway at the moment.  This should be fixed eventually,
          probably by turning the tasklet into a worqueue job.
      
          Convert everything else from semaphore to mutex.
      
          Also rewrite a few of the affected functions to unlock the mutex at a
          single exit point, instead of in several branches.
      
      Sun, 24 Aug 2008 23:28:45 +0200 (CEST)
      firedtv: some header cleanups
      
          Unify #ifndef/#define/#endif guards against multiple inclusion.
          Drop extern keyword from function declarations.
          Remove #include's into header files where struct declarations suffice.
      
          Remove unused ohci1394 interface and related unused ieee1394 interfaces.
      
          Add a few missing #include's and remove a few apparently obsolete ones.
          Sort them alphabetically.
      
      Sun, 24 Aug 2008 23:27:45 +0200 (CEST)
      firedtv: nicer registration message and some initialization fixes
      
          Print the correct name in dvb_register_adapter().
      
          While we are at it, replace two switch cascades by one for loop, remove
          a superfluous member of struct firesat and of two unused arguments of
          AVCIdentifySubunit(), and fix bogus kfree's in firesat_dvbdev_init().
      
      Tue, 26 Aug 2008 14:24:17 +0200 (CEST)
      firesat: rename to firedtv
      
          Suggested by Andreas Monitzer.  Besides DVB-S/-S2 receivers, the driver
          also supports DVB-C and DVB-T receivers, hence the previous project name
          is too narrow now.
      
          Not yet done:  Rename source directory, files, types, variables...
      
      Sun, 24 Aug 2008 23:26:23 +0200 (CEST)
      firesat: add missing copyright notes
      
          Reported by Andreas Monitzer and Christian Dolzer.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      612262a5
  2. 06 2月, 2009 1 次提交
  3. 30 1月, 2009 1 次提交
  4. 29 1月, 2009 4 次提交
  5. 27 1月, 2009 1 次提交
  6. 24 1月, 2009 1 次提交
  7. 07 1月, 2009 3 次提交
  8. 05 1月, 2009 13 次提交
  9. 14 12月, 2008 1 次提交
  10. 10 12月, 2008 1 次提交
    • N
      ieee1394: node manager causes up to ~3.25s delay in freezing tasks · ec9a13cd
      Nigel Cunningham 提交于
      The firewire nodemanager function "nodemgr_host_thread" contains a loop
      that calls try_to_freeze near the top of the loop, but then delays for
      up to 3.25 seconds (plus time to do work) before getting back to the top
      of the loop. When starting a cycle post-boot, this doesn't seem to bite,
      but it is causing a noticeable delay at boot time, when freezing
      processes prior to starting to read the image.
      
      The following patch adds invocation of try_to_freeze to the subloops
      that are used in the body of this function. With these additions, the
      time to freeze when starting to resume at boot time is virtually zero.
      I'm no expert on firewire, and so don't know that we shouldn't check
      the return value and jump back to the top of the loop or such like after
      being frozen, but I submit it for your consideration.
      Signed-off-by: NNigel Cunningham <nigel@tuxonice.net>
      
      The delay until nodemgr freezes was up to 0.25s (plus time for node
      probes) in Linux 2.6.27 and older and up to 3.25s (plus ~) since Linux
      2.6.28-rc1, hence much more noticeable.
      
      try_to_freeze() without any jump is correct.  The surrounding code in
      the respective loops will catch whether another bus reset happens during
      the freeze and handle it.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      ec9a13cd
  11. 30 11月, 2008 2 次提交
  12. 26 11月, 2008 1 次提交
  13. 02 11月, 2008 1 次提交
    • A
      saner FASYNC handling on file close · 233e70f4
      Al Viro 提交于
      As it is, all instances of ->release() for files that have ->fasync()
      need to remember to evict file from fasync lists; forgetting that
      creates a hole and we actually have a bunch that *does* forget.
      
      So let's keep our lives simple - let __fput() check FASYNC in
      file->f_flags and call ->fasync() there if it's been set.  And lose that
      crap in ->release() instances - leaving it there is still valid, but we
      don't have to bother anymore.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      233e70f4
  14. 31 10月, 2008 3 次提交
  15. 17 10月, 2008 1 次提交
  16. 16 10月, 2008 1 次提交
    • S
      ieee1394: survive a few seconds connection loss · fc392fe8
      Stefan Richter 提交于
      There are situations when nodes vanish from the bus and come back in
      quickly thereafter:
        - When certain bus-powered hubs are plugged in,
        - when certain disk enclosures are switched from self-power to bus
          power or vice versa and break the daisy chain during the transition,
        - when the user plugs a cable out and quickly plugs it back in, e.g.
          to reorder a daisy chain (works on Mac OS X if done quickly enough),
        - when certain hubs temporarily malfunction during high bus traffic.
      
      The ieee1394 driver's nodemgr already contained a function to set
      vanished nodes aside into "limbo"; i.e. they wouldn't actually be
      deleted right away.  (In fact, only unloading the driver or writing into
      an obscure sysfs attribute would delete them eventually.)  If nodes
      reappeared later, they would be resurrected out of limbo.
      
      Moving nodes into and out of limbo was accompanied with calling the
      .suspend() and .resume() driver methods of the drivers which were bound
      to a respective node's unit directories.  Not only is this somewhat
      strange due to the intended use of these driver methods for power
      management, also the sbp2 driver in particular does not implement
      .suspend() and .resume().  Hence sbp2 would be disconnected from devices
      in situations as listed above.
      
      We now:
        - leave drivers bound when nodes go into limbo,
        - call the drivers' .update() when nodes come out of limbo,
        - automatically delete in-limbo nodes 3 seconds after the last
          bus reset and bus rescan.
        - Because of the automatic removal, the now obsolete bus attribute
          /sys/bus/ieee1394/destroy_node is removed.
      
      This especially lets sbp2 survive brief disconnections.  You can for
      example yank a disk's cable and plug it back in while reading the
      respective disk with dd, but dd will happily continue as if nothing
      happened.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      fc392fe8