28 Jan, 2015
40 commits
-
commit 5e7e6e0c9b47a45576c38b4a72d67927a5e049f7 upstream.
Recent Leaf firmware versions (>= 3.1.557) do not allow to send
commands for non-existing channels. If a command is sent for a
non-existing channel, the firmware crashes.Reported-by: Christopher Storah
Signed-off-by: Olivier Sobrie
Signed-off-by: Ahmed S. Darwish
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Greg Kroah-Hartman -
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 5138d5c562e3bfe30964e20ab46eec9f8b89225d upstream.
The gpio4 and gpio5 are in 0xf7fc0000 apb which is located in the SM domain.
This patch moves gpio4 and gpio5 to the correct location. This patch also
renames them as the following to match the names we internally used in
marvell:
gpio4 -> sm_gpio1
gpio5 -> sm_gpio0
porte -> portf
portf -> porteThis also matches what we did for BG2 and BG2CD's SM GPIO.
Fixes: cedf57fc4f2f ("ARM: dts: berlin: add the BG2Q GPIO nodes")
Signed-off-by: Jisheng Zhang
Signed-off-by: Sebastian Hesselbarth
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 1fc0703af3143914a389bfa081c7acb09502ed5d upstream.
Currently, our trunking code will check for session trunking, but will
fail to detect client id trunking. This is a problem, because it means
that the client will fail to recognise that the two connections represent
shared state, even if they do not permit a shared session.
By removing the check for the server minor id, and only checking the
major id, we will end up doing the right thing in both cases: we close
down the new nfs_client and fall back to using the existing one.Fixes: 05f4c350ee02e ("NFS: Discover NFSv4 server trunking when mounting")
Cc: Chuck Lever
Tested-by: Chuck Lever
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 7485058eea40783ac142a60c3e799fc66ce72583 upstream.
Using just the filter for checking for trampolines or regs is not enough
when updating the code against the records that represent all functions.
Both the filter hash and the notrace hash need to be checked.To trigger this bug (using trace-cmd and perf):
# perf probe -a do_fork
# trace-cmd start -B foo -e probe
# trace-cmd record -p function_graph -n do_fork sleep 1The trace-cmd record at the end clears the filter before it disables
function_graph tracing and then that causes the accounting of the
ftrace function records to become incorrect and causes ftrace to bug.Link: http://lkml.kernel.org/r/20150114154329.358378039@goodmis.org
[ still need to switch old_hash_ops to old_ops_hash ]
Reviewed-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt
Signed-off-by: Greg Kroah-Hartman -
commit 8f86f83709c585742dea5dd7f0d2b79c43f992ec upstream.
As the set_ftrace_filter affects both the function tracer as well as the
function graph tracer, the ops that represent each have a shared
ftrace_ops_hash structure. This allows both to be updated when the filter
files are updated.But if function graph is enabled and the global_ops (function tracing) ops
is not, then it is possible that the filter could be changed without the
update happening for the function graph ops. This will cause the changes
to not take place and may even cause a ftrace_bug to occur as it could mess
with the trampoline accounting.The solution is to check if the ops uses the shared global_ops filter and
if the ops itself is not enabled, to check if there's another ops that is
enabled and also shares the global_ops filter. In that case, the
modification still needs to be executed.Link: http://lkml.kernel.org/r/20150114154329.055980438@goodmis.org
Reviewed-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt
Signed-off-by: Greg Kroah-Hartman -
commit 237d28db036e411f22c03cfd5b0f6dc2aa9bf3bc upstream.
If the function graph tracer traces a jprobe callback, the system will
crash. This can easily be demonstrated by compiling the jprobe
sample module that is in the kernel tree, loading it and running the
function graph tracer.# modprobe jprobe_example.ko
# echo function_graph > /sys/kernel/debug/tracing/current_tracer
# lsThe first two commands end up in a nice crash after the first fork.
(do_fork has a jprobe attached to it, so "ls" just triggers that fork)The problem is caused by the jprobe_return() that all jprobe callbacks
must end with. The way jprobes works is that the function a jprobe
is attached to has a breakpoint placed at the start of it (or it uses
ftrace if fentry is supported). The breakpoint handler (or ftrace callback)
will copy the stack frame and change the ip address to return to the
jprobe handler instead of the function. The jprobe handler must end
with jprobe_return() which swaps the stack and does an int3 (breakpoint).
This breakpoint handler will then put back the saved stack frame,
simulate the instruction at the beginning of the function it added
a breakpoint to, and then continue on.For function tracing to work, it hijakes the return address from the
stack frame, and replaces it with a hook function that will trace
the end of the call. This hook function will restore the return
address of the function call.If the function tracer traces the jprobe handler, the hook function
for that handler will not be called, and its saved return address
will be used for the next function. This will result in a kernel crash.To solve this, pause function tracing before the jprobe handler is called
and unpause it before it returns back to the function it probed.Some other updates:
Used a variable "saved_sp" to hold kcb->jprobe_saved_sp. This makes the
code look a bit cleaner and easier to understand (various tries to fix
this bug required this change).Note, if fentry is being used, jprobes will change the ip address before
the function graph tracer runs and it will not be able to trace the
function that the jprobe is probing.Link: http://lkml.kernel.org/r/20150114154329.552437962@goodmis.org
Acked-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt
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
