1. 15 10月, 2013 1 次提交
  2. 12 10月, 2013 6 次提交
  3. 06 10月, 2013 5 次提交
  4. 27 9月, 2013 2 次提交
  5. 26 9月, 2013 3 次提交
    • K
      usb/core/devio.c: Don't reject control message to endpoint with wrong direction bit · 831abf76
      Kurt Garloff 提交于
      Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101)
      [1] with the Windows App (EasyNote) works natively but fails when
      Windows is running under KVM (and the USB device handed to KVM).
      
      The reason is a USB control message
       usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 wLength=0008
      This goes to endpoint address 0x01 (wIndex); however, endpoint address
      0x01 does not exist. There is an endpoint 0x81 though (same number,
      but other direction); the app may have meant that endpoint instead.
      
      The kernel thus rejects the IO and thus we see the failure.
      
      Apparently, Linux is more strict here than Windows ... we can't change
      the Win app easily, so that's a problem.
      
      It seems that the Win app/driver is buggy here and the driver does not
      behave fully according to the USB HID class spec that it claims to
      belong to.  The device seems to happily deal with that though (and
      seems to not really care about this value much).
      
      So the question is whether the Linux kernel should filter here.
      Rejecting has the risk that somewhat non-compliant userspace apps/
      drivers (most likely in a virtual machine) are prevented from working.
      Not rejecting has the risk of confusing an overly sensitive device with
      such a transfer. Given the fact that Windows does not filter it makes
      this risk rather small though.
      
      The patch makes the kernel more tolerant: If the endpoint address in
      wIndex does not exist, but an endpoint with toggled direction bit does,
      it will let the transfer through. (It does NOT change the message.)
      
      With attached patch, the app in Windows in KVM works.
       usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but needs 81
      
      I suspect this will mostly affect apps in virtual environments; as on
      Linux the apps would have been adapted to the stricter handling of the
      kernel. I have done that for mine[2].
      
      [1] http://www.pegatech.com/
      [2] https://sourceforge.net/projects/notetakerpen/Signed-off-by: NKurt Garloff <kurt@garloff.de>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      831abf76
    • A
      USB: fix substandard locking for the sysfs files · 232275a0
      Alan Stern 提交于
      This patch straightens out some locking issues in the USB sysfs
      interface:
      
      	Deauthorization will destroy existing configurations.
      	Attributes that read from udev->actconfig need to lock the
      	device to prevent races.  Likewise for the rawdescriptor
      	values.
      
      	Attributes that access an interface's current alternate
      	setting should use ACCESS_ONCE() to obtain the cur_altsetting
      	pointer, to protect against concurrent altsetting changes.
      
      	The supports_autosuspend() attribute routine accesses values
      	from an interface's driver, so it should lock the interface
      	(rather than the usb_device) to protect against concurrent
      	unbinds.  Once this is done, the routine can be simplified
      	considerably.
      
      Scalar values that are stored directly in the usb_device structure are
      always available.  They do not require any locking.  The same is true
      of the cached interface string descriptor, because it is not
      deallocated until the usb_host_interface structure is destroyed.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: Hans de Goede <hdegoede@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      232275a0
    • H
      usb: core: implement AMD remote wakeup quirk · 7868943d
      Huang Rui 提交于
      The following patch is required to resolve remote wake issues with
      certain devices.
      
      Issue description:
      If the remote wake is issued from the device in a specific timing
      condition while the system is entering sleep state then it may cause
      system to auto wake on subsequent sleep cycle.
      
      Root cause:
      Host controller rebroadcasts the Resume signal > 100 µseconds after
      receiving the original resume event from the device. For proper
      function, some devices may require the rebroadcast of resume event
      within the USB spec of 100µS.
      
      Workaroud:
      1. Filter the AMD platforms with Yangtze chipset, then judge of all the usb
      devices are mouse or not. And get out the port id which attached a mouse
      with Pixart controller.
      2. Then reset the port which attached issue device during system resume
      from S3.
      
      [Q] Why the special devices are only mice? Would high speed devices
      such as 3G modem or USB Bluetooth adapter trigger this issue?
      - Current this sensitivity is only confined to devices that use Pixart
        controllers. This controller is designed for use with LS mouse
      devices only. We have not observed any other devices failing. There
      may be a small risk for other devices also but this patch (reset
      device in resume phase) will cover the cases if required.
      
      [Q] Shouldn’t the resume signal be sent within 100 us for every
      device?
      - The Host controller may not send the resume signal within 100us,
        this our host controller specification change. This is why we
      require the patch to prevent side effects on certain known devices.
      
      [Q] Why would clicking mouse INTENSELY to wake the system up trigger
      this issue?
      - This behavior is specific to the devices that use Pixart controller.
        It is timing dependent on when the resume event is triggered during
      the sleep state.
      
      [Q] Is it a host controller issue or mouse?
      - It is the host controller behavior during resume that triggers the
        device incorrect behavior on the next resume.
      
      This patch sets USB_QUIRK_RESET_RESUME flag for these Pixart-based mice
      when they attached to platforms with AMD Yangtze chipset.
      Signed-off-by: NHuang Rui <ray.huang@amd.com>
      Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7868943d
  6. 24 9月, 2013 1 次提交
  7. 18 9月, 2013 5 次提交
  8. 31 8月, 2013 2 次提交
  9. 26 8月, 2013 1 次提交
  10. 24 8月, 2013 4 次提交
  11. 16 8月, 2013 3 次提交
    • S
      usb: Don't fail port power resume on device disconnect. · d49dad3e
      Sarah Sharp 提交于
      Userspace can tell the kernel to power off any USB port, including ones
      that are visible and connectible to users.  When an attached USB device
      goes into suspend, the port will be powered off if the
      pm_qos_no_port_poweroff file for its port is set to 0, the device does
      not have remote wakeup enabled, and the device is marked as persistent.
      
      If the user disconnects the USB device while the port is powered off,
      the current code does not handle that properly.  If you disconnect a
      device, and then run `lsusb -v -s` for the device, the device disconnect
      does not get handled by the USB core.  The runtime resume of the port
      fails, because hub_port_debounce_be_connected() returns -ETIMEDOUT.
      
      This means the port resume fails and khubd doesn't handle the USB device
      disconnect.  This leaves the device listed in lsusb, and the port's
      runtime_status will be permanently marked as "error".
      
      Fix this by ignoring the return value of hub_port_debounce_be_connected.
      Users can disconnect USB devices while the ports are powered off, and we
      must be able to handle that.
      
      This patch should be backported to kernels as old as 3.9, that
      contain the commit ad493e5e "usb: add
      usb port auto power off mechanism"
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Lan Tianyu <tianyu.lan@intel.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      d49dad3e
    • L
      usb: don't check pm qos NO_POWER_OFF flag in usb_port_suspend() · 98a4f1ff
      Lan Tianyu 提交于
      The pm qos NO_POWER_OFF flag is checked twice during usb device suspend
      to see if the usb port power off condition is met. This is redundant and
      also will prevent the port from being powered off if the NO_POWER_OFF
      flag is changed to 1 from 0 after the device was already suspended.
      
      More detail in the following link.
      	http://marc.info/?l=linux-usb&m=136543949130865&w=2
      
      This patch should be backported to kernels as old as 3.7, that
      contain the commit f7ac7787 "usb/acpi:
      Use ACPI methods to power off ports."
      Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      98a4f1ff
    • A
      USB: handle LPM errors during device suspend correctly · aa5ceae2
      Alan Stern 提交于
      The hub driver's usb_port_suspend() routine doesn't handle errors
      related to Link Power Management properly.  It always returns failure,
      it doesn't try to clean up the wakeup setting, (in the case of system
      sleep) it doesn't try to go ahead with the port suspend regardless,
      and it doesn't try to apply the new power-off mechanism.
      
      This patch fixes these problems.
      
      Note: Sarah fixed this patch to apply against 3.11, since the original
      commit (4fae6f0f "USB: handle LPM errors
      during device suspend correctly") called usb_disable_remote_wakeup,
      which won't be added until 3.12.
      
      This patch should be backported to kernels as old as 3.5, that
      contain the commit 8306095f "USB:
      Disable USB 3.0 LPM in critical sections.".  There will be merge
      conflicts, since LTM wasn't added until 3.6.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      aa5ceae2
  12. 15 8月, 2013 2 次提交
  13. 13 8月, 2013 4 次提交
    • M
      usb/hcd: Log error code if reset() fails · c10750b2
      Mark Brown 提交于
      If someone provided meaningful error codes from reset() we should tell the
      user what they were.
      Signed-off-by: NMark Brown <broonie@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c10750b2
    • H
      usb: config->desc.bLength may not exceed amount of data returned by the device · b4f17a48
      Hans de Goede 提交于
      While reading the config parsing code I noticed this check is missing, without
      this check config->desc.wTotalLength can end up with a value larger then the
      dev->rawdescriptors length for the config, and when userspace then tries to
      get the rawdescriptors bad things may happen.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b4f17a48
    • M
      USB: introduce usb_device_no_sg_constraint() helper · bcc48f1a
      Ming Lei 提交于
      Some host controllers(such as xHCI) can support building
      packet from discontinuous buffers, so introduce one flag
      and helper for this kind of host controllers, then the
      feature can help some applications(such as usbnet) by
      supporting arbitrary length of sg buffers.
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bcc48f1a
    • M
      USB: HCD: support giveback of URB in tasklet context · 94dfd7ed
      Ming Lei 提交于
      This patch implements the mechanism of giveback of URB in
      tasklet context, so that hardware interrupt handling time for
      usb host controller can be saved much, and HCD interrupt handling
      can be simplified.
      
      Motivations:
      
      1), on some arch(such as ARM), DMA mapping/unmapping is a bit
      time-consuming, for example: when accessing usb mass storage
      via EHCI on pandaboard, the common length of transfer buffer is 120KB,
      the time consumed on DMA unmapping may reach hundreds of microseconds;
      even on A15 based box, the time is still about scores of microseconds
      
      2), on some arch, reading DMA coherent memoery is very time-consuming,
      the most common example is usb video class driver[1]
      
      3), driver's complete() callback may do much things which is driver
      specific, so the time is consumed unnecessarily in hardware irq context.
      
      4), running driver's complete() callback in hardware irq context causes
      that host controller driver has to release its lock in interrupt handler,
      so reacquiring the lock after return may busy wait a while and increase
      interrupt handling time. More seriously, releasing the HCD lock makes
      HCD becoming quite complicated to deal with introduced races.
      
      So the patch proposes to run giveback of URB in tasklet context, then
      time consumed in HCD irq handling doesn't depend on drivers' complete and
      DMA mapping/unmapping any more, also we can simplify HCD since the HCD
      lock isn't needed to be released during irq handling.
      
      The patch should be reasonable and doable:
      
      1), for drivers, they don't care if the complete() is called in hard irq
      context or softirq context
      
      2), the biggest change is the situation in which usb_submit_urb() is called
      in complete() callback, so the introduced tasklet schedule delay might be a
      con, but it shouldn't be a big deal:
      
      	- control/bulk asynchronous transfer isn't sensitive to schedule
      	  delay
      
      	- the patch schedules giveback of periodic URBs using
      	  tasklet_hi_schedule, so the introduced delay should be very
      	  small
      
      	- for ISOC transfer, generally, drivers submit several URBs
      	  concurrently to avoid interrupt delay, so it is OK with the
      	  little schedule delay.
      
      	- for interrupt transfer, generally, drivers only submit one URB
      	  at the same time, but interrupt transfer is often used in event
      	  report, polling, ... situations, and a little delay should be OK.
      
      Considered that HCDs may optimize on submitting URB in complete(), the
      patch may cause the optimization not working, so introduces one flag to mark
      if the HCD supports to run giveback URB in tasklet context. When all HCDs
      are ready, the flag can be removed.
      
      [1], http://marc.info/?t=136438111600010&r=1&w=2
      
      Cc: Oliver Neukum <oliver@neukum.org>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      94dfd7ed
  14. 03 8月, 2013 1 次提交