- 05 5月, 2015 4 次提交
-
-
由 Grygorii Strashko 提交于
The interrupt polarity provided in devicetree is used to configure the interrupt controller(ARM GIC), however, it seems that we have an inverter at the GIC boundary inside AM57xx which inverts the signal input from sys_irq external interrupt source. Further, as per GIC distributor TRM, http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438d/BGBHIACJ.html#BABJFCFB ARM GIC distributor does not support IRQ trigger type IRQ_TYPE_LEVEL_LOW, and only rising or level high signals. However, for some reason, the current configuration(which gets ignored by GIC driver) functions on some platforms, however, on few platforms results in infinite interrupts hogging the system down. Switch over to rising edge for GIC configuration which is also aligned with trigger point from the RTC chip and the internal inversion. Fixes: 5a0f93c6 ("ARM: dts: Add am57xx-beagle-x15") Signed-off-by: NGrygorii Strashko <Grygorii.Strashko@linaro.org> Signed-off-by: NNishanth Menon <nm@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Sebastian Reichel 提交于
Add missing #iommu-cells property to the isp and iva iommu nodes. This fixes the binding (property is required according to the generic iommu binding) and removes the following kernel warning triggered once the iommu nodes are referenced: [ 0.647521] /ocp/isp@480bc000: could not get #iommu-cells for /ocp/mmu@480bd400 Signed-off-by: NSebastian Reichel <sre@kernel.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: NSakari Ailus <sakari.ailus@iki.fi> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Roger Quadros 提交于
We need to enable EXTCON_USB_GPIO_USB and not EXTCON_GPIO_USB. Fixes: c08a54c0 ("ARM: omap2plus_defconfig: Enable EXTCON_GPIO_USB") Reported-by: NNishant Menon <nm@ti.com> Signed-off-by: NRoger Quadros <rogerq@ti.com> Acked-by-by: Nishanth Menon <nm@ti.com Tested-by: Nishanth Menon <nm@ti.com Reviewed-by: NFelipe Balbi <balbi@ti.com> Acked-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Pavel Machek 提交于
N900 audio recording needs that codec provides bias voltage for integrated digital microphone and headset microphone depending which one is used. Digital microphone uses 2 V bias and it comes from the codec A part. Codec B part drives the headset microphone bias and that is set to 2.5 V. Cc: stable@vger.kernel.org # v3.16+ Signed-off-by: NPavel Machek <pavel@ucw.cz> [Jarkko: Headset mic bias changed to 2 (2.5 V) as it was before commit e2e8bfdf ("ASoC: tlv320aic3x: Convert mic bias to a supply widget")] Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 04 5月, 2015 1 次提交
-
-
由 Tony Lindgren 提交于
If we use a combination of VMODE and I2C4 for retention modes, eventually the off idle power consumption will creep up by about 23mW, even during off mode with I2C4 always staying enabled. Turns out this is because of erratum i531 "Extra Power Consumed When Repeated Start Operation Mode Is Enabled on I2C Interface Dedicated for Smart Reflex (I2C4)" as pointed out by Nishanth Menon <nm@ti.com>. Let's fix the issue by adding i2c_cfg_clear_mask for the bits to clear when initializing the I2C4 adapter so we can clear SREN bit that drives the I2C4 lines low otherwise when there is no traffic. Fixes: 3b8c4ebb ("ARM: OMAP3: Fix idle mode signaling for Cc: stable@vger.kernel.org # v3.16+ sys_clkreq and sys_off_mode") Cc: Kevin Hilman <khilman@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Reviewed-by: NNishanth Menon <nm@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 27 4月, 2015 1 次提交
-
-
由 Andy Lutomirski 提交于
AMD CPUs don't reinitialize the SS descriptor on SYSRET, so SYSRET with SS == 0 results in an invalid usermode state in which SS is apparently equal to __USER_DS but causes #SS if used. Work around the issue by setting SS to __KERNEL_DS __switch_to, thus ensuring that SYSRET never happens with SS set to NULL. This was exposed by a recent vDSO cleanup. Fixes: e7d6eefa x86/vdso32/syscall.S: Do not load __USER32_DS to %ss Signed-off-by: NAndy Lutomirski <luto@kernel.org> Cc: Peter Anvin <hpa@zytor.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Denys Vlasenko <vda.linux@googlemail.com> Cc: Brian Gerst <brgerst@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 24 4月, 2015 6 次提交
-
-
由 Linus Torvalds 提交于
Commit cae2a173 ("x86: clean up/fix 'copy_in_user()' tail zeroing") fixed the failure case tail zeroing of one special case of the x86-64 generic user-copy routine, namely when used for the user-to-user case ("copy_in_user()"). But in the process it broke an even more unusual case: using the user copy routine for kernel-to-kernel copying. Now, normally kernel-kernel copies are obviously done using memcpy(), but we have a couple of special cases when we use the user-copy functions. One is when we pass a kernel buffer to a regular user-buffer routine, using set_fs(KERNEL_DS). That's a "normal" case, and continued to work fine, because it never takes any faults (with the possible exception of a silent and successful vmalloc fault). But Jan Beulich pointed out another, very unusual, special case: when we use the user-copy routines not because it's a path that expects a user pointer, but for a couple of ftrace/kgdb cases that want to do a kernel copy, but do so using "unsafe" buffers, and use the user-copy routine to gracefully handle faults. IOW, for probe_kernel_write(). And that broke for the case of a faulting kernel destination, because we saw the kernel destination and wanted to try to clear the tail of the buffer. Which doesn't work, since that's what faults. This only triggers for things like kgdb and ftrace users (eg trying setting a breakpoint on read-only memory), but it's definitely a bug. The fix is to not compare against the kernel address start (TASK_SIZE), but instead use the same limits "access_ok()" uses. Reported-and-tested-by: NJan Beulich <jbeulich@suse.com> Cc: stable@vger.kernel.org # 4.0 Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Ard Biesheuvel 提交于
Patch e68410eb ("crypto: x86/sha512_ssse3 - move SHA-384/512 SSSE3 implementation to base layer") changed the prototypes of the core asm SHA-512 implementations so that they are compatible with the prototype used by the base layer. However, in one instance, the register that was used for passing the input buffer was reused as a scratch register later on in the code, and since the input buffer param changed places with the digest param -which needs to be written back before the function returns- this resulted in the scratch register to be dereferenced in a memory write operation, causing a GPF. Fix this by changing the scratch register to use the same register as the input buffer param again. Fixes: e68410eb ("crypto: x86/sha512_ssse3 - move SHA-384/512 SSSE3 implementation to base layer") Reported-By: NBobby Powers <bobbypowers@gmail.com> Tested-By: NBobby Powers <bobbypowers@gmail.com> Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Ley Foon Tan 提交于
- flush dcache before flush instruction cache - remork update_mmu_cache and flush_dcache_page - add shmparam.h Signed-off-by: NLey Foon Tan <lftan@altera.com>
-
由 Ezequiel Garcia 提交于
Reported by the header checker (CONFIG_HEADERS_CHECK=y): CHECK usr/include/asm/ (31 files) ./usr/include/asm/ptrace.h:77: found __[us]{8,16,32,64} type without #include <linux/types.h> Signed-off-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar> Acked-by: NLey Foon Tan <lftan@altera.com>
-
由 Steven Miao 提交于
Signed-off-by: NSteven Miao <realmz6@gmail.com>
-
由 Chen Gang 提交于
The related syscalls are below which may cause samples/kdbus building break in next-20150401 tree, the related information and error: CALL scripts/checksyscalls.sh <stdin>:1223:2: warning: #warning syscall kcmp not implemented [-Wcpp] <stdin>:1226:2: warning: #warning syscall finit_module not implemented [-Wcpp] <stdin>:1229:2: warning: #warning syscall sched_setattr not implemented [-Wcpp] <stdin>:1232:2: warning: #warning syscall sched_getattr not implemented [-Wcpp] <stdin>:1235:2: warning: #warning syscall renameat2 not implemented [-Wcpp] <stdin>:1238:2: warning: #warning syscall seccomp not implemented [-Wcpp] <stdin>:1241:2: warning: #warning syscall getrandom not implemented [-Wcpp] <stdin>:1244:2: warning: #warning syscall memfd_create not implemented [-Wcpp] <stdin>:1247:2: warning: #warning syscall bpf not implemented [-Wcpp] <stdin>:1250:2: warning: #warning syscall execveat not implemented [-Wcpp] [...] HOSTCC samples/kdbus/kdbus-workers samples/kdbus/kdbus-workers.c: In function ‘prime_new’: samples/kdbus/kdbus-workers.c:930:18: error: ‘__NR_memfd_create’ undeclared (first use in this function) p->fd = syscall(__NR_memfd_create, "prime-area", MFD_CLOEXEC); ^ samples/kdbus/kdbus-workers.c:930:18: note: each undeclared identifier is reported only once for each function it appears in Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com>
-
- 23 4月, 2015 17 次提交
-
-
由 Rickard Strandqvist 提交于
Remove the function kgdb_post_primary_code() that is not used anywhere. This was partially found by using a static code analysis program called cppcheck. Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Acked-by: NSonic Zhang <sonic.zhang@analog.com>
-
由 Steven Miao 提交于
Signed-off-by: NSteven Miao <realmz6@gmail.com>
-
由 Steven Miao 提交于
Signed-off-by: NSteven Miao <realmz6@gmail.com>
-
由 Scott Jiang 提交于
Signed-off-by: NScott Jiang <scott.jiang.linux@gmail.com> Signed-off-by: NSteven Miao <realmz6@gmail.com>
-
由 Aaron Wu 提交于
Sometimes it fails to wake up from suspend to RAM, this is because we would flush the data cache by assemble command FLUSHINV before suspend to RAM, and there is a delay between this command execution and cache flush completion. Add a 1uS delay to works around this. Signed-off-by: NAaron Wu <Aaron.wu@analog.com>
-
由 Andre Wolokita 提交于
Interacting with the USB_PHY_TEST MMR through debugfs was causing wide-spread chaos in the realm (kernel panic). Expunge all references to this demonic register. Signed-off-by: NAndre Wolokita <Andre.Wolokita@analog.com>
-
由 Sonic Zhang 提交于
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
-
由 Sonic Zhang 提交于
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
-
由 Sonic Zhang 提交于
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
-
由 Sonic Zhang 提交于
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
-
由 Scott Jiang 提交于
There is a new bf6xx audio dma driver, so we don't reuse bf5xx i2s pcm driver again. Signed-off-by: NScott Jiang <scott.jiang.linux@gmail.com>
-
由 Sonic Zhang 提交于
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
-
由 Rickard Strandqvist 提交于
Replacing strncpy with strlcpy to avoid strings that lacks null terminate. Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by: NSteven Miao <realmz6@gmail.com>
-
由 Steven Miao 提交于
Signed-off-by: NSteven Miao <realmz6@gmail.com>
-
由 Aneesh Kumar K.V 提交于
This fix the below build error arch/powerpc/mm/hash_utils_64.c: In function ‘flush_hash_hugepage’: arch/powerpc/mm/hash_utils_64.c:1381:1: error: label at end of compound statement tm_abort: ^ make[1]: *** [arch/powerpc/mm/hash_utils_64.o] Error 1 Reported-by: NAnshuman Khandual <khandual@linux.vnet.ibm.com> Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Guenter Roeck 提交于
These functions are used in various drivers, including the latest version of the 8250 driver. The latter causes the following build failure. drivers/tty/serial/8250/8250_core.c: In function 'mem32be_serial_out': drivers/tty/serial/8250/8250_core.c:456:2: error: implicit declaration of function 'iowrite32be' drivers/tty/serial/8250/8250_core.c: In function 'mem32be_serial_in': drivers/tty/serial/8250/8250_core.c:462:2: error: implicit declaration of function 'ioread32be' Cc: Kevin Cernekee <cernekee@gmail.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Fixes: c627f2ce ("serial: 8250: Add support for big-endian MMIO accesses") Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NRob Herring <robh@kernel.org>
-
由 Guenter Roeck 提交于
These functions are used in various drivers, including the latest version of the 8250 driver. The latter causes the following build failure. drivers/tty/serial/8250/8250_core.c: In function 'mem32be_serial_out': drivers/tty/serial/8250/8250_core.c:456:2: error: implicit declaration of function 'iowrite32be' drivers/tty/serial/8250/8250_core.c: In function 'mem32be_serial_in': drivers/tty/serial/8250/8250_core.c:462:2: error: implicit declaration of function 'ioread32be' Cc: Kevin Cernekee <cernekee@gmail.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Fixes: c627f2ce ("serial: 8250: Add support for big-endian MMIO accesses") Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NRob Herring <robh@kernel.org>
-
- 22 4月, 2015 8 次提交
-
-
由 Andre Przywara 提交于
When userland injects a SPI via the KVM_IRQ_LINE ioctl we currently only check it against a fixed limit, which historically is set to 127. With the new dynamic IRQ allocation the effective limit may actually be smaller (64). So when now a malicious or buggy userland injects a SPI in that range, we spill over on our VGIC bitmaps and bytemaps memory. I could trigger a host kernel NULL pointer dereference with current mainline by injecting some bogus IRQ number from a hacked kvmtool: ----------------- .... DEBUG: kvm_vgic_inject_irq(kvm, cpu=0, irq=114, level=1) DEBUG: vgic_update_irq_pending(kvm, cpu=0, irq=114, level=1) DEBUG: IRQ #114 still in the game, writing to bytemap now... Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ffffffc07652e000 [00000000] *pgd=00000000f658b003, *pud=00000000f658b003, *pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 1053 Comm: lkvm-msi-irqinj Not tainted 4.0.0-rc7+ #3027 Hardware name: FVP Base (DT) task: ffffffc0774e9680 ti: ffffffc0765a8000 task.ti: ffffffc0765a8000 PC is at kvm_vgic_inject_irq+0x234/0x310 LR is at kvm_vgic_inject_irq+0x30c/0x310 pc : [<ffffffc0000ae0a8>] lr : [<ffffffc0000ae180>] pstate: 80000145 ..... So this patch fixes this by checking the SPI number against the actual limit. Also we remove the former legacy hard limit of 127 in the ioctl code. Signed-off-by: NAndre Przywara <andre.przywara@arm.com> Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org> CC: <stable@vger.kernel.org> # 4.0, 3.19, 3.18 [maz: wrap KVM_ARM_IRQ_GIC_MAX with #ifndef __KERNEL__, as suggested by Christopher Covington] Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Mathieu Olivari 提交于
Add the watchdog related entries to the Krait Processor Sub-system (KPSS) timer IPQ8064 devicetree section. Also, add a fixed-clock description of SLEEP_CLK, which will do for now. Signed-off-by: NJosh Cartwright <joshc@codeaurora.org> Signed-off-by: NMathieu Olivari <mathieu@codeaurora.org> Reviewed-by: NStephen Boyd <sboyd@codeaurora.org> Acked-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
-
由 Bjorn Helgaas 提交于
Prior to c770cb4c ("PCI: Mark invalid BARs as unassigned"), if we tried to claim a PCI BAR but could not find an upstream bridge window that matched it, we complained but still allowed the device to be enabled. c770cb4c broke devices that previously worked (mptsas and igb in the case Tony reported, but it could be any devices) because it marks those BARs as IORESOURCE_UNSET, which makes pci_enable_device() complain and return failure: igb 0000:81:00.0: can't enable device: BAR 0 [mem size 0x00020000] not assigned igb: probe of 0000:81:00.0 failed with error -22 The underlying cause is an ACPI Address Space Descriptor for a PCI host bridge window that is marked as "consumer". This is a firmware defect: resources that are produced on the downstream side of a bridge should be marked "producer". But rejecting these BARs that we previously allowed is a functionality regression, and firmware has not used the producer/consumer bit consistently, so we can't rely on it anyway. Stop checking the producer/consumer bit, and assume all bridge Address Space Descriptors are for bridge windows. Note that this change does not affect I/O Port or Fixed Location I/O Port Descriptors, which are commonly used for the [io 0x0cf8-0x0cff] config access range. That range is a "consumer" range and should not be treated as a window. Fixes: c770cb4c ("PCI: Mark invalid BARs as unassigned") Link: https://bugzilla.kernel.org/show_bug.cgi?id=96961Reported-and-tested-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Sowmini Varadhan 提交于
Since it is possible for vnet_event_napi to end up doing vnet_control_pkt_engine -> ... -> vnet_send_attr -> vnet_port_alloc_tx_ring -> ldc_alloc_exp_dring -> kzalloc() (i.e., in softirq context), kzalloc() should be called with GFP_ATOMIC from ldc_alloc_exp_dring. Signed-off-by: NSowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
They both work equally well, and the M7 implementation is simpler and cheaper (less register writes). With help from David Ahern. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Guenter Roeck 提交于
The following warning is seen when compiling parisc images ./arch/parisc/include/asm/pgalloc.h: In function 'pgd_alloc': ./arch/parisc/include/asm/pgalloc.h:29:5: warning: "PT_NLEVELS" is not defined Some definitions of PT_NLEVELS were missed with the conversion to CONFIG_PGTABLE_LEVELS. Fixes: f24ffde4 ("parisc: expose number of page table levels on Kconfig level") Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Acked-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: NHelge Deller <deller@gmx.de>
-
由 Matthew Wilcox 提交于
The only reason to keep parisc's private asm/scatterlist.h was that it had the macro sg_virt_addr(). Convert all callers to use something else (sometimes just sg->offset was enough, others should use sg_virt()), and we can just use the asm-generic scatterlist.h instead. Signed-off-by: NMatthew Wilcox <willy@linux.intel.com> Signed-off-by: NDave Anglin <dave.anglin@bell.net> Signed-off-by: NHelge Deller <deller@gmx.de>
-
由 Ben Serebrin 提交于
The host's decision to enable machine check exceptions should remain in force during non-root mode. KVM was writing 0 to cr4 on VCPU reset and passed a slightly-modified 0 to the vmcs.guest_cr4 value. Tested: Built. On earlier version, tested by injecting machine check while a guest is spinning. Before the change, if guest CR4.MCE==0, then the machine check is escalated to Catastrophic Error (CATERR) and the machine dies. If guest CR4.MCE==1, then the machine check causes VMEXIT and is handled normally by host Linux. After the change, injecting a machine check causes normal Linux machine check handling. Signed-off-by: NBen Serebrin <serebrin@google.com> Reviewed-by: NVenkatesh Srinivas <venkateshs@google.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 21 4月, 2015 3 次提交
-
-
由 Nathan Lynch 提交于
When CONFIG_VDSO=n, the build normally does not enter arch/arm/vdso/ because arch/arm/Makefile does not add it to core-y. However, if the user runs 'make arch/arm/vdso/' the VDSO targets will get visited. This is because the VDSO Makefile itself does not consider the value of CONFIG_VDSO. It is arguably better and more consistent behavior to generate an empty built-in.o when CONFIG_VDSO=n and the user attempts to build arch/arm/vdso/. It's nicer because it doesn't try to build things that Kconfig dependencies are there to prevent (e.g. the dependency on AEABI), and it's less confusing than building objects that won't be used in the final image. Signed-off-by: NNathan Lynch <nathan_lynch@mentor.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Nathan Lynch 提交于
vdsomunge and vdso.so.raw are outputs that don't get matched by the normal ignore rules. Signed-off-by: NNathan Lynch <nathan_lynch@mentor.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Commit bf35706f ("ARM: 8314/1: replace PROCINFO embedded branch with relative offset") broke booting on nommu platforms as it didn't update the nommu boot code. This patch fixes that oversight. Fixes: bf35706f ("ARM: 8314/1: replace PROCINFO embedded branch with relative offset") Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-