- 11 Jun, 2014 40 commits
-
-
Mathias Nyman authored
commit b38f09cc upstream. Sony VAIO t-series machines are not capable of switching usb2 ports over from Intel EHCI to xHCI controller. If tried the USB2 port will be left unconnected and unusable. This patch should be backported to stable kernels as old as 3.12, that contain the commit 26b76798 "Intel xhci: refactor EHCI/xHCI port switching" Reported-by:
Jorge <xxopxe@gmail.com> Tested-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johan Hovold authored
commit c03890ff upstream. A recent patch that purported to fix firmware download on big-endian machines failed to add the corresponding sparse annotation to the i2c-header. This was reported by the kbuild test robot. Adding the appropriate annotation revealed another endianess bug related to the i2c-header Size-field in a code path that is exercised when the firmware is actually being downloaded (and not just verified and left untouched unless older than the firmware at hand). This patch adds the required sparse annotation to the i2c-header and makes sure that the Size-field is sent in little-endian byte order during firmware download also on big-endian machines. Note that this patch is only compile-tested, but that there is no functional change for little-endian systems. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Cc: Ludovic Drolez <ldrolez@debian.org> Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Alexej Starschenko authored
commit 8a61ba3a upstream. Adds product ID for the Novatel E371 PCI Express Mini Card. $ lsusb Bus 001 Device 024: ID 1410:9011 Novatel Wireless $ usb-devices T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 24 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1410 ProdID=9011 Rev=00.03 S: Manufacturer=Novatel Wireless, Inc. S: Product=Novatel Wireless HSPA S: SerialNumber=012773002115811 C: #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 6 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether I: If#= 7 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether Tested with kernel 3.2.0. Signed-off-by:
Alexej Starschenko <starschenko@gmail.com> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 7ac3764f upstream. The file include/uapi/linux/usb/cdc-wdm.h uses a __u16 so it needs to include types.h as well to make the build system happy. Fixes: 3edce1cf ("USB: cdc-wdm: implement IOCTL_WDM_MAX_COMMAND") Cc: Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Bjørn Mork authored
commit 7d189636 upstream. The include/uapi/linux/usb/cdc-wdm.h header defines cdc-wdm userspace APIs and should be exported by make headers_install. Fixes: 3edce1cf ("USB: cdc-wdm: implement IOCTL_WDM_MAX_COMMAND") Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
George McCollister authored
commit d0839d75 upstream. The NovaTech OrionLXm uses an onboard FTDI serial converter for JTAG and console access. Here is the lsusb output: Bus 004 Device 123: ID 0403:7c90 Future Technology Devices International, Ltd Signed-off-by:
George McCollister <george.mccollister@gmail.com> Signed-off-by:
-
Takashi Iwai authored
commit 192a98e2 upstream. The conversion to a fixup table for Replacer model with ALC260 in commit 20f7d928 took the wrong widget NID for COEF setups. Namely, NID 0x1a should have been used instead of NID 0x20, which is the common node for all Realtek codecs but ALC260. Fixes: 20f7d928 ('ALSA: hda/realtek - Replace ALC260 model=replacer with the auto-parser') Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Ronan Marquet authored
commit e30cf2d2 upstream. Correcion of wrong fixup entries add in commit ca8f0424 to replace static model quirk for PB V7900 laptop (will model). [note: the removal of ALC260_FIXUP_HP_PIN_0F chain is also needed as a part of the fix; otherwise the pin is set up wrongly as a headphone, and user-space (PulseAudio) may be wrongly trying to detect the jack state -- tiwai] Fixes: ca8f0424 ('ALSA: hda/realtek - Add the fixup codes for ALC260 model=will') Signed-off-by:
Ronan Marquet <ronan.marquet@orange.fr> Signed-off-by:
-
Takashi Iwai authored
commit 598e3061 upstream. ASUS A8JN with AD1986A codec seems following the normal EAPD in the normal order (0 = off, 1 = on) unlike other machines with AD1986A. Apply the workaround used for Toshiba laptop that showed the same problem. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=75041Signed-off-by:
-
Samuel Ortiz authored
commit 40b9397a upstream. 0466 was probably meant to be 0644, there's no reason why everyone except root could write there. Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Sean MacLennan authored
commit 9326c5ca upstream. A sparse error fixup removed a htons() which is required for the driver to function. This patch puts the htons() back and fixes the sparse warning correctly by changing the left side cast. Signed-off-by:
Sean MacLennan <seanm@seanm.ca> Signed-off-by:
-
Ben Hutchings authored
commit 28a821c3 upstream. This function is largely a duplicate of paste_selection() in drivers/tty/vt/selection.c, but with its own selection state. The speakup selection mechanism should really be merged with vt. For now, apply the changes from 'TTY: vt, fix paste_selection ldisc handling', 'tty: Make ldisc input flow control concurrency-friendly', and 'tty: Fix unsafe vt paste_selection()'. References: https://bugs.debian.org/735202 References: https://bugs.debian.org/744015Reported-by:
Paul Gevers <elbrus@debian.org> Reported-and-tested-by:
Jarek Czekalski <jarekczek@poczta.onet.pl> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Ian Abbott authored
commit ffed54dc upstream. I got a patch from the original author, Fred Brooks, to add a small settling delay after setting the AI channel multiplexor. The lack of delay resulted in unstable or scrambled data on faster processors. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Reported-by:
Fred Brooks <nsaspook@nsaspook.com> Signed-off-by:
-
Ben Hutchings authored
commit d7500135 upstream. Input is handled in softirq context, but when pasting we may need to sleep. speakup_paste_selection() currently tries to bodge this by busy-waiting if in_atomic(), but that doesn't help because the ldisc may also sleep. For bonus breakage, speakup_paste_selection() changes the state of current, even though it's not running in process context. Move it into a work item and make sure to cancel it on exit. References: https://bugs.debian.org/735202 References: https://bugs.debian.org/744015Reported-by:
-
Mathias Nyman authored
commit 5dc2808c upstream. Lists of endpoints are stored for bandwidth calculation for roothub ports. Make sure we remove all endpoints from the list before the whole device, containing its endpoints list_head stuctures, is freed. This used to be done in the wrong order in xhci_mem_cleanup(), and triggered an oops in resume from S4 (hibernate). Tested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
NeilBrown authored
commit 2ac295a5 upstream. Commit 8313b8e5 md: fix problem when adding device to read-only array with bitmap. added a called to md_reap_sync_thread() which cause a reshape thread to be interrupted (in particular, it could cause md_thread() to never even call md_do_sync()). However it didn't set MD_RECOVERY_INTR so ->finish_reshape() would not know that the reshape didn't complete. This only happens when mddev->ro is set and normally reshape threads don't run in that situation. But raid5 and raid10 can start a reshape thread during "run" is the array is in the middle of a reshape. They do this even if ->ro is set. So it is best to set MD_RECOVERY_INTR before abortingg the sync thread, just in case. Though it rare for this to trigger a problem it can cause data corruption because the reshape isn't finished properly. So it is suitable for any stable which the offending commit was applied to. (3.2 or later) Fixes: 8313b8e5Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
NeilBrown authored
commit 3991b31e upstream. If mddev->ro is set, md_to_sync will (correctly) abort. However in that case MD_RECOVERY_INTR isn't set. If a RESHAPE had been requested, then ->finish_reshape() will be called and it will think the reshape was successful even though nothing happened. Normally a resync will not be requested if ->ro is set, but if an array is stopped while a reshape is on-going, then when the array is started, the reshape will be restarted. If the array is also set read-only at this point, the reshape will instantly appear to success, resulting in data corruption. Consequently, this patch is suitable for any -stable kernel. Signed-off-by:
-
Richard Weinberger authored
commit b14ed2c2 upstream. attr.sched_policy is u32, therefore a comparison against < 0 is never true. Fix this by casting sched_policy to int. This issue was reported by coverity CID 1219934. Fixes: dbdb2275 ("sched: Disallow sched_attr::sched_policy < 0") Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/1401741514-7045-1-git-send-email-richard@nod.atSigned-off-by:
Ingo Molnar <mingo@kernel.org> Cc: Dave Jones <davej@redhat.com> Signed-off-by:
-
Martin K. Petersen authored
commit 3b8d2676 upstream. Queued trim only works for some users with MU05 firmware. Revert to blacklisting all firmware versions. Introduced by commit d121f7d0 ("libata: Update queued trim blacklist for M5x0 drives") which this effectively reverts, while retaining the blacklisting of M550. See https://bugzilla.kernel.org/show_bug.cgi?id=71371 for reports of trouble with MU05 firmware. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Tejun Heo <tj@kernel.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Christian König authored
commit 91b0275c upstream. The SDMA sometimes doesn't seem to work reliable. Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 3640da2f upstream. Setting the power state prior to restoring the display hardware leads to blank screens on some systems. Drop the power state set from dpm resume. The power state will get set as part of the mode set sequence. Also add an explicit power state set after mode set resume to cover PX and headless systems. bug: https://bugzilla.kernel.org/show_bug.cgi?id=76761Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Chris Wilson authored
commit 9aab8bff upstream. We only want to modifiy a single field in the userspace view of the execbuffer command buffer, so explicitly change that rather than copy everything back again. This serves two purposes: 1. The single fields are much cheaper to copy (constant size so the copy uses special case code) and much smaller than the whole array. 2. We modify the array for internal use that need to be masked from the user. Note: We need this backported since without it the next bugfix will blow up when userspace recycles batchbuffers and relocations. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Christian König authored
commit 60a44540 upstream. Signed-off-by:
-
Kirill Tkhai authored
commit 0f397f2c upstream. Throttled task is still on rq, and it may be moved to other cpu if user is playing with sched_setaffinity(). Therefore, unlocked task_rq() access makes the race. Juri Lelli reports he got this race when dl_bandwidth_enabled() was not set. Other thing, pointed by Peter Zijlstra: "Now I suppose the problem can still actually happen when you change the root domain and trigger a effective affinity change that way". To fix that we do the same as made in __task_rq_lock(). We do not use __task_rq_lock() itself, because it has a useful lockdep check, which is not correct in case of dl_task_timer(). We do not need pi_lock locked here. This case is an exception (PeterZ): "The only reason we don't strictly need ->pi_lock now is because we're guaranteed to have p->state == TASK_RUNNING here and are thus free of ttwu races". Signed-off-by:
Kirill Tkhai <tkhai@yandex.ru> Signed-off-by:
-
Lai Jiangshan authored
commit 6acbfb96 upstream. Lai found that: WARNING: CPU: 1 PID: 13 at arch/x86/kernel/smp.c:124 native_smp_send_reschedule+0x2d/0x4b() ... migration_cpu_stop+0x1d/0x22 was caused by set_cpus_allowed_ptr() assuming that cpu_active_mask is always a sub-set of cpu_online_mask. This isn't true since 5fbd036b ("sched: Cleanup cpu_active madness"). So set active and online at the same time to avoid this particular problem. Fixes: 5fbd036b ("sched: Cleanup cpu_active madness") Signed-off-by:
Lai Jiangshan <laijs@cn.fujitsu.com> Signed-off-by:
-
Juri Lelli authored
commit b0827819 upstream. Michael Kerrisk noticed that creating SCHED_DEADLINE reservations with certain parameters (e.g, a runtime of something near 2^64 ns) can cause a system freeze for some amount of time. The problem is that in the interface we have u64 sched_runtime; while internally we need to have a signed runtime (to cope with budget overruns) s64 runtime; At the time we setup a new dl_entity we copy the first value in the second. The cast turns out with negative values when sched_runtime is too big, and this causes the scheduler to go crazy right from the start. Moreover, considering how we deal with deadlines wraparound (s64)(a - b) < 0 we also have to restrict acceptable values for sched_{deadline,period}. This patch fixes the thing checking that user parameters are always below 2^63 ns (still large enough for everyone). It also rewrites other conditions that we check, since in __checkparam_dl we don't have to deal with deadline wraparounds and what we have now erroneously fails when the difference between values is too big. Reported-by:
Michael Kerrisk <mtk.manpages@gmail.com> Suggested-by:
Juri Lelli <juri.lelli@gmail.com> Signed-off-by:
-
Peter Zijlstra authored
commit ce5f7f82 upstream. The way we read POSIX one should only call sched_getparam() when sched_getscheduler() returns either SCHED_FIFO or SCHED_RR. Given that we currently return sched_param::sched_priority=0 for all others, extend the same behaviour to SCHED_DEADLINE. Requested-by:
-
Michael Kerrisk authored
commit 143cf23d upstream. The documented[1] behavior of sched_attr() in the proposed man page text is: sched_attr::size must be set to the size of the structure, as in sizeof(struct sched_attr), if the provided structure is smaller than the kernel structure, any additional fields are assumed '0'. If the provided structure is larger than the kernel structure, the kernel verifies all additional fields are '0' if not the syscall will fail with -E2BIG. As currently implemented, sched_copy_attr() returns -EFBIG for for this case, but the logic in sys_sched_setattr() converts that error to -EFAULT. This patch fixes the behavior. [1] http://thread.gmane.org/gmane.linux.kernel/1615615/focus=1697760Signed-off-by:
-
Peter Zijlstra authored
commit dbdb2275 upstream. The scheduler uses policy=-1 to preserve the current policy state to implement sys_sched_setparam(), this got exposed to userspace by accident through sys_sched_setattr(), cure this. Reported-by:
-
Ming Lei authored
commit aa0818c6 upstream. When there isn't enough vring descriptor for adding to vq, blk-mq will be put as stopped state until some of pending descriptors are completed & freed. Unfortunately, the vq's interrupt may come just before blk-mq's BLK_MQ_S_STOPPED flag is set, so the blk-mq will still be kept as stopped even though lots of descriptors are completed and freed in the interrupt handler. The worst case is that all pending descriptors are freed in the interrupt handler, and the queue is kept as stopped forever. This patch fixes the problem by starting/stopping blk-mq with holding vq_lock. Cc: Jens Axboe <axboe@kernel.dk> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 62376251. Ben rightly points out that commit 0bf1457f, which is what this original commit was reverting, never ended up in 3.14-stable, but was only for 3.15. So revert this patch as we now have the same check twice in a row, which is pretty pointless. Although the comments were "prettier"... Cc: Ben Hutchings <ben@decadent.org.uk> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Rafael Aquini <aquini@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Heinz Mauelshagen authored
commit f1daa838 upstream. The DM cache target cannot cope with discards that span multiple cache blocks, so each discard bio that spans more than one cache block must get split by the DM core. Signed-off-by:
Heinz Mauelshagen <heinzm@redhat.com> Acked-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Mike Snitzer authored
commit 80c57893 upstream. Commit 85ad643b ("dm thin: add timeout to stop out-of-data-space mode holding IO forever") introduced a fixed 60 second timeout. Users may want to either disable or modify this timeout. Allow the out-of-data-space timeout to be configured using the 'no_space_timeout' dm-thin-pool module param. Setting it to 0 will disable the timeout, resulting in IO being queued until more data space is added to the thin-pool. Signed-off-by:
-
Markos Chandras authored
commit 721a9205 upstream. Introduced by the following two commits: 75b5b5e0 "MIPS: Add support for FTLBs" 6de20451 "MIPS: Add printing of ES bit for Imgtec cores when cache error occurs" Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Reported-by:
Matheus Almeida <Matheus.Almeida@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Markos Chandras <markos.chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/6980/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Stefan Richter authored
commit 2fe2023a upstream. Undo a feature introduced in v3.14 by commit fcd46b34 "firewire: Enable remote DMA above 4 GB". That change raised the minimum address at which protocol drivers and user programs can register for request reception from 0x0001'0000'0000 to 0x8000'0000'0000. It turned out that at least one vendor-specific protocol exists which uses lower addresses: https://bugzilla.kernel.org/show_bug.cgi?id=76921 For the time being, revert most of commit fcd46b34 so that affected protocols work like with kernel v3.13 and before. Just keep the valid documentation parts from the regressing commit, and the ability to identify controllers which could be programmed to accept >32 bit physical DMA addresses. The rest of fcd46b34 should probably be brought back as an optional instead of default feature. Reported-by:
Fabien Spindler <fabien.spindler@inria.fr> Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Bibek Basu authored
commit c5450db8 upstream. While accessing cur_policy during executing events CPUFREQ_GOV_START, CPUFREQ_GOV_STOP, CPUFREQ_GOV_LIMITS, same mutex lock is not taken, dbs_data->mutex, which leads to race and data corruption while running continious suspend resume test. This is seen with ondemand governor with suspend resume test using rtcwake. Unable to handle kernel NULL pointer dereference at virtual address 00000028 pgd = ed610000 [00000028] *pgd=adf11831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM Modules linked in: nvhost_vi CPU: 1 PID: 3243 Comm: rtcwake Not tainted 3.10.24-gf5cf9e5 #1 task: ee708040 ti: ed61c000 task.ti: ed61c000 PC is at cpufreq_governor_dbs+0x400/0x634 LR is at cpufreq_governor_dbs+0x3f8/0x634 pc : [<c05652b8>] lr : [<c05652b0>] psr: 600f0013 sp : ed61dcb0 ip : 000493e0 fp : c1cc14f0 r10: 00000000 r9 : 00000000 r8 : 00000000 r7 : eb725280 r6 : c1cc1560 r5 : eb575200 r4 : ebad7740 r3 : ee708040 r2 : ed61dca8 r1 : 001ebd24 r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: ad61006a DAC: 00000015 [<c05652b8>] (cpufreq_governor_dbs+0x400/0x634) from [<c055f700>] (__cpufreq_governor+0x98/0x1b4) [<c055f700>] (__cpufreq_governor+0x98/0x1b4) from [<c0560770>] (__cpufreq_set_policy+0x250/0x320) [<c0560770>] (__cpufreq_set_policy+0x250/0x320) from [<c0561dcc>] (cpufreq_update_policy+0xcc/0x168) [<c0561dcc>] (cpufreq_update_policy+0xcc/0x168) from [<c0561ed0>] (cpu_freq_notify+0x68/0xdc) [<c0561ed0>] (cpu_freq_notify+0x68/0xdc) from [<c008eff8>] (notifier_call_chain+0x4c/0x8c) [<c008eff8>] (notifier_call_chain+0x4c/0x8c) from [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68) [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68) from [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28) [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28) from [<c00aac6c>] (pm_qos_update_bounded_target+0xd8/0x310) [<c00aac6c>] (pm_qos_update_bounded_target+0xd8/0x310) from [<c00ab3b0>] (__pm_qos_update_request+0x64/0x70) [<c00ab3b0>] (__pm_qos_update_request+0x64/0x70) from [<c004b4b8>] (tegra_pm_notify+0x114/0x134) [<c004b4b8>] (tegra_pm_notify+0x114/0x134) from [<c008eff8>] (notifier_call_chain+0x4c/0x8c) [<c008eff8>] (notifier_call_chain+0x4c/0x8c) from [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68) [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68) from [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28) [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28) from [<c00ac228>] (pm_notifier_call_chain+0x1c/0x34) [<c00ac228>] (pm_notifier_call_chain+0x1c/0x34) from [<c00ad38c>] (enter_state+0xec/0x128) [<c00ad38c>] (enter_state+0xec/0x128) from [<c00ad400>] (pm_suspend+0x38/0xa4) [<c00ad400>] (pm_suspend+0x38/0xa4) from [<c00ac114>] (state_store+0x70/0xc0) [<c00ac114>] (state_store+0x70/0xc0) from [<c027b1e8>] (kobj_attr_store+0x14/0x20) [<c027b1e8>] (kobj_attr_store+0x14/0x20) from [<c019cd9c>] (sysfs_write_file+0x104/0x184) [<c019cd9c>] (sysfs_write_file+0x104/0x184) from [<c0143038>] (vfs_write+0xd0/0x19c) [<c0143038>] (vfs_write+0xd0/0x19c) from [<c0143414>] (SyS_write+0x4c/0x78) [<c0143414>] (SyS_write+0x4c/0x78) from [<c000f080>] (ret_fast_syscall+0x0/0x30) Code: e1a00006 eb084346 e59b0020 e5951024 (e5903028) ---[ end trace 0488523c8f6b0f9d ]--- Signed-off-by:
Bibek Basu <bbasu@nvidia.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Lucas Stach authored
commit e3beb0ac upstream. This driver is using devres managed calls incorrectly, giving the cpu0 device as first parameter instead of the cpufreq platform device. This results in resources not being freed if the cpufreq platform device is unbound, for example if probing has to be deferred for a missing regulator. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Acked-by:
-
Rabin Vincent authored
commit 483a6c9d upstream. According to the ARM ARM, the behaviour is UNPREDICTABLE if the PC read from the exception return stack is not half word aligned. See the pseudo code for ExceptionReturn() and PopStack(). The signal handler's address has the bit 0 set, and setup_return() directly writes this to regs->ARM_pc. Current hardware happens to discard this bit, but QEMU's emulation doesn't and this makes processes crash. Mask out bit 0 before the exception return in order to get predictable behaviour. Fixes: 19c4d593 ("ARM: ARMv7-M: Add support for exception handling") Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Rabin Vincent <rabin@rab.in> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Andrey Ryabinin authored
commit 537094b6 upstream. According to arm procedure call standart r2 register is call-cloberred. So after the result of x expression was put into r2 any following function call in p may overwrite r2. To fix this, the result of p expression must be saved to the temporary variable before the assigment x expression to __r2. Signed-off-by:
Andrey Ryabinin <a.ryabinin@samsung.com> Reviewed-by:
Nicolas Pitre <nico@linaro.org> Signed-off-by:
-
Santosh Shilimkar authored
commit 4b353a70 upstream. On OMAP4 panda board, there have been several bug reports about boot hang and lock-ups with CPU_IDLE enabled. The root cause of the issue is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common code for right reasons but on OMAP4 which suffers from a nasty ROM code bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..}, we loose interrupts which leads to issues like lock-up, hangs etc. Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP flag} and 54769d65 {cpuidle: OMAP4: remove timer broadcast initialization} to avoid the issue. With this change, OMAP4 panda boards, the mentioned issues are getting fixed. We no longer loose interrupts which was the cause of the regression. Fixes: cb7094e8 (cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP flag) Fixes: ff999b8a (cpuidle: OMAP4: remove timer broadcast initialization) Cc: Roger Quadros <rogerq@ti.com> Cc: Kevin Hilman <khilman@linaro.org> Cc: Tony Lindgren <tony@atomide.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Reported-tested-by:
Roger Quadros <rogerq@ti.com> Reported-tested-by:
Kevin Hilman <khilman@linaro.org> Tested-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by:
-
