linux-stable.git/drivers/usb/core, branch v4.9.2

usb: core: usbport: Use proper LED API to fix potential crash

2017-01-06T09:40:11+00:00

commit 89778ba335e302a450932ce5b703c1ee6216e949 upstream.

Calling brightness_set manually isn't safe as some LED drivers don't
implement this callback. The best idea is to just use a proper helper
which will fallback to the brightness_set_blocking callback if needed.

This fixes:
[ 1461.761528] Unable to handle kernel NULL pointer dereference at virtual address 00000000
(...)
[ 1462.117049] Backtrace:
[ 1462.119521] [] (usbport_trig_port_store [ledtrig_usbport]) from [] (dev_attr_store+0x20/0x2c)
[ 1462.129826]  r7:dcabc7c0 r6:dee0ff80 r5:00000002 r4:bf228164
[ 1462.135511] [] (dev_attr_store) from [] (sysfs_kf_write+0x48/0x4c)
[ 1462.143459]  r5:00000002 r4:c023f738
[ 1462.147049] [] (sysfs_kf_write) from [] (kernfs_fop_write+0xf8/0x1f8)
[ 1462.155258]  r5:00000002 r4:df4a1000
[ 1462.158850] [] (kernfs_fop_write) from [] (__vfs_write+0x34/0x120)
[ 1462.166800]  r10:00000000 r9:dee0e000 r8:c000fc24 r7:00000002 r6:dee0ff80 r5:c01689c0
[ 1462.174660]  r4:df727a80
[ 1462.177204] [] (__vfs_write) from [] (vfs_write+0xac/0x170)
[ 1462.184543]  r9:dee0e000 r8:c000fc24 r7:dee0ff80 r6:b6f092d0 r5:df727a80 r4:00000002
[ 1462.192319] [] (vfs_write) from [] (SyS_write+0x4c/0xa8)
[ 1462.199396]  r9:dee0e000 r8:c000fc24 r7:00000002 r6:b6f092d0 r5:df727a80 r4:df727a80
[ 1462.207174] [] (SyS_write) from [] (ret_fast_syscall+0x0/0x3c)
[ 1462.214774]  r7:00000004 r6:ffffffff r5:00000000 r4:00000000
[ 1462.220456] Code: bad PC value
[ 1462.223560] ---[ end trace 676638a3a12c7a56 ]---

Reported-by: Ralph Sennhauser 
Signed-off-by: Rafał Miłecki 
Fixes: 0f247626cbb ("usb: core: Introduce a USB port LED trigger")
Signed-off-by: Greg Kroah-Hartman

usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices

2017-01-06T09:40:11+00:00

commit 37be66767e3cae4fd16e064d8bb7f9f72bf5c045 upstream.

USB-3 does not have any link state that will avoid negotiating a connection
with a plugged-in cable but will signal the host when the cable is
unplugged.

For USB-3 we used to first set the link to Disabled, then to RxDdetect to
be able to detect cable connects or disconnects. But in RxDetect the
connected device is detected again and eventually enabled.

Instead set the link into U3 and disable remote wakeups for the device.
This is what Windows does, and what Alan Stern suggested.

Cc: Alan Stern 
Acked-by: Alan Stern 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2016-10-11T03:16:43+00:00

Pull more vfs updates from Al Viro:
 ">rename2() work from Miklos + current_time() from Deepa"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  fs: Replace current_fs_time() with current_time()
  fs: Replace CURRENT_TIME_SEC with current_time() for inode timestamps
  fs: Replace CURRENT_TIME with current_time() for inode timestamps
  fs: proc: Delete inode time initializations in proc_alloc_inode()
  vfs: Add current_time() api
  vfs: add note about i_op->rename changes to porting
  fs: rename "rename2" i_op to "rename"
  vfs: remove unused i_op->rename
  fs: make remaining filesystems use .rename2
  libfs: support RENAME_NOREPLACE in simple_rename()
  fs: support RENAME_NOREPLACE for local filesystems
  ncpfs: fix unused variable warning

Merge remote-tracking branch 'ovl/rename2' into for-linus

2016-10-11T03:02:51+00:00

fs: Replace CURRENT_TIME with current_time() for inode timestamps

2016-09-28T01:06:21+00:00

CURRENT_TIME macro is not appropriate for filesystems as it
doesn't use the right granularity for filesystem timestamps.
Use current_time() instead.

CURRENT_TIME is also not y2038 safe.

This is also in preparation for the patch that transitions
vfs timestamps to use 64 bit time and hence make them
y2038 safe. As part of the effort current_time() will be
extended to do range checks. Hence, it is necessary for all
file system timestamps to use current_time(). Also,
current_time() will be transitioned along with vfs to be
y2038 safe.

Note that whenever a single call to current_time() is used
to change timestamps in different inodes, it is because they
share the same time granularity.

Signed-off-by: Deepa Dinamani 
Reviewed-by: Arnd Bergmann 
Acked-by: Felipe Balbi 
Acked-by: Steven Whitehouse 
Acked-by: Ryusuke Konishi 
Acked-by: David Sterba 
Signed-off-by: Al Viro

usb: hub: change CLEAR_FEATURE to SET_FEATURE

2016-09-27T10:20:17+00:00

In USB20 specification, describes in chapter 9.4.5: The Remote Wakeup
field can be modified by the SetFeature() and ClearFeature() requests
using the DEVICE_REMOTE_WAKEUP feature selector.

In USB30 specification, also describes in chapter 9.4.5: The Function
Remote Wakeup field can be modified by the SetFeature() requests
using the FUNCTION_SUSPEND feature selector. In chapter 9.4.9 Set
Feature reference, it describes Function Remote Wake Enabled/Disabled
at suspend options by SET_FEATURE.

In USB30 specification only mentioned SetFeature(), so we need use
SET_FEATURE replace CLEAR_FEATURE to disable USB30 function remote
wakeup in suspend options.

Signed-off-by: Yonglong Wu 
Signed-off-by: Greg Kroah-Hartman

usb: core: Introduce a USB port LED trigger

2016-09-27T10:20:17+00:00

This commit adds a new trigger responsible for turning on LED when USB
device gets connected to the selected USB port. This can can useful for
various home routers that have USB port(s) and a proper LED telling user
a device is connected.

The trigger gets its documentation file but basically it just requires
enabling it and selecting USB ports (e.g. echo 1 > ports/usb1-1).

There was a long discussion on design of this driver. Its current state
is a result of picking them most adjustable solution as others couldn't
handle all cases.

1) It wasn't possible for the driver to register separated trigger for
   each USB port. Some physical USB ports are handled by more than one
   controller and so by more than one USB port. E.g. USB 2.0 physical
   port may be handled by OHCI's port and EHCI's port.
   It's also not possible to assign more than 1 trigger to a single LED
   and implementing such feature would be tricky due to syncing triggers
   and sysfs conflicts with old triggers.

2) Another idea was to register trigger per USB hub. This wouldn't allow
   handling devices with multiple USB LEDs and controllers (hubs)
   controlling more than 1 physical port. It's common for hubs to have
   few ports and each may have its own LED.

This final trigger is highly flexible. It allows selecting any USB ports
for any LED. It was also modified (comparing to the initial version) to
allow choosing ports rather than having user /guess/ proper names. It
was successfully tested on SmartRG SR400ac which has 3 USB LEDs,
2 physical ports and 3 controllers.

It was noted USB subsystem already has usb-gadget and usb-host triggers
but they are pretty trivial ones. They indicate activity only and can't
have ports specified.

In future it may be good idea to consider adding activity support to
usbport as well. This should allow switching to this more generic driver
and maybe marking old ones as obsolete.
This can be implemented with another sysfs file for setting mode. The
default mode wouldn't change so there won't be ABI breakage and so such
feature can be safely implemented later.

There was also an idea of supporting other devices (PCI, SDIO, etc.) but
as this driver already contains some USB specific code (and will get
more) these should be probably separated drivers (triggers).

Signed-off-by: Rafał Miłecki 
Signed-off-by: Greg Kroah-Hartman

usb: core: hcd: add missing header dependencies

2016-09-27T10:20:17+00:00

We get 1 warning when building kernel with W=1:
drivers/usb/core/hcd.c:2390:5: warning: no previous prototype for 'usb_bus_start_enum' [-Wmissing-prototypes]

In fact, these functions are declared in linux/usb/otg.h, so this patch
adds the missing header dependencies.

Signed-off-by: Baoyou Xie 
Signed-off-by: Greg Kroah-Hartman

Merge 4.8-rc7 into usb-next

2016-09-19T07:12:41+00:00

We want/need the USB fixes in here as well.

Signed-off-by: Greg Kroah-Hartman

USB: change bInterval default to 10 ms

2016-09-16T14:29:41+00:00

Some full-speed mceusb infrared transceivers contain invalid endpoint
descriptors for their interrupt endpoints, with bInterval set to 0.
In the past they have worked out okay with the mceusb driver, because
the driver sets the bInterval field in the descriptor to 1,
overwriting whatever value may have been there before.  However, this
approach was never sanctioned by the USB core, and in fact it does not
work with xHCI controllers, because they use the bInterval value that
was present when the configuration was installed.

Currently usbcore uses 32 ms as the default interval if the value in
the endpoint descriptor is invalid.  It turns out that these IR
transceivers don't work properly unless the interval is set to 10 ms
or below.  To work around this mceusb problem, this patch changes the
endpoint-descriptor parsing routine, making the default interval value
be 10 ms rather than 32 ms.

Signed-off-by: Alan Stern 
Tested-by: Wade Berrier 
CC: 
Signed-off-by: Greg Kroah-Hartman