1. 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
  2. 20 8月, 2008 1 次提交
  3. 10 7月, 2007 1 次提交
  4. 01 6月, 2007 1 次提交
    • S
      ieee1394: sbp2: offer SAM-conforming target port ID in sysfs · d7794c86
      Stefan Richter 提交于
      With "modprobe sbp2 long_ieee1394_id=y", the format of
      /sys/bus/scsi/devices/*:*:*:*/ieee1394_id is changed from e.g.
      0001041010004beb:0:0 to 0001041010004beb:00042c:0000.
      
      The longer format fully conforms to object identifier sizes as per
      SAM(-2...4) and reflects what the SAM target port identifier is meant to
      contain:  A Discovery ID allegedly specified by ISO/IEC 13213:1994 ---
      however there is no such thing; the authors of SAM probably meant
      Directory ID).  Especially target nodes with multiple dynamically added
      targets may use Directory IDs to persistently identify target ports.
      
      The new format is independent of implementation details of nodemgr.
      Thus the same ieee1394_id attribute format can be implemented in the new
      firewire stack.
      
      The ieee1394_id is typically used to create persistently named links in
      /dev/disk/by-id.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      d7794c86
  5. 30 4月, 2007 2 次提交
  6. 09 2月, 2007 1 次提交
  7. 08 12月, 2006 1 次提交
    • B
      ieee1394: Consolidate driver registering · ed30c26e
      Ben Collins 提交于
      This patch consolidates some bookkeeping for driver registering. It
      closely models what pci_register_driver() does. The main addition is
      that the owner of the driver is set, so we get a proper symlink
      for /sys/bus/ieee1394/driver/*/module.
      
      Also moves setting of name and bus type into nodemgr. Because of this,
      we can remove the EXPORT_SYMBOL for ieee1394_bus_type, since it's now
      only used in ieee1394.ko.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      ed30c26e
  8. 18 9月, 2006 1 次提交
    • S
      ieee1394: shrink tlabel pools, remove tpool semaphores · 9951903e
      Stefan Richter 提交于
      This patch reduces the size of struct hpsb_host and also removes
      semaphores from ieee1394_transactions.c.  On i386, struct hpsb_host
      shrinks from 10656 bytes to 6688 bytes.  This is accomplished by
       - using a single wait_queue for hpsb_get_tlabel instead of many
         instances of semaphores,
       - using a single lock to serialize access to all tlabel pools (the
         protected code regions are small, i.e. lock contention very low),
       - omitting the sysfs attribute tlabels_allocations.
      
      Drawback:  In the rare case that a process needs to sleep because all
      transaction labels for the node are temporarily exhausted, it is also
      woken up if a tlabel for a different node became free, checks for an
      available tlabel, and is put to sleep again.  The check is not costly
      and the situation occurs extremely rarely.  (Tlabels are typically
      only exhausted if there was no context switch to the khpsbpkt thread
      which recycles tlables.)  Therefore the benefit of reduced tpool size
      outweighs this drawback.
      
      The sysfs attributes tlabels_free and tlabels_mask are not compiled
      anymore unless CONFIG_IEEE1394_VERBOSEDEBUG is set.
      
      The by far biggest member of struct hpsb_host, the struct csr_control
      csr (5272 bytes on i386), is now placed at the end of struct hpsb_host.
      
      Note, hpsb_get_tlabel calls the macro wait_event_interruptible with a
      condition argument which has a side effect (allocation of a tlabel and
      manipulation of the packet).  This side effect happens only if the
      condition is true.  The patch relies on wait_event_interruptible not
      evaluating the condition again after it became true.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      9951903e
  9. 04 7月, 2006 2 次提交
  10. 06 12月, 2005 1 次提交
  11. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4