Add support for the cx24117 dual DVB-S/S2 frontend.
Signed-off-by: Luis Alves <ljalvs@gmail.com>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
There is an asymmetry in ttusb_dec_init_usb()-ttusb_init_rc()
and ttusb_dec_exit_usb()-ttusb_dec_exit_rc() in terms of resources
allocated-deallocated. irq_urb and irq_buffer are allocated in
ttusb_dec_init_usb(), while they are deallocated in ttusb_dec_exit_rc().
As a result there is a leak of them in ttusb_dec_probe().
The patch fixes the asymmetry and a leak on a failure path in ttusb_dec_init_usb().
By the way, it
- removes usage of -1 as a custom error code,
- replaces GFP_ATOMIC by GFP_KERNEL in usb_alloc_coherent() in ttusb_dec_init_usb()
as soon as all other memory allocation done with GFP_KERNEL;
- refactors ttusb_dec_boot_dsp() in an equivalent way except for returning 0
instead of 1 if ttusb_dec_boot_dsp() succeed in (!mode) branch.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
When SMP packets are received, make sure they contain at least 1 byte
header for the opcode. If not, drop the packet and disconnect the link.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The ATT fixed channel is only valid when using LE connections. On
BR/EDR it is required to go through L2CAP connection oriented
channel for ATT.
Drop ATT packets when they are received on a BR/EDR connection.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The generic code is well equipped to differentiate between
SMP and UP configurations.However, there are some devices which
use Cortex-A9 MP core IP with 1 CPU as configuration. To let
these SOCs to co-exist in a CONFIG_SMP=y build by leveraging
the SMP_ON_UP support, we need to additionally check the
number the cores in Cortex-A9 MPCore configuration. Without
such a check in place, the startup code tries to execute
ALT_SMP() set of instructions which lead to CPU faults.
The issue was spotted on TI's Aegis device and this patch
makes now the device work with omap2plus_defconfig which
enables SMP by default. The change is kept limited to only
Cortex-A9 MPCore detection code.
Note that if any future SoC *does* use 0x0 as the PERIPH_BASE, then
the SCU address check code needs to be #ifdef'd for for the Aegis
platform.
Acked-by: Sricharan R <r.sricharan@ti.com>
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This fixes a regression for kernels after v3.2
After commit 72662e0108
ARM: head.S: only include __turn_mmu_on in the initial identity mapping
Zaurus PXA devices call sharpsl_save_param() during fixup and hang on
boot because memcpy refers to physical addresses no longer valid if the
MMU is setup.
Zaurus collie (SA1100) is unaffected (function is called in init_machine).
The code was making assumptions and for PXA the virtual address
should have been used before.
Signed-off-by: Marko Katic <dromede@gmail.com>
Signed-off-by: Andrea Adami <andrea.adami@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 09096f6 (ARM: 7822/1: add workaround for ambiguous C99 stdint.h
types) introduced an ARM specific 'asm/types.h' to work around some
ambiguities in the definitions of 32 bit types. Hence, we will not be
needing the generic version anymore.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Currently mcpm_cpu_power_down() and mcpm_cpu_suspend() trigger BUG()
if mcpm_platform_register() is not called beforehand. This may occur
for many reasons such as some incomplete device tree passed to the kernel
or the like.
Let's be nicer to users and avoid killing the kernel if that happens by
logging a warning and returning to the caller. The mcpm_cpu_suspend()
user is already set to deal with this situation, and so is cpu_die()
invoking mcpm_cpu_die().
The problematic case would have been the B.L switcher's usage of
mcpm_cpu_power_down(), however it has to call mcpm_cpu_power_up() first
which is already set to catch an error resulting from a missing
mcpm_platform_register() call.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This makes the interface more deterministic for userspace, which can expect
(after configuring only the features it supports) to get exactly the same
state from the kernel, independent of the host CPU and kernel version.
Suggested-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
A guest can still attempt to save and restore XSAVE states even if they
have been masked in CPUID leaf 0Dh. This usually is not visible to
the guest, but is still wrong: "Any attempt to set a reserved bit (as
determined by the contents of EAX and EDX after executing CPUID with
EAX=0DH, ECX= 0H) in XCR0 for a given processor will result in a #GP
exception".
The patch also performs the same checks as __kvm_set_xcr in KVM_SET_XSAVE.
This catches migration from newer to older kernel/processor before the
guest starts running.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
XSAVE entries that KVM does not support are reported by
KVM_GET_SUPPORTED_CPUID for leaf 0Dh index 0 if the host supports them;
they should be left out unless there is also hypervisor support for them.
Sub-leafs are correctly handled in supported_xcr0_bit, fix index 0
to match.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
When KVM (de)assigns PCI(e) devices to VMs, a debug message is printed
including the BDF notation of the respective device. Currently, the BDF
notation does not have the commonly used leading zeros. This produces
messages like "assign device 0:1:8.0", which look strange at first sight.
The patch fixes this by exchanging the printk(KERN_DEBUG ...) with dev_info()
and also inserts "kvm" into the debug message, so that it is obvious where
the message comes from. Also reduces LoC.
Acked-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Andre Richter <andre.o.richter@gmail.com>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
The BU21013 touchscreen GPIOs have been pretty confused, correct
them per board, and move the GPIO assignments up to the top
level DTS file so we can control it from there, and avoid defining
the GPIO assignments for non-ST UIB equipped boards.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The TVK1281618 UIB has a TC35892 GPIO expander on it, which has
in the past probably been confused with the GPIO expander on the
older HREF plus previous to v60, which is on an entirely different
part of the system with another I2C address. Register the expander
in the right place.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Otherwise using any atomic memory operation will lock up the GPU due
to a Haswell hardware bug.
v2: Use the _MASKED_BIT_ENABLE macro. Drop drm parameter definition.
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: <stable@vger.kernel.org>
[danvet: Fix checkpatch fail.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we do a treclaim or trecheckpoint we end up running with userspace
PPR and DSCR values. Currently we don't do anything special to avoid
running with user values which could cause a severe performance
degradation.
This patch moves the PPR and DSCR save and restore around treclaim and
trecheckpoint so that we run with user values for a much shorter period.
More care is taken with the PPR as it's impact is greater than the DSCR.
This is similar to user exceptions, where we run HTM_MEDIUM early to
ensure that we don't run with a userspace PPR values in the kernel.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
We can't take IRQs in tm_reclaim as we might have a bogus r13 and r1.
This turns IRQs hard off in this function.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Commit 4df4899 "Add power8 EBB support" included a bug in the handling
of the FAB_CRESP_MATCH and FAB_TYPE_MATCH fields.
These values are pulled out of the event code using EVENT_THR_CTL_SHIFT,
however we were then or'ing that value directly into MMCR1.
This meant we were failing to set the FAB fields correctly, and also
potentially corrupting the value for PMC4SEL. Leading to no counts for
the FAB events and incorrect counts for PMC4.
The fix is simply to shift left the FAB value correctly before or'ing it
with MMCR1.
Reported-by: Sooraj Ravindran Nair <soonair3@in.ibm.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Cc: <stable@vger.kernel.org> # 3.10+
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
modalias_show() should return an empty string on error, not -ENODEV.
This causes the following false and annoying error:
> find /sys/devices -name modalias -print0 | xargs -0 cat >/dev/null
cat: /sys/devices/vio/4000/modalias: No such device
cat: /sys/devices/vio/4001/modalias: No such device
cat: /sys/devices/vio/4002/modalias: No such device
cat: /sys/devices/vio/4004/modalias: No such device
cat: /sys/devices/vio/modalias: No such device
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>
Under heavy (DLPAR?) stress, we tripped this panic() in
arch/powerpc/kernel/iommu.c::iommu_init_table():
page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz));
if (!page)
panic("iommu_init_table: Can't allocate %ld bytes\n", sz);
Before the panic() we got a page allocation failure for an order-2
allocation. There appears to be memory free, but perhaps not in the
ATOMIC context. I looked through all the call-sites of
iommu_init_table() and didn't see any obvious reason to need an ATOMIC
allocation. Most call-sites in fact have an explicit GFP_KERNEL
allocation shortly before the call to iommu_init_table(), indicating we
are not in an atomic context. There is some indirection for some paths,
but I didn't see any locks indicating that GFP_KERNEL is inappropriate.
With this change under the same conditions, we have not been able to
reproduce the panic.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>
arch/powerpc/kernel/sysfs.c exports PURR with write permission.
This may be valid for kernel in phyp mode. But writing to
the file in guest mode causes crash due to a priviledge violation
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org>
The csum_partial_copy_generic() function saves the PowerPC non-volatile
r14, r15, and r16 registers for the main checksum-and-copy loop.
Unfortunately, it fails to restore them upon error exit from this loop,
which results in silent corruption of these registers in the presumably
rare event of an access exception within that loop.
This commit therefore restores these register on error exit from the loop.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The csum_partial_copy_generic() uses register r7 to adjust the remaining
bytes to process. Unfortunately, r7 also holds a parameter, namely the
address of the flag to set in case of access exceptions while reading
the source buffer. Lacking a quantum implementation of PowerPC, this
commit instead uses register r9 to do the adjusting, leaving r7's
pointer uncorrupted.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Previous commit 46723bfa540... introduced a new config option
HAVE_BOOTMEM_INFO_NODE that ended up breaking memory hot-remove for ppc
when sparse vmemmap is not defined.
This patch defines HAVE_BOOTMEM_INFO_NODE for ppc and adds the call to
register_page_bootmem_info_node. Without this we get a BUG_ON for memory
hot remove in put_page_bootmem().
This also adds a stub for register_page_bootmem_memmap to allow ppc to build
with sparse vmemmap defined. Leaving this as a stub is fine since the same
vmemmap addresses are also handled in vmemmap_populate and as such are
properly mapped.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: <stable@vger.kernel.org> [v3.9+]
When receiving connectionless packets on a LE connection, just drop
the packet. There is no concept of connectionless channels for LE.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When receiving SMP packets on a BR/EDR connection, then just drop
the packet and do not try to process it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
gfn_to_memslot() can return NULL or invalid slot. We need to check slot
validity before accessing it.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
The L2CAP raw sockets are only used for BR/EDR signalling. Packets
on LE links should not be forwarded there.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The switch statement for the various L2CAP fixed channel handlers
is not really ordered.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Changing the device class when BR/EDR is disabled has no visible
effect for remote devices. However to simplify the logic allow it
as long as the controller supports BR/EDR operations.
If it is not allowed, then the overall logic becomes rather
complicated since the class of device values would need clearing
or restoring when BR/EDR setting changes.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Loading long term keys into a BR/EDR only controller make no sense.
The kernel would never use any of these keys. So instead of allowing
userspace to waste memory, reject such operation with a not supported
error message.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Loading link keys into a LE only controller make no sense. The kernel
would never use any of these keys. So instead of allowing userspace
to waste memory, reject such operation with a not supported error
message.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Setting the static address does not depend on LE beeing enabled. It
only depends on a controller with LE support.
When depending on LE enabled this command becomes really complicated
since in case LE gets disabled, it would be required to clear the
static address and also its random address representation inside
the controller. With future support for private addresses such
complex setup should be avoided.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Only when BR/EDR is supported and enabled, allow changing of the SSP
setting. Just checking if the hardware supports SSP is not enough
since it might be the case that BR/EDR is disabled.
In the case that BR/EDR is disabled, but SSP supported by the
controller the not supported error message is now returned.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Pull (mostly) ARM clocksource driver updates from Daniel Lezcano:
" - Soren Brinkmann added FEAT_PERCPU to a clock device when it is local
per cpu. This feature prevents the clock framework to choose a per cpu
timer as a broadcast timer. This problem arised when the ARM global
timer is used when switching to the broadcast timer which is the case
now on Xillinx with its cpuidle driver.
- Stephen Boyd extended the generic sched_clock code to support 64bit
counters and removes the setup_sched_clock deprecation, as that causes
lots of warnings since there's still users in the arch/arm tree. He
added also the CLOCK_SOURCE_SUSPEND_NONSTOP flag on the architected
timer as they continue counting during suspend.
- Uwe Kleine-König added some missing __init sections and consolidated the
code by moving the of_node_put call from the drivers to the function
clocksource_of_init. "
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Merge updated full dynticks support from Frederic Weisbecker:
- support 32-bit systems (full dynticks was 64-bit only before)
- support ARM
Signed-off-by: Ingo Molnar <mingo@kernel.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQEcBAABAgAGBQJSSKOHAAoJEHm+PkMAQRiGeREH/3EqHmJPBzmVoJwR9/ykDoLg
u+TJTkuxZG220WhgXS7W/0ECyBX0U7yA0bY9PZbqgcdiLjY0veR18/pOhEq5RzHq
ub8Q+AJdiORF/sq268q7gnNmy3rSCgnrAyHA/bzBtkbisYODwZPYvWQVUjgNZ2dW
qtW/TE9rjANcUrk8WdOu9oWcwsq4cyG3cscbfHE/JLFy/8tB5GoD158gxKLZsLXk
uTCeUHMmvFRT56fZwfyvNstA8ozxXcHBmuu6+Ttceky2zeGzp6dOrd+d2SU1Ps3O
P91x4e/Af4RFEwDczGP6TpSBEf/J/JaqrM1drjhnQHho0hrNRZVUXhADFVADCXY=
=dOjB
-----END PGP SIGNATURE-----
Merge tag 'v3.12-rc3' into timers/core
Merge Linux 3.12-rc3 - refresh the tree with the latest fixes before merging new bits.
Signed-off-by: Ingo Molnar <mingo@kernel.org>
IORESOURCE_BUSY is used to mark temporary driver mem-resources
instead of global regions. This suppresses warnings if regions
overlap with a region marked as BUSY.
This was always the case for VESA/VGA/EFI framebuffer regions so
do the same for simplefb regions. The reason we do this is to
allow device handover to real GPU drivers like
i915/radeon/nouveau which get the same regions via PCI BARs.
Maybe at some point we will be able to unregister platform
devices properly during the handover. In this case the simplefb
region would get removed before the new region is created.
However, this is currently not the case and would require rather
huge changes in remove_conflicting_framebuffers(). Add the BUSY
marker now and try to eventually rewrite the handover for a next release.
Also see kernel/resource.c for more information:
/*
* if a resource is "BUSY", it's not a hardware resource
* but a driver mapping of such a resource; we don't want
* to warn for those; some drivers legitimately map only
* partial hardware resources. (example: vesafb)
*/
This suppresses warnings like:
------------[ cut here ]------------
WARNING: CPU: 2 PID: 199 at arch/x86/mm/ioremap.c:171 __ioremap_caller+0x2e3/0x390()
Info: mapping multiple BARs. Your kernel is fine.
Call Trace:
dump_stack+0x54/0x8d
warn_slowpath_common+0x7d/0xa0
warn_slowpath_fmt+0x4c/0x50
iomem_map_sanity_check+0xac/0xe0
__ioremap_caller+0x2e3/0x390
ioremap_wc+0x32/0x40
i915_driver_load+0x670/0xf50 [i915]
...
Reported-by: Tom Gundersen <teg@jklm.no>
Tested-by: Tom Gundersen <teg@jklm.no>
Tested-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Link: http://lkml.kernel.org/r/1380724864-1757-1-git-send-email-dh.herrmann@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
We have a fairly large batch of fixes this time around, mostly just due to
various platforms all having a fix or two more than usual.
Worth pointing out are:
- A fix for EDMA on Davinci/OMAP where channel allocation broke with
the DT conversion. Due to some miscommunication we didn't
understand the impact of the breakage, so we were pushing back on it
for 3.12, but it sounds like it's actually breaking quite a few people
out there.
- A bunch of fixes for Marvell platforms, some straggling fixes for
merge window fallout and some fixes for a couple of the platforms
(Netgear RN102 in particular).
- A fix for a race between multi-cluster power management and cpu hotplug
on Versatile Express.
And a bunch of other smaller fixes that all add up.
We'll be switching over into stricter regressions-only mode from here
on out.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJSTO8aAAoJEIwa5zzehBx3t/4P/jVzo0/Yvs0GtlD9tyC5uHgc
aDvz7cjP+/w8Is2amSBr+QR/bslT7gYjyBB9cBZluH/v1juohl16jRZMxHOmoV80
f3OfdJ7gXbKRRgrZNw9sBGWEfKrqb/Zr86CMOm51RpLizhHGXv+88DR/Rc63GgTl
P+NBbhyL9DiL3ox7OLM7UlMafovTR0HegeypMkWghBGaIwsgjheNz1xL0/oi+6tW
i74ehXBqoxpuHXm7UzdVD0VcQ+/GCXFo+yC0BrnGoNZG77Etq9CjpNRV3YFVZhCt
qD9RIznRDX2bA1Mcn74bFB9H+eL4c866p/gAH8tgbwdym9KtTcqNgYTR2nL5aAHa
OfD23lsaiy7yftPQX4bnD53bzeXJCJ+246SECK06fphS6PihYPK6iubxVL4yA5e/
iwzqCPQ3+f9NmC4+tLoydA2xzSHtgeCQc+smYVQlyyDMtEUaCzj58GDKebUpm62X
uMIQ8wrDRSJXURZl708UUixEvzQ6OLVgp1B3ASbedbh542qTQIpC2W8FIkYOUb6u
S7uErba0u/UC+bxBlAYNWnBM1npT//bZgCC8LRAJ+S3HIv8OGhHStsCZfGQxbeND
NxgPbHJPgSQu6RzaHcYSweuO38cfl6zkNcor8gf6ts3UOYnJuD+l8PLfqN13Erjm
NUL6gyQIF4uekR4GOTdI
=DLem
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"We have a fairly large batch of fixes this time around, mostly just
due to various platforms all having a fix or two more than usual.
Worth pointing out are:
- A fix for EDMA on Davinci/OMAP where channel allocation broke with
the DT conversion. Due to some miscommunication we didn't
understand the impact of the breakage, so we were pushing back on
it for 3.12, but it sounds like it's actually breaking quite a few
people out there.
- A bunch of fixes for Marvell platforms, some straggling fixes for
merge window fallout and some fixes for a couple of the platforms
(Netgear RN102 in particular).
- A fix for a race between multi-cluster power management and cpu
hotplug on Versatile Express.
And a bunch of other smaller fixes that all add up.
We'll be switching over into stricter regressions-only mode from here
on out"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (31 commits)
ARM: multi_v7_defconfig: add SDHCI for i.MX
bus: mvebu-mbus: Fix optional pcie-mem/io-aperture properties
ARM: mvebu: add missing DT Mbus ranges and relocate PCIe DT nodes for RN102
ARM: at91: sam9g45: shutdown ddr1 too when rebooting
MAINTAINERS: ARM: SIRF: use kernel.org mail box
MAINTAINERS: ARM: SIRF: add missed drivers into maintain list
ARM: edma: Fix clearing of unused list for DT DMA resources
ARM: vexpress: tc2: fix hotplug/idle/kexec race on cluster power down
ARM: dts: sirf: fix interrupt and dma prop of VIP for prima2 and atlas6
ARM: dts: sirf: fix the ranges of peri-iobrg of prima2
ARM: dts: makefile: build atlas6-evb.dtb for ARCH_ATLAS6
ARM: dts: sirf: fix fifosize, clks, dma channels for UART
ARM: mvebu: Add DT entry for ReadyNAS 102 to use gpio-poweroff driver
ARM: mvebu: fix ReadyNAS 102 Power button GPIO to make it active high
ARM: mach-integrator: Add stub for pci_v3_early_init() for !CONFIG_PCI
ARM: shmobile: Remove #gpio-ranges-cells DT property
gpio: rcar: Remove #gpio-range-cells DT property usage
ARM: shmobile: armadillo: fixup ether pinctrl naming
ARM: shmobile: Lager: add Micrel KSZ8041 PHY fixup
ARM: shmobile: update SDHI DT compatibility string to the <unit>-<soc> format
...
Previously, when a signal was registered with SA_SIGINFO, parameters 2
and 3 of the signal handler were written to registers r1 and r2 before
the register set was saved. This led to corruption of these two
registers after returning from the signal handler (the wrong values were
restored).
With this patch, registers are now saved before any parameters are
passed, thus maintaining the processor state from before signal entry.
Signed-off-by: Christian Ruppert <christian.ruppert@abilis.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Pull sparc fixes from David Miller:
"Couple of small bug fixes:
1) strlcpy in ldom_reboot() is still not quite right, use sprintf
instead from Kees Cook.
2) Generic hugetlb interface pte checks should use the widest return
type, otherwise high bits can get chopped off.
3) Fix build with PCI MSI enabled on 32-bit sparc"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
sparc: fix MSI build failure on Sparc32
sparc: remove deprecated IRQF_DISABLED
mm: Fix generic hugetlb pte check return type.
sparc: fix ldom_reboot buffer overflow harder
- mvebu
- fix ReadyNAS 102 power button (needs to be active high)
- fix ReadyNAS 102 automated rebooting (prevent hang) by add gpio-poweroff
node
- fix booting ReadyNAS 102 by adding MBus ranges and PCIe DT nodes
- mvebu-mbus: prevent PCIe driver from continuing with corrupted resource
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQEcBAABAgAGBQJSTERhAAoJEAi3KVZQDZAeFaQH/jmhAZwvSrB7MeTTY7J9eAcl
n4cFHImBiSb6IdDaocKB+yOmEgq/X2LS/DjK71sa0+CQsTq9B5nHxMHioogdUrG7
S8ofIjqu90CBOZ1I5IMSPmA3uOc1B2+wYi9uLxmajMTzYVDDBEZh9LuMy/GjwzU2
/g09RedQ3XkWDVv3pdPdEiC6KZ/gg7gejxOLv0nv9ydxr0DB8/VwmBHWFC0ghawB
3EchoagJ3M+mAbUaxtY6cauV2nnAJOO5mV6ZHl2tIOj4/Mhn8Le/C1t+Zcdf+U82
iAvqWmiRc3Vk96g8xXZWwZoPL7vhidLcE7dpOIZ2ymq5+g3esTaailqRxRqS9+c=
=uNPR
-----END PGP SIGNATURE-----
Merge tag 'fixes-3.12-2' of git://git.infradead.org/linux-mvebu into fixes
From Jason Cooper:
mvebu fixes for v3.12 (round 2)
- mvebu
- fix ReadyNAS 102 power button (needs to be active high)
- fix ReadyNAS 102 automated rebooting (prevent hang) by add gpio-poweroff
node
- fix booting ReadyNAS 102 by adding MBus ranges and PCIe DT nodes
- mvebu-mbus: prevent PCIe driver from continuing with corrupted resource
* tag 'fixes-3.12-2' of git://git.infradead.org/linux-mvebu:
bus: mvebu-mbus: Fix optional pcie-mem/io-aperture properties
ARM: mvebu: add missing DT Mbus ranges and relocate PCIe DT nodes for RN102
ARM: mvebu: Add DT entry for ReadyNAS 102 to use gpio-poweroff driver
ARM: mvebu: fix ReadyNAS 102 Power button GPIO to make it active high
Signed-off-by: Olof Johansson <olof@lixom.net>
Turn on SDHCI for i.MX support so machines can boot with local rootfs
on SD. Tested on a Wandboard Quad.
Signed-off-by: Olof Johansson <olof@lixom.net>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Use the appropriate define instead of 6.
Signed-off-by: Joe Perches <joe@perches.com>
Noticed-by: Julia Lawall <julia.lawall@lip6.fr> via spatch script
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit ebd97be635 ('PCI: remove ARCH_SUPPORTS_MSI kconfig option')
removes the ARCH_SUPPORTS_MSI Kconfig option that allowed
architectures to indicate whether they support PCI MSI or not. Now,
PCI MSI support can be compiled in on any architecture thanks to the
use of weak functions thanks to 4287d824f2 ('PCI: use weak functions
for MSI arch-specific functions').
So, architecture specific code is now responsible to ensure that its
PCI MSI code builds in all cases, or be appropriately conditionally
compiled.
On Sparc, the MSI support is only provided for Sparc64, so the
ARCH_SUPPORTS_MSI kconfig option was only selected for SPARC64, and
not for the Sparc architecture as a whole. Therefore, removing
ARCH_SUPPORTS_MSI broke Sparc32 configurations with CONFIG_PCI_MSI=y,
because the Sparc-specific MSI code is not designed to be built on
Sparc32.
To solve this, this commit ensures that the Sparc MSI code is only
built on Sparc64. This is done thanks to a new Kconfig Makefile helper
option SPARC64_PCI_MSI, modeled after the existing SPARC64_PCI. The
SPARC64_PCI_MSI option is an hidden option that is true when both
Sparc64 PCI support is enabled and MSI is enabled. The
arch/sparc/kernel/pci_msi.c file is now only built when
SPARC64_PCI_MSI is true.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch proposes to remove the IRQF_DISABLED flag from sparc architecture
code. It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The include/asm-generic/hugetlb.h stubs that just vector huge_pte_*()
calls to the pte_*() implementations won't work in certain situations.
x86 and sparc, for example, return "unsigned long" from the bit
checks, and just go "return pte_val(pte) & PTE_BIT_FOO;"
But since huge_pte_*() returns 'int', if any high bits on 64-bit are
relevant, they get chopped off.
The net effect is that we can loop forever trying to COW a huge page,
because the huge_pte_write() check signals false all the time.
Reported-by: Gurudas Pai <gurudas.pai@oracle.com>
Tested-by: Gurudas Pai <gurudas.pai@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: David Rientjes <rientjes@google.com>
The length argument to strlcpy was still wrong. It could overflow the end of
full_boot_str by 5 bytes. Instead of strcat and strlcpy, just use snprint.
Reported-by: Brad Spengler <spender@grsecurity.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
