When the hp mic pin has no VREF bits, the driver forgot to set PIN_IN
bit. Spotted during debugging old MacBook Airs.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=65681
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When a headphone jack is configurable as input, the generic parser
tries to make it retaskable as Headphone Mic. The switching can be
done smoothly if Capture Source control exists (i.e. there is another
input source). Or when user explicitly enables the creation of jack
mode controls, "Headhpone Mic Jack Mode" will be created accordingly.
However, if the headphone mic is the only input source, we have to
create "Headphone Mic Jack Mode" control because there is no capture
source selection. Otherwise, the generic parser assumes that the
input is constantly enabled, thus the headphone is permanently set
as input. This situation happens on the old MacBook Airs where no
input is supported properly, for example.
This patch fixes the problem: now "Headphone Mic Jack Mode" is created
when such an input selection isn't possible.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=65681
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The PL061 driver had the irqdomain initialization in an unfortunate
place: when used with device tree (and thus passing the base IRQ
0) the driver would work, as this registers an irqdomain and waits
for mappings to be done dynamically as the devices request their
IRQs, whereas when booting using platform data the irqdomain core
would attempt to allocate IRQ descriptors dynamically (which works
fine) but also to associate the irq_domain_associate_many() on all
IRQs, which in turn will call the mapping function which at this
point will try to set the type of the IRQ and then tries to acquire
a non-initialized spinlock yielding a backtrace like this:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.13.0-rc1+ #652
Backtrace:
[<c0016f0c>] (dump_backtrace) from [<c00172ac>] (show_stack+0x18/0x1c)
r6:c798ace0 r5:00000000 r4:c78257e0 r3:00200140
[<c0017294>] (show_stack) from [<c0329ea0>] (dump_stack+0x20/0x28)
[<c0329e80>] (dump_stack) from [<c004fa80>] (__lock_acquire+0x1c0/0x1b80)
[<c004f8c0>] (__lock_acquire) from [<c0051970>] (lock_acquire+0x6c/0x80)
r10:00000000 r9:c0455234 r8:00000060 r7:c047d798 r6:600000d3 r5:00000000
r4:c782c000
[<c0051904>] (lock_acquire) from [<c032e484>] (_raw_spin_lock_irqsave+0x60/0x74)
r6:c01a1100 r5:800000d3 r4:c798acd0
[<c032e424>] (_raw_spin_lock_irqsave) from [<c01a1100>] (pl061_irq_type+0x28/0x)
r6:00000000 r5:00000000 r4:c798acd0
[<c01a10d8>] (pl061_irq_type) from [<c0059ef4>] (__irq_set_trigger+0x70/0x104)
r6:00000000 r5:c01a10d8 r4:c046da1c r3:c01a10d8
[<c0059e84>] (__irq_set_trigger) from [<c005b348>] (irq_set_irq_type+0x40/0x60)
r10:c043240c r8:00000060 r7:00000000 r6:c046da1c r5:00000060 r4:00000000
[<c005b308>] (irq_set_irq_type) from [<c01a1208>] (pl061_irq_map+0x40/0x54)
r6:c79693c0 r5:c798acd0 r4:00000060
[<c01a11c8>] (pl061_irq_map) from [<c005d27c>] (irq_domain_associate+0xc0/0x190)
r5:00000060 r4:c046da1c
[<c005d1bc>] (irq_domain_associate) from [<c005d604>] (irq_domain_associate_man)
r8:00000008 r7:00000000 r6:c79693c0 r5:00000060 r4:00000000
[<c005d5d0>] (irq_domain_associate_many) from [<c005d864>] (irq_domain_add_simp)
r8:c046578c r7:c035b72c r6:c79693c0 r5:00000060 r4:00000008 r3:00000008
[<c005d814>] (irq_domain_add_simple) from [<c01a1380>] (pl061_probe+0xc4/0x22c)
r6:00000060 r5:c0464380 r4:c798acd0
[<c01a12bc>] (pl061_probe) from [<c01c0450>] (amba_probe+0x74/0xe0)
r10:c043240c r9:c0455234 r8:00000000 r7:c047d7f8 r6:c047d744 r5:00000000
r4:c0464380
This moves the irqdomain initialization to a point where the spinlock
and GPIO chip are both fully propulated, so the callbacks can be used
without crashes.
I had some problem reproducing the crash, as the devm_kzalloc():ed
zeroed memory would seemingly mask the spinlock as something OK,
but by poisoning the lock like this:
u32 *dum;
dum = (u32 *) &chip->lock;
*dum = 0xaaaaaaaaU;
I could reproduce, fix and test the patch.
Reported-by: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <robherring2@gmail.com>
Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
For Wireless USB audio devices, use multiple isoc packets per URB for
inbound endpoints with a datainterval < 5. This allows the WUSB host
controller to take advantage of bursting to service endpoints whose
logical polling interval is less than the 4ms minimum polling interval
limit in WUSB.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Tony reported that aa0d532605 ("ia64: Use preempt_schedule_irq")
broke PREEMPT=n builds on ia64.
Ok, wrapped my brain around it. I tripped over the magic asm foo which
has a single need_resched check and schedule point for both sys call
return and interrupt return.
So you need the schedule_preempt_irq() for kernel preemption from
interrupt return while on a normal syscall preemption a schedule would
be sufficient. But using schedule_preempt_irq() is not harmful here in
any way. It just sets the preempt_active bit also in cases where it
would not be required.
Even on preempt=n kernels adding the preempt_active bit is completely
harmless. So instead of having an extra function, moving the existing
one out of the ifdef PREEMPT looks like the sanest thing to do.
It would also allow getting rid of various other sti/schedule/cli asm
magic in other archs.
Reported-and-Tested-by: Tony Luck <tony.luck@gmail.com>
Fixes: aa0d532605 ("ia64: Use preempt_schedule_irq")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[slightly edited Changelog]
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1311211230030.30673@ionos.tec.linutronix.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
UHID allows short writes so user-space can omit unused fields. We
automatically set them to 0 in the kernel. However, the 64/32 bit
compat-handler didn't do that in the UHID_CREATE fallback. This will
reveal random kernel heap data (of random size, even) to user-space.
Fixes: befde0226a ('HID: uhid: make creating devices work on 64/32 systems')
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Most Thinkpad Edge series laptops use conexant codec, so far although
the codecs have different minor Vendor Id and minor Subsystem Id,
they all belong to the cxt5066 family, this change can make the
mute/mic-mute LEDs support more generic among cxt_5066 family.
This design refers to the similar solution for the realtek codec
ALC269 family in the patch_realtek.c.
Cc: Alex Hung <alex.hung@canonical.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
1) is a bug fix that happens when root does the following:
echo function_graph > current_tracer
modprobe foo
echo nop > current_tracer
This causes the ftrace internal accounting to get screwed up and
crashes ftrace, preventing the user from using the function tracer
after that.
2) if a TRACE_EVENT has a string field, and NULL is given for it.
The internal trace event code does a strlen() and strcpy() on the
source of field. If it is NULL it causes the system to oops.
This bug has been there since 2.6.31, but no TRACE_EVENT ever passed
in a NULL to the string field, until now.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQEcBAABAgAGBQJSlUw+AAoJEKQekfcNnQGugTYIAJQ7Zfhor2Jrw7XzkcBDpQv9
kqL/NvjLfyA49BLwba0VJCqJA56dEfW7kaSa7Wx0qAHdHKATLDA8G4c9FdHRAmZf
WJ4jDbrcJqc7DA2vEn4aUuczwvTMx0H1KJHPMAu9taEno3YocIzCMxkuNYelwAz2
XUkUGtR7olF85pyVccfZLKnKPtslSwxWoG6WgEqiAap6fIorPlcSXBVYFqLKVTRJ
P2e847eqxMF5ACLmv3dWiEvTPtWY91abN1zpeJYQNjBtQJmzVlvRcXYE6TwPUIFg
RtB9n3SrT+0lEWvcxDbQi+4hKHf+JQLkGaYwWCMJihbdF4sh36olzpUOimKVqsk=
=+9+v
-----END PGP SIGNATURE-----
Merge tag 'trace-fixes-v3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing fixes from Steven Rostedt:
"This includes two fixes.
1) is a bug fix that happens when root does the following:
echo function_graph > current_tracer
modprobe foo
echo nop > current_tracer
This causes the ftrace internal accounting to get screwed up and
crashes ftrace, preventing the user from using the function tracer
after that.
2) if a TRACE_EVENT has a string field, and NULL is given for it.
The internal trace event code does a strlen() and strcpy() on the
source of field. If it is NULL it causes the system to oops.
This bug has been there since 2.6.31, but no TRACE_EVENT ever passed
in a NULL to the string field, until now"
* tag 'trace-fixes-v3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
ftrace: Fix function graph with loading of modules
tracing: Allow events to have NULL strings
Pull ceph bug-fixes from Sage Weil:
"These include a couple fixes to the new fscache code that went in
during the last cycle (which will need to go stable@ shortly as well),
a couple client-side directory fragmentation fixes, a fix for a race
in the cap release queuing path, and a couple race fixes in the
request abort and resend code.
Obviously some of this could have gone into 3.12 final, but I
preferred to overtest rather than send things in for a late -rc, and
then my travel schedule intervened"
* 'for-linus-bugs' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
ceph: allocate non-zero page to fscache in readpage()
ceph: wake up 'safe' waiters when unregistering request
ceph: cleanup aborted requests when re-sending requests.
ceph: handle race between cap reconnect and cap release
ceph: set caps count after composing cap reconnect message
ceph: queue cap release in __ceph_remove_cap()
ceph: handle frag mismatch between readdir request and reply
ceph: remove outdated frag information
ceph: hung on ceph fscache invalidate in some cases
We are missing building windfarm_max6690_sensor.o when building
CONFIG_WINDFARM_RM31. Usually all the windfarm drivers are built
and thus this isn't a problem but some more "tailored" setups
(Gentoo ?) building only that driver are not working because
the require sensor module is missing.
Reported-by: Stanislav Ponomarev <devhexorg@gmail.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* acpica:
ACPI: Clean up incorrect inclusions of ACPICA headers
ACPICA: Update version to 20131115.
ACPICA: Add support to delete all objects attached to the root namespace node.
ACPICA: Delete all attached data objects during namespace node deletion.
ACPICA: Resources: Fix loop termination for the get AML length function.
ACPICA: Tests: Add CHECKSUM_ABORT protection for test utilities.
ACPICA: Debug output: Do not emit function nesting level for kernel build.
Mostly bugfixes and a few small code removals. Worth pointing out is:
- A handful of more fixes to get DT enablement working properly on OMAP,
finding new breakage of things that don't work quite right yet without
the traditional board files. I expect a bit more of this to come in this
release as people test on their hardware.
- Implementation of power_down_finish() on vexpress, to make kexec work and
to stop the MCPM core to produce a warning (the warning was new to 3.13-rc1).
- A handful of minor fixes for various platforms.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJSlPDhAAoJEIwa5zzehBx31dkP/RyP/esMHSBO5k36eB5V35HP
/XcexbgnnH4tDVIKl28qH4/AjkT+09uNZ/QQpbshwmEHw1X5i+Dz455suBCdP0T7
D+dHy/YCMDuMD7ow0OXWyyL9XbILV5VuBUogrdMN/RhzW2gIvIJRuHztKBQcU8sw
L94OIPjlKX/YFrswuy0LXiIZt2Y2k3zFVFCwcxIpTB4F1avYj7luZjSX6y469TEB
JyqfO+hooU/qtuc1pKTnBzKxVI7IVae3bberDhZCCKsAxP1/c5rSMy+nf60rqB4O
nkT09sAr1SBVp6kB4Ql2yHGiZ5ozxSJbMQpx1v73wnS09wL9RXwR1GZPrNcDW90l
qwergTrBxhYdzWyNAf/87DmQhB+Xf7kGqtUuRHleuuFhBOU29qR8oXQ6WMRkzHn9
ZTSRZ99l5a3Aul8w+sEWzOKDdZfhycMsBNzWH8xpzR1fgH4N9GRJlSlqkWdrVGca
QBNiC5bmtPpMgAHSkqK0Zu3rog83NX9NxcXG15FVEah7J4Q/VT/x51AIh0uSRBf0
35lY86R79SQ3FYYyHhl2pyAw8nhY2EmofGSG2WJ+qfZ9TgDSDFdwA0hz2fp9nwFc
Lwb3zGUEyGwgJ4I/n/cDGBfY2CsJuTEcDtB4sW1Vw4GrzMQvc43SWly6e5+RSAgq
reP23wcD4/YKev7//zzI
=zdhe
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"Mostly bugfixes and a few small code removals. Worth pointing out is:
- A handful of more fixes to get DT enablement working properly on
OMAP, finding new breakage of things that don't work quite right
yet without the traditional board files. I expect a bit more of
this to come in this release as people test on their hardware.
- Implementation of power_down_finish() on vexpress, to make kexec
work and to stop the MCPM core to produce a warning (the warning
was new to 3.13-rc1).
- A handful of minor fixes for various platforms"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: bcm2835: add missing #xxx-cells to I2C nodes
ARM: dts: Add max77686 RTC interrupt to cros5250-common
ARM: vexpress/TC2: Implement MCPM power_down_finish()
ARM: tegra: Provide dummy powergate implementation
ARM: omap: fix warning with LPAE build
ARM: OMAP2+: Remove legacy omap4_twl6030_hsmmc_init
ARM: OMAP2+: Remove legacy mux code for display.c
ARM: OMAP2+: Fix undefined reference to set_cntfreq
gpio: twl4030: Fix passing of pdata in the device tree case
gpio: twl4030: Fix regression for twl gpio output
ARM: OMAP2+: More randconfig fixes for reconfigure_io_chain
ARM: dts: imx6qdl: disable spdif "rxtx5" clock option
ARM: dts: Fix omap2 specific dtsi files by adding the missing entries
ARM: OMAP2+: Fix GPMC and simplify bootloader timings for 8250 and smc91x
i2c: omap: Fix missing device tree flags for omap2
Pull IMA fixes from James Morris:
"These three patches fix regressions in the IMA code in your current
tree.
The first fixes a couple of bugs in template_desc_init_fields(), and
the other two ensure that changes in this kernel don't break
userspace"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
ima: make a copy of template_fmt in template_desc_init_fields()
ima: do not send field length to userspace for digest of ima template
ima: do not include field length in template digest calc for ima template
NTB-RP Link Up issue, Xeon Doorbell errata workaround, ntb_transport
link down race, and correct dmaengine_get/put usage. Also, clean-ups
to remove duplicate defines and document a hardware errata. Finally,
some changes to improve performance.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJSj/dCAAoJEG5mS6x6i9IjCfAP/0pVA7VYAjQQGLtpUIf8RNIe
iNV58Q3h74+CSzyHkz51HYuJB+6uRC6c0ChKuZMUZk/ca3hqfW0FcC1V3SjYLzxP
Bdf687TaEE4WJOaTI5hnAzzDQ+gU9aE4DgaqvFz43M4jh4scSleuE+CQ0Pjm682x
71KespuPO7Z77EC5QPbWWV5KRSkF4FHuAuDcr8TYAmSnCb8VDGDxdnwYYwBTeY3j
DuPUwLGwvbE6X4gWmOYZSwDz6cArEs1CunpeP3EUFY4rjTZArc4MSLWdC6lYQtZp
T90khUDU/UklUqlOOuydJe30zT60uPBagcEL94JxyWFT+wa5b/ra+gvU+FE4NBzA
ZW6LVlXnYTQ5XJeO5HNDRBHPZ3zZaDI+TGDBM13EBS0wbcO3PojR6Z78nlkjPLeJ
/a1sIEfM3ts7u3Vpw8GpBbhl6+8tP6xbV/rDbzfE6mfq/VVwbfAa/k9oQVh8pfoJ
YyGq1Gr43aAFm0imPRF0qRNDnSDF2UiYrNHntWWyfhW7Vmq/EjT0H21AHhgxnP7b
3AaKQl7nuYoNzx6x8ZiEcSkDy+8qY84i2vUzd9Qll/SBVCOK7KvBoFmu9x7D+ZdN
0mS4qFNXSmHhow7ur2ffwzIaSkggVIhLbEiH4bYbPP+wXzhlTLTnnRb3lFmTs/5X
/HTR7QGxfDAzcjpYAzlS
=nOG2
-----END PGP SIGNATURE-----
Merge tag 'ntb-3.13' of git://github.com/jonmason/ntb
Pull non-transparent bridge updates from Jon Mason:
"NTB driver bug fixes to address a missed call to pci_enable_msix,
NTB-RP Link Up issue, Xeon Doorbell errata workaround, ntb_transport
link down race, and correct dmaengine_get/put usage.
Also, clean-ups to remove duplicate defines and document a hardware
errata. Finally, some changes to improve performance"
* tag 'ntb-3.13' of git://github.com/jonmason/ntb:
NTB: Disable interrupts and poll under high load
NTB: Enable Snoop on Primary Side
NTB: Document HW errata
NTB: remove duplicate defines
NTB: correct dmaengine_get/put usage
NTB: Fix ntb_transport link down race
ntb: Fix missed call to pci_enable_msix()
NTB: Fix NTB-RP Link Up
NTB: Xeon Doorbell errata workaround
Commit f62805f1 introduced a bug where lazy MMU mode isn't exited if a
m2p_add/remove_override call fails.
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Anthony Liguori <aliguori@amazon.com>
Cc: xen-devel@lists.xenproject.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Matt Wilson <msw@amazon.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: stable@vger.kernel.org
Commit 8c4f3c3fa9 "ftrace: Check module functions being traced on reload"
fixed module loading and unloading with respect to function tracing, but
it missed the function graph tracer. If you perform the following
# cd /sys/kernel/debug/tracing
# echo function_graph > current_tracer
# modprobe nfsd
# echo nop > current_tracer
You'll get the following oops message:
------------[ cut here ]------------
WARNING: CPU: 2 PID: 2910 at /linux.git/kernel/trace/ftrace.c:1640 __ftrace_hash_rec_update.part.35+0x168/0x1b9()
Modules linked in: nfsd exportfs nfs_acl lockd ipt_MASQUERADE sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables uinput snd_hda_codec_idt
CPU: 2 PID: 2910 Comm: bash Not tainted 3.13.0-rc1-test #7
Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
0000000000000668 ffff8800787efcf8 ffffffff814fe193 ffff88007d500000
0000000000000000 ffff8800787efd38 ffffffff8103b80a 0000000000000668
ffffffff810b2b9a ffffffff81a48370 0000000000000001 ffff880037aea000
Call Trace:
[<ffffffff814fe193>] dump_stack+0x4f/0x7c
[<ffffffff8103b80a>] warn_slowpath_common+0x81/0x9b
[<ffffffff810b2b9a>] ? __ftrace_hash_rec_update.part.35+0x168/0x1b9
[<ffffffff8103b83e>] warn_slowpath_null+0x1a/0x1c
[<ffffffff810b2b9a>] __ftrace_hash_rec_update.part.35+0x168/0x1b9
[<ffffffff81502f89>] ? __mutex_lock_slowpath+0x364/0x364
[<ffffffff810b2cc2>] ftrace_shutdown+0xd7/0x12b
[<ffffffff810b47f0>] unregister_ftrace_graph+0x49/0x78
[<ffffffff810c4b30>] graph_trace_reset+0xe/0x10
[<ffffffff810bf393>] tracing_set_tracer+0xa7/0x26a
[<ffffffff810bf5e1>] tracing_set_trace_write+0x8b/0xbd
[<ffffffff810c501c>] ? ftrace_return_to_handler+0xb2/0xde
[<ffffffff811240a8>] ? __sb_end_write+0x5e/0x5e
[<ffffffff81122aed>] vfs_write+0xab/0xf6
[<ffffffff8150a185>] ftrace_graph_caller+0x85/0x85
[<ffffffff81122dbd>] SyS_write+0x59/0x82
[<ffffffff8150a185>] ftrace_graph_caller+0x85/0x85
[<ffffffff8150a2d2>] system_call_fastpath+0x16/0x1b
---[ end trace 940358030751eafb ]---
The above mentioned commit didn't go far enough. Well, it covered the
function tracer by adding checks in __register_ftrace_function(). The
problem is that the function graph tracer circumvents that (for a slight
efficiency gain when function graph trace is running with a function
tracer. The gain was not worth this).
The problem came with ftrace_startup() which should always be called after
__register_ftrace_function(), if you want this bug to be completely fixed.
Anyway, this solution moves __register_ftrace_function() inside of
ftrace_startup() and removes the need to call them both.
Reported-by: Dave Wysochanski <dwysocha@redhat.com>
Fixes: ed926f9b35 ("ftrace: Use counters to enable functions to trace")
Cc: stable@vger.kernel.org # 3.0+
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The flexcan IP core uses the peripheral clock ("per") as basic clock for the
bit timing calculation. However the driver uses the the wrong clock ("ipg").
This leads to wrong bit rates if the rates on both clock are different.
This patch fixes the problem by using the correct clock for the bit rate
calculation.
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Correct a typo that prevented the driver from being built as a module.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Tim Kryger <tim.kryger@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The previous diolan adapter uses other out/in endpoints than
the current DLN-2-U2C in compatibility mode.
They changed from 0x2/0x84 to 0x3/0x83.
This patch gets the endpoints from the usb interface, instead
of hardcode them in the driver.
This was tested on a current DLN-2-U2C board.
Signed-off-by: Martin Vogt <mvogt1@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Use bus->power_keep_link_on instead. The controller shouldn't go to
D3 when the link isn't reset, so essentially avoiding the link reset
means avoiding the runtime PM.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Set the missing pcbeep default amp for ALC668.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
I2C IP block expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and write[lw]_relaxed functions.
If the first simply reads/writes register, the second will byteswap
it if host operates in BE mode.
Changes are trivial sed like replacement of __raw_xxx functions
with xxx_relaxed variant.
Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The I2C controller node needs #address-cells and #size-cells properties,
but these are currently missing. Add them. This allows child nodes to be
parsed correctly.
Cc: stable@vger.kernel.org
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Follow-up to commit 294d31e822 ("sony-laptop: don't change keyboard
backlight settings"): avoid messing up the state on resume. Leave it to
what was before suspending as it's anyway likely that we still don't
know what value we should write to the EC registers. This fix is also
required in 3.12
Cc: stable@vger.kernel.org
Tested-by: Karol Babioch <karol@babioch.de>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit c284ee2cf1. Turns out
the locking was incorrect.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: Chao Bi <chao.bi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Header file <acpi/acpi.h> contains environemnt settings and architecture
specific implementation that should be included before any other ACPICA
headers in order to keep a consistent build environment for ACPICA users.
The following internal ACPICA header files should be included from
<acpi/acpi.h> and should not be included by other kernel files:
<acpi/acpiosxf.h>
<acpi/acpixf.h>
Clean up incorrect inclusions of these files from non-ACPICA source
files.
[rjw: Subject and changelog]
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Without the interrupt you'll get problems if you enable
CONFIG_RTC_DRV_MAX77686. Setup the interrupt properly in the device
tree.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Cc: stable@vger.kernel.org
This patch implements the power_down_finish() method for TC2, to
enable the kernel to confirm when CPUs are safely powered down.
The information required for determining when a CPU is parked
cannot be obtained from any single place, so a few sources of
information must be combined:
* mcpm_cpu_power_down() must be pending for the CPU, so that we
don't get confused by false STANDBYWFI positives arising from
CPUidle. This is detected by waiting for the tc2_pm use count
for the target CPU to reach 0.
* Either the SPC must report that the CPU has asserted
STANDBYWFI, or the TC2 tile's reset control logic must be
holding the CPU in reset.
Just checking for STANDBYWFI is not sufficient, because this
signal is not latched when the the cluster is clamped off and
powered down: the relevant status bits just drop to zero. This
means that STANDBYWFI status cannot be used for reliable
detection of the last CPU in a cluster reaching WFI.
This patch is required in order for kexec to work with MCPM on TC2.
MCPM code was changed in commit 0de0d64675 ('ARM: 7848/1: mcpm:
Implement cpu_kill() to synchronise on powerdown'), and since then it
will hit a WARN_ON_ONCE() due to power_down_finish not being implemented
on the TC2 platform.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Pawel Moll <pawel.moll@arm.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
idlestates in sysfs are counted from 0.
This fixes a wrong error message.
Current behavior on a machine with 4 sleep states is:
cpupower idle-set -e 4
Idlestate 4 enabled on CPU 0
-----Wrong---------------------
cpupower idle-set -e 5
Idlestate enabling not supported by kernel
-----Must and now will be -----
cpupower idle-set -e 5
Idlestate 6 not available on CPU 0
-------------------------------
cpupower idle-set -e 6
Idlestate 6 not available on CPU 0
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The cpupower idle-set subcommand was introduce recently.
This patch provides the missing manpage.
If cpupower is properly installed it will show up automatically
(similar to git), when invoking:
cpupower help idle-set
or
cpupower idle-set --help
Some parts have been taken over and adjusted from
git commit 62d6ae880e
documentation submitted by Carsten Emde.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Both sides of the comparison are the same, looks like a cut-and-paste error.
Spotted by Coverity.
Signed-off-by: Dave Jones <davej@fedoraproject.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
In order to support increased build test coverage for drivers, implement
dummies for the powergate implementation. This will allow the drivers to
be built without requiring support for Tegra to be selected.
This patch solves the following build errors, which can be triggered in
v3.13-rc1 by selecting DRM_TEGRA without ARCH_TEGRA:
drivers/built-in.o: In function `gr3d_remove':
drivers/gpu/drm/tegra/gr3d.c:321: undefined reference to `tegra_powergate_power_off'
drivers/gpu/drm/tegra/gr3d.c:325: undefined reference to `tegra_powergate_power_off'
drivers/built-in.o: In function `gr3d_probe':
drivers/gpu/drm/tegra/gr3d.c:266: undefined reference to `tegra_powergate_sequence_power_up'
drivers/gpu/drm/tegra/gr3d.c:273: undefined reference to `tegra_powergate_sequence_power_up'
Signed-off-by: Thierry Reding <treding@nvidia.com>
[swarren, updated commit description]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
From Tony Lindgren:
Few more fixes for issues found booting older omaps using device tree.
Also few randconfig build fixes and removal of some dead code for omap4
as it no longer has legacy platform data based booting support.
* tag 'omap-for-v3.13/more-fixes-for-merge-window-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2+: Remove legacy omap4_twl6030_hsmmc_init
ARM: OMAP2+: Remove legacy mux code for display.c
ARM: OMAP2+: Fix undefined reference to set_cntfreq
gpio: twl4030: Fix passing of pdata in the device tree case
gpio: twl4030: Fix regression for twl gpio output
ARM: OMAP2+: More randconfig fixes for reconfigure_io_chain
ARM: dts: Fix omap2 specific dtsi files by adding the missing entries
ARM: OMAP2+: Fix GPMC and simplify bootloader timings for 8250 and smc91x
i2c: omap: Fix missing device tree flags for omap2
Some omap3 code is throwing a warning:
arch/arm/mach-omap2/pm34xx.c: In function 'omap3_save_secure_ram_context':
arch/arm/mach-omap2/pm34xx.c:123:32: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
In reality this code will never actually execute with LPAE=y, since
Cortex-A8 doesn't support it. So downcasting the __pa() is safe in
this case.
Signed-off-by: Olof Johansson <olof@lixom.net>
Acked-by: Tony Lindgren <tony@atomide.com>
When the system enters suspend, it disables all interrupts in
suspend_device_irqs(), including the interrupts marked EARLY_RESUME.
On the resume side things are different. The EARLY_RESUME interrupts
are reenabled in sys_core_ops->resume and the non EARLY_RESUME
interrupts are reenabled in the normal system resume path.
When suspend_noirq() failed or suspend is aborted for any other
reason, we might omit the resume side call to sys_core_ops->resume()
and therefor the interrupts marked EARLY_RESUME are not reenabled and
stay disabled forever.
To solve this, enable all irqs unconditionally in irq_resume()
regardless whether interrupts marked EARLY_RESUMEhave been already
enabled or not.
This might try to reenable already enabled interrupts in the non
failure case, but the only affected platform is XEN and it has been
confirmed that it does not cause any side effects.
[ tglx: Massaged changelog. ]
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by-and-tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Cc: <ian.campbell@citrix.com>
Cc: <rjw@rjwysocki.net>
Cc: <len.brown@intel.com>
Cc: <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1385388587-16442-1-git-send-email-ldewangan@nvidia.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
If the next seqno returned by the firmware is 0, we return an error
(-16) in the iwl_mvm_get_last_nonqos_seq() function. This is because
we return an integer and don't use any casting when calculating the
last seqno from the one we received. Fix this by using a cast to u16
when doing the calculation, so we return 0xfff0, as we should.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
In an open BSS, after suspend/resume, we don't set the last seqno
because the iwl_mvm_setup_connection_keep() returns too early. This
happens because the check to see if we have any keys was returning
immediately, without setting seqno and seqno_valid. Fix this.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
If we call ieee80211_hw_restart, it means that the
firmware is in bad condition and will be reset soon.
Since the firmware will be reset, there is no good
reason to keep sending host commands.
Signed-off-by: Alexander Bondar <alexander.bondar@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
A new firmware is coming out soon with new APIs.
To make sure that this new firmware won't be loaded on old
driver that don't support it, it's API version has been
updated to 8. In order to be able to load it, bump the API
version to 8.
API version 7 is still supported and will be for another
year or so.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Time event notification can have a failure status even if
the time event was scheduled:
* in START notification, this can happen if the time event
was scheduled later than the requested apply time.
* in STOP notification, this can happen if the time event
is truncated.
Even if both happened, the offchannel packets sent during
the remain on channel are very likely to have been sent.
Hence, don't WARN when this happens, but rather print a
discrete line in the kernel log.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
