| Age | Commit message (Collapse) | Author |
|---|
|
fixes-rc3
|
|
The 8th NAND partition should be named "NAND.u-boot-env.backup1"
instead of "NAND.u-boot-env". This is to be consistent with other
TI boards as well as u-boot.
CC: Pekon Gupta <pekon@pek-sem.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
The I2C3 pins are taken from pads E21 (GPIO6_14) and
F20 (GPIO6_15). Use the right pinmux register and mode.
Also set the I2C3 bus frequency to a safer 400KHz than
3.4Mhz.
CC: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
There is a following AB-BA dependency between cpu_hotplug.lock and
cpuidle_lock:
1) cpu_hotplug.lock -> cpuidle_lock
enable_nonboot_cpus()
_cpu_up()
cpu_hotplug_begin()
LOCK(cpu_hotplug.lock)
cpu_notify()
...
acpi_processor_hotplug()
cpuidle_pause_and_lock()
LOCK(cpuidle_lock)
2) cpuidle_lock -> cpu_hotplug.lock
acpi_os_execute_deferred() workqueue
...
acpi_processor_cst_has_changed()
cpuidle_pause_and_lock()
LOCK(cpuidle_lock)
get_online_cpus()
LOCK(cpu_hotplug.lock)
Fix this by reversing the order acpi_processor_cst_has_changed() does
thigs -- let it first execute the protection against CPU hotplug by
calling get_online_cpus() and obtain the cpuidle lock only after that (and
perform the symmentric change when allowing CPUs hotplug again and
dropping cpuidle lock).
Spotted by lockdep.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The _SUN device indentification object is not guaranteed to return
the same value every time it is executed, so we should not cache its
return value, but rather execute it every time as needed. If it is
cached, an incorrect stale value may be used in some situations.
This issue was exposed by commit 202317a573b2 (ACPI / scan: Add
acpi_device objects for all device nodes in the namespace). Fix it
by avoiding to cache the return value of _SUN.
Fixes: 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace)
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The current code just returns -EINVAL because mode can't be equal to
both 1 and 2.
Also this function is messy so I have cleaned it up:
1) Remove initializers like "int time = -1". Initializing variables to
garbage values turns off GCC's uninitialized variable warnings so it
can lead to bugs.
2) Use kstrtoint() instead of sscanf().
3) Use SCI_KBD_MODE_FNZ and SCI_KBD_MODE_AUTO instead of magic numbers 1
and 2.
4) Don't check for "mode == -1" because that can't happen.
5) Preserve the error code from toshiba_kbd_illum_status_set().
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs
Pull f2fs bug fixes from Jaegeuk Kim:
"This series includes patches to:
- fix recovery routines
- fix bugs related to inline_data/xattr
- fix when casting the dentry names
- handle EIO or ENOMEM correctly
- fix memory leak
- fix lock coverage"
* tag 'for-f2fs-3.17-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs: (28 commits)
f2fs: reposition unlock_new_inode to prevent accessing invalid inode
f2fs: fix wrong casting for dentry name
f2fs: simplify by using a literal
f2fs: truncate stale block for inline_data
f2fs: use macro for code readability
f2fs: introduce need_do_checkpoint for readability
f2fs: fix incorrect calculation with total/free inode num
f2fs: remove rename and use rename2
f2fs: skip if inline_data was converted already
f2fs: remove rewrite_node_page
f2fs: avoid double lock in truncate_blocks
f2fs: prevent checkpoint during roll-forward
f2fs: add WARN_ON in f2fs_bug_on
f2fs: handle EIO not to break fs consistency
f2fs: check s_dirty under cp_mutex
f2fs: unlock_page when node page is redirtied out
f2fs: introduce f2fs_cp_error for readability
f2fs: give a chance to mount again when encountering errors
f2fs: trigger release_dirty_inode in f2fs_put_super
f2fs: don't skip checkpoint if there is no dirty node pages
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
Pull key subsystem fixes from James Morris:
"Fixes for the keys subsystem, one of which addresses a use-after-free
bug"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
PEFILE: Relax the check on the length of the PKCS#7 cert
KEYS: Fix use-after-free in assoc_array_gc()
KEYS: Fix public_key asymmetric key subtype name
KEYS: Increase root_maxkeys and root_maxbytes sizes
|
|
Structure name and variable name were erroneously interchanged
Signed-off-by: Noam Camus <noamc@ezchip.com>
Acked-by: Vineet Gupta <vgupta@synopsys.com>
[ Also removed pointless cast from "void *". - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull more arm64 fixes from Will Deacon:
"Another handful of arm64 fixes here. They address some issues found
by running smatch on the arch code (ignoring the false positives) and
also stop 32-bit Android from losing track of its stack.
There's one additional irq migration fix in the pipeline, but it came
in after I'd tagged and tested this set.
- a few fixes for real issues found by smatch (after Dan's talk at KS)
- revert the /proc/cpuinfo changes merged during the merge window.
We've opened a can of worms here, so we need to find out where we
stand before we change this interface.
- implement KSTK_ESP for compat tasks, otherwise 32-bit Android gets
confused wondering where its [stack] has gone
- misc fixes (fpsimd context handling, crypto, ...)"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
Revert "arm64: cpuinfo: print info for all CPUs"
arm64: fix bug for reloading FPSIMD state after cpu power off
arm64: report correct stack pointer in KSTK_ESP for compat tasks
arm64: Add brackets around user_stack_pointer()
arm64: perf: don't rely on layout of pt_regs when grabbing sp or pc
arm64: ptrace: fix compat reg getter/setter return values
arm64: ptrace: fix compat hardware watchpoint reporting
arm64: Remove unused variable in head.S
arm64/crypto: remove redundant update of data
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI fix from Bjorn Helgaas:
"This fixes an ARM allmodconfig build problem:
Remove module option for ST Microelectronics SPEAr13xx"
* tag 'pci-v3.17-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
PCI: spear: Remove module option
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds
Pull LED fix from Bryan Wu:
"Hugh, Jiri and many other people found a kernel oops due to a LED
change merged recently. Now the right fix might just revert it and
avoid the kernel oops"
* 'leds-fixes-for-3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
Revert "leds: convert blink timer to workqueue"
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v3.17
A few more driver specific fixes on top of the currently pending fixes
(which are already in your tree but not Linus').
|
|
Thanks to Dan Carpenter for extending smatch to find bugs like this.
(This was found using a development version of smatch.)
Fixes: 36de928641ee48b2078d3fe9514242aaa2f92013
Reported-by: Dan Carpenter <dan.carpenter@oracle.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/urgent
Pull an RCU fix from Paul E. McKenney:
"This series contains a single commit fixing an initialization bug
reported by Amit Shah and fixed by Pranith Kumar (and tested by Amit).
This bug results in a boot-time hang in callback-offloaded configurations
where callbacks were posted before the offloading ('rcuo') kthreads
were created."
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
fc95ca7284bc54953165cba76c3228bd2cdb9591 introduces a memset in
kvmppc_alloc_hpt since the general CMA doesn't clear the memory it
allocates.
However, the size argument passed to memset is computed from a signed value
and its signed bit is extended by the cast the compiler is doing. This lead
to extremely large size value when dealing with order value >= 31, and
almost all the memory following the allocated space is cleaned. As a
consequence, the system is panicing and may even fail spawning the kdump
kernel.
This fix makes use of an unsigned value for the memset's size argument to
avoid sign extension. Among this fix, another shift operation which may
lead to signed extended value too is also fixed.
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Alexander Graf <agraf@suse.de>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
git://people.freedesktop.org/~thomash/linux into drm-fixes
Two vmwgfx fixes, marked for stable as well
* 'vmwgfx-fixes-3.17' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: Fix a potential infinite spin waiting for fifo idle
drm/vmwgfx: Fix an incorrect OOM return value
|
|
Relax the check on the length of the PKCS#7 cert as it appears that the PE
file wrapper size gets rounded up to the nearest 8.
The debugging output looks like this:
PEFILE: ==> verify_pefile_signature()
PEFILE: ==> pefile_parse_binary()
PEFILE: checksum @ 110
PEFILE: header size = 200
PEFILE: cert = 968 @547be0 [68 09 00 00 00 02 02 00 30 82 09 56 ]
PEFILE: sig wrapper = { 968, 200, 2 }
PEFILE: Signature data not PKCS#7
The wrapper is the first 8 bytes of the hex dump inside []. This indicates a
length of 0x968 bytes, including the wrapper header - so 0x960 bytes of
payload.
The ASN.1 wrapper begins [ ... 30 82 09 56 ]. That indicates an object of size
0x956 - a four byte discrepency, presumably just padding for alignment
purposes.
So we just check that the ASN.1 container is no bigger than the payload and
reduce the recorded size appropriately.
Whilst we're at it, allow shorter PKCS#7 objects that manage to squeeze within
127 or 255 bytes. It's just about conceivable if no X.509 certs are included
in the PKCS#7 message.
Reported-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Peter Jones <pjones@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
|
|
An edit script should be considered inaccessible by a function once it has
called assoc_array_apply_edit() or assoc_array_cancel_edit().
However, assoc_array_gc() is accessing the edit script just after the
gc_complete: label.
Reported-by: Andreea-Cristina Bernat <bernat.ada@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Andreea-Cristina Bernat <bernat.ada@gmail.com>
cc: shemming@brocade.com
cc: paulmck@linux.vnet.ibm.com
Cc: stable@vger.kernel.org
Signed-off-by: James Morris <james.l.morris@oracle.com>
|
|
The length of the name of an asymmetric key subtype must be stored in struct
asymmetric_key_subtype::name_len so that it can be matched by a search for
"<subkey_name>:<partial_fingerprint>". Fix the public_key subtype to have
name_len set.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
|
|
Now that NFS client uses the kernel key ring facility to store the NFSv4
id/gid mappings, the defaults for root_maxkeys and root_maxbytes need to be
substantially increased.
These values have been soak tested:
https://bugzilla.redhat.com/show_bug.cgi?id=1033708#c73
Signed-off-by: Steve Dickson <steved@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
|
|
It should have been removed with commit d1b6848590af
("cpufreq / intel_pstate: Optimize intel_pstate_set_policy")
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Many CPUs do not support complete set of RAPL domains, as a
result this detection failed message is very misleading and
can be annoying.
[ 5.082632] intel_rapl: RAPL domain core detection failed
[ 5.088370] intel_rapl: RAPL domain uncore detection failed
So lower the warning message to info and only print out the RAPL
domains that are supported.
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
I've confirmed that monitoring the package power usage as well as setting power
limits appear to be working as expected. Supports the package and dram domains.
Tested aginst cpu:
Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
Signed-off-by: Jason Baron <jbaron@akamai.com>
Acked-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
After commit d431cbc53cb7 (PM / sleep: Simplify sleep states sysfs
interface code) the pm_states[] array is not populated initially,
which causes setup_test_suspend() to always fail and the suspend
testing during boot doesn't work any more.
Fix the problem by using pm_labels[] instead of pm_states[] in
setup_test_suspend() and storing a pointer to the label of the
sleep state to test rather than the number representing it,
because the connection between the state numbers and labels is
only established by suspend_set_ops().
Fixes: d431cbc53cb7 (PM / sleep: Simplify sleep states sysfs interface code)
Reported-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
On the Toshiba Tecra Z40, after a suspend-to-disk, some FN hotkeys
driven by toshiba_acpi are not functional.
Calling the ACPI object ENAB on resume makes them back alive.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
|
'asoc/fix/da732x', 'asoc/fix/omap', 'asoc/fix/rsnd', 'asoc/fix/rt5640', 'asoc/fix/rt5677', 'asoc/fix/simple' and 'asoc/fix/tegra' into asoc-linus
|
|
|
|
This is a follow-up patch to commit 49458e83082d ("ideapad-laptop:
Constify DMI table and other r/o variables") to do what its commit
message says. The actual commit differs from the patch posted at
https://www.mail-archive.com/platform-driver-x86@vger.kernel.org/msg05340.html
significantly, probably due to a bad merge conflict resolution. Fix up
the mess and constify the DMI table for real and fix the bogus
double-const of ideapad_rfk_data[].
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Matthew Garrett <matthew.garrett@nebula.com>
Cc: Ike Panhc <ike.pan@canonical.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
|
During allocation and initialization of the network driver structures,
the wrong pointer is used to initialize a spin lock. Fix the spin lock
initialization by using the proper pointer.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The user_skb maybe be leaked if the operation on it failed and codes
skipped into the label "out:" without calling genlmsg_unicast.
Cc: Pravin Shelar <pshelar@nicira.com>
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
make defconfig reports:
warning: (NETFILTER_XT_TARGET_LOG) selects NF_LOG_IPV6 which has unmet direct dependencies (NET && INET && IPV6 && NETFILTER && NETFILTER_ADVANCED)
Fixes: d79a61d netfilter: NETFILTER_XT_TARGET_LOG selects NF_LOG_*
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Pablo Neira Ayuso says:
====================
pull request: Netfilter/IPVS fixes for net
The following patchset contains seven Netfilter fixes for your net
tree, they are:
1) Make the NAT infrastructure independent of x_tables, some users are
already starting to test nf_tables with NAT without enabling x_tables.
Without this patch for Kconfig, there's a superfluous dependency
between NAT and x_tables.
2) Allow to use 0 in the cgroup match, the kernel rejects with -EINVAL
with no good reason. From Daniel Borkmann.
3) Select CONFIG_NF_NAT from the nf_tables NAT expression, this also
resolves another NAT dependency with x_tables.
4) Use HAVE_JUMP_LABEL instead of CONFIG_JUMP_LABEL in the Netfilter hook
code as elsewhere in the kernel to resolve toolchain problems, from
Zhouyi Zhou.
5) Use iptunnel_handle_offloads() to set up tunnel encapsulation
depending on the offload capabilities, reported by Alex Gartrell
patch from Julian Anastasov.
6) Fix wrong family when registering the ip_vs_local_reply6() hook,
also from Julian.
7) Select the NF_LOG_* symbols from NETFILTER_XT_TARGET_LOG. Rafał
Miłecki reported that when jumping from 3.16 to 3.17-rc, his log
target is not selected anymore due to changes in the previous
development cycle to accomodate the full logging support for
nf_tables.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Some hosts can be both little and big endian.
In certain scenarios a big endian kernel can kexec a little endian kernel.
This patch fixes this case from both ends:
1) Return endianity to original values on shutdown (in case little endian kernel boots after we shutdown).
2) Do not rely on HW reset values when loading driver in little endian kernel
but configure them explicitly (in case previous kernel was big endian and did not reset the HW).
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: Ariel Elior <Ariel.Elior@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When qeth device is queried for ethtool data, hardware operation
is performed to extract the necessary information from the card.
If the card is not online at the moment (e.g. it is undergoing
recovery), this operation produces undesired effects like
temporarily freezing the system. This patch prevents execution
of the hardware query operation when the card is not online.
In such case, ioctl() operation returns error with errno ENODEV.
Reviewed-by: Ursula Braun <ursula.braun@de.ibm.com>
Signed-off-by: Eugene Crosser <Eugene.Crosser@ru.ibm.com>
Signed-off-by: Frank Blaschka <blaschka@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Calxeda 1G/10G XGMAC Ethernet support should be available only on
Calxeda ECX-1000/2000 (Highbank/Midway) platforms.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Renesas SuperH Ethernet support should be available only on
Renesas ARM SoCs and SuperH architecture.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Simon Horman <horms@verge.net.au>
Cc: Magnus Damm <magnus.damm@gmail.com>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When a link is already up, the following sequence makes the kernel
block completely:
ip link set dev eth0 down
ip link set dev eth0 up
This is because on suspended phy, the following lines
__lpc_eth_reset(pldat);
__lpc_eth_init(pldat);
make the LPC ethernet core block (see LPC32x0 manual). The PHY needs to be
(re-)activated low-level first.
Signed-off-by: Roland Stigge <stigge@antcom.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The patch fixes race conditions between PCI error recovery callbacks and
potential ifup/ifdown.
First, if ifup (tg3_open) is called between tg3_io_error_detected() and
tg3_io_resume() then tp->timer is armed twice before expiry. Once during
tg3_open() and again during tg3_io_resume(). This results in BUG
at kernel/time/timer.c:945.
Second, if ifdown (tg3_close) is called between tg3_io_error_detected()
and tg3_io_resume() then tg3_napi_disable() is called twice without
a tg3_napi_enable between. Once during tg3_io_error_detected() and again
during tg3_close(). The tg3_io_resume() then hangs on rtnl_lock().
v2: Added logging messages per Prashant's request
Cc: Prashant Sreedharan <prashant@broadcom.com>
Cc: Michael Chan <mchan@broadcom.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Acked-by: Prashant Sreedharan <prashant@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
We ran into a case on ppc64 running mariadb where io_getevents would
return zeroed out I/O events. After adding instrumentation, it became
clear that there was some missing synchronization between reading the
tail pointer and the events themselves. This small patch fixes the
problem in testing.
Thanks to Zach for helping to look into this, and suggesting the fix.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Cc: stable@vger.kernel.org
|
|
Analogous to commit 8858d88a25142544843869f0cd3e6654aa7b4aec
that fixed commit 70b41abc151f9
"ARM: ux500: move MSP pin control to the device tree"
accidentally activated MSP2, giving rise to a boot scroll
scream as the kernel attempts to probe a driver for it and
fails to obtain DMA channel 14.
For some reason I forgot to fix this on the Snowball. Fix
this up by marking the node disabled again.
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Kevin Hilman <khilman@linaro.org>
|
|
This reverts commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758.
It's broken as it changes led_blink_set() in a way that it can now sleep
(while synchronously waiting for workqueue to be cancelled). That's a
problem, because it's possible that this function gets called from atomic
context (tpt_trig_timer() takes a readlock and thus disables preemption).
This has been brought up 3 weeks ago already [1] but no proper fix has
materialized, and I keep seeing the problem since 3.17-rc1.
[1] https://lkml.org/lkml/2014/8/16/128
BUG: sleeping function called from invalid context at kernel/workqueue.c:2650
in_atomic(): 1, irqs_disabled(): 0, pid: 2335, name: wpa_supplicant
5 locks held by wpa_supplicant/2335:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c7c92>] rtnl_lock+0x12/0x20
#1: (&wdev->mtx){+.+.+.}, at: [<ffffffffc06e649c>] cfg80211_mgd_wext_siwessid+0x5c/0x180 [cfg80211]
#2: (&local->mtx){+.+.+.}, at: [<ffffffffc0817dea>] ieee80211_prep_connection+0x17a/0x9a0 [mac80211]
#3: (&local->chanctx_mtx){+.+.+.}, at: [<ffffffffc08081ed>] ieee80211_vif_use_channel+0x5d/0x2a0 [mac80211]
#4: (&trig->leddev_list_lock){.+.+..}, at: [<ffffffffc081e68c>] tpt_trig_timer+0xec/0x170 [mac80211]
CPU: 0 PID: 2335 Comm: wpa_supplicant Not tainted 3.17.0-rc3 #1
Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008
ffff8800360b5a50 ffff8800751f76d8 ffffffff8159e97f ffff8800360b5a30
ffff8800751f76e8 ffffffff810739a5 ffff8800751f77b0 ffffffff8106862f
ffffffff810685d0 0aa2209200000000 ffff880000000004 ffff8800361c59d0
Call Trace:
[<ffffffff8159e97f>] dump_stack+0x4d/0x66
[<ffffffff810739a5>] __might_sleep+0xe5/0x120
[<ffffffff8106862f>] flush_work+0x5f/0x270
[<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80
[<ffffffff810945ca>] ? mark_held_locks+0x6a/0x90
[<ffffffff81068a5f>] ? __cancel_work_timer+0x6f/0x100
[<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100
[<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10
[<ffffffff8147cf3b>] led_blink_set+0x1b/0x40
[<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211]
[<ffffffffc081ecdd>] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211]
[<ffffffffc07e4278>] __ieee80211_recalc_idle+0x98/0x140 [mac80211]
[<ffffffffc07e59ce>] ieee80211_idle_off+0xe/0x10 [mac80211]
[<ffffffffc0804e5b>] ieee80211_add_chanctx+0x3b/0x220 [mac80211]
[<ffffffffc08062e4>] ieee80211_new_chanctx+0x44/0xf0 [mac80211]
[<ffffffffc080838a>] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211]
[<ffffffffc0817df8>] ieee80211_prep_connection+0x188/0x9a0 [mac80211]
[<ffffffffc081c246>] ieee80211_mgd_auth+0x256/0x2e0 [mac80211]
[<ffffffffc07eab33>] ieee80211_auth+0x13/0x20 [mac80211]
[<ffffffffc06cb006>] cfg80211_mlme_auth+0x106/0x270 [cfg80211]
[<ffffffffc06ce085>] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211]
[<ffffffffc06cf670>] cfg80211_connect+0x3f0/0x540 [cfg80211]
[<ffffffffc06e6148>] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211]
[<ffffffffc06e651e>] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211]
[<ffffffffc06e36c0>] ? cfg80211_wext_giwessid+0x50/0x50 [cfg80211]
[<ffffffffc06e36dd>] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211]
[<ffffffff81584d0c>] ioctl_standard_iw_point+0x14c/0x3e0
[<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[<ffffffff8158502a>] ioctl_standard_call+0x8a/0xd0
[<ffffffff81584fa0>] ? ioctl_standard_iw_point+0x3e0/0x3e0
[<ffffffff81584b76>] wireless_process_ioctl.constprop.10+0xb6/0x100
[<ffffffff8158521d>] wext_handle_ioctl+0x5d/0xb0
[<ffffffff814cfb29>] dev_ioctl+0x329/0x620
[<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[<ffffffff8149c7f2>] sock_ioctl+0x142/0x2e0
[<ffffffff811b0140>] do_vfs_ioctl+0x300/0x520
[<ffffffff815a67fb>] ? sysret_check+0x1b/0x56
[<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[<ffffffff811b03e1>] SyS_ioctl+0x81/0xa0
[<ffffffff815a67d6>] system_call_fastpath+0x1a/0x1f
wlan0: send auth to 00:0b:6b:3c:8c:e4 (try 1/3)
wlan0: authenticated
wlan0: associate with 00:0b:6b:3c:8c:e4 (try 1/3)
wlan0: RX AssocResp from 00:0b:6b:3c:8c:e4 (capab=0x431 status=0 aid=2)
wlan0: associated
IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
cfg80211: Calling CRDA for country: NA
wlan0: Limiting TX power to 27 (27 - 0) dBm as advertised by 00:0b:6b:3c:8c:e4
=================================
[ INFO: inconsistent lock state ]
3.17.0-rc3 #1 Not tainted
---------------------------------
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
((&(&led_cdev->blink_work)->work)){+.?...}, at: [<ffffffff810685d0>] flush_work+0x0/0x270
{SOFTIRQ-ON-W} state was registered at:
[<ffffffff81094dbe>] __lock_acquire+0x30e/0x1a30
[<ffffffff81096c81>] lock_acquire+0x91/0x110
[<ffffffff81068608>] flush_work+0x38/0x270
[<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100
[<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10
[<ffffffff8147cf3b>] led_blink_set+0x1b/0x40
[<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211]
[<ffffffffc081ecdd>] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211]
[<ffffffffc07e4278>] __ieee80211_recalc_idle+0x98/0x140 [mac80211]
[<ffffffffc07e59ce>] ieee80211_idle_off+0xe/0x10 [mac80211]
[<ffffffffc0804e5b>] ieee80211_add_chanctx+0x3b/0x220 [mac80211]
[<ffffffffc08062e4>] ieee80211_new_chanctx+0x44/0xf0 [mac80211]
[<ffffffffc080838a>] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211]
[<ffffffffc0817df8>] ieee80211_prep_connection+0x188/0x9a0 [mac80211]
[<ffffffffc081c246>] ieee80211_mgd_auth+0x256/0x2e0 [mac80211]
[<ffffffffc07eab33>] ieee80211_auth+0x13/0x20 [mac80211]
[<ffffffffc06cb006>] cfg80211_mlme_auth+0x106/0x270 [cfg80211]
[<ffffffffc06ce085>] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211]
[<ffffffffc06cf670>] cfg80211_connect+0x3f0/0x540 [cfg80211]
[<ffffffffc06e6148>] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211]
[<ffffffffc06e651e>] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211]
[<ffffffffc06e36dd>] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211]
[<ffffffff81584d0c>] ioctl_standard_iw_point+0x14c/0x3e0
[<ffffffff8158502a>] ioctl_standard_call+0x8a/0xd0
[<ffffffff81584b76>] wireless_process_ioctl.constprop.10+0xb6/0x100
[<ffffffff8158521d>] wext_handle_ioctl+0x5d/0xb0
[<ffffffff814cfb29>] dev_ioctl+0x329/0x620
[<ffffffff8149c7f2>] sock_ioctl+0x142/0x2e0
[<ffffffff811b0140>] do_vfs_ioctl+0x300/0x520
[<ffffffff811b03e1>] SyS_ioctl+0x81/0xa0
[<ffffffff815a67d6>] system_call_fastpath+0x1a/0x1f
irq event stamp: 493416
hardirqs last enabled at (493416): [<ffffffff81068a5f>] __cancel_work_timer+0x6f/0x100
hardirqs last disabled at (493415): [<ffffffff81067e9f>] try_to_grab_pending+0x1f/0x160
softirqs last enabled at (493408): [<ffffffff81053ced>] _local_bh_enable+0x1d/0x50
softirqs last disabled at (493409): [<ffffffff81054c75>] irq_exit+0xa5/0xb0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock((&(&led_cdev->blink_work)->work));
<Interrupt>
lock((&(&led_cdev->blink_work)->work));
*** DEADLOCK ***
2 locks held by swapper/0/0:
#0: (((&tpt_trig->timer))){+.-...}, at: [<ffffffff810b4c50>] call_timer_fn+0x0/0x180
#1: (&trig->leddev_list_lock){.+.?..}, at: [<ffffffffc081e68c>] tpt_trig_timer+0xec/0x170 [mac80211]
stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-rc3 #1
Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008
ffffffff8246eb30 ffff88007c203b00 ffffffff8159e97f ffffffff81a194c0
ffff88007c203b50 ffffffff81599c29 0000000000000001 ffffffff00000001
ffff880000000000 0000000000000006 ffffffff81a194c0 ffffffff81093ad0
Call Trace:
<IRQ> [<ffffffff8159e97f>] dump_stack+0x4d/0x66
[<ffffffff81599c29>] print_usage_bug+0x1f4/0x205
[<ffffffff81093ad0>] ? check_usage_backwards+0x140/0x140
[<ffffffff810944d3>] mark_lock+0x223/0x2b0
[<ffffffff81094d60>] __lock_acquire+0x2b0/0x1a30
[<ffffffff81096c81>] lock_acquire+0x91/0x110
[<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80
[<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211]
[<ffffffff81068608>] flush_work+0x38/0x270
[<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80
[<ffffffff810945ca>] ? mark_held_locks+0x6a/0x90
[<ffffffff81068a5f>] ? __cancel_work_timer+0x6f/0x100
[<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211]
[<ffffffff8109469d>] ? trace_hardirqs_on_caller+0xad/0x1c0
[<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211]
[<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100
[<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10
[<ffffffff8147cf3b>] led_blink_set+0x1b/0x40
[<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211]
[<ffffffff810b4cc5>] call_timer_fn+0x75/0x180
[<ffffffff810b4c50>] ? process_timeout+0x10/0x10
[<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211]
[<ffffffff810b50ac>] run_timer_softirq+0x1fc/0x2f0
[<ffffffff81054805>] __do_softirq+0x115/0x2e0
[<ffffffff81054c75>] irq_exit+0xa5/0xb0
[<ffffffff810049b3>] do_IRQ+0x53/0xf0
[<ffffffff815a74af>] common_interrupt+0x6f/0x6f
<EOI> [<ffffffff8147b56e>] ? cpuidle_enter_state+0x6e/0x180
[<ffffffff8147b732>] cpuidle_enter+0x12/0x20
[<ffffffff8108bba0>] cpu_startup_entry+0x330/0x360
[<ffffffff8158fb51>] rest_init+0xc1/0xd0
[<ffffffff8158fa90>] ? csum_partial_copy_generic+0x170/0x170
[<ffffffff81af3ff2>] start_kernel+0x44f/0x45a
[<ffffffff81af399c>] ? set_init_arg+0x53/0x53
[<ffffffff81af35ad>] x86_64_start_reservations+0x2a/0x2c
[<ffffffff81af36a0>] x86_64_start_kernel+0xf1/0xf4
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
|
The driver was not bound checking the received length byte to ensure it was within the
the buffer size that is allocated for SMBus blocks. This resulted in buffer overflows
whenever an invalid length byte was received.
It also failed to ensure the length byte was not zero. If it received zero, it would end up
in an infinite loop as the at91_twi_read_next_byte function returned immediately without
allowing RHR to be read to clear the RXRDY interrupt.
Tested agaisnt a SMBus compliant battery.
Signed-off-by: Marek Roszko <mark.roszko@gmail.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
|
|
In rk3x SOC, the I2C controller can receive/transmit up to 32 bytes data
in one chunk, so the size of data to be write/read to/from TXDATAx/RXDATAx
must be less than or equal 32 bytes at a time.
Tested on rk3288-pinky board, elan receive 158 bytes data.
Signed-off-by: Addy Ke <addy.ke@rock-chips.com>
Acked-by: Max Schwarz <max.schwarz@online.de>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
|
|
There is a race condition in at91_do_twi_xfer when signals arrive.
If a signal is recieved while waiting for a transfer to complete
wait_for_completion_interruptible_timeout() will return -ERESTARTSYS.
This is not handled correctly resulting in interrupts still being
enabled and a transfer being in flight when we return.
Symptoms include a range of oopses and bus lockups. Oopses can happen
when the transfer completes because the interrupt handler will corrupt
the stack. If a new transfer is started before the interrupt fires
the controller will start a new transfer in the middle of the old one,
resulting in confused slaves and a locked bus.
To avoid this, use wait_for_completion_io_timeout instead so that we
don't have to deal with gracefully shutting down the transfer and
disabling the interrupts.
Signed-off-by: Simon Lindgren <simon@aqwary.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
|
|
The "clock-frequency" DT property is listed as optional, However,
the current code stores the return value of of_property_read_u32 in
the return code of mv64xxx_of_config, but then forgets to clear it
after setting the default value of "clock-frequency". It is then
passed out to the main probe function, resulting in a probe failure
when "clock-frequency" is missing.
This patch checks and then throws away the return value of
of_property_read_u32, instead of storing it and having to clear it
afterwards.
This issue was discovered after the property was removed from all
sunxi DTs.
Fixes: 4c730a06c19bb ("i2c: mv64xxx: Set bus frequency to 100kHz if clock-frequency is not provided")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Cc: stable@vger.kernel.org
Acked-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
Sometimes the MNR and MST interrupts happen simultaneously (stop automatically
follows NACK, according to the manuals) and in such case the ID_NACK flag isn't
set since the MST interrupt handling precedes MNR and all interrupts are cleared
and disabled then, so that MNR interrupt is never noticed -- this causes NACK'ed
transfers to be falsely reported as successful. Exchanging MNR and MST handlers
fixes this issue, however the MNR bit somehow gets set again even after being
explicitly cleared, so I decided to completely suppress handling of all disabled
interrupts (which is a good thing anyway)...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: stable@vger.kernel.org
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
|
When intel_tv_detect() fails to do load detection it would forget to
drop the locks and clean up the acquire context. Fix it up.
This is a regression from:
commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Aug 11 13:15:35 2014 +0300
drm/i915: Fix locking for intel_enable_pipe_a()
v2: Make the code more readable (Chris)
v3: Drop WARN_ON(type < 0) (Chris)
Cc: stable@vger.kernel.org
Cc: Tibor Billes <tbilles@gmx.com>
Reported-by: Tibor Billes <tbilles@gmx.com>
Tested-by: Tibor Billes <tbilles@gmx.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-master
|
