28 Jan, 2015
40 commits
-
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 -
commit 0145058c3d30b4319d747f64caa16a9cb15f0581 upstream.
This patch partially reverts commit 421520ba98290a73b35b7644e877a48f18e06004
(only the arm64 part). There is no guarantee that the boot-loader places other
images like dtb in a different page than initrd start/end, especially when the
kernel is built with 64KB pages. When this happens, such pages must not be
freed. The free_reserved_area() already takes care of rounding up "start" and
rounding down "end" to avoid freeing partially used pages.Reported-by: Peter Maydell
Signed-off-by: Catalin Marinas
Signed-off-by: Will Deacon
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 bfe5fda8e7ced129716f5741cf7ed2592a338824 upstream.
Patch c49f63530bb6 ("powernv: Add OPAL tracepoints") has a spurious
store to the stack:ld r12,opal_tracepoint_refcount@toc(r2); \
std r12,32(r1); \The store was originally used to save the current tracepoint status
so the entry and the exit tracepoints were always balanced. In the
end I just created a separate path when tracepoints are enabled.The offset on the stack used for this store is not valid for ABIv2
and it causes strange issues. I noticed it because OPAL console input
was broken.Fixes: c49f63530bb6 ("powernv: Add OPAL tracepoints")
Signed-off-by: Anton Blanchard
Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman -
commit 52d304eb4eaced9ad04b64ba7cd6ceb5153bbf18 upstream.
commit 0efaa7e82f02fe69c05ad28e905f31fc86e6f08e
locks: generic_delete_lease doesn't need a file_lock at allmoves the call to fl->fl_lmops->lm_change() to a place in the
code where fl might be a non-lease lock.
When that happens, fl_lmops is NULL and an Oops ensures.So add an extra test to restore correct functioning.
Reported-by: Linda Walsh
Link: https://bugzilla.suse.com/show_bug.cgi?id=912569
Fixes: 0efaa7e82f02fe69c05ad28e905f31fc86e6f08e
Signed-off-by: NeilBrown
Signed-off-by: Jeff Layton
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 -
commit 678fa12fb8e75c6dc1e781a02e3ddbbba7e1a904 upstream.
The au0828 quirks table is currently not in sync with the au0828
media driver.Syncronize it and put them on the same order as found at au0828
driver, as all the au0828 devices with analog TV need the
same quirks.Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman
