1. 23 9月, 2015 1 次提交
  2. 19 8月, 2015 1 次提交
  3. 15 8月, 2015 1 次提交
  4. 26 3月, 2015 2 次提交
  5. 10 1月, 2015 1 次提交
    • S
      usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN · 5efd2ea8
      Sebastian Andrzej Siewior 提交于
      the following error pops up during "testusb -a -t 10"
      | musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128,	f134e000/be842000 (bad dma)
      hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
      size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
      hcd_buffer_alloc() returning memory which is 32 bytes aligned and it
      might by identified by buffer_offset() as another buffer. This means the
      buffer which is on a 32 byte boundary will not get freed, instead it
      tries to free another buffer with the error message.
      
      This patch fixes the issue by creating the smallest DMA buffer with the
      size of ARCH_KMALLOC_MINALIGN (or 32 in case ARCH_KMALLOC_MINALIGN is
      smaller). This might be 32, 64 or even 128 bytes. The next three pools
      will have the size 128, 512 and 2048.
      In case the smallest pool is 128 bytes then we have only three pools
      instead of four (and zero the first entry in the array).
      The last pool size is always 2048 bytes which is the assumed PAGE_SIZE /
      2 of 4096. I doubt it makes sense to continue using PAGE_SIZE / 2 where
      we would end up with 8KiB buffer in case we have 16KiB pages.
      Instead I think it makes sense to have a common size(s) and extend them
      if there is need to.
      There is a BUILD_BUG_ON() now in case someone has a minalign of more than
      128 bytes.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5efd2ea8
  6. 04 12月, 2014 1 次提交
  7. 18 7月, 2014 1 次提交
  8. 12 10月, 2013 1 次提交
  9. 03 8月, 2013 1 次提交
  10. 21 5月, 2013 1 次提交
    • J
      usb: ehci: Only sleep for post-resume handover if devices use persist · 9b790915
      Julius Werner 提交于
      The current EHCI code sleeps a flat 110ms in the resume path if there
      was a USB 1.1 device connected to its companion controller during
      suspend, waiting for the device to reappear and reset so that it can be
      handed back to the companion. This is necessary if the device uses
      persist, so that the companion controller can actually see it during its
      own resume path.
      
      However, if the device doesn't use persist, this is entirely
      unnecessary. We might just as well ignore it and have the normal device
      detection/reset/handoff code handle it asynchronously when it eventually
      shows up. As USB 1.1 devices are almost exclusively HIDs these days (for
      which persist has no value), this can allow distros to shave another
      tenth of a second off their resume time.
      
      In order to enable this optimization, the patch also adds a new
      usb_for_each_dev() iterator that is exported by the USB core and wraps
      bus_for_each_dev() with the logic to differentiate between struct
      usb_device and struct usb_interface on the usb_bus_type bus.
      Signed-off-by: NJulius Werner <jwerner@chromium.org>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b790915
  11. 12 4月, 2013 1 次提交
  12. 08 4月, 2013 1 次提交
    • K
      driver core: add uid and gid to devtmpfs · 3c2670e6
      Kay Sievers 提交于
      Some drivers want to tell userspace what uid and gid should be used for
      their device nodes, so allow that information to percolate through the
      driver core to userspace in order to make this happen.  This means that
      some systems (i.e.  Android and friends) will not need to even run a
      udev-like daemon for their device node manager and can just rely in
      devtmpfs fully, reducing their footprint even more.
      Signed-off-by: NKay Sievers <kay@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3c2670e6
  13. 29 3月, 2013 1 次提交
    • A
      USB: remove CONFIG_USB_SUSPEND option · 84ebc102
      Alan Stern 提交于
      This patch (as1675) removes the CONFIG_USB_SUSPEND option, essentially
      replacing it everywhere with CONFIG_PM_RUNTIME (except for one place
      in hub.c, where it is replaced with CONFIG_PM because the code needs
      to be used in both runtime and system PM).  The net result is code
      shrinkage and simplification.
      
      There's very little point in keeping CONFIG_USB_SUSPEND because almost
      everybody enables it.  The few that don't will find that the usbcore
      module has gotten somewhat bigger and they will have to take active
      measures if they want to prevent hubs from being runtime suspended.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: Peter Chen <peter.chen@freescale.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      84ebc102
  14. 22 11月, 2012 1 次提交
  15. 25 10月, 2012 1 次提交
  16. 11 7月, 2012 1 次提交
    • S
      USB: Disable LPM while the device is unconfigured. · 9cf65991
      Sarah Sharp 提交于
      The USB 3.0 Set/Clear Feature U1/U2 Enable cannot be sent to a device in
      the Default or Addressed state.  It can only be sent to a configured
      device.  Change the USB core to initialize the LPM disable count to 1
      (disabled), which reflects this limitation.
      
      Change usb_set_configuration() to ensure that if the device is
      unconfigured on entry, usb_lpm_disable() is not called.  This avoids
      sending the Clear Feature U1/U2 when the device is in the Addressed
      state.  When usb_set_configuration() exits with a successfully installed
      configuration, usb_lpm_enable() will be called.
      
      Once the new configuration is installed, make sure
      usb_set_configuration() only calls usb_enable_lpm() if the device moved
      to the Configured state.  If we have unconfigured the device by sending
      it a Set Configuration for config 0, don't enable LPM.
      
      This commit should be backported to kernels as old as 3.5, that contain
      the commit 8306095f "USB: Disable USB
      3.0 LPM in critical sections."
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      9cf65991
  17. 16 5月, 2012 1 次提交
    • S
      usb: fix breakage on systems without ACPI · ea79c2ed
      Sasha Levin 提交于
      Commit da0af6e7 ("usb: Bind devices to ACPI devices when possible") really
      tries to force-bind devices even when impossible, unlike what it says in
      the subject.
      
      CONFIG_ACPI is not an indication that ACPI tables are actually present, nor
      is an indication that any USB relevant information is present in them. There
      is no reason to fail the creation of a USB bus if it can't bind it to
      ACPI device during initialization.
      
      On systems with CONFIG_ACPI set but without ACPI tables it would cause a
      boot panic.
      Signed-off-by: NSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ea79c2ed
  18. 12 5月, 2012 1 次提交
  19. 30 4月, 2012 1 次提交
  20. 25 1月, 2012 1 次提交
  21. 13 1月, 2012 1 次提交
  22. 04 1月, 2012 1 次提交
  23. 27 9月, 2011 1 次提交
  24. 30 4月, 2011 1 次提交
  25. 19 3月, 2011 1 次提交
  26. 17 11月, 2010 1 次提交
    • A
      USB: use the runtime-PM autosuspend implementation · fcc4a01e
      Alan Stern 提交于
      This patch (as1428) converts USB over to the new runtime-PM core
      autosuspend framework.  One slightly awkward aspect of the conversion
      is that USB devices will now have two suspend-delay attributes: the
      old power/autosuspend file and the new power/autosuspend_delay_ms
      file.  One expresses the delay time in seconds and the other in
      milliseconds, but otherwise they do the same thing.  The old attribute
      can be deprecated and then removed eventually.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fcc4a01e
  27. 11 8月, 2010 1 次提交
  28. 22 5月, 2010 1 次提交
  29. 21 5月, 2010 5 次提交
    • M
      USB: remove match_device · c024b726
      Ming Lei 提交于
      usb_find_device was the only one user of match_device, now
      it is removed, so remove match_device to fix the compile warning
      below reported by Stephen Rothwell:
      
      	drivers/usb/core/usb.c:596: warning: 'match_device'
      	defined but not used
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NMing Lei <tom.leiming@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c024b726
    • M
      USB: remove usb_find_device · 22b4b611
      Ming Lei 提交于
      Now on one uses this function and it seems useless,
      so remove usb_find_device.
      
      [tom@tom linux-2.6-next]$ grep -r -n -I usb_find_device ./
      drivers/media/dvb/dvb-usb/dvb-usb-init.c:160:static struct
      dvb_usb_device_description * dvb_usb_find_device(struct usb_device
      *udev,struct dvb_usb_device_properties *props, int *cold)
      
      drivers/media/dvb/dvb-usb/dvb-usb-init.c:230:   if ((desc =
      dvb_usb_find_device(udev,props,&cold)) == NULL) {
      
      drivers/usb/core/usb.c:630: * usb_find_device - find a specific usb device in the system
      drivers/usb/core/usb.c:642:struct usb_device *usb_find_device(u16 vendor_id, u16 product_id)
      Signed-off-by: NMing Lei <tom.leiming@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      22b4b611
    • A
      USB: fix usbmon and DMA mapping for scatter-gather URBs · ff9c895f
      Alan Stern 提交于
      This patch (as1368) fixes a rather obscure bug in usbmon: When tracing
      URBs sent by the scatter-gather library, it accesses the data buffers
      while they are still mapped for DMA.
      
      The solution is to move the mapping and unmapping out of the s-g
      library and into the usual place in hcd.c.  This requires the addition
      of new URB flag bits to describe the kind of mapping needed, since we
      have to call dma_map_sg() if the HCD supports native scatter-gather
      operation and dma_map_page() if it doesn't.  The nice thing about
      having the new flags is that they simplify the testing for unmapping.
      
      The patch removes the only caller of usb_buffer_[un]map_sg(), so those
      functions are #if'ed out.  A later patch will remove them entirely.
      
      As a result of this change, urb->sg will be set in situations where
      it wasn't set previously.  Hence the xhci and whci drivers are
      adjusted to test urb->num_sgs instead, which retains its original
      meaning and is nonzero only when the HCD has to handle a scatterlist.
      
      Finally, even when a submission error occurs we don't want to hand
      URBs to usbmon before they are unmapped.  The submission path is
      rearranged so that map_urb_for_dma() is called only for non-root-hub
      URBs and unmap_urb_for_dma() is called immediately after a submission
      error.  This simplifies the error handling.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      ff9c895f
    • A
      USB: remove uses of URB_NO_SETUP_DMA_MAP · 0ede76fc
      Alan Stern 提交于
      This patch (as1350) removes all usages of coherent buffers for USB
      control-request setup-packet buffers.  There's no good reason to
      reserve coherent memory for these things; control requests are hardly
      ever used in large quantity (the major exception is firmware
      transfers, and they aren't time-critical).  Furthermore, only seven
      drivers used it.  We might as well always use streaming DMA mappings
      for setup-packet buffers, and remove some extra complexity from
      usbcore.
      
      The DMA-mapping portion of hcd.c is currently in flux.  A separate
      patch will be submitted to remove support for URB_NO_SETUP_DMA_MAP
      after everything else settles down.  The removal should go smoothly,
      as by then nobody will be using it.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0ede76fc
    • E
      USB: make hcd.h public (drivers dependency) · 27729aad
      Eric Lescouet 提交于
      The usbcore headers: hcd.h and hub.h are shared between usbcore,
      HCDs and a couple of other drivers (e.g. USBIP modules).
      So, it makes sense to move them into a more public location and
      to cleanup dependency of those modules on kernel internal headers.
      This patch moves hcd.h from drivers/usb/core into include/linux/usb/
      Signed-of-by: NEric Lescouet <eric@lescouet.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      27729aad
  30. 01 5月, 2010 1 次提交
  31. 03 3月, 2010 2 次提交
    • H
      USB: Move hcd free_dev call into usb_disconnect to fix oops · f7410ced
      Herbert Xu 提交于
      USB: Move hcd free_dev call into usb_disconnect
      
      I found a way to oops the kernel:
      
      1. Open a USB device through devio.
      2. Remove the hcd module in the host kernel.
      3. Close the devio file descriptor.
      
      The problem is that closing the file descriptor does usb_release_dev
      as it is the last reference.  usb_release_dev then tries to invoke
      the hcd free_dev function (or rather dereferencing the hcd driver
      struct).  This causes an oops as the hcd driver has already been
      unloaded so the struct is gone.
      
      This patch tries to fix this by bringing the free_dev call earlier
      and into usb_disconnect.  I have verified that repeating the
      above steps no longer crashes with this patch applied.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f7410ced
    • A
      USB: convert to the runtime PM framework · 9bbdf1e0
      Alan Stern 提交于
      This patch (as1329) converts the USB stack over to the PM core's
      runtime PM framework.  This involves numerous changes throughout
      usbcore, especially to hub.c and driver.c.  Perhaps the most notable
      change is that CONFIG_USB_SUSPEND now depends on CONFIG_PM_RUNTIME
      instead of CONFIG_PM.
      
      Several fields in the usb_device and usb_interface structures are no
      longer needed.  Some code which used to depend on CONFIG_USB_PM now
      depends on CONFIG_USB_SUSPEND (requiring some rearrangement of header
      files).
      
      The only visible change in behavior should be that following a system
      sleep (resume from RAM or resume from hibernation), autosuspended USB
      devices will be resumed just like everything else.  They won't remain
      suspended.  But if they aren't in use then they will naturally
      autosuspend again in a few seconds.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      9bbdf1e0
  32. 24 12月, 2009 1 次提交
  33. 16 12月, 2009 1 次提交
  34. 15 12月, 2009 1 次提交
    • R
      USB: Close usb_find_interface race v3 · c2d284ee
      Russ Dill 提交于
      USB drivers that create character devices call usb_register_dev in their
      probe function. This associates the usb_interface device with that minor
      number and creates the character device and announces it to the world.
      However, the driver's probe function is called before the new
      usb_interface is added to the driver's klist_devices.
      
      This is a problem because userspace will respond to the character device
      creation announcement by opening the character device. The driver's open
      function will the call usb_find_interface to find the usb_interface
      associated with that minor number. usb_find_interface will walk the
      driver's list of devices and find the usb_interface with the matching
      minor number.
      
      Because the announcement happens before the usb_interface is added to the
      driver's klist_devices, a race condition exists. A straightforward fix
      is to walk the list of devices on usb_bus_type instead since the device
      is added to that list before the announcement occurs.
      
      bus_find_device calls get_device to bump the reference count on the found
      device. It is arguable that the reference count should be dropped by the
      caller of usb_find_interface instead of usb_find_interface, however,
      the current users of usb_find_interface do not expect this.
      
      The original version of this patch only matched against minor number
      instead of driver and minor number. This version matches against both.
      Signed-off-by: NRuss Dill <Russ.Dill@gmail.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c2d284ee