1. 17 5月, 2009 1 次提交
    • S
      firewire: core: improve check for local node · 92368890
      Stefan Richter 提交于
      My recently added test for a device being local in fw-cdev.c got it
      slightly wrong:  Comparisons of node IDs are only valid if the
      generation is current, which I forgot to check.  Normally, serialization
      by card->lock takes care of this, but a device in FW_DEVICE_GONE state
      will necessarily have a wrong generation and invalid node_id.
      
      The "is it local?" check is made 100% correct and simpler now by means
      of a struct fw_device flag which is set at fw_device creation.
      
      Besides the fw-cdev site which was to be fixed, there is another site
      which can make use of the new flag, and an RFC-2734 driver will benefit
      from it too.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      92368890
  2. 25 3月, 2009 5 次提交
  3. 21 1月, 2009 1 次提交
    • S
      firewire: keep highlevel drivers attached during brief connection loss · 3d36a0df
      Stefan Richter 提交于
      There are situations when nodes vanish from the bus and come back
      quickly thereafter:
        - When certain bus-powered hubs are plugged in,
        - when certain devices are plugged into 6-port hubs,
        - 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.
      
      Until now, firewire-core reported affected nodes as lost to the
      highlevel drivers (firewire-sbp2 and userspace drivers).  We now delay
      the destruction of device representations until after at least two
      seconds after the last bus reset.  If a "new" device is detected in this
      period whose bus information block and root directory header match that
      of a device which is pending for deletion, we resurrect that device and
      send update calls to highlevel drivers.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      3d36a0df
  4. 05 1月, 2009 1 次提交
  5. 14 7月, 2008 1 次提交
  6. 18 4月, 2008 2 次提交
    • S
      firewire: reread config ROM when device reset the bus · c9755e14
      Stefan Richter 提交于
      When a device changes its configuration ROM, it announces this with a
      bus reset.  firewire-core has to check which node initiated a bus reset
      and whether any unit directories went away or were added on this node.
      
      Tested with an IOI FWB-IDE01AB which has its link-on bit set if bus
      power is available but does not respond to ROM read requests if self
      power is off.  This implements
        - recognition of the units if self power is switched on after fw-core
          gave up the initial attempt to read the config ROM,
        - shutdown of the units when self power is switched off.
      
      Also tested with a second PC running Linux/ieee1394.  When the eth1394
      driver is inserted and removed on that node, fw-core now notices the
      addition and removal of the IPv4 unit on the ieee1394 node.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      c9755e14
    • S
      firewire: refactor fw_unit reference counting · 1dc3bea7
      Stefan Richter 提交于
      Add wrappers for getting and putting a unit.
      Remove some line breaks.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NJarod Wilson <jwilson@redhat.com>
      1dc3bea7
  7. 02 3月, 2008 1 次提交
    • S
      firewire: fix crash in automatic module unloading · 855c603d
      Stefan Richter 提交于
      "modprobe firewire-ohci; sleep .1; modprobe -r firewire-ohci" used to
      result in crashes like this:
      
          BUG: unable to handle kernel paging request at ffffffff8807b455
          IP: [<ffffffff8807b455>]
          PGD 203067 PUD 207063 PMD 7c170067 PTE 0
          Oops: 0010 [1] PREEMPT SMP
          CPU 0
          Modules linked in: i915 drm cpufreq_ondemand acpi_cpufreq freq_table applesmc input_polldev led_class coretemp hwmon eeprom snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss button thermal processor sg snd_hda_intel snd_pcm snd_timer snd snd_page_alloc sky2 i2c_i801 rtc [last unloaded: crc_itu_t]
          Pid: 9, comm: events/0 Not tainted 2.6.25-rc2 #3
          RIP: 0010:[<ffffffff8807b455>]  [<ffffffff8807b455>]
          RSP: 0018:ffff81007dcdde88  EFLAGS: 00010246
          RAX: ffff81007dc95040 RBX: ffff81007dee5390 RCX: 0000000000005e13
          RDX: 0000000000008c8b RSI: 0000000000000001 RDI: ffff81007dee5388
          RBP: ffff81007dc5eb40 R08: 0000000000000002 R09: ffffffff8022d05c
          R10: ffffffff8023b34c R11: ffffffff8041a353 R12: ffff81007dee5388
          R13: ffffffff8807b455 R14: ffffffff80593bc0 R15: 0000000000000000
          FS:  0000000000000000(0000) GS:ffffffff8055a000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
          CR2: ffffffff8807b455 CR3: 0000000000201000 CR4: 00000000000006e0
          DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
          DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
          Process events/0 (pid: 9, threadinfo ffff81007dcdc000, task ffff81007dc95040)
          Stack:  ffffffff8023b396 ffffffff88082524 0000000000000000 ffffffff8807d9ae
          ffff81007dc5eb40 ffff81007dc9dce0 ffff81007dc5eb40 ffff81007dc5eb80
          ffff81007dc9dce0 ffffffffffffffff ffffffff8023be87 0000000000000000
          Call Trace:
          [<ffffffff8023b396>] ? run_workqueue+0xdf/0x1df
          [<ffffffff8023be87>] ? worker_thread+0xd8/0xe3
          [<ffffffff8023e917>] ? autoremove_wake_function+0x0/0x2e
          [<ffffffff8023bdaf>] ? worker_thread+0x0/0xe3
          [<ffffffff8023e813>] ? kthread+0x47/0x74
          [<ffffffff804198e0>] ? trace_hardirqs_on_thunk+0x35/0x3a
          [<ffffffff8020c008>] ? child_rip+0xa/0x12
          [<ffffffff8020b6e3>] ? restore_args+0x0/0x3d
          [<ffffffff8023e68a>] ? kthreadd+0x14c/0x171
          [<ffffffff8023e68a>] ? kthreadd+0x14c/0x171
          [<ffffffff8023e7cc>] ? kthread+0x0/0x74
          [<ffffffff8020bffe>] ? child_rip+0x0/0x12
      
          Code:  Bad RIP value.
          RIP  [<ffffffff8807b455>]
          RSP <ffff81007dcdde88>
          CR2: ffffffff8807b455
          ---[ end trace c7366c6657fe5bed ]---
      
      Note that this crash happened _after_ firewire-core was unloaded.  The
      shared workqueue tried to run firewire-core's device initialization jobs
      or similar jobs.
      
      The fix makes sure that firewire-ohci and hence firewire-core is not
      unloaded before all device shutdown jobs have been completed.  This is
      determined by the count of device initializations minus device releases.
      
      Also skip useless retries in the node initialization job if the node is
      to be shut down.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NJarod Wilson <jwilson@redhat.com>
      855c603d
  8. 16 2月, 2008 1 次提交
    • S
      firewire: fix "kobject_add failed for fw* with -EEXIST" · 96b19062
      Stefan Richter 提交于
      There is a race between shutdown and creation of devices:  fw-core may
      attempt to add a device with the same name of an already existing
      device.  http://bugzilla.kernel.org/show_bug.cgi?id=9828
      
      Impact of the bug:  Happens rarely (when shutdown of a device coincides
      with creation of another), forces the user to unplug and replug the new
      device to get it working.
      
      The fix is obvious:  Free the minor number *after* instead of *before*
      device_unregister().  This requires to take an additional reference of
      the fw_device as long as the IDR tree points to it.
      
      And while we are at it, we fix an additional race condition:
      fw_device_op_open() took its reference of the fw_device a little bit too
      late, hence was in danger to access an already invalid fw_device.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      96b19062
  9. 31 1月, 2008 1 次提交
  10. 17 10月, 2007 1 次提交
  11. 10 7月, 2007 1 次提交
  12. 01 6月, 2007 1 次提交
  13. 11 5月, 2007 1 次提交
  14. 29 3月, 2007 1 次提交
  15. 21 3月, 2007 1 次提交
  16. 10 3月, 2007 9 次提交