1. 24 2月, 2009 2 次提交
    • 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: 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
  2. 05 1月, 2009 1 次提交
    • S
      ieee1394: ignore nonzero Bus_Info_Block.max_rom, fetch config ROM in quadlets · 0bed1819
      Stefan Richter 提交于
      It is already known that buggy firmwares exist which report a bogus
      link_spd in their config ROM bus info block.  We now got the first
      report of a bogus max_rom too (Freecom FireWire Hard Drive 1TB,
      http://bugzilla.kernel.org/show_bug.cgi?id=12206).
      
      I suspect other OSs only use quadlet reads to fetch the config ROM,
      otherwise the firmware authors would have noticed their mistake.
      Hence limit ieee1394's config ROM fetching routine to quadlets as the
      safe minimum regardless of what the bus info block says.
      
      This will potentially slow the bus reset handling by nodemgr somewhat
      down.  But most existing devices support only quadlet reads anyway,
      hence there will often be no actual difference to before this change.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      0bed1819
  3. 14 12月, 2008 1 次提交
  4. 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
  5. 31 10月, 2008 1 次提交
  6. 16 10月, 2008 2 次提交
    • 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
    • S
      ieee1394: nodemgr clean up class iterators · 11305c3e
      Stefan Richter 提交于
      Remove useless pointer type casts.
      Remove unnecessary hi->host indirection where only host is used.
      Remove an unnecessary WARN_ON.
      Change a few names.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      11305c3e
  7. 20 8月, 2008 2 次提交
  8. 22 7月, 2008 2 次提交
  9. 02 5月, 2008 1 次提交
  10. 19 4月, 2008 1 次提交
  11. 18 4月, 2008 1 次提交
  12. 25 1月, 2008 1 次提交
  13. 17 10月, 2007 3 次提交
    • S
      ieee1394: csr1212: proper refcounting · 17a19b79
      Stefan Richter 提交于
      At least since nodemgr got rid of coarse global locking, accesses to
      struct csr1212_keyval's reference counter should be atomic and coupled
      with proper barriers.  Also, calls to csr1212_keep_keyval(kv) should
      occur before kv is being used.
      
      (We probably should convert refcnt to struct kref, but how to keep
      csr1212_destroy_keyval's implementation non-recursively then?)
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      17a19b79
    • S
      ieee1394: nodemgr: fix leak of struct csr1212_keyval · 638d5bb8
      Stefan Richter 提交于
      csr1212_keep_keyval(kv) in nodemgr_process_root_directory was
      unbalanced if ne->vendor_name_kv already exists.  This happens for
      example if eth1394 or raw1394 modify the local config ROM and it is
      parsed again.
      
      As a bonus, the attempt to add the vendor_name_kv sysfs attribute
      when it already exists is now fixed for good.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      638d5bb8
    • S
      ieee1394: Fix kthread stopping in nodemgr_host_thread · 69e2b602
      Satyam Sharma 提交于
      The nodemgr host thread can exit on its own even when kthread_should_stop
      is not true, on receiving a signal (might never happen in practice, as
      it ignores signals). But considering kthread_stop() must not be mixed with
      kthreads that can exit on their own, I think changing the code like this
      is clearer. This change means the thread can cut its sleep short when
      receive a signal but looking at the code around, that sounds okay (and
      again, it might never actually recieve a signal in practice).
      Signed-off-by: NSatyam Sharma <satyam@infradead.org>
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      69e2b602
  14. 13 10月, 2007 1 次提交
    • K
      Driver core: change add_uevent_var to use a struct · 7eff2e7a
      Kay Sievers 提交于
      This changes the uevent buffer functions to use a struct instead of a
      long list of parameters. It does no longer require the caller to do the
      proper buffer termination and size accounting, which is currently wrong
      in some places. It fixes a known bug where parts of the uevent
      environment are overwritten because of wrong index calculations.
      
      Many thanks to Mathieu Desnoyers for finding bugs and improving the
      error handling.
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      7eff2e7a
  15. 18 7月, 2007 1 次提交
    • R
      Freezer: make kernel threads nonfreezable by default · 83144186
      Rafael J. Wysocki 提交于
      Currently, the freezer treats all tasks as freezable, except for the kernel
      threads that explicitly set the PF_NOFREEZE flag for themselves.  This
      approach is problematic, since it requires every kernel thread to either
      set PF_NOFREEZE explicitly, or call try_to_freeze(), even if it doesn't
      care for the freezing of tasks at all.
      
      It seems better to only require the kernel threads that want to or need to
      be frozen to use some freezer-related code and to remove any
      freezer-related code from the other (nonfreezable) kernel threads, which is
      done in this patch.
      
      The patch causes all kernel threads to be nonfreezable by default (ie.  to
      have PF_NOFREEZE set by default) and introduces the set_freezable()
      function that should be called by the freezable kernel threads in order to
      unset PF_NOFREEZE.  It also makes all of the currently freezable kernel
      threads call set_freezable(), so it shouldn't cause any (intentional)
      change of behaviour to appear.  Additionally, it updates documentation to
      describe the freezing of tasks more accurately.
      
      [akpm@linux-foundation.org: build fixes]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NNigel Cunningham <nigel@nigel.suspend2.net>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Gautham R Shenoy <ego@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      83144186
  16. 16 7月, 2007 1 次提交
  17. 10 7月, 2007 2 次提交
  18. 01 6月, 2007 2 次提交
    • 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
    • S
      ieee1394: fix calculation of sysfs attribute "address" · a52938f3
      Stefan Richter 提交于
      struct csr1212_keyval.offset is relative to 0xffff f000 0000 rather than
      0xffff f000 0400.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      a52938f3
  19. 09 5月, 2007 1 次提交
  20. 30 4月, 2007 6 次提交
  21. 28 4月, 2007 2 次提交
  22. 17 2月, 2007 1 次提交
  23. 09 2月, 2007 2 次提交
  24. 08 12月, 2006 2 次提交