We should be passing the pointer itself instead of the address of the
pointer.
This was a copy and paste bug when we replaced the calls to
hci_send_cmd(). Originally, the arguments were "len, cp" but we
overwrote them with "sizeof(cp), &cp" by mistake.
Fixes: b3d3914006 ('Bluetooth: Move amp assoc read/write completed callback to amp.c')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Definitions from linux/platform_data/atmel.h are not used, remove the
include.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Linus reports the following deadlock on rtnl_mutex; triggered only
once so far (extract):
[12236.694209] NetworkManager D 0000000000013b80 0 1047 1 0x00000000
[12236.694218] ffff88003f902640 0000000000000000 ffffffff815d15a9 0000000000000018
[12236.694224] ffff880119538000 ffff88003f902640 ffffffff81a8ff84 00000000ffffffff
[12236.694230] ffffffff81a8ff88 ffff880119c47f00 ffffffff815d133a ffffffff81a8ff80
[12236.694235] Call Trace:
[12236.694250] [<ffffffff815d15a9>] ? schedule_preempt_disabled+0x9/0x10
[12236.694257] [<ffffffff815d133a>] ? schedule+0x2a/0x70
[12236.694263] [<ffffffff815d15a9>] ? schedule_preempt_disabled+0x9/0x10
[12236.694271] [<ffffffff815d2c3f>] ? __mutex_lock_slowpath+0x7f/0xf0
[12236.694280] [<ffffffff815d2cc6>] ? mutex_lock+0x16/0x30
[12236.694291] [<ffffffff814f1f90>] ? rtnetlink_rcv+0x10/0x30
[12236.694299] [<ffffffff8150ce3b>] ? netlink_unicast+0xfb/0x180
[12236.694309] [<ffffffff814f5ad3>] ? rtnl_getlink+0x113/0x190
[12236.694319] [<ffffffff814f202a>] ? rtnetlink_rcv_msg+0x7a/0x210
[12236.694331] [<ffffffff8124565c>] ? sock_has_perm+0x5c/0x70
[12236.694339] [<ffffffff814f1fb0>] ? rtnetlink_rcv+0x30/0x30
[12236.694346] [<ffffffff8150d62c>] ? netlink_rcv_skb+0x9c/0xc0
[12236.694354] [<ffffffff814f1f9f>] ? rtnetlink_rcv+0x1f/0x30
[12236.694360] [<ffffffff8150ce3b>] ? netlink_unicast+0xfb/0x180
[12236.694367] [<ffffffff8150d344>] ? netlink_sendmsg+0x484/0x5d0
[12236.694376] [<ffffffff810a236f>] ? __wake_up+0x2f/0x50
[12236.694387] [<ffffffff814cad23>] ? sock_sendmsg+0x33/0x40
[12236.694396] [<ffffffff814cb05e>] ? ___sys_sendmsg+0x22e/0x240
[12236.694405] [<ffffffff814cab75>] ? ___sys_recvmsg+0x135/0x1a0
[12236.694415] [<ffffffff811a9d12>] ? eventfd_write+0x82/0x210
[12236.694423] [<ffffffff811a0f9e>] ? fsnotify+0x32e/0x4c0
[12236.694429] [<ffffffff8108cb70>] ? wake_up_q+0x60/0x60
[12236.694434] [<ffffffff814cba09>] ? __sys_sendmsg+0x39/0x70
[12236.694440] [<ffffffff815d4797>] ? entry_SYSCALL_64_fastpath+0x12/0x6a
It seems so far plausible that the recursive call into rtnetlink_rcv()
looks suspicious. One way, where this could trigger is that the senders
NETLINK_CB(skb).portid was wrongly 0 (which is rtnetlink socket), so
the rtnl_getlink() request's answer would be sent to the kernel instead
to the actual user process, thus grabbing rtnl_mutex() twice.
One theory would be that netlink_autobind() triggered via netlink_sendmsg()
internally overwrites the -EBUSY error to 0, but where it is wrongly
originating from __netlink_insert() instead. That would reset the
socket's portid to 0, which is then filled into NETLINK_CB(skb).portid
later on. As commit d470e3b483 ("[NETLINK]: Fix two socket hashing bugs.")
also puts it, -EBUSY should not be propagated from netlink_insert().
It looks like it's very unlikely to reproduce. We need to trigger the
rhashtable_insert_rehash() handler under a situation where rehashing
currently occurs (one /rare/ way would be to hit ht->elasticity limits
while not filled enough to expand the hashtable, but that would rather
require a specifically crafted bind() sequence with knowledge about
destination slots, seems unlikely). It probably makes sense to guard
__netlink_insert() in any case and remap that error. It was suggested
that EOVERFLOW might be better than an already overloaded ENOMEM.
Reference: http://thread.gmane.org/gmane.linux.network/372676
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
The commit "e29aa33 bna: Enable Multi Buffer RX" moved packets counter
increment from the beginning of the NAPI processing loop after the check
for erroneous packets so they are never accounted. This counter is used
to inform firmware about number of processed completions (packets).
As these packets are never acked the firmware fires IRQs for them again
and again.
Fixes: e29aa33 ("bna: Enable Multi Buffer RX")
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Acked-by: Rasesh Mody <rasesh.mody@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Marcin Wojtas says:
====================
Fixes for the network driver of Marvell Armada 375 SoC
This is a set of three patches that fix long-lasting problems implemented in
the initial support for the Armada 375 network controller.
Due to an inappropriate concept of handling the per-CPU sent packets'
processing on TX path the driver numerous problems occured, such as RCU
stalls. Those have been fixed, of which details you can find in the commit
logs. The patches were intensively tested on top of v4.2-rc5.
I'm looking forward to any comments or remarks.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The PP2 controller is capable of per-CPU TX processing, which means there are
per-CPU banked register sets and queues. Current version of the driver supports
TX packet coalescing - once on given CPU sent packets amount reaches a threshold
value, an IRQ occurs. However, there is a single interrupt line responsible for
CPU0/1 TX and RX events (the latter is not per-CPU, the hardware does not
support RSS).
When the top-half executes the interrupt cause is not known. This is why in
NAPI poll function, along with RX processing, IRQ cause register on both
CPU's is accessed in order to determine on which of them the TX coalescing
threshold might have been reached. Thus the egress processing and releasing the
buffers is able to take place on the corresponding CPU. Hitherto approach lead
to an illegal usage of on_each_cpu function in softirq context.
The problem is solved by resigning from TX coalescing interrupts and separating
egress finalization from NAPI processing. For that purpose a method of using
hrtimer is introduced. In main transmit function (mvpp2_tx) buffers are released
once a software coalescing threshold is reached. In case not all the data is
processed a timer is set on this CPU - in its interrupt context a tasklet is
scheduled in which all queues are processed. At once only one timer per-CPU can
be running, which is controlled by a dedicated flag.
This commit removes TX processing from NAPI polling function, disables hardware
coalescing and enables hrtimer with tasklet, using new per-CPU port structure
(mvpp2_port_pcpu).
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
mvpp2 driver allows usage of per-CPU TX processing. Once the packets are
prepared independetly on each CPU, the hardware enqueues the descriptors in
common TX queue. After they are sent, the buffers and associated sk_buffs
should be released on the corresponding CPU.
This is why a special index is maintained in order to point to the right data to
be released after transmission takes place. Each per-CPU TX queue comprise an
array of sent sk_buffs, freed in mvpp2_txq_bufs_free function. However, the
index was used there also for obtaining a descriptor (and therefore a buffer to
be DMA-unmapped) from common TX queue, which was wrong, because it was not
referring to the current CPU.
This commit enables proper unmapping of sent data buffers by indexing them in
per-CPU queues using a dedicated array for keeping their physical addresses.
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Using spinlocks protection during one-time driver initialization is not
necessary. Moreover it resulted in invalid GFP_KERNEL allocation under the lock.
This commit removes redundant spinlocks from buffer manager part of mvpp2
initialization.
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reported-by: Alexandre Fournier <alexandre.fournier@wisp-e.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- Fix runtime PM issues on Arizona
- Fix IRQ/Suspend race on Arizona
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVyMu3AAoJEFGvii+H/Hdhvp4QAIBWKyet/MbWQY5rptvKZmTV
zQeTjQb6Qyr/hUJQ1Ptedu/Df5eX8L4HVVLuQDTTMjVMd+4KSAD18PdqrjMsQ7U3
fTfkYs4w4o71aSg3yKVQ8Y+OekwmumVPWOTlb2PSFwEciEhBS1Fgl0BIOWy3Or3g
rEG19B0/rlL2CE448C9ENqtUcEmt4MylyyoDFUz/27zLY74Jw7trHpXBY9d1tXhG
BJD9qQNDdO1o5zBvvVQ8ETr+QK60GahayuwhXtnbJbvL46wGrxhOALwS9UtyhF/w
XgEvZkX7Ns6uZrZkLhz251GNPxqE7CEe2HZ2x8EUj8TxbIXA/QbNm4sid6xe74IQ
YGRTrVql5By+LYemEqrOIw2T4i+7HI7hOf+LI6kVWvn49/zr6v7Vk2deSZ+aIcEs
9rUTa7upIoLA5msDgk1SILdxKjStkgbz/BDUdAH8hbIJe8hzk29Kr2A9/D1QwIif
k41+KWDaobUFiKLUQUavPdGTVus05kolsmgikmlg7lB3WSB496uhsQ9DxddH7Vqo
WoJ4BHXn4O++uSAuGe8MQGBYviK32pEpSc5k+U1dauIqNmrRy1W7Tt5DsKtNNWDn
F64KVNNLfbEhHp9Tgnd+7axvhuNpll6FaSGEvFC+TsA4Xdvk692k5HmDA2L4/Dyx
OCHLOve/vkNqPi8mmD5K
=/Rnq
-----END PGP SIGNATURE-----
Merge tag 'mfd-fixes-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD fixes from Lee Jones:
- fix dependency issues on ChromeOS platforms
- fix runtime PM issues on Arizona
- fix IRQ/suspend race on Arizona
* tag 'mfd-fixes-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd:
mfd: Remove MFD_CROS_EC_SPI depends on OF
platform/chrome: Don't make CHROME_PLATFORMS depends on X86 || ARM
mfd: arizona: Fix initialisation of the PM runtime
mfd: arizona: Fix race between runtime suspend and IRQs
negotiation issues, and string formatting.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJVx78FAAoJEG5mS6x6i9IjczkP/2kVMQUdGTOCbxX7tqDUO4Fc
nL2oa6uyUTv7/YaEIG2qdk3XTJB7xQI75LROySjMrG1hxMpR7HRz4pvskB3AB3SJ
AyyX5SoD067YyZ7CX85S0LYN+vGo7eimdzbDMm1lZn9184cuKPxvkZr2sVgwEP0c
AqtiZwHySmUIJ/twfG3W3Mb1Xx2b5Y9F26h94ewDe5kXsVxWF1+ROS6iTF4hK5PT
WE/x7Y0Db0Dq4xEFZ1crzUSsln7qY+u2bUzujPZbpPrs4dR81PK48EGJtag9fLa1
kuyXSE2vZEOIgAchS3P1JkN5Fj3mJNZkPcchWdkCqxzr4TqC4dydE/P1Etp7ZAT/
7L8xIlHdl4EBClmqdFnoOlA2EgaLwbwOyKny1vDPO+s4WoLjy7KrgsttEDRfRe0I
d2yJZyqQohXWUoW9bgoyHRy4c6r0i4heOq4ImSggHCFqdp5yhKzXR7xUQxvcPakh
Bqu/7wfpEov9R2gOej/pt5j2ogE1cahpv9jhHgxvxKSHyXLvwkE/xW3eGARP4diK
nuybsHXeA5KaFHfcKfnJXiGVNTXNeDgqx2Ia3t9+DC4EnnKQKC6UVVUq8VsV/IXe
LCudolCza1PKNFAuXEWO10UPJeHLe+97eojXcdOFy/qPkiIz6YPt+bE73nBDit8w
4EUQYPAxWjZqCf+bfLSb
=zMAG
-----END PGP SIGNATURE-----
Merge tag 'ntb-4.2-rc7' of git://github.com/jonmason/ntb
Pull NTB bugfixes from Jon Mason:
"NTB bug fixes to address transport receive issues, stats, link
negotiation issues, and string formatting"
* tag 'ntb-4.2-rc7' of git://github.com/jonmason/ntb:
ntb: avoid format string in dev_set_name
NTB: Fix dereference before check
NTB: Fix zero size or integer overflow in ntb_set_mw
NTB: Schedule to receive on QP link up
NTB: Fix oops in debugfs when transport is half-up
NTB: ntb_netdev not covering all receive errors
NTB: Fix transport stats for multiple devices
NTB: Fix ntb_transport out-of-order RX update
Pull RCU pathwalk fix from Al Viro:
"Another racy use of nd->path.dentry in RCU mode"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
may_follow_link() should use nd->inode
Fix kernel-doc warning in libata-core.c:
Warning(..//drivers/ata/libata-core.c:4763): No description found for parameter 'tag'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
CTR hardware implementation does not match with kernel spec causing a counter bug
where just low 8 bytes are used for counter, when should be all 16bytes.
Since we already have other counter modes working according with specs
not worth to keep CTR itself on NX.
Signed-off-by: Leonidas S. Barbosa <leosilva@linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Marcelo and Fin are no long IBMers, thus no longer NX maintainers.
Updating with the new names.
Adding VMX crypto maintainers.
Signed-off-by: Leonidas S. Barbosa <leosilva@linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The PCI capabilities list for Intel DH895xCC VFs (device id 0x0443) with
QuickAssist Technology is prematurely terminated in hardware.
Workaround the issue by hard-coding the known expected next capability
pointer and saving the PCIE cap into internal buffer.
Patch generated against cryptodev-2.6
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Some VF drivers need FW const table, so the PF driver needs to load it.
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Add code specific for the dh895xcc virtual function.
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Add code that enables SRIOV on dh895xcc devices.
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Adf admin and HW arbiter function can be used by dh895xcc specific code
well as the new dh895xccvf and future devices so moving them to
qat_common so that they can be shared.
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The HTML output works a little nicer that way.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The probe error path for this driver, for all intents and purposes,
is the talitos_remove() function due to the common "goto err_out".
Without this patch applied, talitos_remove() will panic under these
two conditions:
1. If the RNG device hasn't been registered via
talitos_register_rng() prior to entry into talitos_remove(),
then the attempt to unregister the RNG "device" will cause a panic.
2. If the priv->chan array has not been allocated prior to entry
into talitos_remove(), then the per-channel FIFO cleanup will panic
because of the dereference of that NULL "array".
Both of the above scenarios occur if talitos_probe_irq() fails.
This patch resolves issue #1 by introducing a boolean to mask the
hwrng_unregister() call in talitos_unregister_rng() if RNG device
registration was unsuccessful.
It resolves issue #2 by checking that priv->chan is not NULL in the
per-channel FIFO cleanup for loop.
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Register only algorithms supported by CAAM hardware, using the CHA
version and instantiation registers to identify hardware capabilities.
Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com>
Tested-by: Horia Geantă <horia.geanta@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Allow CAAM to be selected in the kernel for Freescale i.MX devices if
ARCH_MXC is enabled.
Signed-off-by: Steve Cornelius <steve.cornelius@freescale.com>
Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com>
Tested-by: Horia Geantă <horia.geanta@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Add CAAM clock support to the i.MX6 clocking infrastructure.
Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com>
Tested-by: Horia Geantă <horia.geanta@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The clocks and clock-names properties describe input clocks that may be
required for enablement of CAAM.
Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com>
Tested-by: Horia Geantă <horia.geanta@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Avoid moving the head of the scatterlist entry by using temporary
pointers to walk the scatterlist.
Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com>
Tested-by: Horia Geantă <horia.geanta@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Since fields must be ORed in to operate correctly using any order of
operations, changed allocations of the combination of extended
descriptor structs + hardware scatterlists to use kzalloc() instead
of kmalloc(), so as to ensure that residue data would not be ORed in
with the correct data.
Signed-off-by: Steve Cornelius <steve.cornelius@freescale.com>
Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com>
Tested-by: Horia Geantă <horia.geanta@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Modify the Scatter-Gather entry definitions for the Freescale
CAAM driver to include support for both 64- and 32-bit DMA pointers.
Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com>
Tested-by: Horia Geantă <horia.geanta@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
ARM-based systems may disable clocking to the CAAM device on the
Freescale i.MX platform for power management purposes. This patch
enables the required clocks when the CAAM module is initialized and
disables the required clocks when the CAAM module is shut down.
Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com>
Tested-by: Horia Geantă <horia.geanta@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Add set/clear 32-bit primitives for compatibility with ARM devices since
the primitives were previously only defined for the Power architecture.
Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com>
Tested-by: Horia Geantă <horia.geanta@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Freescale i.MX6 ARM platforms do not support hardware cache coherency.
This patch adds cache coherency support to the CAAM driver.
Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com>
Tested-by: Horia Geantă <horia.geanta@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The comment says it's using trialcs->mems_allowed as a temp variable but
it didn't match the code. Change the code to match the comment.
This fixes an issue when writing in cpuset.mems when a sub-directory
exists: we need to write several times for the information to persist:
| root@alban:/sys/fs/cgroup/cpuset# mkdir footest9
| root@alban:/sys/fs/cgroup/cpuset# cd footest9
| root@alban:/sys/fs/cgroup/cpuset/footest9# mkdir aa
| root@alban:/sys/fs/cgroup/cpuset/footest9# cat cpuset.mems
|
| root@alban:/sys/fs/cgroup/cpuset/footest9# echo 0 > cpuset.mems
| root@alban:/sys/fs/cgroup/cpuset/footest9# cat cpuset.mems
|
| root@alban:/sys/fs/cgroup/cpuset/footest9# echo 0 > cpuset.mems
| root@alban:/sys/fs/cgroup/cpuset/footest9# cat cpuset.mems
| 0
| root@alban:/sys/fs/cgroup/cpuset/footest9# cat aa/cpuset.mems
|
| root@alban:/sys/fs/cgroup/cpuset/footest9# echo 0 > aa/cpuset.mems
| root@alban:/sys/fs/cgroup/cpuset/footest9# cat aa/cpuset.mems
| 0
| root@alban:/sys/fs/cgroup/cpuset/footest9#
This should help to fix the following issue in Docker:
https://github.com/opencontainers/runc/issues/133
In some conditions, a Docker container needs to be started twice in
order to work.
Signed-off-by: Alban Crequy <alban@endocode.com>
Tested-by: Iago López Galeiras <iago@endocode.com>
Cc: <stable@vger.kernel.org> # 3.17+
Acked-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
The ESP code has been updated to generate a completely linear
AD SG list. This unfortunately broke authencesn which expects
the AD to be divided into at least three parts.
This patch fixes it to cope with the new format. Later we will
fix it properly to accept arbitrary input and not rely on the
input being linear as part of the AEAD conversion.
Fixes: 7021b2e1cd ("esp4: Switch to new AEAD interface")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
We need to unset 'perf_event_attr::freq' bit (default 1) when
'period' term is specified within event definition like:
-e 'cpu/cpu-cycles,call-graph=fp,time,period=100000'
otherwise it will handle the period value as frequency
(and fail if it crossed the maximum allowed frequency value).
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/20150808171210.GC17040@krava.brq.redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
For perf report/script srcline currently only the base file name of the
source file is printed. This is a good default because it usually fits
on the screen.
But in some cases we want to know the full file name, for example to
aggregate hits per file.
In the later case we need more than the base file name to resolve file
naming collisions: for example the kernel source has ~70 files named
"core.c"
It's also useful as input to post processing tools which want to point
to the right file.
Add a flag to allow full file name output.
Add an option to perf report/script to enable this option.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/r/1438986245-15191-1-git-send-email-andi@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Alienware 15 has CA0132 codec for its onboard sound, but the pin
config and mapping seem quite different from other Creative boards.
This patch corrects them, at least, for providing the right headphone
and mic jack notification, as well as removing the non-existing SPDIF
pins.
Even with this fix, not all stuff works perfectly yet, mainly because
of the badly written ca0132 driver code -- it has too many implicit
assumptions of pin configs and maps. Nevertheless, this is a small
good step forward.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101981
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Changing the frequency of the USB clock must be done before the
PLL is powered on (prepared). This matters when the USB clock
is not setup by either boot ROM or boot loader. Reorder the
function calls to adhere to the order noted in the user manual.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Since 906c55579a ("timekeeping: Copy the shadow-timekeeper over the
real timekeeper last") it has become possible on arm64 to:
- Obtain a CLOCK_MONOTONIC_COARSE or CLOCK_REALTIME_COARSE timestamp
via syscall.
- Subsequently obtain a timestamp for the same clock ID via VDSO which
predates the first timestamp (by one jiffy).
This is because arm64's update_vsyscall is deriving the coarse time
using the __current_kernel_time interface, when it should really be
using the timekeeper object provided to it by the timekeeping core.
It happened to work before only because __current_kernel_time would
access the same timekeeper object which had been passed to
update_vsyscall. This is no longer the case.
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
It turns out that a PV domU also requires the "Xen PV" APIC
driver. Otherwise, the flat driver is used and we get stuck in busy
loops that never exit, such as in this stack trace:
(gdb) target remote localhost:9999
Remote debugging using localhost:9999
__xapic_wait_icr_idle () at ./arch/x86/include/asm/ipi.h:56
56 while (native_apic_mem_read(APIC_ICR) & APIC_ICR_BUSY)
(gdb) bt
#0 __xapic_wait_icr_idle () at ./arch/x86/include/asm/ipi.h:56
#1 __default_send_IPI_shortcut (shortcut=<optimized out>,
dest=<optimized out>, vector=<optimized out>) at
./arch/x86/include/asm/ipi.h:75
#2 apic_send_IPI_self (vector=246) at arch/x86/kernel/apic/probe_64.c:54
#3 0xffffffff81011336 in arch_irq_work_raise () at
arch/x86/kernel/irq_work.c:47
#4 0xffffffff8114990c in irq_work_queue (work=0xffff88000fc0e400) at
kernel/irq_work.c:100
#5 0xffffffff8110c29d in wake_up_klogd () at kernel/printk/printk.c:2633
#6 0xffffffff8110ca60 in vprintk_emit (facility=0, level=<optimized
out>, dict=0x0 <irq_stack_union>, dictlen=<optimized out>,
fmt=<optimized out>, args=<optimized out>)
at kernel/printk/printk.c:1778
#7 0xffffffff816010c8 in printk (fmt=<optimized out>) at
kernel/printk/printk.c:1868
#8 0xffffffffc00013ea in ?? ()
#9 0x0000000000000000 in ?? ()
Mailing-list-thread: https://lkml.org/lkml/2015/8/4/755
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
A sun7i-a20-olinuxino-micro fails to boot when kernel parameter
vt.global_cursor_default=0. The value is copied to vc->vc_deccm
causing the initialization of ops->cur_blink_jiffies to be skipped.
Unconditionally initialize it.
Reported-and-tested-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The echoaudio locally defines TRUE and FALSE. Not only is this
redundant given that C now has a boolean type it results in lots of
warnings as other headers also define these macros, causing duplicate
definitions. Fix this by removing the local defines and converting all
local users to use the standard C true and false instead, simply
removing the macros is less safe due to implicit inclusion of the other
definitons.
[fixed overlooked replacement of FALSE by tiwai]
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
