1. 21 5月, 2010 4 次提交
  2. 23 9月, 2009 1 次提交
  3. 29 7月, 2009 1 次提交
    • S
      USB: Fix parsing of SuperSpeed Endpoint Companion descriptor. · 9f8e4438
      Sarah Sharp 提交于
      usb_parse_ss_endpoint_companion() was supposed to allocate a structure to
      hold the SuperSpeed Endpoint Companion descriptor, and either copy the
      values the device returned, or fill in default values if the device
      descriptor did not include the companion descriptor.
      
      However, the previous code would miss the last endpoint in a configuration
      with no descriptors after it.  Make usb_parse_endpoint() allocate the SS
      endpoint companion descriptor and fill it with default values, even if
      we've run out of buffer space in this configuration descriptor.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      9f8e4438
  4. 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
  5. 25 4月, 2008 1 次提交
    • D
      USB: ehci tolerates some buggy devices · caa9ef67
      David Brownell 提交于
      This teaches EHCI how to to work around bugs in certain high speed
      devices, by accomodating "bulk" packets that exceed the 512 byte
      constant value required by the USB 2.0 specification.  (Have a
      look at section 5.8.3, paragraphs 1 and 3.)
      
      It also makes the descriptor parsing code warn when it encounters
      such bugs.  (We've had reports of maybe two or three such devices,
      all pretty recent.)
      
      Such devices are nonconformant.  The proper fix is have the vendors
      of those devices do the simple, obvious, and correct thing ... which
      will let them be used with USB hosts that don't have workarounds for
      this particular vendor bug.  But unless/until they do, we can at least
      have one of the high speed HCDs work with such buggy devices.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      caa9ef67
  6. 02 2月, 2008 1 次提交
  7. 13 10月, 2007 1 次提交
  8. 13 7月, 2007 3 次提交
  9. 09 6月, 2007 1 次提交
  10. 23 5月, 2007 1 次提交
  11. 28 9月, 2006 1 次提交
  12. 01 7月, 2006 1 次提交
  13. 18 11月, 2005 1 次提交
  14. 29 10月, 2005 2 次提交
  15. 19 4月, 2005 1 次提交
  16. 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