| Age | Commit message (Collapse) | Author |
|---|
|
ad65782fba50 (context_tracking: Optimize main APIs off case
with static key) converted context tracking main APIs to inline
function and left ARM asm callers behind.
This can be easily fixed by making ARM calling the post static
keys context tracking function. We just need to replicate the
static key checks there. We'll remove these later when ARM will
support the context tracking static keys.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Tested-by: Kevin Hilman <khilman@linaro.org>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Anil Kumar <anilk4.v@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Kevin Hilman <khilman@linaro.org>
|
|
More thorough testing showed that these verbs were necessary to
improve quality of the internal mic. Patch originally from Realtek.
BugLink: https://bugs.launchpad.net/bugs/1231931
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
ALC283 pin control for Line1 default control by hidden register.
Use line1 as internal Mic will not get sound when boost value up.
Set control by verb for hidden register will solve this issue.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This patch adds the default pin configuration and some init verbs for
setting COEFs, in addition to the correction of input pin AMP caps
for MacBook Air 6,1 and 6,2. With these changes, the headphone jack
detection starts working properly.
[trivial space fixes by tiwai]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60811
Signed-off-by: Ben Whitten <benwhitten@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
On AMD family 14h, applying microcode patch on the a core (core0)
would also affect the other core (core1) in the same compute
unit. The driver would skip applying the patch on core1, but it
still need to update kernel structures to reflect the proper
patch level.
The current logic is not updating the struct
ucode_cpu_info.cpu_sig.rev of the skipped core. This causes the
/sys/devices/system/cpu/cpu1/microcode/version to report
incorrect patch level as shown below:
$ grep . cpu?/microcode/version
cpu0/microcode/version:0x600063d
cpu1/microcode/version:0x6000626
cpu2/microcode/version:0x600063d
cpu3/microcode/version:0x6000626
cpu4/microcode/version:0x600063d
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Acked-by: Borislav Petkov <bp@suse.de>
Cc: <bp@alien8.de>
Cc: <jacob.w.shin@gmail.com>
Cc: <herrmann.der.user@googlemail.com>
Link: http://lkml.kernel.org/r/1285806432-1995-1-git-send-email-suravee.suthikulpanit@amd.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
* pm-cpufreq-fixes:
cpufreq: exynos5440: Fix potential NULL pointer dereference
cpufreq: check cpufreq driver is valid and cpufreq isn't disabled in cpufreq_get()
acpi-cpufreq: skip loading acpi_cpufreq after intel_pstate
|
|
* acpi-fixes:
ACPI / scan: fix typo in comments of acpi_bus_unregister_driver()
ACPI / IPMI: Fix atomic context requirement of ipmi_msg_handler()
|
|
The DLink DWA-125 Rev D1 also uses this driver.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: Sergey Kostanbaev <sergey.kostanbaev@gmail.com>
Tested-by: Sergey Kostanbaev <sergey.kostanbaev@gmail.com>
Cc: Sergey Kostanbaev <sergey.kostanbaev@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Add PCI id for Intel Merrifield
Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
In case of usb phy reinitialization:
e.g. insmod usb-module(usb works well) -> rmmod usb-module -> insmod usb-module
It found the PHY_CLK_VALID bit didn't work if it's not with the power-on reset.
So we just check PHY_CLK_VALID bit during the stage with POR, this can be met
by the tricky of checking FSL_SOC_USB_PRICTRL register.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
There's a bunch of failure exits in ffs_fs_mount() with
seriously broken recovery logics. Most of that appears to stem
from misunderstanding of the ->kill_sb() semantics; unlike
->put_super() it is called for *all* superblocks of given type,
no matter how (in)complete the setup had been. ->put_super()
is called only if ->s_root is not NULL; any failure prior to
setting ->s_root will have the call of ->put_super() skipped.
->kill_sb(), OTOH, awaits every superblock that has come from
sget().
Current behaviour of ffs_fs_mount():
We have struct ffs_sb_fill_data data on stack there. We do
ffs_dev = functionfs_acquire_dev_callback(dev_name);
and store that in data.private_data. Then we call mount_nodev(),
passing it ffs_sb_fill() as a callback. That will either fail
outright, or manage to call ffs_sb_fill(). There we allocate an
instance of struct ffs_data, slap the value of ffs_dev (picked
from data.private_data) into ffs->private_data and overwrite
data.private_data by storing ffs into an overlapping member
(data.ffs_data). Then we store ffs into sb->s_fs_info and attempt
to set the rest of the things up (root inode, root dentry, then
create /ep0 there). Any of those might fail. Should that
happen, we get ffs_fs_kill_sb() called before mount_nodev()
returns. If mount_nodev() fails for any reason whatsoever,
we proceed to
functionfs_release_dev_callback(data.ffs_data);
That's broken in a lot of ways. Suppose the thing has failed in
allocation of e.g. root inode or dentry. We have
functionfs_release_dev_callback(ffs);
ffs_data_put(ffs);
done by ffs_fs_kill_sb() (ffs accessed via sb->s_fs_info), followed by
functionfs_release_dev_callback(ffs);
from ffs_fs_mount() (via data.ffs_data). Note that the second
functionfs_release_dev_callback() has every chance to be done to freed memory.
Suppose we fail *before* root inode allocation. What happens then?
ffs_fs_kill_sb() doesn't do anything to ffs (it's either not called at all,
or it doesn't have a pointer to ffs stored in sb->s_fs_info). And
functionfs_release_dev_callback(data.ffs_data);
is called by ffs_fs_mount(), but here we are in nasal daemon country - we
are reading from a member of union we'd never stored into. In practice,
we'll get what we used to store into the overlapping field, i.e. ffs_dev.
And then we get screwed, since we treat it (struct gfs_ffs_obj * in
disguise, returned by functionfs_acquire_dev_callback()) as struct
ffs_data *, pick what would've been ffs_data ->private_data from it
(*well* past the actual end of the struct gfs_ffs_obj - struct ffs_data
is much bigger) and poke in whatever it points to.
FWIW, there's a minor leak on top of all that in case if ffs_sb_fill()
fails on kstrdup() - ffs is obviously forgotten.
The thing is, there is no point in playing all those games with union.
Just allocate and initialize ffs_data *before* calling mount_nodev() and
pass a pointer to it via data.ffs_data. And once it's stored in
sb->s_fs_info, clear data.ffs_data, so that ffs_fs_mount() knows that
it doesn't need to kill the sucker manually - from that point on
we'll have it done by ->kill_sb().
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Cc: stable <stable@vger.kernel.org> # 3.3+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The put_device(dev) at the bottom of the loop of device_shutdown
may result in the dev being cleaned up. In device_create_release,
the dev is kfreed.
However, device_shutdown attempts to use the dev pointer again after
put_device by referring to dev->parent.
Copy the parent pointer instead to avoid this condition.
This bug was found on Chromium OS's chromeos-3.8, which is based on v3.8.11.
See bug report : https://code.google.com/p/chromium/issues/detail?id=297842
This can easily be reproduced when shutting down with
hidraw devices that report battery condition.
Two examples are the HP Bluetooth Mouse X4000b and the Apple Magic Mouse.
For example, with the magic mouse :
The dev in question is "hidraw0"
dev->parent is "magicmouse"
In the course of the shutdown for this device, the input event cleanup calls
a put on hidraw0, decrementing its reference count.
When we finally get to put_device(dev) in device_shutdown, kobject_cleanup
is called and device_create_release does kfree(dev).
dev->parent is no longer valid, and we may crash in
put_device(dev->parent).
This change should be applied on any kernel with this change :
d1c6c030fcec6f860d9bb6c632a3ebe62e28440b
Cc: stable@vger.kernel.org
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
In kobj_ns_current_may_mount the default should be to allow the
mount. The test is only for a single kobj_ns_type at a time, and unless
there is a reason to prevent it the mounting sysfs should be allowed.
Subsystems that are not registered can't have are not involved so can't
have a reason to prevent mounting sysfs.
This is a bug-fix to:
commit 7dc5dbc879bd0779924b5132a48b731a0bc04a1e
Author: Eric W. Biederman <ebiederm@xmission.com>
Date: Mon Mar 25 20:07:01 2013 -0700
sysfs: Restrict mounting sysfs
Don't allow mounting sysfs unless the caller has CAP_SYS_ADMIN rights
over the net namespace. The principle here is if you create or have
capabilities over it you can mount it, otherwise you get to live with
what other people have mounted.
Instead of testing this with a straight forward ns_capable call,
perform this check the long and torturous way with kobject helpers,
this keeps direct knowledge of namespaces out of sysfs, and preserves
the existing sysfs abstractions.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
That came in via the userns tree during the 3.12 merge window.
Reported-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 666b9adc801ef012612c4e43e0f44b2cdc1979cf terminated vmbus
version negotiation incorrectly. We need to terminate the version
negotiation only if the current negotiation were to timeout.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Cc: Olaf Hering <ohering@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The current code does not correctly negotiate the version numbers for the util
driver when hosted on earlier hosts. The version numbers presented by this
driver were not compatible with the version numbers supported by Windows Server
2008. Fix this problem.
I would like to thank Olaf Hering (ohering@suse.com) for identifying the problem.
Reported-by: Olaf Hering <ohering@suse.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Unset init_clients_timer and amthif_stall_timers
in mei_reset in order to cancel timer ticking and hence
avoid recursive reset calls.
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Bus layer omitted check for client state transition while waiting
for read completion
The client state transition may occur for example as result
of firmware initiated reset
Add mei_cl_is_transitioning wrapper to reduce the code
repetition.:
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
1. u8 counters are prone to hard to detect overflow:
make them unsigned long to match bit_ functions argument type
2. don't check me_clients_num for negativity, it is unsigned.
3. init all the me client counters from one place
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 'tty: ar933x_uart: add device tree support
and binding documentation' introduced a new doc in
bindins/tty/serial.
According to a recent thread [1] on the linux-serial
list, the binding documentation of serial drivers
should be added into bindings/serial.
Move the documentation of qca,ar9330-uart to the
correct place.
1. http://marc.info/?l=linux-serial&m=137771295411517
Cc: devicetree@vger.kernel.org
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
For controller versions greater than 1.6, setting ULPI_PHY_CLK_SEL
bit when USB_EN bit is already set causes instability issues with
PHY_CLK_VLD bit. So USB_EN is set only for IP controller version
below 1.6 before setting ULPI_PHY_CLK_SEL bit
Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit f5ea1100 cleans up the disk to host conversions for
node directory entries, but because a variable is reused in
xfs_node_toosmall() the next node is not correctly found.
If the original node is small enough (<= 3/8 of the node size),
this change may incorrectly cause a node collapse when it should
not. That will cause an assert in xfstest generic/319:
Assertion failed: first <= last && last < BBTOB(bp->b_length),
file: /root/newest/xfs/fs/xfs/xfs_trans_buf.c, line: 569
Keep the original node header to get the correct forward node.
(When a node is considered for a merge with a sibling, it overwrites the
sibling pointers of the original incore nodehdr with the sibling's
pointers. This leads to loop considering the original node as a merge
candidate with itself in the second pass, and so it incorrectly
determines a merge should occur.)
Signed-off-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
[v3: added Dave Chinner's (slightly modified) suggestion to the commit header,
cleaned up whitespace. -bpm]
|
|
Add missing break into the restore function.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
After reports from Chris and Josh Boyer of a rare crash in applesmc,
Guenter pointed at the initialization problem fixed below. The patch
has not been verified to fix the crash, but should be applied
regardless.
Reported-by: <jwboyer@fedoraproject.org>
Suggested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Cc: stable@vger.kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
of_get_display_timing(s) use of_find_node_by_name
to get child node, this is incorrect, of_get_child_by_name
should be used instead. The patch fixes it.
Small typo is also corrected.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
Fix to return -EINVAL when virtual vertical size smaller than real
instead of 0, as done elsewhere in this function. Also remove dup code.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The nice thing about devm_* is that the driver doesn't need to free the
resources but the driver core takes care about that. This also
simplifies the error path quite a bit and removes the wrong check for a
clock pointer being NULL.
Russell King - ARM Linux <linux@arm.linux.org.uk>:
"And this patch also fixes the above: disabling/unpreparing _after_ putting
the thing - which was quite silly... :)"
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
The DSI-CM driver uses the backlight class so needs to build depend on it.
Signed-off-by: Mark Brown <broonie@linaro.org>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
BIOS can mark a pin as "no physical connection" if the port is used by an
integrated display which is not audio capable. And audio driver will overlook
such pins.
On Haswell, such a disconneted pin will keep muted and connected to the 1st
converter by default. But if the 1st convertor is assigned to a connected pin
for audio streaming. The muted disconnected pin can make the connected pin
no sound output.
So this patch avoids using assigned converters for all unused pins for Haswell,
including the disconected pins.
Signed-off-by: Mengdong Lin <mengdong.lin@intel.com>
Reviewed-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Currently we assume that userspace will shut down the compressed stream
correctly. However, if userspcae dies (e.g. cplay & ctrl-C) we dont
stop the stream before freeing it.
This now checks that the stream is stopped before freeing.
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Commit 'e7f3880cd9b98c5bf9391ae7acdec82b75403776'
tty: Fix recursive deadlock in tty_perform_flush()
introduced a regression where tcflush() does not generate
SIGTTOU for background process groups.
Make sure ioctl(TCFLSH) calls tty_check_change() when
invoked from the line discipline.
Cc: stable@vger.kernel.org # v3.10+
Reported-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Update the STI driver by setting cpu_possible_mask to make EMEV2
SMP work as expected together with the ARM broadcast timer.
This breakage was introduced by:
f7db706 ARM: 7674/1: smp: Avoid dummy clockevent being preferred over real hardware clock-event
Without this fix SMP operation is broken on EMEV2 since no
broadcast timer interrupts trigger on the secondary CPU cores.
Signed-off-by: Magnus Damm <damm@opensource.se>
Tested-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
direction bit
Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101)
[1] with the Windows App (EasyNote) works natively but fails when
Windows is running under KVM (and the USB device handed to KVM).
The reason is a USB control message
usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 wLength=0008
This goes to endpoint address 0x01 (wIndex); however, endpoint address
0x01 does not exist. There is an endpoint 0x81 though (same number,
but other direction); the app may have meant that endpoint instead.
The kernel thus rejects the IO and thus we see the failure.
Apparently, Linux is more strict here than Windows ... we can't change
the Win app easily, so that's a problem.
It seems that the Win app/driver is buggy here and the driver does not
behave fully according to the USB HID class spec that it claims to
belong to. The device seems to happily deal with that though (and
seems to not really care about this value much).
So the question is whether the Linux kernel should filter here.
Rejecting has the risk that somewhat non-compliant userspace apps/
drivers (most likely in a virtual machine) are prevented from working.
Not rejecting has the risk of confusing an overly sensitive device with
such a transfer. Given the fact that Windows does not filter it makes
this risk rather small though.
The patch makes the kernel more tolerant: If the endpoint address in
wIndex does not exist, but an endpoint with toggled direction bit does,
it will let the transfer through. (It does NOT change the message.)
With attached patch, the app in Windows in KVM works.
usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but needs 81
I suspect this will mostly affect apps in virtual environments; as on
Linux the apps would have been adapted to the stricter handling of the
kernel. I have done that for mine[2].
[1] http://www.pegatech.com/
[2] https://sourceforge.net/projects/notetakerpen/
Signed-off-by: Kurt Garloff <kurt@garloff.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
If NO_DMA=y:
drivers/built-in.o: In function `dma_set_coherent_mask':
include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
Reviewed-and-tested-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
There is a pending TD which is not freed after request finishes,
we do this due to a controller bug. This TD needs to be freed when
the driver is removed. It prints below error message when unload
chipidea driver at current code:
"ci_hdrc ci_hdrc.0: dma_pool_destroy ci_hw_td, b0001000 busy"
It indicates the buffer at dma pool are still in use.
This commit will free the pending TD at driver's removal procedure,
it can fix the problem described above.
Acked-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
If not, the PHY will be active even the controller is not in use.
We find this issue due to the PHY's clock refcount is not correct
due to -EPROBE_DEFER return after phy's init.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
It needs to free ci->hw_bank.regmap explicitly since it is not managed
resource.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When we rmmod gadget, the ci->driver needs to be cleared.
Otherwise, when we plug in usb cable again, the driver will
consider gadget is there, and go to enumeration procedure,
but in fact, it was removed.
ci_hdrc ci_hdrc.0: Connected to host
Unable to handle kernel paging request at virtual address 7f02a42c
pgd = 80004000
[7f02a42c] *pgd=3f13d811, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1] SMP ARM
Modules linked in: usb_f_acm u_serial libcomposite configfs [last unloaded: g_serial]
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0+ #42
task: 807dba88 ti: 807d0000 task.ti: 807d0000
PC is at udc_irq+0x8fc/0xea4
LR is at l2x0_cache_sync+0x5c/0x6c
pc : [<803de7f4>] lr : [<8001d0f0>] psr: 20000193
sp : 807d1d98 ip : 807d1d80 fp : 807d1df4
r10: af809900 r9 : 808184d4 r8 : 00080001
r7 : 00082001 r6 : afb711f8 r5 : afb71010 r4 : ffffffea
r3 : 7f02a41c r2 : afb71010 r1 : 807d1dc0 r0 : afb71068
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c53c7d Table: 3f01804a DAC: 00000017
Process swapper/0 (pid: 0, stack limit = 0x807d0238)
Stack: (0x807d1d98 to 0x807d2000)
1d80: 00000000 afb71014
1da0: 000040f6 00000000 00000001 00000000 00007530 00000000 afb71010 001dcd65
1dc0: 01000680 00400000 807d1e2c afb71010 0000004e 00000000 00000000 0000004b
1de0: 808184d4 af809900 807d1e0c 807d1df8 803dbc24 803ddf04 afba75c0 0000004e
1e00: 807d1e44 807d1e10 8007a19c 803dbb9c 8108e7e0 8108e7e0 9ceddce0 af809900
1e20: 0000004e 807d0000 0000004b 00000000 00000010 00000000 807d1e5c 807d1e48
1e40: 8007a334 8007a154 af809900 0000004e 807d1e74 807d1e60 8007d3b4 8007a2f0
1e60: 0000004b 807cce3c 807d1e8c 807d1e78 80079b08 8007d300 00000180 807d8ba0
1e80: 807d1eb4 807d1e90 8000eef4 80079aec 00000000 f400010c 807d8ce4 807d1ed8
1ea0: f4000100 96d5c75d 807d1ed4 807d1eb8 80008600 8000eeac 8042699c 60000013
1ec0: ffffffff 807d1f0c 807d1f54 807d1ed8 8000e180 800085dc 807d1f20 00000046
1ee0: 9cedd275 00000010 8108f080 807de294 00000001 807de248 96d5c75d 00000010
1f00: 00000000 807d1f54 00000000 807d1f20 8005ff54 8042699c 60000013 ffffffff
1f20: 9cedd275 00000010 00000005 8108f080 8108f080 00000001 807de248 8086bd00
1f40: 807d0000 00000001 807d1f7c 807d1f58 80426af0 80426950 807d0000 00000000
1f60: 808184c0 808184c0 807d8954 805b886c 807d1f8c 807d1f80 8000f294 80426a44
1f80: 807d1fac 807d1f90 8005f110 8000f288 807d1fac 807d8908 805b4748 807dc86c
1fa0: 807d1fbc 807d1fb0 805aa58c 8005f068 807d1ff4 807d1fc0 8077c860 805aa530
1fc0: ffffffff ffffffff 8077c330 00000000 00000000 807bef88 00000000 10c53c7d
1fe0: 807d88d0 807bef84 00000000 807d1ff8 10008074 8077c594 00000000 00000000
Backtrace:
[<803ddef8>] (udc_irq+0x0/0xea4) from [<803dbc24>] (ci_irq+0x94/0x14c)
[<803dbb90>] (ci_irq+0x0/0x14c) from [<8007a19c>] (handle_irq_event_percpu+0x54/0x19c)
r5:0000004e r4:afba75c0
[<8007a148>] (handle_irq_event_percpu+0x0/0x19c) from [<8007a334>] (handle_irq_event+0x50/0x70)
[<8007a2e4>] (handle_irq_event+0x0/0x70) from [<8007d3b4>] (handle_fasteoi_irq+0xc0/0x16c)
r5:0000004e r4:af809900
[<8007d2f4>] (handle_fasteoi_irq+0x0/0x16c) from [<80079b08>] (generic_handle_irq+0x28/0x38)
r5:807cce3c r4:0000004b
[<80079ae0>] (generic_handle_irq+0x0/0x38) from [<8000eef4>] (handle_IRQ+0x54/0xb4)
r4:807d8ba0 r3:00000180
[<8000eea0>] (handle_IRQ+0x0/0xb4) from [<80008600>] (gic_handle_irq+0x30/0x64)
r8:96d5c75d r7:f4000100 r6:807d1ed8 r5:807d8ce4 r4:f400010c
r3:00000000
[<800085d0>] (gic_handle_irq+0x0/0x64) from [<8000e180>] (__irq_svc+0x40/0x54)
Exception stack(0x807d1ed8 to 0x807d1f20)
1ec0: 807d1f20 00000046
1ee0: 9cedd275 00000010 8108f080 807de294 00000001 807de248 96d5c75d 00000010
1f00: 00000000 807d1f54 00000000 807d1f20 8005ff54 8042699c 60000013 ffffffff
r7:807d1f0c r6:ffffffff r5:60000013 r4:8042699c
[<80426944>] (cpuidle_enter_state+0x0/0xf4) from [<80426af0>] (cpuidle_idle_call+0xb8/0x174)
r9:00000001 r8:807d0000 r7:8086bd00 r6:807de248 r5:00000001
r4:8108f080
[<80426a38>] (cpuidle_idle_call+0x0/0x174) from [<8000f294>] (arch_cpu_idle+0x18/0x5c)
[<8000f27c>] (arch_cpu_idle+0x0/0x5c) from [<8005f110>] (cpu_startup_entry+0xb4/0x148)
[<8005f05c>] (cpu_startup_entry+0x0/0x148) from [<805aa58c>] (rest_init+0x68/0x80)
r7:807dc86c
[<805aa524>] (rest_init+0x0/0x80) from [<8077c860>] (start_kernel+0x2d8/0x334)
[<8077c588>] (start_kernel+0x0/0x334) from [<10008074>] (0x10008074)
Code: e59031e0 e51b203c e24b1034 e2820058 (e5933010)
---[ end trace f874b2c5533c04bc ]---
Kernel panic - not syncing: Fatal exception in interrupt
Tested-by: Marek Vasut <marex@denx.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Clocksource devices provided by DT can be disabled (status != "okay").
Instead of registering clocksource drivers for disabled nodes, respect
the device's status by skiping disabled nodes.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
Some variants of Exynos MCT, namely exynos4210-mct at the moment, use
normal, shared interrupts for local timers. This means that each
interrupt must have correct affinity set to fire only on CPU
corresponding to given local timer.
However after recent conversion of clocksource drivers to not use the
local timer API for local timer initialization any more, the point of
time when local timers get initialized changed and irq_set_affinity()
fails because the CPU is not marked as online yet.
This patch fixes this by moving the call to irq_set_affinity() to
CPU_ONLINE notification, so the affinity is being set when the CPU goes
online.
This fixes a regression introduced by commit
ee98d27df6 ARM: EXYNOS4: Divorce mct from local timer API
which rendered all Exynos4210 based boards unbootable due to
failing irq_set_affinity() making local timers inoperatible.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
This commit:
573145f08c2b92c45498468afbbba909f6ce6135
clocksource: armada-370-xp: Use CLOCKSOURCE_OF_DECLARE
replaced a call to the driver's timer initialization by a call to
clocksource_of_init(). However, it failed to select CONFIG_CLKSRC_OF.
Fix this by selecting CONFIG_CLKSRC_OF for Armada370/XP machines.
Without this change the kernel is stuck at: 'Calibrating delay loop...'.
Signed-off-by: Jean Pihet <jean.pihet@linaro.org>
Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
Since uhci-hcd, ehci-hcd, and xhci-hcd support runtime PM, the .pm
field in their pci_driver structures should be protected by CONFIG_PM
rather than CONFIG_PM_SLEEP. The corresponding change has already
been made for ohci-hcd.
Without this change, controllers won't do runtime suspend if system
suspend or hibernation isn't enabled.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 24f531371de1 (USB: EHCI: accept very late isochronous URBs)
changed the isochronous API provided by ehci-hcd. URBs submitted too
late, so that the time slots for all their packets have already
expired, are no longer rejected outright. Instead the submission is
accepted, and the URB completes normally with a -EXDEV error for each
packet. This is what client drivers expect.
This patch implements the same policy in ohci-hcd. The change is more
complicated than it was in ehci-hcd, because ohci-hcd doesn't scan for
isochronous completions in the same way as ehci-hcd does. Rather, it
depends on the hardware adding completed TDs to a "done queue". Some
OHCI controller don't handle this properly when a TD's time slot has
already expired, so we have to avoid adding such TDs to the schedule
in the first place. As a result, if the URB was submitted too late
then none of its TDs will get put on the schedule, so none of them
will end up on the done queue, so the driver will never realize that
the URB should be completed.
To solve this problem, the patch adds one to urb_priv->td_cnt for such
URBs, making it larger than urb_priv->length (td_cnt already gets set
to the number of TD's that had to be skipped because their slots have
expired). Each time an URB is given back, the finish_urb() routine
looks to see if urb_priv->td_cnt for the next URB on the same endpoint
is marked in this way. If so, it gives back the next URB right away.
This should be applied to all kernels containing commit 815fa7b91761
(USB: OHCI: fix logic for scheduling isochronous URBs).
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 24f531371de1 (USB: EHCI: accept very late isochronous URBs)
changed the isochronous API provided by ehci-hcd. URBs submitted too
late, so that the time slots for all their packets have already
expired, are no longer rejected outright. Instead the submission is
accepted, and the URB completes normally with a -EXDEV error for each
packet. This is what client drivers expect.
This patch implements the same policy in uhci-hcd. It should be
applied to all kernels containing commit c44b225077bb (UHCI: implement
new semantics for URB_ISO_ASAP).
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 24f531371de1 (USB: EHCI: accept very late isochronous URBs)
changed the isochronous API provided by ehci-hcd. URBs submitted too
late, so that the time slots for all their packets have already
expired, are no longer rejected outright. Instead the submission is
accepted, and the URB completes normally with a -EXDEV error for each
packet. This is what client drivers expect.
The same policy should be implemented in imx21-hcd, but I don't know
enough about the hardware to do it. As a second-best substitute, this
patch treats very late isochronous submissions as though the
URB_ISO_ASAP flag were set. I don't have any way to test this change,
unfortunately.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Sascha Hauer <kernel@pengutronix.de>
CC: Martin Fuzzey <mfuzzey@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus
Sarah writes:
xhci: Bug fixes for 3.12.
Hi Greg,
Here's five bug fixes for 3.12.
The first two bugs fix issues with the command cancellation handling,
which can lead to oopses or the xHCI driver attempting to handle
previously-completed transfers. People have been running into oopses
and odd behavior with command cancellation for a couple kernel releases,
so they're marked for stable.
The third patch fixes an issue with USB remote wakeup under xHCI that
can only be reproduced under ChromeOS. As discussed, this fix is not
urgent, and isn't marked for stable.
The fourth patch fixes a race condition between URB cancellation and
userspace clearing an endpoint stall. The fifth patch removes some
annoying dmesg spam when a USB 3.0 device is disconnected, by avoiding
sending a Set SEL request.
Sarah Sharp
|
|
Since commit b5dc0d10 (drm/imx: kill firstopen callback) the following probe
failure is seen:
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] No driver support for vblank timestamp query.
[drm] Initialized imx-drm 1.0.0 20120507 on minor 0
imx-ldb ldb.10: adding encoder failed with -16
imx-ldb: probe of ldb.10 failed with error -16
imx-ipuv3 2400000.ipu: IPUv3H probed
imx-ipuv3 2800000.ipu: IPUv3H probed
imx-ipuv3-crtc imx-ipuv3-crtc.0: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.0 failed with error -16
imx-ipuv3-crtc imx-ipuv3-crtc.1: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.1 failed with error -16
imx-ipuv3-crtc imx-ipuv3-crtc.2: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.2 failed with error -16
imx-ipuv3-crtc imx-ipuv3-crtc.3: adding crtc failed with -16.
imx-ipuv3-crtc: probe of imx-ipuv3-crtc.3 failed with error -16
The reason for the probe failure is that now 'imxdrm->references' is incremented
early in imx_drm_driver_load(), so the following checks in imx_drm_add_crtc()
and imx_drm_add_encoder():
if (imxdrm->references) {
ret = -EBUSY;
goto err_busy;
}
,will always fail.
Instead of manually keeping the references in the imx-drm driver, let's use
drm->open_count.
After this patch, lvds panel is functional on a mx6qsabrelite board.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Don't allow entry to iwctl_siwencodeext if device not open.
This fixes a race condition where wpa supplicant/network manager
enters the function when the device is already closed.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Cc: stable@vger.kernel.org # 3.8+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The vt6656 is prone to resetting on the usb bus.
It seems there is a race condition and wpa supplicant is
trying to open the device via iw_handlers before its actually
closed at a stage that the buffers are being removed.
The device is longer considered open when the
buffers are being removed. So move ~DEVICE_FLAGS_OPENED
flag to before freeing the device buffers.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
