1. 25 3月, 2009 2 次提交
  2. 21 1月, 2009 2 次提交
  3. 05 1月, 2009 2 次提交
  4. 26 10月, 2008 1 次提交
  5. 14 7月, 2008 1 次提交
    • S
      firewire: fix race of bus reset with request transmission · 792a6102
      Stefan Richter 提交于
      Reported by Jay Fenlason:  A bus reset tasklet may call
      fw_flush_transactions and touch transactions (call their callback which
      will free them) while the context which submitted the transaction is
      still inserting it into the transmission queue.
      
      A simple solution to this problem is to _not_ "flush" the transactions
      because of a bus reset (complete the transcations as 'cancelled').  They
      will now simply time out (completed as 'cancelled' by the split-timeout
      timer).
      
      Jay Fenlason thought of this fix too but I was quicker to type it out.
      :-)
      
      Background:
      Contexts which access an instance of struct fw_transaction are:
       1. the submitter, until it inserted the packet which is embedded in the
          transaction into the AT req DMA,
       2. the AsReqTrContext tasklet when the request packet was acked by the
          responder node or transmission to the responder failed,
       3. the AsRspRcvContext tasklet when it found a request which matched
          an incoming response,
       4. the card->flush_timer when it picks up timed-out transactions to
          cancel them,
       5. the bus reset tasklet when it cancels transactions (this access is
          eliminated by this patch),
       6. a process which shuts down an fw_card (unregisters it from fw-core
          when the controller is unbound from fw-ohci) --- although in this
          case there shouldn't really be any transactions anymore because we
          wait until all card users finished their business with the card.
      
      All of these contexts run concurrently (except for the 6th, presumably).
      The 1st is safe against the 2nd and 3rd because of the way how a request
      packet is carefully submitted to the hardware.  A race between 2nd and
      3rd has been fixed a while ago (bug 9617).  The 4th is almost safe
      against 1st, 2nd, 3rd;  there are issues with it if huge scheduling
      latencies occur, to be fixed separately.  The 5th looks safe against
      2nd, 3rd, and 4th but is unsafe against 1st.  Maybe this could be fixed
      with an explicit state variable in struct fw_transaction.  But this
      would require fw_transaction to be rewritten as only dynamically
      allocatable object with reference counting --- not a good solution if we
      also can simply kill this 5th accessing context (replace it by the 4th).
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      792a6102
  6. 18 4月, 2008 2 次提交
    • S
      firewire: fix synchronization of gap counts · 25b1c3d8
      Stefan Richter 提交于
      Fix:  The fact that nodes had different gap counts would be overlooked
      if the bus manager code would pick gap count 63 because of beta
      repeaters or because of very large hop counts.  In this case, the bus
      manager code would miss that it actually has to send the PHY config
      packet with gap count 63.
      
      Related trivial changes:  Use bool for an int used as bool, touch up
      some comments.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      25b1c3d8
    • 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
  7. 14 3月, 2008 1 次提交
  8. 02 3月, 2008 1 次提交
  9. 31 1月, 2008 1 次提交
  10. 17 10月, 2007 2 次提交
  11. 10 7月, 2007 3 次提交
  12. 11 5月, 2007 5 次提交
  13. 29 3月, 2007 1 次提交
  14. 10 3月, 2007 10 次提交