1. 03 5月, 2011 1 次提交
    • B
      firewire: Fix for broken configrom updates in quick succession · 2e053a27
      B.J. Buchalter 提交于
      Current implementation of ohci_set_config_rom() uses a deferred
      bus reset via fw_schedule_bus_reset(). If clients add multiple
      unit descriptors to the config_rom in quick succession, the
      deferred bus reset may not have fired before succeeding update
      requests have come in. This can lead to an incorrect partial
      update of the config_rom for both addition and removal of
      config_rom descriptors, as the ohci_set_config_rom() routine
      will return -EBUSY if a previous pending update has not been
      completed yet; the requested update just gets dropped on the floor.
      
      This patch recognizes that the "in-flight" update can be modified
      until it has been processed by the bus-reset, and the locking
      in the bus_reset_tasklet ensures that the update is done atomically
      with respect to modifications made by ohci_set_config_rom(). The
      -EBUSY error case is simply removed.
      
      [Stefan R:  The bug always existed at least theoretically.  But it
      became easy to trigger since 2.6.36 commit 02d37bed "firewire: core:
      integrate software-forced bus resets with bus management" which
      introduced long mandatory delays between janitorial bus resets.]
      Signed-off-by: NBenjamin Buchalter <bj@mhlabs.com>
      Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (trivial style changes)
      Cc: <stable@kernel.org> # 2.6.36.y and newer
      2e053a27
  2. 15 3月, 2011 2 次提交
  3. 26 2月, 2011 2 次提交
  4. 23 1月, 2011 1 次提交
  5. 13 1月, 2011 1 次提交
    • C
      firewire: ohci: fix compilation on arches without PAGE_KERNEL_RO · 14271304
      Clemens Ladisch 提交于
      PAGE_KERNEL_RO is not available on all architectures, so its use
      in the new AR code broke compilation on sparc64.
      
      Because the read-only mapping was just a debugging aid, just use
      PAGE_KERNEL instead.
      Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
      
      James Bottomley wrote:
      > On Thu, 2011-01-13 at 08:27 +0100, Clemens Ladisch wrote:
      >> firewire: ohci: fix compilation on arches without PAGE_KERNEL_RO, e.g. sparc
      >>
      >> PAGE_KERNEL_RO is not available on all architectures, so its use in the
      >> new AR code broke compilation on sparc64.
      >>
      >> Because the R/O mapping is only used to catch drivers that try to write
      >> to the reception buffer and not actually required for correct operation,
      >> we can just use a normal PAGE_KERNEL mapping where _RO is not available.
      [...]
      >> +/*
      >> + * For archs where PAGE_KERNEL_RO is not supported;
      >> + * mapping the AR buffers readonly for the CPU is just a debugging aid.
      >> + */
      >> +#ifndef PAGE_KERNEL_RO
      >> +#define PAGE_KERNEL_RO PAGE_KERNEL
      >> +#endif
      >
      > This might cause interesting issues on sparc64 if it ever acquired a
      > PAGE_KERNEL_RO.  Sparc64 has extern pgprot_t for it's PAGE_KERNEL types
      > rather than #defines, so the #ifdef check wouldn't see this.
      >
      > I think either PAGE_PROT_RO becomes part of our arch API (so all
      > architectures are forced to add it), or, if it's not part of the API,
      > ohci isn't entitled to use it.  The latter seems simplest since you have
      > no real use for write protection anyway.
      Reported-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      14271304
  6. 04 1月, 2011 4 次提交
  7. 14 12月, 2010 9 次提交
  8. 12 12月, 2010 2 次提交
  9. 31 10月, 2010 4 次提交
  10. 17 10月, 2010 1 次提交
  11. 09 9月, 2010 1 次提交
  12. 29 8月, 2010 1 次提交
    • S
      firewire: ohci: work around VIA and NEC PHY packet reception bug · a4dc090b
      Stefan Richter 提交于
      VIA VT6306, VIA VT6308, and NEC OrangeLink controllers do not write
      packet event codes for received PHY packets (or perhaps write
      evt_no_status, hard to tell).  Work around it by overwriting the
      packet's ACK by ack_complete, so that upper layers that listen to PHY
      packet reception get to see these packets.
      
      (Also tested:  TI TSB82AA2, TI TSB43AB22/A, TI XIO2213A, Agere FW643,
      JMicron JMB381 --- these do not exhibit this bug.)
      
      Clemens proposed a quirks flag for that, IOW whitelist known misbehaving
      controllers for this workaround.  Though to me it seems harmless enough
      to enable for all controllers.
      
      The log_ar_at_event() debug log will continue to show the original
      status from the DMA unit.
      
      Reported-by: Clemens Ladisch <clemens@ladisch.de> (VT6308)
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      a4dc090b
  13. 30 7月, 2010 3 次提交
    • S
      firewire: add isochronous multichannel reception · 872e330e
      Stefan Richter 提交于
      This adds the DMA context programming and userspace ABI for multichannel
      reception, i.e. for listening on multiple channel numbers by means of a
      single DMA context.
      
      The use case is reception of more streams than there are IR DMA units
      offered by the link layer.  This is already implemented by the older
      ohci1394 + ieee1394 + raw1394 stack.  And as discussed recently on
      linux1394-devel, this feature is occasionally used in practice.
      
      The big drawbacks of this mode are that buffer layout and interrupt
      generation necessarily differ from single-channel reception:  Headers
      and trailers are not stripped from packets, packets are not aligned with
      buffer chunks, interrupts are per buffer chunk, not per packet.
      
      These drawbacks also cause a rather hefty code footprint to support this
      rarely used OHCI-1394 feature.  (367 lines added, among them 94 lines of
      added userspace ABI documentation.)
      
      This implementation enforces that a multichannel reception context may
      only listen to channels to which no single-channel context on the same
      link layer is presently listening to.  OHCI-1394 would allow to overlay
      single-channel contexts by the multi-channel context, but this would be
      a departure from the present first-come-first-served policy of IR
      context creation.
      
      The implementation is heavily based on an earlier one by Jay Fenlason.
      Thanks Jay.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      872e330e
    • S
      firewire: ohci: release channel in error path · e5b06c07
      Stefan Richter 提交于
      firewire-ohci keeps book of which isochronous channels are occupied by
      IR DMA contexts, so that there cannot be more than one context listening
      to a certain channel.
      
      If IR context creation failed due to an out-of-memory condition, this
      bookkeeping leaked a channel.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      e5b06c07
    • S
      firewire: ohci: use memory barriers to order descriptor updates · 071595eb
      Stefan Richter 提交于
      When we append to a DMA program, we need to ensure that the order in
      which initialization of the new descriptors and update of the
      branch_address of the old tail descriptor, as seen by the PCI device,
      happen as intended.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      071595eb
  14. 23 7月, 2010 2 次提交
    • S
      firewire: cdev: add PHY pinging · cc550216
      Stefan Richter 提交于
      This extends the FW_CDEV_IOC_SEND_PHY_PACKET ioctl() for /dev/fw* to be
      useful for ping time measurements.  One application for it would be gap
      count optimization in userspace that is based on ping times rather than
      hop count.  (The latter is implemented in firewire-core itself but is
      not applicable to beta PHYs that act as repeater.)
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      cc550216
    • S
      firewire: cdev: add PHY packet reception · bf54e146
      Stefan Richter 提交于
      Add an FW_CDEV_IOC_RECEIVE_PHY_PACKETS ioctl() and
      FW_CDEV_EVENT_PHY_PACKET_RECEIVED poll()/read() event for /dev/fw*.
      This can be used to get information from remote PHYs by remote access
      PHY packets.
      
      This is also the 2nd half of the functionality (the receive part) to
      support a userspace implementation of a VersaPHY transaction layer.
      
      Safety considerations:
      
        - PHY packets are generally broadcasts, hence some kind of elevated
          privileges should be required of a process to be able to listen in
          on PHY packets.  This implementation assumes that a process that is
          allowed to open the /dev/fw* of a local node does have this
          privilege.
      
          There was an inconclusive discussion about introducing POSIX
          capabilities as a means to check for user privileges for these
          kinds of operations.
      
      Other limitations:
      
        - PHY packet reception may be switched on by ioctl() but cannot be
          switched off again.  It would be trivial to provide an off switch,
          but this is not worth the code.  The client should simply close()
          the fd then, or just ignore further events.
      
        - For sake of simplicity of API and kernel-side implementation, no
          filter per packet content is provided.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      bf54e146
  15. 13 7月, 2010 1 次提交
    • S
      firewire: core: integrate software-forced bus resets with bus management · 02d37bed
      Stefan Richter 提交于
      Bus resets which are triggered
        - by the kernel drivers after updates of the local nodes' config ROM,
        - by userspace software via ioctl
      shall be deferred until after >=2 seconds after the last bus reset.
      
      If multiple modifications of the local nodes' config ROM happen in a row,
      only a single bus reset should happen after them.
      
      When the local node's link goes from inactive to active or vice versa,
      and at the two occasions of bus resets mentioned above --- and if the
      current gap count differs from 63 --- the bus reset should be preceded
      by a PHY configuration packet that reaffirms the gap count.  Otherwise a
      bus manager would have to reset the bus again right after that.
      
      This is necessary to promote bus stability, e.g. leave grace periods for
      allocations and reallocations of isochronous channels and bandwidth,
      SBP-2 reconnections etc.; see IEEE 1394 clause 8.2.1.
      
      This change implements all of the above by moving bus reset initiation
      into a delayed work (except for bus resets which are triggered by the
      bus manager workqueue job and are performed there immediately).  It
      comes with a necessary addition to the card driver methods that allows
      to get the current gap count from PHY registers.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      02d37bed
  16. 19 6月, 2010 4 次提交
  17. 10 6月, 2010 1 次提交