1. 03 5月, 2011 1 次提交
  2. 14 3月, 2011 1 次提交
  3. 26 2月, 2011 1 次提交
  4. 01 12月, 2010 1 次提交
  5. 23 10月, 2010 2 次提交
  6. 21 5月, 2010 3 次提交
  7. 03 3月, 2010 1 次提交
  8. 23 9月, 2009 2 次提交
  9. 16 6月, 2009 3 次提交
    • S
      USB: Change names of SuperSpeed ep companion descriptor structs. · f0058c62
      Sarah Sharp 提交于
      Differentiate between SuperSpeed endpoint companion descriptor and the
      wireless USB endpoint companion descriptor.  Make all structure names for
      this descriptor have "ss" (SuperSpeed) in them.  David Vrabel asked for
      this change in http://marc.info/?l=linux-usb&m=124091465109367&w=2Reported-by: NDavid Vrabel <david.vrabel@csr.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f0058c62
    • S
      USB: Parse and store the SuperSpeed endpoint companion descriptors. · 663c30d0
      Sarah Sharp 提交于
      The USB 3.0 bus specification added an "Endpoint Companion" descriptor that is
      supposed to follow all SuperSpeed Endpoint descriptors.  This descriptor is used
      to extend the bus protocol to allow more packets to be sent to an endpoint per
      "microframe".  The word microframe was removed from the USB 3.0 specification
      because the host controller does not send Start Of Frame (SOF) symbols down the
      USB 3.0 wires.
      
      The descriptor defines a bMaxBurst field, which indicates the number of packets
      of wMaxPacketSize that a SuperSpeed device can send or recieve in a service
      interval.  All non-control endpoints may set this value as high as 16 packets
      (bMaxBurst = 15).
      
      The descriptor also allows isochronous endpoints to further specify that they
      can send and receive multiple bursts per service interval.  The bmAttributes
      allows them to specify a "Mult" of up to 3 (bmAttributes = 2).
      
      Bulk endpoints use bmAttributes to report the number of "Streams" they support.
      This was an extension of the endpoint pipe concept to allow multiple mass
      storage device commands to be outstanding for one bulk endpoint at a time.  This
      should allow USB 3.0 mass storage devices to support SCSI command queueing.
      Bulk endpoints can say they support up to 2^16 (65,536) streams.
      
      The information in the endpoint companion descriptor must be stored with the
      other device, config, interface, and endpoint descriptors because the host
      controller needs to access them quickly, and we need to install some default
      values if a SuperSpeed device doesn't provide an endpoint companion descriptor.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      663c30d0
    • S
      USB: Add SuperSpeed to the list of USB device speeds. · 6b403b02
      Sarah Sharp 提交于
      Modify the USB core to handle the new USB 3.0 speed, "SuperSpeed".  This
      is 5.0 Gbps (wire speed).  There are probably more places that check for
      speed that I've missed.
      
      SuperSpeed devices have a 512 byte endpoint 0 max packet size.  This shows
      up as a bMaxPacketSize0 set to 0x09 (see table 9-8 of the USB 3.0 bus
      spec).
      
      xHCI spec says that the xHC can handle intervals up to 2^15 microframes.  That
      might change when real silicon becomes available.
      
      Add FIXME note for SuperSpeed isochronous endpoints.  They can transmit up
      to 16 packets in one "burst" before they wait for an acknowledgment of the
      packets.  They can do up to 3 bursts per microframe (determined by the
      mult value in the endpoint companion descriptor).  The xHCI driver doesn't
      have support for isoc yet, so fix this later.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6b403b02
  10. 25 3月, 2009 3 次提交
  11. 18 12月, 2008 1 次提交
  12. 03 5月, 2008 1 次提交
  13. 25 4月, 2008 3 次提交
  14. 28 4月, 2007 1 次提交
  15. 24 2月, 2007 1 次提交
  16. 17 2月, 2007 1 次提交
  17. 08 2月, 2007 2 次提交
  18. 13 7月, 2006 1 次提交
  19. 01 2月, 2006 1 次提交
  20. 29 6月, 2005 1 次提交
  21. 28 6月, 2005 1 次提交
    • D
      [PATCH] USB: wireless usb <linux/usb_ch9.h> declarations · 5da0106f
      David Brownell 提交于
      This provides declarations for new requests, descriptors, and bitfields as
      defined in the Wireless USB 1.0 spec.  Device support will involve a new
      "Wire Adapter" device class, connecting a USB Host to a cluster of wireless
      USB devices.  There will be two adapter types:
      
        * Host Wireless Adapter (HWA):  the downstream link is wireless, which
          connects a wireless USB host to wireless USB devices (not unlike like
          a hub) including to the second type of adapter.
      
        * Device Wireless Adapter (DWA): the upstream link is wireless, for
          connecting existing USB devices through wired links into the cluser.
      
      All wireless USB devices will need persistent (and secure!) key storage, and
      it's probable that Linux -- or device firmware -- will need to be involved
      with that to bootstrap the initial secure key exchange.
      
      Some user interface is required in that initial key exchange, and since the
      most "hands-off" one is a wired USB link, I suspect wireless operation will
      usually not be the only mode for wireless USB devices.  (Plus, devices can
      recharge batteries using wired USB...)  All other key exchange protocols need
      error prone user interactions, like copying and/or verifying keys.
      
      It'll likely be a while before we have commercial Wireless USB hardware,
      much less Linux implementations that know how to use it.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5da0106f
  22. 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