Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 04 3月, 2016 1 次提交
  3. 21 2月, 2016 2 次提交
  5. 15 2月, 2016 4 次提交
  7. 10 2月, 2016 1 次提交
  9. 07 2月, 2016 1 次提交
  11. 04 2月, 2016 3 次提交
    • O
      usb: no locking for reading descriptors in sysfs · b4a90d04
      由 Oliver Neukum 提交于 
      Quting the relevant thread:

> In fact, I suspect the locking added by the kernel 3.13 commit for
> read_descriptors() is invalid because read_descriptors() performs no USB
> activity; read_descriptors() just reads information from an allocated
> memory structure. This structure is protected as the structure is
> existing before and after the sysfs vfs descriptors entry is created or
> destroyed.

You're right.  For some reason I thought that usb_deauthorize_device()
would destroy the rawdescriptor structures (as mentioned in that
commit's Changelog), but it doesn't.  The locking in read_descriptors()
is unnecessary.

> The information is only written at the time of enumeration
> and does not change. At least that is my understanding.
>
> It is noted that in our testing of kernel 3.8 on ARM, that sysfs
> read_descriptors() was non-blocking because the kernel 3.13 comment was
> not there.
>
> The pre-kernel 3.13 sysfs read_descriptors() seemed to work OK.
>
> Proposal:
> =========
>
> Remove the usb_lock_device(udev) and usb_unlock_device(udev) from
> devices/usb/core/sysfs.c in read_descriptors() that was added by the
> kernel 3.13 commit
> "232275a0 USB: fix substandard locking for the sysfs files"
>
> Any comments to this proposal ?

It seems okay to me.  Please submit a patch.

So this removes the locking making the point about -EINTR in
the first path moot.
Signed-off-by: NOliver Neukum <oneukum@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b4a90d04
    • O
      usb: sysfs: make locking interruptible · 7dd9cba5
      由 Oliver Neukum 提交于 
      232275a0 USB: fix substandard locking for the sysfs files
introduced needed locking into sysfs operations on USB devices
It, however, uses uninterruptible sleep and if the error
handling is on extreme cases of sleep lengths of 10s of seconds
are possible. Unless we are removing the device we should use
interruptible sleep.
Signed-off-by: NOliver Neukum <oneukum@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7dd9cba5
    • H
      usb: core: switch bus numbering to using idr · 5363de75
      由 Heiner Kallweit 提交于 
      USB bus numbering is based on directly dealing with bitmaps and
defines a separate list of busses.
This can be simplified and unified by using existing idr functionality.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5363de75
  13. 25 1月, 2016 11 次提交
  15. 08 1月, 2016 1 次提交
  17. 23 12月, 2015 1 次提交
  19. 19 12月, 2015 1 次提交
    • A
      USB: fix invalid memory access in hub_activate() · e50293ef
      由 Alan Stern 提交于 
      Commit 8520f380 ("USB: change hub initialization sleeps to
delayed_work") changed the hub_activate() routine to make part of it
run in a workqueue.  However, the commit failed to take a reference to
the usb_hub structure or to lock the hub interface while doing so.  As
a result, if a hub is plugged in and quickly unplugged before the work
routine can run, the routine will try to access memory that has been
deallocated.  Or, if the hub is unplugged while the routine is
running, the memory may be deallocated while it is in active use.

This patch fixes the problem by taking a reference to the usb_hub at
the start of hub_activate() and releasing it at the end (when the work
is finished), and by locking the hub interface while the work routine
is running.  It also adds a check at the start of the routine to see
if the hub has already been disconnected, in which nothing should be
done.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NAlexandru Cornea <alexandru.cornea@intel.com>
Tested-by: NAlexandru Cornea <alexandru.cornea@intel.com>
Fixes: 8520f380 ("USB: change hub initialization sleeps to delayed_work")
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e50293ef
  21. 12 12月, 2015 1 次提交
  23. 05 12月, 2015 3 次提交
    • O
      usb: make "nousb" a clear module parameter · 097a9ea0
      由 Oliver Neukum 提交于 
      It shouldn't matter how usbcore is compiled. As it is a subsystem,
the correct way to use nousb should be usbcore.nousb
Signed-off-by: NOliver Neukum <oneukum@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      097a9ea0
    • A
      usb: Add connected retry on resume for non SS devices · 6b82b122
      由 Al Cooper 提交于 
      Currently usb_port_resume waits for up to 2 seconds for CONNECT
status for SS devices only. This change will do the same thing for
non-SS devices even though the reason is a little different. This
will fix an issue where VBUS is turned off during system wide
"suspend to ram" and some 2.0 devices take greater than the current
max of 100ms to show connected after VBUS is enabled. This is most
commonly seen on hard drive based devices and USB3.0 devices plugged
into a 2.0 only port.
Signed-off-by: NAl Cooper <alcooperx@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6b82b122
    • D
      usb: Quiet down false peer failure messages · 6406eeb3
      由 Don Zickus 提交于 
      My recent Intel box is spewing these messages:

xhci_hcd 0000:00:14.0: xHCI Host Controller
xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: xHCI Host Controller
usb usb2: Manufacturer: Linux 4.3.0+ xhci-hcd
usb usb2: SerialNumber: 0000:00:14.0
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 6 ports detected
usb: failed to peer usb2-port2 and usb1-port1 by location (usb2-port2:none) (usb1-port1:usb2-port1)
usb usb2-port2: failed to peer to usb1-port1 (-16)
usb: port power management may be unreliable
usb: failed to peer usb2-port3 and usb1-port1 by location (usb2-port3:none) (usb1-port1:usb2-port1)
usb usb2-port3: failed to peer to usb1-port1 (-16)
usb: failed to peer usb2-port5 and usb1-port1 by location (usb2-port5:none) (usb1-port1:usb2-port1)
usb usb2-port5: failed to peer to usb1-port1 (-16)
usb: failed to peer usb2-port6 and usb1-port1 by location (usb2-port6:none) (usb1-port1:usb2-port1)
usb usb2-port6: failed to peer to usb1-port1 (-16)

Diving into the acpi tables, I noticed the EHCI hub has 12 ports while the XHCI
hub has 8 ports.  Most of those ports are of connect type USB_PORT_NOT_USED
(including port 1 of the EHCI hub).

Further the unused ports have location data initialized to 0x80000000.

Now each unused port on the xhci hub walks the port list and finds a matching
peer with port1 of the EHCI hub because the zero'd out group id bits falsely match.
After port1 of the XHCI hub, each following matching peer will generate the
above warning.

These warnings seem to be harmless for this scenario as I don't think it
matters that unused ports could not create a peer link.

The attached patch utilizes that assumption and just turns the pr_warn into
pr_debug to quiet things down.

Tested on my Intel box.
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Acked-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6406eeb3
  25. 02 12月, 2015 8 次提交
    • L
      usb: core: lpm: add sysfs node for usb3 lpm permit · 513072d9
      由 Lu Baolu 提交于 
      USB3 LPM is default on in Linux kernel if both xHCI host controller
and the USB devices declare to be LPM-capable. Unfortunately, some
devices are known to work well with LPM disabled, but to be broken
if LPM is enabled, although it declares the LPM capability.  Users
won't be able to use this kind of devices, until someone puts them
in the kernel blacklist and gets the kernel upgraded.

This patch adds a sysfs node to permit or forbit USB3 LPM U1 or U2
entry for a port. The settings apply to both before and after device
enumeration. Supported values are "0" - neither u1 nor u2 permitted,
"u1" - only u1 is permitted, "u2" - only u2 is permitted, "u1_u2" -
both u1 and u2 are permitted. With this interface, users can use an
LPM-unfriendly USB device on a released Linux kernel.
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: NZhuang Jin Can <jin.can.zhuang@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      513072d9
    • L
      usb: core: lpm: fix usb3_hardware_lpm sysfs node · bf5ce5bf
      由 Lu Baolu 提交于 
      Commit 655fe4ef ("usbcore: add sysfs support to xHCI usb3
hardware LPM") introduced usb3_hardware_lpm sysfs node. This
doesn't show the correct status of USB3 U1 and U2 LPM status.

This patch fixes this by replacing usb3_hardware_lpm with two
nodes, usb3_hardware_lpm_u1 (for U1) and usb3_hardware_lpm_u2
(for U2), and recording the U1/U2 LPM status in right places.

This patch should be back-ported to kernels as old as 4.3,
that contains Commit 655fe4ef ("usbcore: add sysfs support
to xHCI usb3 hardware LPM").

Cc: stable@vger.kernel.org
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bf5ce5bf
    • B
      usb: Use the USB_SS_MULT() macro to decode burst multiplier for log message · 5377adb0
      由 Ben Hutchings 提交于 
      usb_parse_ss_endpoint_companion() now decodes the burst multiplier
correctly in order to check that it's <= 3, but still uses the wrong
expression if warning that it's > 3.

Fixes: ff30cbc8 ("usb: Use the USB_SS_MULT() macro to get the ...")
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5377adb0
    • H
      usb: core : hub: Fix BOS 'NULL pointer' kernel panic · 464ad8c4
      由 Hans Yang 提交于 
      When a USB 3.0 mass storage device is disconnected in transporting
state, storage device driver may handle it as a transport error and
reset the device by invoking usb_reset_and_verify_device()
and following could happen:

in usb_reset_and_verify_device():
   udev->bos = NULL;

For U1/U2 enabled devices, driver will disable LPM, and in some
conditions:
   from usb_unlocked_disable_lpm()
    --> usb_disable_lpm()
    --> usb_enable_lpm()
        udev->bos->ss_cap->bU1devExitLat;

And it causes 'NULL pointer' and 'kernel panic':

[  157.976257] Unable to handle kernel NULL pointer dereference
at virtual address 00000010
...
[  158.026400] PC is at usb_enable_link_state+0x34/0x2e0
[  158.031442] LR is at usb_enable_lpm+0x98/0xac
...
[  158.137368] [<ffffffc0006a1cac>] usb_enable_link_state+0x34/0x2e0
[  158.143451] [<ffffffc0006a1fec>] usb_enable_lpm+0x94/0xac
[  158.148840] [<ffffffc0006a20e8>] usb_disable_lpm+0xa8/0xb4
...
[  158.214954] Kernel panic - not syncing: Fatal exception

This commit moves 'udev->bos = NULL' behind usb_unlocked_disable_lpm()
to prevent from NULL pointer access.

Issue can be reproduced by following setup:
1) A SS pen drive behind a SS hub connected to the host.
2) Transporting data between the pen drive and the host.
3) Abruptly disconnect hub and pen drive from host.
4) With a chance it crashes.
Signed-off-by: NHans Yang <hansy@nvidia.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      464ad8c4
    • J
      USB: constify usb_mon_operations structure · 6fb8ac81
      由 Julia Lawall 提交于 
      The usb_mon_operations structure is never modified, so declare it as const.

Done with the help of Coccinelle.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6fb8ac81
    • A
      USB: add usbfs snooping for REAP and DISCARD · a016a816
      由 Alan Stern 提交于 
      This patch improves the usbfs_snoop debugging facility by adding
messages for a couple of significant events which, up to now, have not
been logged.  The events are reaping and discarding (i.e.,
cancelling) an URB.  The debugging messages include the userspace
address of the URB being reaped or discarded.

The reaping messages have to be added in four places, in order to
handle blocking and non-blocking reaps in both normal and 32-bit
compatibility mode.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a016a816
    • A
      USB: limit usbfs snooping of URB contents · 0290cc9f
      由 Alan Stern 提交于 
      The usbfs_snoop facility can be very useful for debugging problems
involving usbfs.  However, it always prints out the entire contents of
every URB.  When dealing with large quantities of data, this can be
less than helpful.

This patch ameliorates the situation by adding a module parameter to
usbcore for controlling the maximum number of bytes to print when
snooping an URB.  This makes debugging much easier.  For backward
compatibility, the default value is set unreasonably high.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0290cc9f
    • A
      USB: quirks: Fix another ELAN touchscreen · df36c5be
      由 Adrien Vergé 提交于 
      Like other buggy models that had their fixes [1], the touchscreen with
id 04f3:21b8 from ELAN Microelectronics needs the device-qualifier
quirk. Otherwise, it fails to respond, blocks the boot for a random
amount of time and pollutes dmesg with:

[ 2887.373196] usb 1-5: new full-speed USB device number 41 using xhci_hcd
[ 2889.502000] usb 1-5: unable to read config index 0 descriptor/start: -71
[ 2889.502005] usb 1-5: can't read configurations, error -71
[ 2889.654571] usb 1-5: new full-speed USB device number 42 using xhci_hcd
[ 2891.783438] usb 1-5: unable to read config index 0 descriptor/start: -71
[ 2891.783443] usb 1-5: can't read configurations, error -71

[1]: See commits c68929f7, 876af5d4, d7499475, a32c99e7 and dc703ec2.
Tested-by: NAdrien Vergé <adrienverge@gmail.com>
Signed-off-by: NAdrien Vergé <adrienverge@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      df36c5be
  27. 20 11月, 2015 2 次提交