28 Jan, 2015
40 commits
-
commit 889b77f7fd2bcc922493d73a4c51d8a851505815 upstream.
Flooding the Kvaser CAN to USB dongle with multiple reads and
writes in very high frequency (*), closing the CAN channel while
all the transmissions are on (#), opening the device again (@),
then sending a small number of packets would make the driver
enter an almost infinite loop of:[....]
[15959.853988] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853990] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853991] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853993] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853994] kvaser_usb 4-3:1.0 can0: cannot find free context
[15959.853995] kvaser_usb 4-3:1.0 can0: cannot find free context
[....]_dragging the whole system down_ in the process due to the
excessive logging output.Initially, this has caused random panics in the kernel due to a
buggy error recovery path. That got fixed in an earlier commit.(%)
This patch aims at solving the root cause. -->16 tx URBs and contexts are allocated per CAN channel per USB
device. Such URBs are protected by:a) A simple atomic counter, up to a value of MAX_TX_URBS (16)
b) A flag in each URB context, stating if it's free
c) The fact that ndo_start_xmit calls are themselves protected
by the networking layers higher aboveAfter grabbing one of the tx URBs, if the driver noticed that all
of them are now taken, it stops the netif transmission queue.
Such queue is worken up again only if an acknowedgment was received
from the firmware on one of our earlier-sent frames.Meanwhile, upon channel close (#), the driver sends a CMD_STOP_CHIP
to the firmware, effectively closing all further communication. In
the high traffic case, the atomic counter remains at MAX_TX_URBS,
and all the URB contexts remain marked as active. While opening
the channel again (@), it cannot send any further frames since no
more free tx URB contexts are available.Reset all tx URB contexts upon CAN channel close.
(*) 50 parallel instances of `cangen0 -g 0 -ix`
(#) `ifconfig can0 down`
(@) `ifconfig can0 up`
(%) "can: kvaser_usb: Don't free packets when tight on URBs"Signed-off-by: Ahmed S. Darwish
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman -
commit b442723fcec445fb0ae1104888dd22cd285e0a91 upstream.
Flooding the Kvaser CAN to USB dongle with multiple reads and
writes in high frequency caused seemingly-random panics in the
kernel.On further inspection, it seems the driver erroneously freed the
to-be-transmitted packet upon getting tight on URBs and returning
NETDEV_TX_BUSY, leading to invalid memory writes and double frees
at a later point in time.Note:
Finding no more URBs/transmit-contexts and returning NETDEV_TX_BUSY
is a driver bug in and out of itself: it means that our start/stop
queue flow control is broken.This patch only fixes the (buggy) error handling code; the root
cause shall be fixed in a later commit.Acked-by: Olivier Sobrie
Signed-off-by: Ahmed S. Darwish
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman -
commit 68693b8ea4e284c46bff919ac62bd9ccdfdbb6ba upstream.
since the split of host+gadget mode in commit 74c2e9360058 ("usb: musb:
factor out hcd initalization") we leak the usb_hcd struct. We call now
musb_host_cleanup() which does basically usb_remove_hcd() and also sets
the hcd variable to NULL. Doing so makes the finall call to
musb_host_free() basically a nop and the usb_hcd remains around for ever
without anowner.
This patch drops that NULL assignment for that reason.Fixes: 74c2e9360058 ("usb: musb: factor out hcd initalization")
Cc: Daniel Mack
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit 6d89252a998a695ecb0348fc2d717dc33d90cae9 upstream.
Commit c3ee9b76aa93 (EHCI: improved logic for isochronous scheduling)
introduced the idea of using ehci->last_iso_frame as the origin (or
base) for the circular calculations involved in modifying the
isochronous schedule. However, the new code it added used
ehci->last_iso_frame before the value was properly initialized. This
patch rectifies the mistake by moving the initialization lines earlier
in iso_stream_schedule().This fixes Bugzilla #72891.
Signed-off-by: Alan Stern
Fixes: c3ee9b76aa93
Reported-by: Joe Bryant
Tested-by: Joe Bryant
Tested-by: Martin Long
Signed-off-by: Greg Kroah-Hartman -
commit 32a4bf2e81ec378e5925d4e069e0677a6c86a6ad upstream.
Use tty kref to release the fake tty in usb_console_setup to avoid use
after free if the underlying serial driver has acquired a reference.Note that using the tty destructor release_one_tty requires some more
state to be initialised.Fixes: 4a90f09b20f4 ("tty: usb-serial krefs")
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
commit d269d4434c72ed0da3a9b1230c30da82c4918c63 upstream.
The USB console currently allocates a temporary fake tty which is used
to pass terminal settings to the underlying serial driver.The tty struct is not fully initialised, something which can lead to a
lockdep warning (or worse) if a serial driver tries to acquire a
line-discipline reference:usbserial: USB Serial support registered for pl2303
pl2303 1-2.1:1.0: pl2303 converter detected
usb 1-2.1: pl2303 converter now attached to ttyUSB0
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 68 Comm: udevd Tainted: G W 3.18.0-rc5 #10
[] (unwind_backtrace) from [] (show_stack+0x20/0x24)
[] (show_stack) from [] (dump_stack+0x24/0x28)
[] (dump_stack) from [] (__lock_acquire+0x1e50/0x2004)
[] (__lock_acquire) from [] (lock_acquire+0xe4/0x18c)
[] (lock_acquire) from [] (ldsem_down_read_trylock+0x78/0x90)
[] (ldsem_down_read_trylock) from [] (tty_ldisc_ref+0x24/0x58)
[] (tty_ldisc_ref) from [] (usb_serial_handle_dcd_change+0x48/0xe8)
[] (usb_serial_handle_dcd_change) from [] (pl2303_read_int_callback+0x210/0x220 [pl2303])
[] (pl2303_read_int_callback [pl2303]) from [] (__usb_hcd_giveback_urb+0x80/0x140)
[] (__usb_hcd_giveback_urb) from [] (usb_giveback_urb_bh+0x98/0xd4)
[] (usb_giveback_urb_bh) from [] (tasklet_hi_action+0x9c/0x108)
[] (tasklet_hi_action) from [] (__do_softirq+0x148/0x42c)
[] (__do_softirq) from [] (irq_exit+0xd8/0x114)
[] (irq_exit) from [] (__handle_domain_irq+0x84/0xdc)
[] (__handle_domain_irq) from [] (omap_intc_handle_irq+0xd8/0xe0)
[] (omap_intc_handle_irq) from [] (__irq_svc+0x44/0x7c)
Exception stack(0xdf4e7f08 to 0xdf4e7f50)
7f00: debc0b80 df4e7f5c 00000000 00000000 debc0b80 be8da96c
7f20: 00000000 00000128 c000fc84 df4e6000 00000000 df4e7f94 00000004 df4e7f50
7f40: c038ebc0 c038d74c 600f0013 ffffffff
[] (__irq_svc) from [] (___sys_sendmsg.part.29+0x0/0x2e0)
[] (___sys_sendmsg.part.29) from [] (SyS_sendmsg+0x18/0x1c)
[] (SyS_sendmsg) from [] (ret_fast_syscall+0x0/0x48)
console [ttyUSB0] enabledFixes: 36697529b5bb ("tty: Replace ldisc locking with ldisc_sem")
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
commit 5fb694f96e7c19e66b1c55124b98812e32e3efa5 upstream.
When unloading the module 'g_hid.ko', the urb request will be dequeued and the
completion routine will be excuted. If there is no urb packet, the urb request
will not be added to the endpoint queue and the completion routine pointer in
urb request is NULL.Accessing to this NULL function pointer will cause the Oops issue reported
below.Add the code to check if the urb request is in the endpoint queue
or not. If the urb request is not in the endpoint queue, a negative
error code will be returned.Here is the Oops log:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = dedf0000
[00000000] *pgd=3ede5831, *pte=00000000, *ppte=00000000
Internal error: Oops: 80000007 [#1] ARM
Modules linked in: g_hid(-) usb_f_hid libcomposite
CPU: 0 PID: 923 Comm: rmmod Not tainted 3.18.0+ #2
Hardware name: Atmel SAMA5 (Device Tree)
task: df6b1100 ti: dedf6000 task.ti: dedf6000
PC is at 0x0
LR is at usb_gadget_giveback_request+0xc/0x10
pc : [] lr : [] psr: 60000093
sp : dedf7eb0 ip : df572634 fp : 00000000
r10: 00000000 r9 : df52e210 r8 : 60000013
r7 : df6a9858 r6 : df52e210 r5 : df6a9858 r4 : df572600
r3 : 00000000 r2 : ffffff98 r1 : df572600 r0 : df6a9868
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c53c7d Table: 3edf0059 DAC: 00000015
Process rmmod (pid: 923, stack limit = 0xdedf6230)
Stack: (0xdedf7eb0 to 0xdedf8000)
7ea0: 00000000 c02adbbc df572580 deced608
7ec0: df572600 df6a9868 df572634 c02aed3c df577c00 c01b8608 00000000 df6be27c
7ee0: 00200200 00100100 bf0162f4 c000e544 dedf6000 00000000 00000000 bf010c00
7f00: bf0162cc bf00159c 00000000 df572980 df52e218 00000001 df5729b8 bf0031d0
[..]
[] (usb_gadget_giveback_request) from [] (request_complete+0x64/0x88)
[] (request_complete) from [] (usba_ep_dequeue+0x70/0x128)
[] (usba_ep_dequeue) from [] (hidg_unbind+0x50/0x7c [usb_f_hid])
[] (hidg_unbind [usb_f_hid]) from [] (remove_config.isra.6+0x98/0x9c [libcomposite])
[] (remove_config.isra.6 [libcomposite]) from [] (__composite_unbind+0x34/0x98 [libcomposite])
[] (__composite_unbind [libcomposite]) from [] (usb_gadget_remove_driver+0x50/0x78)
[] (usb_gadget_remove_driver) from [] (usb_gadget_unregister_driver+0x64/0x94)
[] (usb_gadget_unregister_driver) from [] (hidg_cleanup+0x10/0x34 [g_hid])
[] (hidg_cleanup [g_hid]) from [] (SyS_delete_module+0x118/0x19c)
[] (SyS_delete_module) from [] (ret_fast_syscall+0x0/0x30)
Code: bad PC valueSigned-off-by: Songjun Wu
[nicolas.ferre@atmel.com: reworked the commit message]
Signed-off-by: Nicolas Ferre
Fixes: 914a3f3b3754 ("USB: add atmel_usba_udc driver")
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit 6785a1034461c2d2c205215f63a50a740896e55b upstream.
When receive data, the RXRDY in status register set by hardware
after a new packet has been stored in the endpoint FIFO. When it
is copied from FIFO, this bit is cleared which make the FIFO can
be accessed again.In the receive_data() function, this bit RXRDY has been cleared.
So, after the receive_data() function return, this bit should
not be cleared again, or else it may cause the accessing FIFO
corrupt, which will make the data loss.Fixes: 914a3f3b3754 (USB: add atmel_usba_udc driver)
Acked-by: Nicolas Ferre
Signed-off-by: Bo Shen
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit f40afdddeb6c54ffd1e2920a5e93e363d6748db6 upstream.
According to the datasheet, when transfer using DMA, the control
setting for IN packet only need END_BUF_EN, END_BUF_IE, CH_EN,
while for OUT packet, need more two bits END_TR_EN and END_TR_IE
to be configured.Fixes: 914a3f3b3754 (USB: add atmel_usba_udc driver)
Acked-by: Nicolas Ferre
Signed-off-by: Bo Shen
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit b44be2462dbe3e23f0aedff64de52a1e8e47a1cd upstream.
Commit 3b74c73f8d6f053f422e85fce955b61fb181cfe7 switched over to memdup_user()
in ep_write() function and removed kfree (kbuf).
memdup_user() function allocates memory which is never freed.Fixes: 3b74c73 (usb: gadget: inode: switch over to memdup_user())
Signed-off-by: Mario Schuknecht
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit b5122236bba8d7ef62153da5b55cc65d0944c61e upstream.
Fix null-pointer dereference during probe if the interface-status
completion handler is called before the individual ports have been set
up.Fixes: f79b2d0fe81e ("USB: keyspan: fix NULL-pointer dereferences and
memory leaks")
Reported-by: Richard
Tested-by: Richard
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
commit d80c0d14183516f184a5ac88e11008ee4c7d2a2e upstream.
As has been discussed in the thread starting with
https://lkml.kernel.org/g/549748e9.d+SiJzqu50f1r4lSAL043YSc@arcor.de
Sierra Wireless MC73xx devices with USB VID/PID 0x1199:0x68c0 require the
option_send_setup() code to be used on the USB interface for the AT port
to make unsolicited response codes work correctly. Move these devices from
the qcserial driver where they have been added by commit
70a3615fc07c2330ed7c1e922f3c44f4a67c0762 ("usb: qcserial: add Sierra Wireless
MC73xx") to the option driver and add a MC73xx-specific blacklist
to ensure that
1. the sendsetup code is not used for the DIAG/DM and NMEA interfaces
2. the option driver does not attach to the QMI/network interfacesSigned-off-by: Reinhard Speyerer
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
commit 1ae78a4870989a354028cb17dabf819b595e70e3 upstream.
Added virtual com port VID/PID entries for CEL USB sticks and MeshWorks
devices.Signed-off-by: David Peterson
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
commit 90441b4dbe90ba0c38111ea89fa093a8c9627801 upstream.
Fixing typo for MeshConnect IDs. The original PID (0x8875) is not in
production and is not needed. Instead it has been changed to the
official production PID (0x8857).Signed-off-by: Preston Fick
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
commit 39e60635a01520e8c8ed3946a28c2b98e6a46f79 upstream.
DWC3 gadget sets up a pool of 32 TRBs for each EP during initialization. This
means, the max TRBs that can be submitted for an EP is fixed to 32. Since the
request queue for an EP is a linked list, any number of requests can be queued
to it by the gadget layer. However, the dwc3 driver must not submit TRBs more
than the pool it has created for. This limit wasn't respected when SG was used
resulting in submitting more than the max TRBs, eventually leading to
non-transfer of the TRBs submitted over the max limit.Root cause:
When SG is used, there are two loops iterating to prepare TRBs:
- Outer loop over the request_list
- Inner loop over the SG list
The code was missing break to get out of the outer loop.Fixes: eeb720fb21d6 (usb: dwc3: gadget: add support for SG lists)
Signed-off-by: Amit Virdi
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit ec512fb8e5611fed1df2895f90317ce6797d6b32 upstream.
When scatter gather (SG) is used, multiple TRBs are prepared from one DWC3
request (dwc3_request). So while preparing TRBs, the 'last' flag should be set
only when it is the last TRB being prepared from the last dwc3_request entry.The current implementation uses list_is_last to check if the dwc3_request is the
last entry from the request_list. However, list_is_last returns false for the
last entry too. This is because, while preparing the first TRB from a request,
the function dwc3_prepare_one_trb modifies the request's next and prev pointers
while moving the URB to req_queued. Hence, list_is_last always returns false no
matter what.The correct way is not to access the modified pointers of dwc3_request but to
use list_empty macro instead.Fixes: e5ba5ec833aa (usb: dwc3: gadget: fix scatter gather implementation)
Signed-off-by: Amit Virdi
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit 56abcab833fafcfaeb2f5b25e0364c1dec45f53e upstream.
Commit 8dccddbc2368 ("OHCI: final fix for NVIDIA problems (I hope)")
introduced into 3.1.9 broke boot on e.g. Freescale P2020DS development
board. The code path that was previously specific to NVIDIA controllers
had then become taken for all chips.However, the M5237 installed on the board wedges solid when accessing
its base+OHCI_FMINTERVAL register, making it impossible to boot any
kernel newer than 3.1.8 on this particular and apparently other similar
machines.Don't readl() and writel() base+OHCI_FMINTERVAL on PCI ID 10b9:5237.
The patch is suitable for the -next tree as well as all maintained
kernels up to 3.2 inclusive.Signed-off-by: Arseny Solokha
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman -
commit 0915e6feb38de8d3601819992a5bd050201a56fa upstream.
The gpio device attributes were never destroyed when the gpio was
unexported (or on export failures).Use device_create_with_groups() to create the default device attributes
of the gpio class device. Note that this also fixes the
attribute-creation race with userspace for these attributes.Remove contingent attributes in export error path and on unexport.
Fixes: d8f388d8dc8d ("gpio: sysfs interface")
Signed-off-by: Johan Hovold
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 121b6a79955a3a3fd7bbb9b8cb88d5b9dad6283d upstream.
The gpio-chip device attributes were never destroyed when the device was
removed.Fix by using device_create_with_groups() to create the device attributes
of the chip class device.Note that this also fixes the attribute-creation race with userspace.
Fixes: d8f388d8dc8d ("gpio: sysfs interface")
Signed-off-by: Johan Hovold
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 6798acaa0138d8b12f1c54402ebcb66fea3deb03 upstream.
Move direct and indirect calls to gpiochip_remove_pin_ranges outside of
spin lock as they can end up taking a mutex in pinctrl_remove_gpio_range.Note that the pin ranges are already added outside of the lock.
Fixes: 9ef0d6f7628b ("gpiolib: call pin removal in chip removal function")
Fixes: f23f1516b675 ("gpiolib: provide provision to register pin ranges")
Signed-off-by: Johan Hovold
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 00acc3dc248063f982cfacfbe5e78c0d6797ffef upstream.
Fix memory leak and sleep-while-atomic in gpiochip_remove.
The memory leak was introduced by afa82fab5e13 ("gpio / ACPI: Move event
handling registration to gpiolib irqchip helpers") that moved the
release of acpi interrupt resources to gpiochip_irqchip_remove, but by
then the resources are no longer accessible as the acpi_gpio_chip has
already been freed by acpi_gpiochip_remove.Note that this also fixes a few potential sleep-while-atomics, which has
been around since 1425052097b5 ("gpio: add IRQ chip helpers in gpiolib")
when the call to gpiochip_irqchip_remove while holding a spinlock was
added (a couple of irq-domain paths can end up grabbing mutexes).Fixes: afa82fab5e13 ("gpio / ACPI: Move event handling registration to
gpiolib irqchip helpers")
Fixes: 1425052097b5 ("gpio: add IRQ chip helpers in gpiolib")Signed-off-by: Johan Hovold
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 5539b3c938d64a60cb1fc442ac3ce9263d52de0c upstream.
Memory allocated and references taken by of_gpiochip_add and
acpi_gpiochip_add were never released on errors in gpiochip_add (e.g.
failure to find free gpio range).Fixes: 391c970c0dd1 ("of/gpio: add default of_xlate function if device
has a node pointer")
Fixes: 664e3e5ac64c ("gpio / ACPI: register to ACPI events
automatically")Signed-off-by: Johan Hovold
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit e733a2fb8cbcff0747108cb529ffb4e4a00465ac upstream.
The CrystalCove GPIO chip has can_sleep set so its demultiplexed irqs
will have IRQ_NESTED_THREAD flag set, thus we should use the nested
version handle_nested_irq in CrystalCove's irq handler instead of
handle_generic_irq, or the following warning will be hit and the
functionality is lost:[ 4089.639554] Hardware name: ASUSTeK COMPUTER INC. T100TA/T100TA, BIOS T100TA.313 08/13/2014
[ 4089.639564] 00000002 00000000 c24fbdf4 c16e0257 c24fbe38 c24fbe28 c105390c c18ec480
[ 4089.639596] c24fbe54 00000048 c18f8e3b 00000295 c10a60fc 00000295 c10a60fc f4464540
[ 4089.639626] f446459c c278ad40 c24fbe40 c1053974 00000009 c24fbe38 c18ec480 c24fbe54
[ 4089.639656] Call Trace:
[ 4089.639685] [] dump_stack+0x41/0x52
[ 4089.639707] [] warn_slowpath_common+0x8c/0xc0
[ 4089.639727] [] ? irq_nested_primary_handler+0x2c/0x30
[ 4089.639744] [] ? irq_nested_primary_handler+0x2c/0x30
[ 4089.639763] [] warn_slowpath_fmt+0x34/0x40
[ 4089.639781] [] irq_nested_primary_handler+0x2c/0x30
[ 4089.639800] [] handle_irq_event_percpu+0x76/0x190
[ 4089.639818] [] ? regmap_format_10_14_write+0x30/0x30
[ 4089.639836] [] ? _regmap_bus_raw_write+0x4c/0x70
[ 4089.639854] [] handle_irq_event+0x31/0x50
[ 4089.639872] [] handle_simple_irq+0x4b/0x70
[ 4089.639889] [] generic_handle_irq+0x24/0x40
[ 4089.639908] [] crystalcove_gpio_irq_handler+0xa7/0xc0
[ 4089.639927] [] handle_nested_irq+0x77/0x190
[ 4089.639947] [] regmap_irq_thread+0x1b1/0x360
[ 4089.639966] [] irq_thread_fn+0x18/0x30
[ 4089.639983] [] irq_thread+0xf6/0x110
[ 4089.640001] [] ? irq_finalize_oneshot.part.30+0x1b0/0x1b0
[ 4089.640019] [] ? irq_forced_thread_fn+0x50/0x50
[ 4089.640037] [] ? irq_thread_check_affinity+0xc0/0xc0
[ 4089.640054] [] kthread+0xa9/0xc0
[ 4089.640074] [] ret_from_kernel_thread+0x21/0x30
[ 4089.640091] [] ? kthread_create_on_node+0x110/0x110
[ 4089.640105] ---[ end trace dca7946ad31eba7d ]---Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=90521
Reported-and-tested-by: Brian Loften
Signed-off-by: Aaron Lu
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 7b8792bbdffdff3abda704f89c6a45ea97afdc62 upstream.
of_get_named_gpiod_flags fails with -EPROBE_DEFER in cases
where the gpio chip is available and the GPIO translation fails.This causes drivers to be re-probed erroneusly, and hides the
real problem(i.e. the GPIO number being out of range).Signed-off-by: Hans Holmberg
Reviewed-by: Alexandre Courbot
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 41f632fe177bc4822c2e8236fe7c291e6e9eb6f8 upstream.
Remove bogus call to of_gpiochip_add (and of_gpio_chip remove in error
path) which is also called when adding the gpio chip.This prevents adding the same pinctrl range twice.
Fixes: 3f8c50c9b110 ("OF: pinctrl: MIPS: lantiq: implement lantiq/xway
pinctrl support")Signed-off-by: Johan Hovold
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 41544f9f38f19cb46dc9a8fa37c58677a0300899 upstream.
Call spin_lock_init() before the spinlocks are used, both in early init
and probe functions preventing a lockdep splat.I have been observing lockdep complaining [1] during boot on my a80 optimus [2]
when CONFIG_PROVE_LOCKING has been enabled. This patch resolves the splat,
and has been tested on a few other sunxi platforms without issue.[1] http://storage.kernelci.org/next/next-20150107/arm-multi_v7_defconfig+CONFIG_PROVE_LOCKING=y/lab-tbaker/boot-sun9i-a80-optimus.html
[2] http://kernelci.org/boot/?a80-optimusSigned-off-by: Tyler Baker
Acked-by: Philipp Zabel
Signed-off-by: Kevin Hilman
Signed-off-by: Olof Johansson
Signed-off-by: Greg Kroah-Hartman -
commit 3ca8c717429b90f621aed28af029da4c3da378bc upstream.
Just like all previous UAS capable Seagate disk enclosures, these need the
US_FL_NO_ATA_1X to not crash when udev probes them.Signed-off-by: Hans de Goede
Signed-off-by: Greg Kroah-Hartman -
commit c6fa3945c8b5baf62f2e849104ecd6f3a1e5e407 upstream.
Like the JMicron JMS567 enclosures with the JMS566 choke on report-opcodes,
so avoid it.Tested-and-reported-by: Takeo Nakayama
Signed-off-by: Hans de Goede
Signed-off-by: Greg Kroah-Hartman -
commit e5797a3d079f3e5049140055d850691b5cc7d10a upstream.
This is yet another Seagate device which needs the US_FL_NO_ATA_1X quirk
Reported-by: Marcin Zajączkowski
Signed-off-by: Hans de Goede
Signed-off-by: Greg Kroah-Hartman -
commit b13a65ef190e488e2761d65bdd2e1fe8a3a125f5 upstream.
H_RST bit in H_CSR register may be found lit before reset is started,
for example if preceding reset flow hasn't completed.
In that case asserting H_RST will be ignored, therefore we need to clean
H_RST bit to start a successful reset sequence.Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman -
commit 0c86ac2c50647451d6a70dc900f8bb0ee3d485d9 upstream.
This patch fixes a NULL pointer dereference on led_dat->mode_val. Due to
this bug, a kernel oops can be observed at probe time on the LaCie 2Big
and 5Big v2 boards:Unable to handle kernel NULL pointer dereference at virtual address 00000008
[...]
[] (netxbig_led_probe) from [] (platform_drv_probe+0x4c/0x9c)
[] (platform_drv_probe) from [] (driver_probe_device+0x98/0x25c)
[] (driver_probe_device) from [] (__driver_attach+0x8c/0x90)
[] (__driver_attach) from [] (bus_for_each_dev+0x68/0x94)
[] (bus_for_each_dev) from [] (bus_add_driver+0x124/0x1dc)
[] (bus_add_driver) from [] (driver_register+0x78/0xf8)
[] (driver_register) from [] (do_one_initcall+0x80/0x1cc)
[] (do_one_initcall) from [] (kernel_init_freeable+0xe4/0x1b4)
[] (kernel_init_freeable) from [] (kernel_init+0xc/0xec)
[] (kernel_init) from [] (ret_from_fork+0x14/0x24)
[...]This bug was introduced by commit 588a6a99286ae30afb1339d8bc2163517b1b7dd1
("leds: netxbig: fix attribute-creation race").Signed-off-by: Simon Guinot
Acked-by: Johan Hovold
Signed-off-by: Bryan Wu
Signed-off-by: Greg Kroah-Hartman -
commit 25906052d953d3fbdb7e19480b9de5e6bb949f3f upstream.
Since ALE table is a common resource for both the interfaces in Dual EMAC
mode and while bringing up the second interface in cpsw_ndo_set_rx_mode()
all the multicast entries added by the first interface is flushed out and
only second interface multicast addresses are added. Fixing this by
flushing multicast addresses based on dual EMAC port vlans which will not
affect the other emac port multicast addresses.Fixes: d9ba8f9 (driver: net: ethernet: cpsw: dual emac interface implementation)
Signed-off-by: Mugunthan V N
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 776d4e9f5c0229037707f692b386b1f2a5bac054 upstream.
Adds FCoE config option I40E_FCOE, so that FCoE can be enabled
as needed but otherwise have it disabled by default.This also eliminate multiple FCoE config checks, instead now just
one config check for CONFIG_I40E_FCOE.The I40E FCoE was added with 3.17 kernel and therefore this patch
shall be applied to stable 3.17 kernel also.Signed-off-by: Vasu Dev
Tested-by: Jim Young
Signed-off-by: Jeff Kirsher
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit c93edc639392df733c7d72db4376a9add775d18a upstream.
commit 5c90422439d6
"iwlwifi: mvm: don't allow diversity if BT Coex / TT forbid it"
broke Rx with 2 chains for diversity.
This had an impact on throughput where we're using only a single
stream (11a/b/g APs, single stream APs, static SMPS).Fixes: 5c90422439d6 ("iwlwifi: mvm: don't allow diversity if BT Coex / TT forbid it")
Signed-off-by: Eyal Shapira
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Greg Kroah-Hartman -
commit 3cbc6123a93dc91b99b58f7ea37d267fe93e1cad upstream.
Host controllers lacking the required internal vmmc regulator may still
follow the spec with regard to the LSB of SDHCI_POWER_CONTROL. Set the
SDHCI_POWER_ON bit when vmmc is enabled to encourage the controller to
to drive CMD, DAT, SDCLK.This fixes a regression observed on some Qualcomm and Nvidia boards
caused by 5222161 mmc: sdhci: Improve external VDD regulator support.Fixes: 52221610dd84 (mmc: sdhci: Improve external VDD regulator support)
Signed-off-by: Tim Kryger
Tested-by: Bjorn Andersson
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman -
commit 7c2e211f3c95b91912a92a8c6736343690042e2e upstream.
Current vfio-pci just supports normal pci device, so vfio_pci_probe() will
return if the pci device is not a normal device. While current code makes a
mistake. PCI_HEADER_TYPE is the offset in configuration space of the device
type, but we use this value to mask the type value.This patch fixs this by do the check directly on the pci_dev->hdr_type.
Signed-off-by: Wei Yang
Signed-off-by: Alex Williamson
Signed-off-by: Greg Kroah-Hartman -
commit bb9ff078860f9d2f79d3a6bea3af9f48354ddb75 upstream.
An error was returned if composing was not supported, instead of if
cropping was not supported.A classic copy-and-paste bug. Found with v4l2-compliance.
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit ac03086067a5524ae9e020ba5712a208c67b2736 upstream.
The end timer is used for switching back from repeat code timings when
no repeat codes have been received for a certain amount of time. When
the protocol is changed, the end timer is deleted synchronously with
del_timer_sync(), however this takes place while holding the main spin
lock, and the timer handler also needs to acquire the spin lock.This opens the possibility of a deadlock on an SMP system if the
protocol is changed just as the repeat timer is expiring. One CPU could
end up in img_ir_set_decoder() holding the lock and waiting for the end
timer to complete, while the other CPU is stuck in the timer handler
spinning on the lock held by the first CPU.Lockdep also spots a possible lock inversion in the same code, since
img_ir_set_decoder() acquires the img-ir lock before the timer lock, but
the timer handler will try and acquire them the other way around:=========================================================
[ INFO: possible irq lock inversion dependency detected ]
3.18.0-rc5+ #957 Not tainted
---------------------------------------------------------
swapper/0/0 just changed the state of lock:
(((&hw->end_timer))){+.-...}, at: [] _call_timer_fn+0x0/0xfc
but this lock was taken by another, HARDIRQ-safe lock in the past:
(&(&priv->lock)->rlock#2){-.....}and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:CPU0 CPU1
---- ----
lock(((&hw->end_timer)));
local_irq_disable();
lock(&(&priv->lock)->rlock#2);
lock(((&hw->end_timer)));
lock(&(&priv->lock)->rlock#2);*** DEADLOCK ***
This is fixed by releasing the main spin lock while performing the
del_timer_sync() call. The timer is prevented from restarting before the
lock is reacquired by a new "stopping" flag which img_ir_handle_data()
checks before updating the timer.---------------------------------------------------------
swapper/0/0 just changed the state of lock:
(((&hw->end_timer))){+.-...}, at: [] _call_timer_fn+0x0/0xfc
but this lock was taken by another, HARDIRQ-safe lock in the past:
(&(&priv->lock)->rlock#2){-.....}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(((&hw->end_timer)));
local_irq_disable();
lock(&(&priv->lock)->rlock#2);
lock(((&hw->end_timer)));
lock(&(&priv->lock)->rlock#2);
*** DEADLOCK ***
This is fixed by releasing the main spin lock while performing the
del_timer_sync() call. The timer is prevented from restarting before the
lock is reacquired by a new "stopping" flag which img_ir_handle_data()
checks before updating the timer.Signed-off-by: James Hogan
Cc: Sifan Naeem
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit ea0de4ec5489da0fe738b274effac4f950e93d76 upstream.
A problem was found on Polaris where if the unit it booted via the power
button on the infrared remote then the next button press on the remote
would return the key code used to power on the unit.The sequence is:
- The polaris powered off but with the powerdown controller (PDC) block
still powered.
- Press power key on remote, IR block receives the key.
- Kernel starts, IR code is in IMG_IR_DATA_x but neither IMG_IR_RXDVAL
or IMG_IR_RXDVALD2 are set.
- Wait any amount of time.
- Press any key.
- IMG_IR_RXDVAL or IMG_IR_RXDVALD2 is set but IMG_IR_DATA_x is
unchanged since the powerup key data was never read.This is worked around by always reading the IMG_IR_DATA_x in
img_ir_set_decoder(), rather than only when the IMG_IR_RXDVAL or
IMG_IR_RXDVALD2 bit is set.Signed-off-by: Dylan Rajaratnam
Signed-off-by: James Hogan
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 2228d80dd05a4fc5a410fde847677b8fb3eb23d7 upstream.
We've got a bug report at disconnecting a Webcam, where the kernel
spews warnings like below:
WARNING: CPU: 0 PID: 8385 at ../fs/sysfs/group.c:219 sysfs_remove_group+0x87/0x90()
sysfs group c0b2350c not found for kobject 'event3'
CPU: 0 PID: 8385 Comm: queue2:src Not tainted 3.16.2-1.gdcee397-default #1
Hardware name: ASUSTeK Computer INC. A7N8X-E/A7N8X-E, BIOS ASUS A7N8X-E Deluxe ACPI BIOS Rev 1013 11/12/2004
c08d0705 ddc75cbc c0718c5b ddc75ccc c024b654 c08c6d44 ddc75ce8 000020c1
c08d0705 000000db c03d1ec7 c03d1ec7 00000009 00000000 c0b2350c d62c9064
ddc75cd4 c024b6a3 00000009 ddc75ccc c08c6d44 ddc75ce8 ddc75cfc c03d1ec7
Call Trace:
[] try_stack_unwind+0x156/0x170
[] dump_trace+0x53/0x180
[] show_trace_log_lvl+0x46/0x50
[] show_stack_log_lvl+0x51/0xe0
[] show_stack+0x27/0x50
[] dump_stack+0x3e/0x4e
[] warn_slowpath_common+0x84/0xa0
[] warn_slowpath_fmt+0x33/0x40
[] sysfs_remove_group+0x87/0x90
[] device_del+0x34/0x180
[] evdev_disconnect+0x19/0x50
[] __input_unregister_device+0x9a/0x140
[] input_unregister_device+0x45/0x80
[] uvc_delete+0x26/0x110 [uvcvideo]
[] v4l2_device_release+0x98/0xc0 [videodev]
[] device_release+0x2b/0x90
[] kobject_cleanup+0x6f/0x1a0
[] v4l2_release+0x43/0x70 [videodev]
[] __fput+0xb1/0x1b0
[] task_work_run+0x91/0xb0
[] do_exit+0x265/0x910
[] do_group_exit+0x34/0xa0
[] get_signal_to_deliver+0x17f/0x590
[] do_signal+0x3a/0x960
[] do_notify_resume+0x67/0x90
[] work_notifysig+0x30/0x3b
[] 0xb7739e5f
---[ end trace b1e56095a485b631 ]---The cause is that uvc_status_cleanup() is called after usb_put_*() in
uvc_delete(). usb_put_*() removes the sysfs parent and eventually
removes the children recursively, so the later device_del() can't find
its sysfs. The fix is simply rearrange the call orders in
uvc_delete() so that the child is removed before the parent.Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=897736
Reported-and-tested-by: Martin PluskalSigned-off-by: Takashi Iwai
Signed-off-by: Laurent Pinchart
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman
