- 09 Dec, 2015 40 commits
-
-
Robin Murphy authored
commit 5accd17d upstream. For reasons not entirely apparent, but now enshrined in history, the architectural mapping of AArch32 banked registers to AArch64 registers actually orders SP_<mode> and LR_<mode> backwards compared to the intuitive r13/r14 order, for all modes except FIQ. Fix the compat_<reg>_<mode> macros accordingly, in the hope of avoiding subtle bugs with KVM and AArch32 guests. Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Acked-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mirza Krak authored
commit 7cecd9ab upstream. According to SJA1000 data sheet error-warning (EI) interrupt is not cleared by setting the controller in to reset-mode. Then if we have the following case: - system is suspended (echo mem > /sys/power/state) and SJA1000 is left in operating state - A bus error condition occurs which activates EI interrupt, system is still suspended which means EI interrupt will be not be handled nor cleared. If the above two events occur, on resume there is no way to return the SJA1000 to operating state, except to cycle power to it. By simply reading the IR register on start we will clear any previous conditions that could be present. Signed-off-by:
Mirza Krak <mirza.krak@hostmobility.com> Reported-by:
Christian Magnusson <Christian.Magnusson@semcon.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Marek Vasut authored
commit 562b103a upstream. The sizeof() is invoked on an incorrect variable, likely due to some copy-paste error, and this might result in memory corruption. Fix this. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Wolfgang Grandegger <wg@grandegger.com> Cc: netdev@vger.kernel.org Signed-off-by:
-
Johan Hedberg authored
commit a6ad2a6b upstream. The commit 89cbb063 introduced support for deferred connection parameter removal when unpairing by removing them only once an existing connection gets disconnected. However, it failed to address the scenario when we're *not* connected and do an unpair operation. What makes things worse is that most user space BlueZ versions will first issue a disconnect request and only then unpair, meaning the buggy code will be triggered every time. This effectively causes the kernel to resume scanning and reconnect to a device for which we've removed all keys and GATT database information. This patch fixes the issue by adding the missing call to the hci_conn_params_del() function to a branch which handles the case of no existing connection. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Dmitry Tunin authored
commit 18e0afab upstream. T: Bus=04 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=817b Rev=00.02 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb BugLink: https://bugs.launchpad.net/bugs/1506615Signed-off-by:
Dmitry Tunin <hanipouspilot@gmail.com> Signed-off-by:
-
Dmitry Tunin authored
commit cd355ff0 upstream. This adapter works with the existing linux-firmware. T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0930 ProdID=021c Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb BugLink: https://bugs.launchpad.net/bugs/1502781Signed-off-by:
-
David Herrmann authored
commit 660f0fc0 upstream. The HIDP specs define an idle-timeout which automatically disconnects a device. This has always been implemented in the HIDP layer and forced a synchronous shutdown of the hidp-scheduler. This works just fine, but lacks a forced disconnect on the underlying l2cap channels. This has been broken since: commit 5205185d Author: David Herrmann <dh.herrmann@gmail.com> Date: Sat Apr 6 20:28:47 2013 +0200 Bluetooth: hidp: remove old session-management The old session-management always forced an l2cap error on the ctrl/intr channels when shutting down. The new session-management skips this, as we don't want to enforce channel policy on the caller. In other words, if user-space removes an HIDP device, the underlying channels (which are *owned* and *referenced* by user-space) are still left active. User-space needs to call shutdown(2) or close(2) to release them. Unfortunately, this does not work with idle-timeouts. There is no way to signal user-space that the HIDP layer has been stopped. The API simply does not support any event-passing except for poll(2). Hence, we restore old behavior and force EUNATCH on the sockets if the HIDP layer is disconnected due to idle-timeouts (behavior of explicit disconnects remains unmodified). User-space can still call getsockopt(..., SO_ERROR, ...) ..to retrieve the EUNATCH error and clear sk_err. Hence, the channels can still be re-used (which nobody does so far, though). Therefore, the API still supports the new behavior, but with this patch it's also compatible to the old implicit channel shutdown. Reported-by:
Mark Haun <haunma@keteu.org> Reported-by:
Luiz Augusto von Dentz <luiz.dentz@gmail.com> Signed-off-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
-
Larry Finger authored
commit 1e6e6328 upstream. This adds the USB ID for the Sitecom WLA2100. The Windows 10 inf file was checked to verify that the addition is correct. Reported-by:
Frans van de Wiel <fvdw@fvdw.eu> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Frans van de Wiel <fvdw@fvdw.eu> Signed-off-by:
-
Dan Carpenter authored
commit 1f9c6e1b upstream. There were several bugs here. 1) The done label was in the wrong place so we didn't copy any information out when there was no command given. 2) We were using PAGE_SIZE as the size of the buffer instead of "PAGE_SIZE - pos". 3) snprintf() returns the number of characters that would have been printed if there were enough space. If there was not enough space (and we had fixed the memory corruption bug #2) then it would result in an information leak when we do simple_read_from_buffer(). I've changed it to use scnprintf() instead. I also removed the initialization at the start of the function, because I thought it made the code a little more clear. Fixes: 5e6e3a92 ('wireless: mwifiex: initial commit for Marvell mwifiex driver') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Tony Lindgren authored
commit 75c08f17 upstream. Commit 68bab866 ("mfd: twl6040: Optional clk32k clock handling") added clock handling for the 32k clock from palmas-clk. However, that patch did not consider a typical situation where twl6040 is built-in, and palmas-clk is a loadable module like we have in omap2plus_defconfig. If palmas-clk is not loaded before twl6040 probes, we will get a "clk32k is not handled" warning during booting. This means that any drivers relying on this clock will mysteriously fail, including omap5-uevm WLAN and audio. Note that for WLAN, we probably should also eventually get the clk32kgaudio for MMC3 directly as that's shared between audio and WLAN SDIO at least for omap5-uevm. It seems the WLAN chip cannot get it as otherwise MMC3 won't get properly probed. Fixes: 68bab866 ("mfd: twl6040: Optional clk32k clock handling") Signed-off-by:
Tony Lindgren <tony@atomide.com> Reviewed-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Linus Walleij authored
commit 7bdccef3 upstream. A static code checker found a memory leak in the Versatile ICST code. Fix it. Fixes: a183da63 "clk: versatile: respect parent rate in ICST clock" Reported-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Ingo Molnar authored
commit b2f73922 upstream. So the /proc/PID/stat 'wchan' field (the 30th field, which contains the absolute kernel address of the kernel function a task is blocked in) leaks absolute kernel addresses to unprivileged user-space: seq_put_decimal_ull(m, ' ', wchan); The absolute address might also leak via /proc/PID/wchan as well, if KALLSYMS is turned off or if the symbol lookup fails for some reason: static int proc_pid_wchan(struct seq_file *m, struct pid_namespace *ns, struct pid *pid, struct task_struct *task) { unsigned long wchan; char symname[KSYM_NAME_LEN]; wchan = get_wchan(task); if (lookup_symbol_name(wchan, symname) < 0) { if (!ptrace_may_access(task, PTRACE_MODE_READ)) return 0; seq_printf(m, "%lu", wchan); } else { seq_printf(m, "%s", symname); } return 0; } This isn't ideal, because for example it trivially leaks the KASLR offset to any local attacker: fomalhaut:~> printf "%016lx\n" $(cat /proc/$$/stat | cut -d' ' -f35) ffffffff8123b380 Most real-life uses of wchan are symbolic: ps -eo pid:10,tid:10,wchan:30,comm and procps uses /proc/PID/wchan, not the absolute address in /proc/PID/stat: triton:~/tip> strace -f ps -eo pid:10,tid:10,wchan:30,comm 2>&1 | grep wchan | tail -1 open("/proc/30833/wchan", O_RDONLY) = 6 There's one compatibility quirk here: procps relies on whether the absolute value is non-zero - and we can provide that functionality by outputing "0" or "1" depending on whether the task is blocked (whether there's a wchan address). These days there appears to be very little legitimate reason user-space would be interested in the absolute address. The absolute address is mostly historic: from the days when we didn't have kallsyms and user-space procps had to do the decoding itself via the System.map. So this patch sets all numeric output to "0" or "1" and keeps only symbolic output, in /proc/PID/wchan. ( The absolute sleep address can generally still be profiled via perf, by tasks with sufficient privileges. ) Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <andreyknvl@google.com> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Kostya Serebryany <kcc@google.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: kasan-dev <kasan-dev@googlegroups.com> Cc: linux-kernel@vger.kernel.org Link: http://lkml.kernel.org/r/20150930135917.GA3285@gmail.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Maxime Ripard authored
commit 2502d0ef upstream. The CPU_MAP register is duplicated for each CPUs at different addresses, each instance being at a different address. However, the code so far was using CONFIG_NR_CPUS to initialise the CPU_MAP registers for each registers, while the SoCs embed at most 4 CPUs. This is especially an issue with multi_v7_defconfig, where CONFIG_NR_CPUS is currently set to 16, resulting in writes to registers that are not CPU_MAP. Fixes: c5aff182 ("net: mvneta: driver for Marvell Armada 370/XP network unit") Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Oren Givon authored
commit 4ab75944 upstream. Add some new PCI IDs for the 8260 series which were missing. The following sub-system IDs were added: 0x0130, 0x1130, 0x0132, 0x1132, 0x1150, 0x8110, 0x9110, 0x8130, 0x9130, 0x8132, 0x9132, 0x8150, 0x9150, 0x0044, 0x0930 Signed-off-by:
Oren Givon <oren.givon@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit 03a19cbb upstream. The hardware bug in the commit mentioned below forces us not to re-enable the clock gating in the Host Cluster. The impact on the power consumption is minimal and it allows the WAKE_ME interrupt to propagate. Fixes: c9fdec9f ("iwlwifi: pcie: fix prepare card flow") Signed-off-by:
-
Christophe Ricard authored
commit e65917b6 upstream. When receiving data in nci_hci_msg_rx_work, extract pipe value using NCI_HCP_MSG_GET_PIPE macro. Signed-off-by:
Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Christophe Ricard authored
commit d8cd37ed upstream. When sending HCI data over NCI, HCI return code is part of the NCI data. In order to get correctly the HCI return code, we assume the NCI communication is successful and extract the return code for the nci_hci functions return code. This is done because nci_to_errno does not match hci return code value. Signed-off-by:
-
Christophe Ricard authored
commit 500c4ef0 upstream. When sending HCI data over NCI, cmd information should be present only on the first packet. Each packet shall be specifically allocated and sent to the NCI layer. Signed-off-by:
-
Ola Olsson authored
commit 4baf6bea upstream. If parse_acl_data succeeds but the subsequent parsing of smps attributes fails, there will be a memory leak due to early returns. Fix that by moving the ACL parsing later. Fixes: 18998c38 ("cfg80211: allow requesting SMPS mode on ap start") Signed-off-by:
Ola Olsson <ola.olsson@sonymobile.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Janusz.Dziedzic@tieto.com authored
commit 519ee691 upstream. In case of one shot NOA the interval can be 0, catch that instead of potentially (depending on the driver) crashing like this: divide error: 0000 [#1] SMP [...] Call Trace: <IRQ> [<ffffffffc08e891c>] ieee80211_extend_absent_time+0x6c/0xb0 [mac80211] [<ffffffffc08e8a17>] ieee80211_update_p2p_noa+0xb7/0xe0 [mac80211] [<ffffffffc069cc30>] ath9k_p2p_ps_timer+0x170/0x190 [ath9k] [<ffffffffc070adf8>] ath_gen_timer_isr+0xc8/0xf0 [ath9k_hw] [<ffffffffc0691156>] ath9k_tasklet+0x296/0x2f0 [ath9k] [<ffffffff8107ad65>] tasklet_action+0xe5/0xf0 [...] Signed-off-by:
Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by:
-
Arik Nemtsov authored
commit 254d3dfe upstream. In TDLS channel-switch operations the chandef can sometimes be NULL. Avoid an oops in the trace code for these cases and just print a chandef full of zeros. Fixes: a7a6bdd0 ("mac80211: introduce TDLS channel switch ops") Signed-off-by:
Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by:
-
Johannes Berg authored
commit 8ec6d978 upstream. The ifmgd->ave_beacon_signal value cannot be taken as is for comparisons, it must be divided by since it's represented like that for better accuracy of the EWMA calculations. This would lead to invalid driver RSSI events. Fix the used value. Fixes: 615f7b9b ("mac80211: add driver RSSI threshold events") Signed-off-by:
-
Andrei Otcheretianski authored
commit a64cba3c upstream. Local request to deauthenticate wasn't handled while associating, thus the association could continue even when the user space required to disconnect. Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by:
-
Andrew Cooper authored
commit 581b7f15 upstream. There appears to be no formal statement of what pv_irq_ops.save_fl() is supposed to return precisely. Native returns the full flags, while lguest and Xen only return the Interrupt Flag, and both have comments by the implementations stating that only the Interrupt Flag is looked at. This may have been true when initially implemented, but no longer is. To make matters worse, the Xen PVOP leaves the upper bits undefined, making the BUG_ON() undefined behaviour. Experimentally, this now trips for 32bit PV guests on Broadwell hardware. The BUG_ON() is consistent for an individual build, but not consistent for all builds. It has also been a sitting timebomb since SMAP support was introduced. Use native_save_fl() instead, which will obtain an accurate view of the AC flag. Signed-off-by:
Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by:
David Vrabel <david.vrabel@citrix.com> Tested-by:
Rusty Russell <rusty@rustcorp.com.au> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: <lguest@lists.ozlabs.org> Cc: Xen-devel <xen-devel@lists.xen.org> Link: http://lkml.kernel.org/r/1433323874-6927-1-git-send-email-andrew.cooper3@citrix.comSigned-off-by:
-
Borislav Petkov authored
commit 04633df0 upstream. When we get loaded by a 64-bit bootloader, kernel entry point is startup_64 in head_64.S. We don't trust any and all bootloaders because some will fiddle with CPU configuration so we go ahead and massage each CPU into sanity again. For example, some dell BIOSes have this XD disable feature which set IA32_MISC_ENABLE[34] and disable NX. This might be some dumb workaround for other OSes but Linux sure doesn't need it. A similar thing is present in the Surface 3 firmware - see https://bugzilla.kernel.org/show_bug.cgi?id=106051 - which sets this bit only on the BSP: # rdmsr -a 0x1a0 400850089 850089 850089 850089 I know, right?! There's not even an off switch in there. So fix all those cases by sanitizing the 64-bit entry point too. For that, make verify_cpu() callable in 64-bit mode also. Requested-and-debugged-by:
"H. Peter Anvin" <hpa@zytor.com> Reported-and-tested-by:
Bastien Nocera <bugzilla@hadess.net> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1446739076-21303-1-git-send-email-bp@alien8.deSigned-off-by:
-
Krzysztof Mazur authored
commit 68accac3 upstream. The commit f5f3497c extended the low identity mapping. However, if the kernel uses more than 2 GB (VMSPLIT_2G_OPT or VMSPLIT_1G memory split), the normal memory mapping is overwritten by the low identity mapping causing a crash. To avoid overwritting, limit the low identity map to cover only memory before kernel range (PAGE_OFFSET). Fixes: f5f3497c "x86/setup: Extend low identity map to cover whole kernel range Signed-off-by:
Krzysztof Mazur <krzysiek@podlesie.net> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Matt Fleming <matt.fleming@intel.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Link: http://lkml.kernel.org/r/1446815916-22105-1-git-send-email-krzysiek@podlesie.netSigned-off-by:
-
Paolo Bonzini authored
commit f5f3497c upstream. On 32-bit systems, the initial_page_table is reused by efi_call_phys_prolog as an identity map to call SetVirtualAddressMap. efi_call_phys_prolog takes care of converting the current CPU's GDT to a physical address too. For PAE kernels the identity mapping is achieved by aliasing the first PDPE for the kernel memory mapping into the first PDPE of initial_page_table. This makes the EFI stub's trick "just work". However, for non-PAE kernels there is no guarantee that the identity mapping in the initial_page_table extends as far as the GDT; in this case, accesses to the GDT will cause a page fault (which quickly becomes a triple fault). Fix this by copying the kernel mappings from swapper_pg_dir to initial_page_table twice, both at PAGE_OFFSET and at identity mapping. For some reason, this is only reproducible with QEMU's dynamic translation mode, and not for example with KVM. However, even under KVM one can clearly see that the page table is bogus: $ qemu-system-i386 -pflash OVMF.fd -M q35 vmlinuz0 -s -S -daemonize $ gdb (gdb) target remote localhost:1234 (gdb) hb *0x02858f6f Hardware assisted breakpoint 1 at 0x2858f6f (gdb) c Continuing. Breakpoint 1, 0x02858f6f in ?? () (gdb) monitor info registers ... GDT= 0724e000 000000ff IDT= fffbb000 000007ff CR0=0005003b CR2=ff896000 CR3=032b7000 CR4=00000690 ... The page directory is sane: (gdb) x/4wx 0x32b7000 0x32b7000: 0x03398063 0x03399063 0x0339a063 0x0339b063 (gdb) x/4wx 0x3398000 0x3398000: 0x00000163 0x00001163 0x00002163 0x00003163 (gdb) x/4wx 0x3399000 0x3399000: 0x00400003 0x00401003 0x00402003 0x00403003 but our particular page directory entry is empty: (gdb) x/1wx 0x32b7000 + (0x724e000 >> 22) * 4 0x32b7070: 0x00000000 [ It appears that you can skate past this issue if you don't receive any interrupts while the bogus GDT pointer is loaded, or if you avoid reloading the segment registers in general. Andy Lutomirski provides some additional insight: "AFAICT it's entirely permissible for the GDTR and/or LDT descriptor to point to unmapped memory. Any attempt to use them (segment loads, interrupts, IRET, etc) will try to access that memory as if the access came from CPL 0 and, if the access fails, will generate a valid page fault with CR2 pointing into the GDT or LDT." Up until commit 23a0d4e8 ("efi: Disable interrupts around EFI calls, not in the epilog/prolog calls") interrupts were disabled around the prolog and epilog calls, and the functional GDT was re-installed before interrupts were re-enabled. Which explains why no one has hit this issue until now. ] Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Reported-by:
Laszlo Ersek <lersek@redhat.com> Cc: <stable@vger.kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Signed-off-by:
Matt Fleming <matt.fleming@intel.com> [ Updated changelog. ] Signed-off-by:
-
Eric Northup authored
commit 54a20552 upstream. It was found that a guest can DoS a host by triggering an infinite stream of "alignment check" (#AC) exceptions. This causes the microcode to enter an infinite loop where the core never receives another interrupt. The host kernel panics pretty quickly due to the effects (CVE-2015-5307). Signed-off-by:
Eric Northup <digitaleric@google.com> Signed-off-by:
-
Radim Krčmář authored
commit c77f3fab upstream. After moving PIR to IRR, the interrupt needs to be delivered manually. Reported-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
-
James Hogan authored
commit 585bb8f9 upstream. If either of the memory allocations in kvm_arch_vcpu_create() fail, the vcpu which has been allocated and kvm_vcpu_init'd doesn't get uninit'd in the error handling path. Add a call to kvm_vcpu_uninit() to fix this. Fixes: 669e846e ("KVM/MIPS32: MIPS arch specific APIs for KVM") Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Gleb Natapov <gleb@kernel.org> Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by:
-
James Hogan authored
commit c5c2a3b9 upstream. The immediate field of the CACHE instruction is signed, so ensure that it gets sign extended by casting it to an int16_t rather than just masking the low 16 bits. Fixes: e685c689 ("KVM/MIPS32: Privileged instruction/target branch emulation.") Signed-off-by:
-
James Hogan authored
commit 002374f3 upstream. ASID restoration on guest resume should determine the guest execution mode based on the guest Status register rather than bit 30 of the guest PC. Fix the two places in locore.S that do this, loading the guest status from the cop0 area. Note, this assembly is specific to the trap & emulate implementation of KVM, so it doesn't need to check the supervisor bit as that mode is not implemented in the guest. Fixes: b680f70f ("KVM/MIPS32: Entry point for trampolining to...") Signed-off-by:
-
Hauke Mehrtens authored
commit 4e7d30db upstream. This adds a basic implementation of clk_round_rate() The clk_round_rate() function is called by multiple drivers and subsystems now and the lantiq clk driver is supposed to export this, but doesn't do so, this causes linking problems like this one: ERROR: "clk_round_rate" [drivers/media/v4l2-core/videodev.ko] undefined! Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Acked-by:
John Crispin <blogic@openwrt.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11358/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Arnd Bergmann authored
commit 54c09889 upstream. The z2 machine calls pxa27x_set_pwrmode() in order to power off the machine, but this function gets discarded early at boot because it is marked __init, as pointed out by kbuild: WARNING: vmlinux.o(.text+0x145c4): Section mismatch in reference from the function z2_power_off() to the function .init.text:pxa27x_set_pwrmode() The function z2_power_off() references the function __init pxa27x_set_pwrmode(). This is often because z2_power_off lacks a __init annotation or the annotation of pxa27x_set_pwrmode is wrong. This removes the __init section modifier to fix rebooting and the build error. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: ba4a90a6 ("ARM: pxa/z2: fix building error of pxa27x_cpu_suspend() no longer available") Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Tony Lindgren authored
commit 0efc898a upstream. Commit 99f84cae ("ARM: dts: add wl12xx/wl18xx bindings") added device tree bindings for the TI WLAN SDIO on many omap variants. I recall wondering how come omap5-uevm did not have the WLAN added and this issue has been bugging me for a while now, and I finally tracked it down to a bad pinmux regression, and a missing deferred probe handling for the 32k clock from palmas that's requested by twl6040. Basically 392adaf7 ("ARM: dts: omap5-evm: Add mcspi data") added pin muxing for mcspi4 that conflicts with the onboard WLAN. While some omap5-uevm don't have WLAN populated, the pins are not reused for other devices. And as the SDIO bus should be probed, let's try to enable WLAN by default. Let's fix the regression and add the WLAN configuration as done for the other boards in 99f84cae ("ARM: dts: add wl12xx/wl18xx bindings"). And let's use the new MMC pwrseq for the 32k clock as suggested by Javier Martinez Canillas <javier@dowhile0.org>. Note that without a related deferred probe fix for twl6040, the 32k clock is not initialized if palmas-clk is a module and twl6040 is built-in. Let's also use the generic "non-removable" instead of the legacy "ti,non-removable" property while at it. And finally, note that omap5 seems to require WAKEUP_EN for the WLAN GPIO interrupt. Fixes: 392adaf7 ("ARM: dts: omap5-evm: Add mcspi data") Cc: Sourav Poddar <sourav.poddar@ti.com> Signed-off-by:
-
Patrick Doyle authored
commit 5fcf8d1a upstream. fncpy() requires that the source and the destination are both 8-byte aligned. Signed-off-by:
Patrick Doyle <pdoyle@irobot.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Fixes: d94e688c ("ARM: at91/pm: move the copying the sram function to the sram initialization phase") Signed-off-by:
-
Holger Busse authored
commit d1a9c24a upstream. Correcting the dma declaration for i2c1 dma. Signed-off-by:
Holger Busse <h.busse@kathrein-sachsen.de> Signed-off-by:
-
Dmitry Osipenko authored
commit e77b675f upstream. Commit 72daceb9 ("net: rfkill: gpio: Add default GPIO driver mappings for ACPI") removed possibility to request GPIO by table index for non-ACPI platforms without changing its users. As result "shutdown" GPIO request will fail if request for "reset" GPIO succeeded or "reset" will be requested instead of "shutdown" if "reset" wasn't defined. Fix it by making gpiod_lookup_table use con_id's instead of indexes. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Fixes: 72daceb9 (net: rfkill: gpio: Add default GPIO driver mappings for ACPI) Acked-by:
Alexandre Courbot <acourbot@nvidia.com> Reviewed-by:
Marc Dietrich <marvin24@gmx.de> Tested-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Peter Chen authored
commit facf47ee upstream. For imx27, it needs three clocks to let the controller work, the old code is wrong, and usbmisc has not included clock handling code any more. Without this patch, it will cause below data abort when accessing usbmisc registers. usbcore: registered new interface driver usb-storage Unhandled fault: external abort on non-linefetch (0x008) at 0xf4424600 pgd = c0004000 [f4424600] *pgd=10000452(bad) Internal error: : 8 [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 4.1.0-next-20150701-dirty #3089 Hardware name: Freescale i.MX27 (Device Tree Support) task: c7832b60 ti: c783e000 task.ti: c783e000 PC is at usbmisc_imx27_init+0x4c/0xbc LR is at usbmisc_imx27_init+0x40/0xbc pc : [<c03cb5c0>] lr : [<c03cb5b4>] psr: 60000093 sp : c783fe08 ip : 00000000 fp : 00000000 r10: c0576434 r9 : 0000009c r8 : c7a773a0 r7 : 01000000 r6 : 60000013 r5 : c7a776f0 r4 : c7a773f0 r3 : f4424600 r2 : 00000000 r1 : 00000001 r0 : 00000001 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: a0004000 DAC: 00000017 Process swapper (pid: 1, stack limit = 0xc783e190) Stack: (0xc783fe08 to 0xc7840000) Signed-off-by:
Peter Chen <peter.chen@freescale.com> Reported-by:
Fabio Estevam <fabio.estevam@freescale.com> Tested-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Peter Ujfalusi authored
commit 696d8b70 upstream. In case when the interrupt happened for the second eDMA the channel number was incorrectly passed to the client driver. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
