Following execution of a signal handler, we currently restore the VFP
context from the ucontext in the signal frame. This involves copying
from the user stack into the current thread's vfp_hard_struct and then
flushing the new data out to the hardware registers.
This is problematic when using a preemptible kernel because we could be
context switched whilst updating the vfp_hard_struct. If the current
thread has made use of VFP since the last context switch, the VFP
notifier will copy from the hardware registers into the vfp_hard_struct,
overwriting any data that had been partially copied by the signal code.
Disabling preemption across copy_from_user calls is a terrible idea, so
instead we move the VFP thread flush *before* we update the
vfp_hard_struct. Since the flushing is performed lazily, this has the
effect of disabling VFP and clearing the CPU's VFP state pointer,
therefore preventing the thread from being updated with stale data on
the next context switch.
Cc: stable <stable@vger.kernel.org>
Tested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This reverts commit 3c424f3598.
Joachim Eastwood reports:
| "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping"
| Commit: 3c424f3598 in Linus master
|
| Breaks booting on my custom AT91RM9200 board.
| There isn't any error messages or anything that indicates what goes
| wrong it just stops after; Uncompressing Linux... done, booting the
| kernel.
|
| Reverting it makes my board boot again.
and further debugging reveals:
ioremap: pfn=fffff phys=fffff000 offset=400 size=1000
ioremap: area c3ffdfc0: phys_addr=200000 pfn=200 size=4000
ioremap: found: addr fef74000 => fed73000 => fed73400
Clearly, an area for pfn 0x200, 16K can't ever satisfy a request for pfn
0xfffff. This happens because the changed if statement becomes:
if (0x00200 > 0xfffff ||
0xfffff000 + 0x400 + 0x1000-1 > 0x00200000 + 0x4000-1)
and therefore:
if (0x00200 > 0xfffff ||
0x000003ff > 0x00203fff)
The if condition fails, and so we _believe_ that the SRAM mapping fits
our request. Clearly that's totally bogus.
Moreover, the original premise of the 'fix' patch was wrong:
| The condition checking boundaries of the requested and existing
| mappings didn't take in-page offset into consideration though,
| which lead to obscure and hard to debug problems when requested
| mapping crossed end of the static one.
as the code immediately above this loop does:
size = PAGE_ALIGN(offset + size);
so 'size' already contains the requested offset into the page.
So, revert the broken 'fix'.
Acked-by: Nicolas Pitre <nico@linaro.org>
Both sparc 32-bit's software divide assembler and MPILIB provide
clz_tab[] with identical contents.
Break it out into a seperate object file and select it when
SPARC32 or MPILIB is set.
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: James Morris <jmorris@namei.org>
Return to behaviour perf MSR had before introducing vPMU in case vPMU
is disabled. Some guests access those registers unconditionally and do
not expect it to fail.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
On hosts without this patch, 32bit guests will crash (and 64bit guests
may behave in a wrong way) for example by simply executing following
nasm-demo-application:
[bits 32]
global _start
SECTION .text
_start: syscall
(I tested it with winxp and linux - both always crashed)
Disassembly of section .text:
00000000 <_start>:
0: 0f 05 syscall
The reason seems a missing "invalid opcode"-trap (int6) for the
syscall opcode "0f05", which is not available on Intel CPUs
within non-longmodes, as also on some AMD CPUs within legacy-mode.
(depending on CPU vendor, MSR_EFER and cpuid)
Because previous mentioned OSs may not engage corresponding
syscall target-registers (STAR, LSTAR, CSTAR), they remain
NULL and (non trapping) syscalls are leading to multiple
faults and finally crashs.
Depending on the architecture (AMD or Intel) pretended by
guests, various checks according to vendor's documentation
are implemented to overcome the current issue and behave
like the CPUs physical counterparts.
[mtosatti: cleanup/beautify code]
Signed-off-by: Stephan Baerwolf <stephan.baerwolf@tu-ilmenau.de>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
In order to be able to proceed checks on CPU-specific properties
within the emulator, function "get_cpuid" is introduced.
With "get_cpuid" it is possible to virtually call the guests
"cpuid"-opcode without changing the VM's context.
[mtosatti: cleanup/beautify code]
Signed-off-by: Stephan Baerwolf <stephan.baerwolf@tu-ilmenau.de>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
commit 43db595e8b
(sh: switch to GENERIC_PCI_IOMAP)
failed to take into account the PCI channels's
io_map_base for mapping IO BARs.
This also caused a new warning on sh.
Fix this, without re-introducing code duplication,
by setting NO_GENERIC_PCI_IOPORT_MAP
and supplying a sh-specific __pci_ioport_map.
Reported-by: Kevin Cernekee <cernekee@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
commit eab90291d3
(mips: switch to GENERIC_PCI_IOMAP)
failed to take into account the PCI controller's
io_map_base for mapping IO BARs.
This also caused a new warning on mips.
Fix this, without re-introducing code duplication,
by setting NO_GENERIC_PCI_IOPORT_MAP
and supplying a mips-specific __pci_ioport_map.
Reported-by: Kevin Cernekee <cernekee@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This reverts commit d761f0c521.
Patch: "cpu: Register a generic CPU device on architectures that currently do not"
(sha1: 9f13a1fd45)
selects GENERIC_CPU_DEVICES for Microblaze which register cpu.
My patch was done in the same time that's why cpu was registered twice which
caused this warning log:
------------[ cut here ]------------
WARNING: at fs/sysfs/dir.c:481 sysfs_add_one+0xb0/0xdc()
sysfs: cannot create duplicate filename '/devices/system/cpu/cpu0'
Modules linked in:
...
Signed-off-by: Michal Simek <monstr@monstr.eu>
In order to keep the sensor's master clock frequency in valid range
when FIMC parent clock is xusbxti, the specified frequency must be
exactly 24MHZ, otherwise it's being set to too low value due to
rounding.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
The real LCD resolution on Nuri is 1024x600, not 1280x800. This change
fixes the color distortion (green shadows) on half of the screen.
Also increase framebuffer virtual size for display panning support.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
[S390] dasd: revalidate server for new pathgroup
[S390] dasd: revert LCU optimization
[S390] cleanup entry point definition
This commit removes the reboot quirk originally added by commit
e19e074 ("x86: Fix reboot problem on VersaLogic Menlow boards").
Testing with a VersaLogic Ocelot (VL-EPMs-21a rev 1.00 w/ BIOS
6.5.102) revealed the following regarding the reboot hang
problem:
- v2.6.37 reboot=bios was needed.
- v2.6.38-rc1: behavior changed, reboot=acpi is needed,
reboot=kbd and reboot=bios results in system hang.
- v2.6.38: VersaLogic patch (e19e074 "x86: Fix reboot problem on
VersaLogic Menlow boards") was applied prior to v2.6.38-rc7. This
patch sets a quirk for VersaLogic Menlow boards that forces the use
of reboot=bios, which doesn't work anymore.
- v3.2: It seems that commit 660e34c ("x86: Reorder reboot method
preferences") changed the default reboot method to acpi prior to
v3.0-rc1, which means the default behavior is appropriate for the
Ocelot. No VersaLogic quirk is required.
The Ocelot board used for testing can successfully reboot w/out
having to pass any reboot= arguments for all 3 current versions
of the BIOS.
Signed-off-by: Michael D Labriola <michael.d.labriola@gmail.com>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Michael D Labriola <mlabriol@gdeb.com>
Cc: Kushal Koolwal <kushalkoolwal@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/87vcnub9hu.fsf@gmail.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Skip DMI checks for vendor specific reboot quirks if the user
passed in a reboot= arg on the command line - we should never
override user choices.
Signed-off-by: Michael D Labriola <michael.d.labriola@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Michael D Labriola <mlabriol@gdeb.com>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/87wr8ab9od.fsf@gmail.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
* 'stable/for-linus-fixes-3.3' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
xen/granttable: Disable grant v2 for HVM domains.
x86: xen: size struct xen_spinlock to always fit in arch_spinlock_t
* 'fixes' of git://git.linaro.org/people/rmk/linux-arm: (31 commits)
ARM: 7304/1: ioremap: fix boundary check when reusing static mapping
ARM: 7301/1: Rename the T() macro to TUSER() to avoid namespace conflicts
ARM: 7299/1: ftrace: clear zero bit in reported IPs for Thumb-2
ARM: 7298/1: realview: fix mapping of MPCore private memory region
PCMCIA: fix sa1111 oops on remove
ARM: 7288/1: mach-sa1100: add missing module_init() call
ARM: 7297/1: smp_twd: make sure timer is stopped before registering it
ARM: 7296/1: proc-v7.S: remove HARVARD_CACHE preprocessor guards
ARM: 7295/1: cortex-a7: move proc_info out of !CONFIG_ARM_LPAE block
ARM: 7293/1: logical_cpu_map: decouple CPU mapping from SMP
ARM: 7291/1: cache: assume 64-byte L1 cachelines for ARMv7 CPUs
ARM: 7290/1: vmlinux.lds.S: align the exception fixup table to a 4-byte boundary
ARM: 7289/1: vmlinux.lds.S: do not hardcode cacheline size as 32 bytes
MFD: ucb1x00-ts: fix resume failure
MFD: ucb1x00-core: fix gpiolib direction_output handling
MFD: ucb1x00-core: fix missing restore of io output data on resume
MFD: mcp-core: fix mcp_priv() to be more type safe
MFD: mcp-core: fix complaints from the genirq layer
Revert "ARM: sa11x0: Implement autoloading of codec and codec pdata for mcp bus."
Revert "ARM: sa1100: Refactor mcp-sa11x0 to use platform resources."
...
Fix up conflict due to arch/arm/mach-mx5/Kconfig having been merged into
mach-imx5 (commit 784a90c0a7: "ARM i.MX: Merge i.MX5 support into
mach-imx"), but the ARM_L1_CACHE_SHIFT_6 entry was moved to be driven by
the CPU_V7 logic from it in the old location in rmk's branch (commit
a092f2b153: "ARM: 7291/1: cache: assume 64-byte L1 cachelines for
ARMv7 CPUs").
AT91 needed reset fixes which resulted in some minor code refactoring,
it also adds a feature-removal for one of their platforms for 3.4.
The USB patches have been acked by Greg K-H.
i.MX and ux500 both have some minor fixes, nothing controversial.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPIlhOAAoJEIwa5zzehBx3l+UP/1LcalLOTEU0bthHNBUoQYEQ
drDqaFlnBsDryuOzbtGGO41jRySqQWQfQTiVThrEpE3ZUH+NLih5cDRk2sUIzdMd
8tFWMN7HJnvaA0LT6ODcnC4HoRUBWieYLrPnjA+rlUPFCY/vJQ5010xFhZs2nGBo
Y5AOQ6Fun/1z5P4V5u+6GzKPPsJZPaCqEPwLJoc5yCJgvfO6RnAFuICv0F183lMh
TYVkZISF3GYdD/wWQZuytYJRj6IB3mV1GCe0q1fRD9E49929mOnC4SZ3gwa3nF4D
9IAJviVq+YtEIwTw4H+DJ+k7NXS7GR+F6hxcCrWygEYlOgFqHlRYIL35pxXWq+Sm
s0jMxC3RdyXmbfhuwi4o607OwMQkwVyNM+N5xUGaww4Inn3Lw6VPaqyQRtW6Bhiz
o/fyuOALFt7FDoLII02BJgFMdoeEV1gfXlTTdiz7yEekE0h9ng0A3VSRQRph3kLn
CScQZyOFGrFFm9UNM0T0FrWlshd+ZU1yQGAdZHIX/Fv/euLNhXDnF2bKxAx7CiTh
wcFezf7vjXjs/iTV+ZsDBe0oKWGmdvxVJksDV6X74DlMfZd9AYi+ntvXzvWrcHdp
C6wmTtePlSbEMem3RhWEQD8EeTy/qwzPRwLVNqlyT7QURhqCgJlbx133gMEt6113
wd95I9VZjKE6KSKh7BsS
=nS4F
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
arm-soc fixes for 3.3-rc:
AT91 needed reset fixes which resulted in some minor code refactoring,
it also adds a feature-removal for one of their platforms for 3.4.
The USB patches have been acked by Greg K-H.
i.MX and ux500 both have some minor fixes, nothing controversial.
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
arch/arm/mach-imx/mach-mx53_ard.c: add missing iounmap
ARM: imx: iomux-v1.h: Fix build error due to __init annotation
ARM: at91: Fix at91sam9g45 and at91cap9 reset
ARM: at91: make rstc soc independent
ARM: at91: introduce AT91_SAM9_ALT_RESET to select the at91sam9 alternative reset
ARM: at91: merge at91cap9_ddrsdr.h in at91sam9_ddrsdr.h
ARM: at91: fix cap9 ddrsdr register
ARM/USB: at91/ohci-at91: rename vbus_pin_inverted to vbus_pin_active_low
USB: at91: fix clk_get error handling
ARM: at91: removal of CAP9 SoC family
ARM: at91: fix at91rm9200 soc subtype handling
mach-ux500: no MMC_CAP_SD_HIGHSPEED on Snowball
mach-ux500: enable ARM errata 764369
mach-ux500: do not override outer.inv_all
mach-ux500: musb: now musb is always in OTG mode
ARM: imx6: add missing twd_clk for imx6q clock
Smatch complains that we have some inconsistent NULL checking.
If "task" were NULL then it would lead to a NULL dereference
later. We can remove this test because earlier on in the
function we have:
if (!task)
task = current;
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Namhyung Kim <namhyung@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Clemens Ladisch <clemens@ladisch.de>
Link: http://lkml.kernel.org/r/20120128105246.GA25092@elgon.mountain
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Since commit 576d2f2525 "ARM: add
generic ioremap optimization by reusing static mappings" ioremap()
is trying to reuse existing static mapping when possible.
The condition checking boundaries of the requested and existing
mappings didn't take in-page offset into consideration though,
which lead to obscure and hard to debug problems when requested
mapping crossed end of the static one.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 5a05a8200a ("davinci_emac:
use an unique MDIO bus name") introduced during the v3.3 merge
window updated the davinci mdio bus name to make it unique.
Update the bus name in board files which use DaVinci MDIO bus
to match the new name. Without this PHY is not detected with
error like:
PHY 0:01 not found
net eth0: could not connect to phy 0:01
Tested on DM365 and DA850 EVMs.
Cc: Florian Fainelli <florian@openwrt.org>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
* commit 'v3.3-rc1': (9775 commits)
Linux 3.3-rc1
x86, syscall: Need __ARCH_WANT_SYS_IPC for 32 bits
qnx4: don't leak ->BitMap on late failure exits
qnx4: reduce the insane nesting in qnx4_checkroot()
qnx4: di_fname is an array, for crying out loud...
KEYS: Permit key_serial() to be called with a const key pointer
keys: fix user_defined key sparse messages
ima: fix cred sparse warning
uml: fix compile for x86-64
MPILIB: Add a missing ENOMEM check
tpm: fix (ACPI S3) suspend regression
nvme: fix merge error due to change of 'make_request_fn' fn type
xen: using EXPORT_SYMBOL requires including export.h
gpio: tps65910: Use correct offset for gpio initialization
acpi/apei/einj: Add extensions to EINJ from rev 5.0 of acpi spec
intel_idle: Split up and provide per CPU initialization func
ACPI processor: Remove unneeded variable passed by acpi_processor_hotadd_init V2
tg3: Fix single-vector MSI-X code
openvswitch: Fix multipart datapath dumps.
ipv6: fix per device IP snmp counters
...
* 'fixes-for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson:
mach-ux500: no MMC_CAP_SD_HIGHSPEED on Snowball
mach-ux500: enable ARM errata 764369
mach-ux500: do not override outer.inv_all
mach-ux500: musb: now musb is always in OTG mode
Commit 4a858cfc9a (arm: convert sysdev_class to a regular subsystem)
converted the samsung sysdevs into subsys_interface instances.
While the original add-function only had a (struct sys_device *)
parameter, the dev_add from subsys_interface needs
(struct device *, struct subsys_interface *)
leading to "initialized from incompatible pointer type" warnings.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Fixed following build warning with exynos4_defconfig.
arch/arm/mach-exynos/clock.c:33: warning: 'exynos4_clock_save' defined but not used
arch/arm/mach-exynos/clock-exynos4210.c:35: warning: 'exynos4210_clock_save' defined but not used
arch/arm/mach-exynos/clock-exynos4212.c:35: warning: 'exynos4212_clock_save' defined but not used
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
The common static default_i2c_data structure gets bus_num set by each
s3c_i2c?_set_platdata() call, except for s3c_i2c0_set_platdata(). Thus
if for instance s3c_i2c1_set_platdata() is called prior to
s3c_i2c0_set_platdata() the I2C0 controller has bus_num set to wrong value
of 1, i.e. the one from previous set_platdata call. Fix this by also setting
bus_num for I2C0.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch fixes the following build issue, which happens only if
SMP has been disabled:
arch/arm/mach-exynos/built-in.o: In function `exynos4_pm_resume':
arch/arm/mach-exynos/pm.c:387: undefined reference to `scu_enable'
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
When the S3C64xx CPUs were converted to clkdev mappings were added for the
I2C controllers on them. On S3C6410 a device name is specified for I2C
controller 1 but not for controller 0 which makes the code less robust as
we'll falsely return the clock for controller 0 if there's an error in the
request for controller 1.
Improve things by registering a device name for controller 0 as well. Due
to the fact that we change the numbering for controller 0 depending on if
we've registered controller 1 this requires an ifdef to choose the name.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Now that it's in common.c it's not used in multiple source files.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Add missing iounmap in error handling code, in a case where the function
already preforms iounmap on some other execution path.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e;
statement S,S1;
int ret;
@@
e = \(ioremap\|ioremap_nocache\)(...)
... when != iounmap(e)
if (<+...e...+>) S
... when any
when != iounmap(e)
*if (...)
{ ... when != iounmap(e)
return ...; }
... when any
iounmap(e);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Tony Lindgren <tony@atomide.com>
pdata needs to be freed before leaving the function in an error case.
A simplified version of the semantic match that finds the problem is as
follows: (http://coccinelle.lip6.fr)
// <smpl>
@r exists@
local idexpression x;
statement S;
identifier f1;
position p1,p2;
expression *ptr != NULL;
@@
x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...x...+> }
x->f1
...>
(
return \(0\|<+...x...+>\|ptr\);
|
return@p2 ...;
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Currently MMC2 setup code can only enable loopback clock and
relies on reset value for boards that need to have it disabled.
This causes a problem with certain bootloaders that always enable
that clock, resulting with unwanted bootloader dependencies.
Fix this by making it disable the clock if board data says so.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Tony Lindgren <tony@atomide.com>
hsmmc23_before_set_reg() can set MMCSDIO2ADPCLKISEL bit, which
enables internal clock for MMC2. Currently this function is also called
by code handling MMC3, and if .internal_clock is set in platform data
(by default it currently is), it will set MMCSDIO2ADPCLKISEL for MMC2
instead of MMC3 (MMC3 doesn't have such bit so nothing actually needs to
be done). This breaks 2nd SD slot on pandora.
Fix this by changing hsmmc23_before_set_reg() to only handle MMC2.
Note that this removes .remux() call for MMC3, but no board currently
needs it and it's also not called for MMC4 and MMC5.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
following statement can only change device size from 8-bit(0) to 16-bit(1),
but not vice versa:
regval |= GPMC_CONFIG1_DEVICESIZE(wval);
so as this field has 1 reserved bit, that could be used in future,
just clear both bits and then OR with the desired value
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
Commit 2f0778af (ARM: 7205/2: sched_clock: allow sched_clock to be
selected at runtime) had a typo for the case when CONFIG_OMAP_32K_TIMER
is not set.
In dmtimer_read_sched_clock(), wrong argument was getting passed to
__omap_dm_timer_read_counter() function call; instead of "&clksrc",
we were passing "clksrc.io_base", which results into kernel crash.
To reproduce kernel crash, just disable the CONFIG_OMAP_32K_TIMER config
option (and DEBUG_LL) and build/boot the kernel.
This will use dmtimer as a kernel clocksource and lead to kernel
crash during boot -
[ 0.000000] OMAP clocksource: GPTIMER2 at 26000000 Hz
[ 0.000000] sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every
165191ms
[ 0.000000] Unable to handle kernel paging request at virtual address
00030ef1
[ 0.000000] pgd = c0004000
[ 0.000000] [00030ef1] *pgd=00000000
[ 0.000000] Internal error: Oops: 5 [#1] SMP
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 Not tainted (3.3.0-rc1-11574-g0c76665-dirty #3)
[ 0.000000] PC is at dmtimer_read_sched_clock+0x18/0x4c
[ 0.000000] LR is at update_sched_clock+0x10/0x84
[ 0.000000] pc : [<c00243b8>] lr : [<c0018684>] psr: 200001d3
[ 0.000000] sp : c0641f38 ip : c0641e18 fp : 0000000a
[ 0.000000] r10: 151c3303 r9 : 00000026 r8 : 76276259
[ 0.000000] r7 : 00028547 r6 : c065ac80 r5 : 431bde82 r4 : c0655968
[ 0.000000] r3 : 00030ef1 r2 : fb032000 r1 : 00000028 r0 : 00000001
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
[tony@atomide.com: updated comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/microcode_amd: Add support for CPU family specific container files
x86/amd: Add missing feature flag for fam15h models 10h-1fh processors
x86/boot-image: Don't leak phdrs in arch/x86/boot/compressed/misc.c::Parse_elf()
x86/numachip: Drop unnecessary conflict with EDAC
x86/uv: Fix uninitialized spinlocks
x86/uv: Fix uv_gpa_to_soc_phys_ram() shift
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
m68k: Fix assembler constraint to prevent overeager gcc optimisation
mac_esp: rename irq
mac_scsi: dont enable mac_scsi irq before requesting it
macfb: fix black and white modes
m68k/irq: Remove obsolete IRQ_FLG_* definitions
Fix up trivial conflict in arch/m68k/kernel/process_mm.c as per Geert.
rsyslog will display KERN_EMERG messages on a connected
terminal. However, these messages are useless/undecipherable
for a general user.
For example, after a softlockup we get:
Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
kernel:Stack:
Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
kernel:Call Trace:
Message from syslogd@intel-s3e37-04 at Jan 25 14:18:06 ...
kernel:Code: ff ff a8 08 75 25 31 d2 48 8d 86 38 e0 ff ff 48 89
d1 0f 01 c8 0f ae f0 48 8b 86 38 e0 ff ff a8 08 75 08 b1 01 4c 89 e0 0f 01 c9 <e8> ea 69 dd ff 4c 29 e8 48 89 c7 e8 0f bc da ff 49 89 c4 49 89
This happens because the printk levels for these messages are
incorrect. Only an informational message should be displayed on
a terminal.
I modified the printk levels for various messages in the kernel
and tested the output by using the drivers/misc/lkdtm.c kernel
modules (ie, softlockups, panics, hard lockups, etc.) and
confirmed that the console output was still the same and that
the output to the terminals was correct.
For example, in the case of a softlockup we now see the much
more informative:
Message from syslogd@intel-s3e37-04 at Jan 25 10:18:06 ...
BUG: soft lockup - CPU4 stuck for 60s!
instead of the above confusing messages.
AFAICT, the messages no longer have to be KERN_EMERG. In the
most important case of a panic we set console_verbose(). As for
the other less severe cases the correct data is output to the
console and /var/log/messages.
Successfully tested by me using the drivers/misc/lkdtm.c module.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: dzickus@redhat.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/1327586134-11926-1-git-send-email-prarit@redhat.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Quite oddly, all of the arguments passed through from the top
level macros to the second level which didn't need parentheses
had them, while the only expression (involving a parameter)
needing them didn't.
Very recently I got bitten by the lack thereof when using
something like "array + index" for the first operand, with
"array" being an array more narrow than int.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/4F2183A9020000780006F3E6@nat28.tlf.novell.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Add missing iounmap in error handling code, in a case where the function
already preforms iounmap on some other execution path.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e;
statement S,S1;
int ret;
@@
e = \(ioremap\|ioremap_nocache\)(...)
... when != iounmap(e)
if (<+...e...+>) S
... when any
when != iounmap(e)
*if (...)
{ ... when != iounmap(e)
return ...; }
... when any
iounmap(e);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Fix the following build error found when building imx_v4_v5_defconfig:
CC arch/arm/mach-imx/mach-imx27ipcam.o
In file included from arch/arm/plat-mxc/include/mach/iomux-mx27.h:23,
from arch/arm/mach-imx/mach-imx27ipcam.c:22:
arch/arm/plat-mxc/include/mach/iomux-v1.h:99: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'imx_iomuxv1_init'
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
if the HDMI PHY is kept powered on when the cable is not connected.
This patch solves the problem by adding hot-plug-detection into the HDMI
IP driver. This is not a real HPD support in the sense that nobody else
than the IP driver gets to know about the HPD events, but is only meant
to fix the HW bug.
The strategy is simple: If the display device is turned off by the user,
the PHY power is set to OFF. When the display device is turned on by the
user, the PHY power is set either to LDOON or TXON, depending on whether
the HDMI cable is connected.
The reason to avoid PHY OFF when the display device is on, but the cable
is disconnected, is that when the PHY is turned OFF, the HDMI IP is not
"ticking" and thus the DISPC does not receive pixel clock from the HDMI
IP. This would, for example, prevent any VSYNCs from happening, and
would thus affect the users of omapdss. By using LDOON when the cable is
disconnected we'll avoid the HW bug, but keep the HDMI working as usual
from the user's point of view.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Both Panda and 4430SDP use GPIO 63 as HDMI hot-plug-detect. Configure
this GPIO in the board files.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
The HDMI GPIO pins LS_OE and CT_CP_HPD are not currently configured.
This patch configures them as output pins.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
"hdmi_hpd" pin is muxed to INPUT and PULLUP, but the pin is not
currently used, and in the future when it is used, the pin is used as a
GPIO and is board specific, not an OMAP4 wide thing.
So remove the muxing for now.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
The GPIO 60 on 4430sdp and Panda is not HPD GPIO, as currently marked in
the board files, but CT_CP_HPD, which is used to enable/disable HPD
functionality.
This patch renames the GPIO.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Instead of freeing the GPIOs individually, use gpio_free_array().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
We've decided to provide CPU family specific container files
(starting with CPU family 15h). E.g. for family 15h we have to
load microcode_amd_fam15h.bin instead of microcode_amd.bin
Rationale is that starting with family 15h patch size is larger
than 2KB which was hard coded as maximum patch size in various
microcode loaders (not just Linux).
Container files which include patches larger than 2KB cause
different kinds of trouble with such old patch loaders. Thus we
have to ensure that the default container file provides only
patches with size less than 2KB.
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: Borislav Petkov <borislav.petkov@amd.com>
Cc: <stable@kernel.org>
Link: http://lkml.kernel.org/r/20120120164412.GD24508@alberich.amd.com
[ documented the naming convention and tidied the code a bit. ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
That is the last one missing for those CPUs.
Others were recently added with commits
fb215366b3
(KVM: expose latest Intel cpu new features (BMI1/BMI2/FMA/AVX2) to guest)
and
commit 969df4b829
(x86: Report cpb and eff_freq_ro flags correctly)
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Link: http://lkml.kernel.org/r/20120120163823.GC24508@alberich.amd.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Initialize two spinlocks in tlb_uv.c and also properly define/initialize
the uv_irq_lock.
The lack of explicit initialization seems to be functionally
harmless, but it is diagnosed when these are turned on:
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_LOCKDEP=y
Signed-off-by: Cliff Wickman <cpw@sgi.com>
Cc: <stable@kernel.org>
Cc: Dimitri Sivanich <sivanich@sgi.com>
Link: http://lkml.kernel.org/r/E1RnXd1-0003wU-PM@eag09.americas.sgi.com
[ Added the uv_irq_lock initialization fix by Dimitri Sivanich ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
uv_gpa_to_soc_phys_ram() was inadvertently ignoring the
shift values. This fix takes the shift into account.
Signed-off-by: Russ Anderson <rja@sgi.com>
Cc: <stable@kernel.org>
Link: http://lkml.kernel.org/r/20120119020753.GA7228@sgi.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
dss_core has to be initialized before any other DSS hwmod. Currently
this is broken as dss_core is listed in chip/revision specific hwmod
lists while other DSS hwmods are listed in common list which is
registered first.
This patch moves DSS hwmods (except for dss_core) to the separate list
which is registered last to ensure that dss_core is already registered.
This solves the problem with BUG() in L3 interrupt handler on boards
with DSS enabled in bootloader.
The long-term fix to this is to ensure modules are set up in dependency
order in the hwmod core code.
CC: Tomi Valkeinen <tomi.valkeinen@ti.com>
CC: Archit Taneja <archit@ti.com>
CC: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
[paul@pwsan.com: add notes that this is just a temporary workaround until
hwmod dependencies are added]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Commit 22f51371f8 ("ARM: OMAP3: pm: use
prcm chain handler") breaks the build on a 2420-only config, due to
a missing include for plat/irqs.h:
CC arch/arm/mach-omap2/prm2xxx_3xxx.o
arch/arm/mach-omap2/prm2xxx_3xxx.c:41:11: error: 'INT_34XX_PRCM_MPU_IRQ' undeclared here (not in a function)
Fix by explicitly including it.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Commit 7b250aff1c ("ARM: OMAP: Avoid
cpu_is_omapxxxx usage until map_io is done") breaks the build on a
2420-only config on v3.3-rc1:
arch/arm/mach-omap2/built-in.o: In function `omap2430_init_early':
arch/arm/mach-omap2/io.c:406: undefined reference to `omap2_set_globals_243x'
arch/arm/mach-omap2/io.c:410: undefined reference to `omap243x_clockdomains_init'
arch/arm/mach-omap2/io.c:411: undefined reference to `omap2430_hwmod_init'
Fix by only compiling omap2420_init_early() when CONFIG_SOC_OMAP2420
is selected, and only compiling omap2430_init_early() when
CONFIG_SOC_OMAP2430 is selected.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
To be able to get the memory resources by name from
the DMIC driver (for MPU and for DMA).
Without this patch, functionality that was working in 3.2 breaks in
3.3-rc1. This patch should have gone in as part of the 3.3 merge
window, but was inadvertently missed.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
[paul@pwsan.com: added commit message note]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
dispc's sysc_flags is missing SYSC_HAS_ENAWAKEUP flag. This seems to
cause SYNC_LOST errors from the DSS when the power management is
enabled.
This patch adds the missing SYSC_HAS_ENAWAKEUP flag. Note that there are
other flags missing also (clock activity, DSI's sysc flags), but as they
are not critical, they will be fixed in the next merge window.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Currently OMAP2 and 3 share the same omap_hwmod_class and
omap_hwmod_class_sysconfig for dispc. However, OMAP3 has sysconfig
bits that OMAP2 doesn't have, so we need to split those structs into
OMAP2 and OMAP3 specific versions.
This patch only splits the structs, without changing the contents.
This is a prerequisite for a subsequent fix.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
[paul@pwsan.com: added commit note]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
This macro is used to generate unprivileged accesses (LDRT/STRT) to user
space.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The dynamic ftrace ops startup test currently fails on Thumb-2 kernels:
Testing tracer function: PASSED
Testing dynamic ftrace: PASSED
Testing dynamic ftrace ops #1: (0 0 0 0 0) FAILED!
This is because while the addresses in the mcount records do not have
the zero bit set, the IP reported by the mcount call does have it set
(because it is copied from the LR). This mismatch causes the ops
filtering in ftrace_ops_list_func() to not call the relevant tracers.
Fix this by clearing the zero bit before adjusting the LR for the mcount
instruction size. Also, combine the mov+sub into a single sub
instruction.
Acked-by: Dave Martin <dave.martin@linaro.org>
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Since commit 0536bdf33f (ARM: move iotable mappings within
the vmalloc region), the RealView PB11MP cannot boot anymore.
This is caused by the way the mappings are described on this
platform (define replaced by hex values for clarity):
{ /* GIC CPU interface mapping */
.virtual = IO_ADDRESS(0x1F000100),
.pfn = __phys_to_pfn(0x1F000100),
.length = SZ_4K,
.type = MT_DEVICE,
}, { /* GIC distributor mapping */
.virtual = IO_ADDRESS(0x1F001000),
.pfn = __phys_to_pfn(0x1F001000),
.length = SZ_4K,
.type = MT_DEVICE,
}
The first mapping ends up reserving two pages, and clashes with
the second one, which triggers a BUG_ON in vm_area_add_early().
In order to solve this problem, treat the MPCore private memory
region (containing the SCU, the GIC and the TWD) as a single region,
as described in the TRM:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/CACGDJJC.html
The EB11MP is converted the same way, even if it manages to avoid
the problem.
Tested on both PB11MP and EB11MP.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc: Fix build on some non-freescale platforms
powerpc/powernv: Fix PCI resource handling
powerpc/crash: Fix build error without SMP
powerpc/cpuidle: Make it a bool, not a tristate
powerpc/85xx: Add dr_mode property in USB nodes
powerpc/85xx: Enable USB2 controller node for P1020RDB
powerpc/85xx: Fix cmd12 bug and add the chip compatible for eSDHC
arch/powerpc/sysdev/fsl_pci.c: add missing iounmap
powerpc: fix compile error with 85xx/p1022_ds.c
Commit 9deaa53ac7 broke build
on platforms that use legacy_serial.c without also having
CONFIG_SERIAL_8250_FSL enabled due to an unconditional code
to a routine in that module.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Recent changes to the handling of PCI resources for host bridges
are breaking the PowerNV code for assigning resources on IODA.
The root of the problem is that the pci_bus attached to a host
bridge no longer has its "legacy" resource pointers populated
but only uses the newer list instead.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Davem says:
1) Fix JIT code generation on x86-64 for divide by zero, from Eric Dumazet.
2) tg3 header length computation correction from Eric Dumazet.
3) More build and reference counting fixes for socket memory cgroup
code from Glauber Costa.
4) module.h snuck back into a core header after all the hard work we
did to remove that, from Paul Gortmaker and Jesper Dangaard Brouer.
5) Fix PHY naming regression and add some new PCI IDs in stmmac, from
Alessandro Rubini.
6) Netlink message generation fix in new team driver, should only advertise
the entries that changed during events, from Jiri Pirko.
7) SRIOV VF registration and unregistration fixes, and also add a
missing PCI ID, from Roopa Prabhu.
8) Fix infinite loop in tx queue flush code of brcmsmac, from Stanislaw Gruszka.
9) ftgmac100/ftmac100 build fix, missing interrupt.h include.
10) Memory leak fix in net/hyperv do_set_mutlicast() handling, from Wei Yongjun.
11) Off by one fix in netem packet scheduler, from Vijay Subramanian.
12) TCP loss detection fix from Yuchung Cheng.
13) TCP reset packet MD5 calculation uses wrong address, fix from Shawn Lu.
14) skge carrier assertion and DMA mapping fixes from Stephen Hemminger.
15) Congestion recovery undo performed at the wrong spot in BIC and CUBIC
congestion control modules, fix from Neal Cardwell.
16) Ethtool ETHTOOL_GSSET_INFO is unnecessarily restrictive, from Michał Mirosław.
17) Fix triggerable race in ipv6 sysctl handling, from Francesco Ruggeri.
18) Statistics bug fixes in mlx4 from Eugenia Emantayev.
19) rds locking bug fix during info dumps, from your's truly.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (67 commits)
rds: Make rds_sock_lock BH rather than IRQ safe.
netprio_cgroup.h: dont include module.h from other includes
net: flow_dissector.c missing include linux/export.h
team: send only changed options/ports via netlink
net/hyperv: fix possible memory leak in do_set_multicast()
drivers/net: dsa/mv88e6xxx.c files need linux/module.h
stmmac: added PCI identifiers
llc: Fix race condition in llc_ui_recvmsg
stmmac: fix phy naming inconsistency
dsa: Add reporting of silicon revision for Marvell 88E6123/88E6161/88E6165 switches.
tg3: fix ipv6 header length computation
skge: add byte queue limit support
mv643xx_eth: Add Rx Discard and Rx Overrun statistics
bnx2x: fix compilation error with SOE in fw_dump
bnx2x: handle CHIP_REVISION during init_one
bnx2x: allow user to change ring size in ISCSI SD mode
bnx2x: fix Big-Endianess in ethtool -t
bnx2x: fixed ethtool statistics for MF modes
bnx2x: credit-leakage fixup on vlan_mac_del_all
macvlan: fix a possible use after free
...
I could not find cpus_in_crash anywhere in the sourcetree, except for
arch/powerpc/kernel/crash.c. Moving the definition into the CONFIG_SMP
fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
As pointed out, asm/system.h has empty inline implementations for
update_smt_snooze_delay and pseries_notify_cpuidle_add_cpu, which are
used when CONFIG_PSERIES_IDLE is undefined. Since those two functions
are used in core power architecture functions (store_smt_snooze_delay
at kernel/sysfs.c and smp_xics_setup_cpu at platforms/pseries/smp.c),
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
If NR_CPUS < 256 then arch_spinlock_t is only 16 bits wide but struct
xen_spinlock is 32 bits. When a spin lock is contended and
xl->spinners is modified the two bytes immediately after the spin lock
would be corrupted.
This is a regression caused by 84eb950db1
(x86, ticketlock: Clean up types and accessors) which reduced the size
of arch_spinlock_t.
Fix this by making xl->spinners a u8 if NR_CPUS < 256. A
BUILD_BUG_ON() is also added to check the sizes of the two structures
are compatible.
In many cases this was not noticable as there would often be padding
bytes after the lock (e.g., if any of CONFIG_GENERIC_LOCKBREAK,
CONFIG_DEBUG_SPINLOCK, or CONFIG_DEBUG_LOCK_ALLOC were enabled).
The bnx2 driver is affected. In struct bnx2, phy_lock and
indirect_lock may have no padding after them. Contention on phy_lock
would corrupt indirect_lock making it appear locked and the driver
would deadlock.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
CC: stable@kernel.org #only 3.2
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
There's no need to keep the DMA_REQ_SEL defines inside the ifdef.
Fixes the following build break with CONFIG_TEGRA_SYSTEM_DMA=n:
arch/arm/mach-tegra/devices.c:645: error: 'TEGRA_DMA_REQ_SEL_I2S_1' undeclared here (not in a function)
arch/arm/mach-tegra/devices.c:663: error: 'TEGRA_DMA_REQ_SEL_I2S2_1' undeclared here (not in a function)
arch/arm/mach-tegra/devices.c:663: error: initializer element is not constant
arch/arm/mach-tegra/devices.c:663: error: (near initialization for 'i2s_resource2[1].start')
arch/arm/mach-tegra/devices.c:664: error: initializer element is not constant
arch/arm/mach-tegra/devices.c:664: error: (near initialization for 'i2s_resource2[1].end')
Signed-off-by: Olof Johansson <olof@lixom.net>
Acked-by: Stephen Warren <swarren@nvidia.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPFmj/AAoJEIwa5zzehBx3utoP/2JKstlluwVdoIjzLDwJIZWS
BiFO90iC6knKHb3c4ZXBNtD4yz8ImFGr2v3IY4pR+feECu+zS/AYeynrr4AjlaRj
2wHI3/Cl2VktlzUR0k1KqfNrt1HLpZ8myxJ/pKchU8+KnxeQwCdV7MzkxocO0Abs
BQFhXj2WuS6b+H3kObrTy7n3tIyVeGUOW/bPU9TfWeRYEWBpGlqtPOH6A2cGi5e3
Iu9d9MPAiMt33+e7wZdmVHFky+ueqqeKevev+Vt8/JSJbPO7EseS/sbTOZH7Q1Yc
BWe5iARFpV9viJJMlwlO+wJ08BrqzCZ6M/mBITMAZ+a/EMYRn0TwibsWDw1GcAsA
H04Z1TW7pjni7SNFJavW3YWIR3TAKDZqwWbekGl2RzYqKmer1Hk6gwHAhxDQlMGY
2S7dSnw97zRA0WxW6kMPw5VY9VpDD1qjW+29UpEEePfAVhKkwE+lKYlX4k/l0ElC
9iYNoMVlhS4d5A7ZvhNU28XyGoxzAPNA4nC5OMUARZN++oSURDJ1kGNc73WQ8IbG
x+zZ7AFvt7y8OgZqG4bE+SeiHlYVAjtyV08WLxtDx4vTyNYuiWIXguf2hLJWEJPY
sqPGFHrMeh9YvYOXaa+DFb0fPkBJVJt663FPZ4TG2UBlphi26Ax5FtcnSBBvY4QV
CCen+xhdxX/dp83A/A0k
=ZgSs
-----END PGP SIGNATURE-----
Merge tag 'arm-soc-imx-move' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Consolidate i.MX 5 platforms to be under the new shared i.MX 3/5/6 tree.
* tag 'arm-soc-imx-move' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM i.MX: Update defconfig
ARM i.MX: Merge i.MX5 support into mach-imx
ARM i.MX5: remove unnecessary includes from board files
Fix up fairly trivial conflicts due to various changes nearby in
arch/arm/{mach,plat}-imx/{Kconfig,Makefile}
Pull request had been sent to the wrong email address, but happened
before the merge window closed. I'm merging the MX 5 consolidation,
since it apparently will help the next development window and will avoid
conflicts later as per Arnd.
If the provided system call number is equal to __NR_syscalls, the
current check will pass and a function pointer just after the system
call table may be called, since sys_call_table is an array with total
size __NR_syscalls.
Whether or not this is a security bug depends on what the compiler puts
immediately after the system call table. It's likely that this won't do
anything bad because there is an additional NULL check on the syscall
entry, but if there happens to be a non-NULL value immediately after the
system call table, this may result in local privilege escalation.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: <stable@vger.kernel.org>
Cc: Chen Liqin <liqin.chen@sunplusct.com>
Cc: Lennox Wu <lennox.wu@gmail.com>
Cc: Eugene Teo <eugeneteo@kernel.sg>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
kdump only allocates memory for the prstatus ELF note. For s390x,
besides of prstatus multiple ELF notes for various different register
types are stored. Therefore the currently allocated memory is not
sufficient. With this patch the KEXEC_NOTE_BYTES macro can be defined
by architecture code and for s390x it is set to the correct size now.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Jornada SSP driver is supposed to be initialized by a
module_init() call, but it was missed at some merge point. Since
the driver mostly pass calls through it magically works anyway,
but needs to be rectified.
Cc: Kristoffer Ericson <kristoffer.ericson@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
On secondary CPUs, the Timer Control Register is not reset
to a sane value before the timer is registered, and the TRM
doesn't seem to indicate any reset value either. In some cases,
the kernel will take an interrupt too early, depending on what
junk was present in the registers at reset time.
The fix is to set the Timer Control Register to 0 before
registering the clock_event_device and enabling the interrupt.
Problem seen on VE (Cortex A5) and Tegra.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
On v7, we use the same cache maintenance instructions for data lines
as for unified lines. This was not the case for v6, where HARVARD_CACHE
was defined to indicate the L1 cache topology.
This patch removes the erroneous compile-time check for HARVARD_CACHE in
proc-v7.S, ensuring that we perform I-side invalidation at boot.
Reported-and-Acked-by: Shawn Guo <shawn.guo@linaro.org>
Cc: stable <stable@vger.kernel.org>
Acked-by: Catalin Marinas <Catalin.Marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The merging of commits 1b6ba46b ("ARM: LPAE: MMU setup for the 3-level
page table format") and b4244738 ("ARM: 7202/1: Add Cortex-A7 proc info")
during the merge window ended up putting the Cortex-A7 proc_info into a
code block guarded by !CONFIG_ARM_LPAE. This makes Cortex-A7 platforms
unbootable when LPAE is enabled.
This patch moves the proc_info structure for Cortex-A7 outside of the
guarded block.
Cc: Pawel Moll <pawel.moll@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
It turns out that the logical CPU mapping is useful even when !CONFIG_SMP
for manipulation of devices like interrupt and power controllers when
running a UP kernel on a CPU other than 0. This can happen when kexecing
a UP image from an SMP kernel.
In the future, multi-cluster systems running AMP configurations will
require something similar for mapping cluster IDs, so it makes sense to
decouple this logic in preparation for this support.
Acked-by: Yang Bai <hamo.by@gmail.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Reported-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
To ensure correct alignment of cacheline-aligned data, the maximum
cacheline size needs to be known at compile time.
Since Cortex-A8 and Cortex-A15 have 64-byte cachelines (and it is likely
that there will be future ARMv7 implementations with the same line size)
then it makes sense to assume that CPU_V7 implies a 64-byte L1 cacheline
size. For CPUs with smaller caches, this will result in some harmless
padding but will help with single zImage work and avoid hitting subtle
bugs with misaligned data structures.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The exception fixup table is currently aligned to a 32-byte boundary.
Whilst this won't cause any problems, the exception_table_entry
structures contain only a pair of unsigned longs, so 4-byte alignment
is all that is required. If the table was walked from start to end,
cacheline alignment may bring some performance benefits, but since a
binary search is used, the access pattern is random and will not benefit
from a stricter alignment.
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The linker script assumes a cacheline size of 32 bytes when aligning
the .data..cacheline_aligned and .data..percpu sections.
This patch updates the script to use L1_CACHE_BYTES, which should be set
to 64 on platforms that require it.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Passing the address of a variable as an operand to an asm statement
doesn't mark the value of this variable as used, so gcc may optimize its
initialisation away. Fix this by using the "m" constraint instead.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: stable@vger.kernel.org
This reverts commit 5dd7bf59e0.
Conflicts:
scripts/mod/file2alias.c
This change is wrong on many levels. First and foremost, it causes a
regression. On boot on Assabet, which this patch gives a codec id of
'ucb1x00', it gives:
ucb1x00 ID not found: 1005
0x1005 is a valid ID for the UCB1300 device.
Secondly, this patch is way over the top in terms of complexity. The
only device which has been seen to be connected with this MCP code is
the UCB1x00 (UCB1200, UCB1300 etc) devices, and they all use the same
driver. Adding a match table, requiring the codec string to match the
hardware ID read out of the ID register, etc is completely over the top
when we can just read the hardware ID register.
DA850: sysclk4-7 only exist for pll0. for pll1 sysclk1-3 exist.
Remove the non-existing clocks.
Signed-off-by: Bas van den Berg <b.van.den.berg.nl@gmail.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
warning: (MACH_OMAP3_TOUCHBOOK && DRM_RADEON_KMS && DRM_I915 &&
STUB_POULSBO && FB_BACKLIGHT && USB_APPLEDISPLAY && FB_OLPC_DCON &&
ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && EEEPC_LAPTOP &&
ACPI_ASUS && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE
which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT)
A lot of boards need BACKLIGHT_CLASS_DEVICE for the framebuffers to
work, but it's not *needed* for the device itself. It might be nice to
enable it by default somewhoe if graphics stuff is enabled, but that's
another story.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
As on the other sam9 we need to cleanly shutdown the DDRAM before rebooting.
On those SoC the SDRAM/DDRAM controller is different. So, the assembly code
ends up being not cleanly combined with previous at91sam9_alt_restart function.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Currently setting it to PQFP changes subtype to BGA as subtypes are
swapped in at91rm9200_set_type().
Wrong subtype causes GPIO bank D not to work at all.
After this fix, subtype is still set as unknown. But board code should
fill it in with proper value. Another information is thus printed.
Bug discovery and first implementation made by Veli-Pekka Peltola.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: stable <stable@vger.kernel.org>
MMC_CAP_SD_HIGHSPEED is not supported on Snowball board resulting on
initialization errors.
Cc: stable@kernel.org
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Fredrik Soderstedt <fredrik.soderstedt@stericsson.com>
Signed-off-by: Philippe Langlais <philippe.langlais@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This applies ARM errata 764369 for all ux500 platforms.
Cc: stable@kernel.org
Signed-off-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Invalidating outer cache without disabling it is a big
nono, and so, remove the machine specific outer.inv_all
And at the same time it does not prevent us overriding
outer.disable as we do not have any such secure SMI to
handle the same while kexec disables the outer cache.
Signed-off-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This change is needed after 622859634 "usb: musb: drop a
gigantic amount of ifdeferry", where CONFIG_USB_MUSB_PERIPHERAL
& CONFIG_USB_MUSB_HOST has been removed.
Signed-off-by: Philippe Langlais <philippe.langlais@linaro.org>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This tiny patch adds generic atomic64 support for the Microblaze
architecture.
The patch is against the latest linux-2.6-microblaze tree. It also
fixes the kernel build for microblaze:
Error log:
CC kernel/trace/trace_clock.o
kernel/trace/trace_clock.c:117: error: expected '=', ',', ';', 'asm'
or '__attribute__' before 'trace_counter'
kernel/trace/trace_clock.c: In function 'trace_clock_counter':
kernel/trace/trace_clock.c:126: error: implicit declaration of
function 'atomic64_add_return'
kernel/trace/trace_clock.c:126: error: 'trace_counter' undeclared
(first use in this function)
kernel/trace/trace_clock.c:126: error: (Each undeclared identifier is
reported only once
kernel/trace/trace_clock.c:126: error: for each function it appears in.)
make[2]: *** [kernel/trace/trace_clock.o] Error 1
make[1]: *** [kernel/trace] Error 2
make: *** [kernel] Error 2
Signed-off-by: Ariane Keller <ariane.keller@tik.ee.ethz.ch>
Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Signed-off-by: Michal Simek <monstr@monstr.eu>
With commit 5def51b (ARM: 7211/1: smp_twd: get the rate from a clock)
hitting mainline, if we do not have a twd_clk for lookup, we will see
the following error message in boot log.
smp_twd: clock not found: -2
Actually we should add this clock regardless of the error message,
so that we can:
* Avoid the local timer calibrating at boot time
* Make the local timer cpufreq aware on imx6q
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/accounting, proc: Fix /proc/stat interrupts sum
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
tracepoints/module: Fix disabling tracepoints with taint CRAP or OOT
x86/kprobes: Add arch/x86/tools/insn_sanity to .gitignore
x86/kprobes: Fix typo transferred from Intel manual
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, syscall: Need __ARCH_WANT_SYS_IPC for 32 bits
x86, tsc: Fix SMI induced variation in quick_pit_calibrate()
x86, opcode: ANDN and Group 17 in x86-opcode-map.txt
x86/kconfig: Move the ZONE_DMA entry under a menu
x86/UV2: Add accounting for BAU strong nacks
x86/UV2: Ack BAU interrupt earlier
x86/UV2: Remove stale no-resources test for UV2 BAU
x86/UV2: Work around BAU bug
x86/UV2: Fix BAU destination timeout initialization
x86/UV2: Fix new UV2 hardware by using native UV2 broadcast mode
x86: Get rid of dubious one-bit signed bitfield
In checkin
303395ac3b x86: Generate system call tables and unistd_*.h from tables
the feature macros in <asm/unistd.h> were unified between 32 and 64
bits. Unfortunately 32 bits requires __ARCH_WANT_SYS_IPC and this was
inadvertently dropped.
Reported-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Link: http://lkml.kernel.org/r/CALLzPKbeXN5gdngo8uYYU8mAow=XhrwBFBhKfG811f37BubQOg@mail.gmail.com
Fix the following build warning:
CC arch/arm/kernel/setup.o
In file included from arch/arm/kernel/setup.c:39:
arch/arm/include/asm/elf.h:102:1: warning: "vmcore_elf64_check_arch" redefined
In file included from arch/arm/kernel/setup.c:24:
include/linux/crash_dump.h:30:1: warning: this is the location of the previous definition
Since commit 93a72052 (crash_dump: export is_kdump_kernel to modules, consolidate elfcorehdr_addr, setup_elfcorehdr and saved_max_pfn)
the inclusion of <linux/crash_dump.h> is no longer needed.
Remove the inclusion of <linux/crash_dump.h> and the build warning is fixed.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
All other ports use "Kernel code" to identify the Kernel text segment
in /proc/iomem. Change the ARM resources to do the same.
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
We can stall RCU processing on SMP platforms if a CPU sits in its idle
loop for a long time. This happens because we don't call irq_enter()
and irq_exit() around generic_smp_call_function_interrupt() and
friends. Add the necessary calls, and remove the one from within
ipi_timer(), so that they're all in a common place.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
WARNING: vmlinux.o(.text+0x1bc9c): Section mismatch in reference from the function ct_ca9x4_init_cpu_map() to the function .init.text:scu_get_core_count()
The function ct_ca9x4_init_cpu_map() references
the function __init scu_get_core_count().
WARNING: vmlinux.o(.text+0x1bce8): Section mismatch in reference from the function ct_ca9x4_init_cpu_map() to the function .init.text:set_smp_cross_call()
The function ct_ca9x4_init_cpu_map() references
the function __init set_smp_cross_call().
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 716a3dc200 (ARM: Add arm_memblock_steal() to allocate memory
away from the kernel) added a function which calls memblock_alloc().
This causes a section conflict:
WARNING: vmlinux.o(.text+0xc614): Section mismatch in reference from the function arm_memblock_steal() to the function .init.text:memblock_alloc()
The function arm_memblock_steal() references
the function __init memblock_alloc().
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
WARNING: arch/arm/mach-sa1100/built-in.o(.data+0x11b8): Section mismatch in reference from the variable sa1100_driver to the function .init.text:sa1100_cpu_init()
The variable sa1100_driver references
the function __init sa1100_cpu_init()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
f408c985ce (GPIO: sa1100: implement proper gpiolib gpio_to_irq conversion)
made gpio_to_irq() a function. This breaks collie where it's used to
initialize some static data. Fix that by moving the initialization to
the init code.
arch/arm/mach-sa1100/collie.c:139: error: initializer element is not constant
arch/arm/mach-sa1100/collie.c:139: error: (near initialization for 'collie_power_resource[0].start')
arch/arm/mach-sa1100/collie.c:140: error: initializer element is not constant
arch/arm/mach-sa1100/collie.c:140: error: (near initialization for 'collie_power_resource[0].end')
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This reverts commit 7cea00657d.
The sa1100 cleanups fatally broke the SA1100 RTC driver - the first
hint that something is wrong are these compiler warnings:
drivers/rtc/rtc-sa1100.c:42:1: warning: "RCNR" redefined
In file included from arch/arm/mach-sa1100/include/mach/hardware.h:73,
from drivers/rtc/rtc-sa1100.c:35:
arch/arm/mach-sa1100/include/mach/SA-1100.h:877:1: warning: this is the location of the previous definition
drivers/rtc/rtc-sa1100.c:43:1: warning: "RTAR" redefined
arch/arm/mach-sa1100/include/mach/SA-1100.h:876:1: warning: this is the location of the previous definition
drivers/rtc/rtc-sa1100.c:44:1: warning: "RTSR" redefined
arch/arm/mach-sa1100/include/mach/SA-1100.h:879:1: warning: this is the location of the previous definition
drivers/rtc/rtc-sa1100.c:45:1: warning: "RTTR" redefined
arch/arm/mach-sa1100/include/mach/SA-1100.h:878:1: warning: this is the location of the previous definition
drivers/rtc/rtc-sa1100.c:47:1: warning: "RTSR_HZE" redefined
arch/arm/mach-sa1100/include/mach/SA-1100.h:891:1: warning: this is the location of the previous definition
drivers/rtc/rtc-sa1100.c:48:1: warning: "RTSR_ALE" redefined
arch/arm/mach-sa1100/include/mach/SA-1100.h:890:1: warning: this is the location of the previous definition
drivers/rtc/rtc-sa1100.c:49:1: warning: "RTSR_HZ" redefined
arch/arm/mach-sa1100/include/mach/SA-1100.h:889:1: warning: this is the location of the previous definition
drivers/rtc/rtc-sa1100.c:50:1: warning: "RTSR_AL" redefined
arch/arm/mach-sa1100/include/mach/SA-1100.h:888:1: warning: this is the location of the previous definition
and the second problem, which is far more severe, are the different
register layouts, resulting in the wrong registers being read on
SA11x0 platforms. This patch adds:
#define RCNR 0x00 /* RTC Count Register */
#define RTAR 0x04 /* RTC Alarm Register */
#define RTSR 0x08 /* RTC Status Register */
#define RTTR 0x0c /* RTC Timer Trim Register */
but the SA11x0 registers are:
#define RTAR __REG(0x90010000) /* RTC Alarm Reg. */
#define RCNR __REG(0x90010004) /* RTC CouNt Reg. */
#define RTTR __REG(0x90010008) /* RTC Trim Reg. */
#define RTSR __REG(0x90010010) /* RTC Status Reg. */
Randy Dunlap reports that we get
arch/x86/um/shared/sysdep/ptrace.h:7:20: error: redefinition of 'regs_return_value'
arch/x86/um/shared/sysdep/ptrace.h:7:20: note: previous definition of 'regs_return_value' was here
when compiling UML for x86-64.
Stephen Rothwell root-caused it and says:
"Caused by commit d7e7528bcd ("Audit: push audit success and retcode
into arch ptrace.h") (another patch that was never in linux-next :-().
This file now needs protection against double inclusion."
so let's do as the man says.
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Analyzed-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This includes initial support for the recently published ACPI 5.0 spec.
In particular, support for the "hardware-reduced" bit that eliminates
the dependency on legacy hardware.
APEI has patches resulting from testing on real hardware.
Plus other random fixes.
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux: (52 commits)
acpi/apei/einj: Add extensions to EINJ from rev 5.0 of acpi spec
intel_idle: Split up and provide per CPU initialization func
ACPI processor: Remove unneeded variable passed by acpi_processor_hotadd_init V2
ACPI processor: Remove unneeded cpuidle_unregister_driver call
intel idle: Make idle driver more robust
intel_idle: Fix a cast to pointer from integer of different size warning in intel_idle
ACPI: kernel-parameters.txt : Add intel_idle.max_cstate
intel_idle: remove redundant local_irq_disable() call
ACPI processor: Fix error path, also remove sysdev link
ACPI: processor: fix acpi_get_cpuid for UP processor
intel_idle: fix API misuse
ACPI APEI: Convert atomicio routines
ACPI: Export interfaces for ioremapping/iounmapping ACPI registers
ACPI: Fix possible alignment issues with GAS 'address' references
ACPI, ia64: Use SRAT table rev to use 8bit or 16/32bit PXM fields (ia64)
ACPI, x86: Use SRAT table rev to use 8bit or 32bit PXM fields (x86/x86-64)
ACPI: Store SRAT table revision
ACPI, APEI, Resolve false conflict between ACPI NVS and APEI
ACPI, Record ACPI NVS regions
ACPI, APEI, EINJ, Refine the fix of resource conflict
...
Several problems fixed in this patch :
1) Target of the conditional jump in case a divide by 0 is performed
by a bpf is wrong.
2) Must 'generate' the full function prologue/epilogue at pass=0,
or else we can stop too early in pass=1 if the proglen doesnt change.
(if the increase of prologue/epilogue equals decrease of all
instructions length because some jumps are converted to near jumps)
3) Change the wrong length detection at the end of code generation to
issue a more explicit message, no need for a full stack trace.
Reported-by: Phil Oester <kernel@linuxace.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The vmlinux file for s390 contains a currently unused entry point,
which is specified in two different locations: the linker script
and the makefile. As it happens both definitions are different and
the linker file is broken (_start does not exist) and the makefile
specifies an entry point which makes no sense (the SALIPL loader
entry point).
So lets get rid of one definition (the makefile) and use the entry
point of all other ipl methods (0x10000 -> startup) to be consistent.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Enable USB2 controller node for P1020RDB. USB2 controller is used only
when board boots from SPI or SD as it is muxed with eLBC
Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
According to latest kernel, the auto-cmd12 property should be
"sdhci,auto-cmd12", and according to the SDHC binding and the workaround for
the special chip, add the chip compatible for eSDHC: "fsl,p1022-esdhc",
"fsl,mpc8536-esdhc", "fsl,p1020-esdhc", "fsl,p2020-esdhc" and
"fsl,p1010-esdhc".
Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Some fallout from the 3.3. merge window as well as a couple bug fixes
for older preexisting bugs that seem valid to include at this time:
* sched_clock changes broke picoxcell, fix included
* BSYM bugs causing issues with thumb2-built kernels on SMP
* Missing module.h include on msm.
* A collection of bugfixes for samsung platforms that didn't make it into
the first pull requests.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPFRlTAAoJEIwa5zzehBx3vNAP/132diTVp8P5m9+fmgkyKL1Q
g6Djzdp7y4sEACCuHxTGIwhusqjwFlfTU1DnjOcQrylvN/GSBEqn1Kdjp3sC++F5
+Zot4psLpcKJk94HgbGvG+kXZ+mD2DaQUybVL/O/9ShfoUK589i4LSWWTUO4Chp8
C2Vi0s64UQW8R2gt/S7LaoaN+qbbNBDQRPj+hWJ/mO15RSH5V3XgpSOGvTq6+/QK
nG/kcbVTu4su2z5mOxOZRw+Wx+woEKwpu/4viy5Kfoyj7igHAnWMGww8tkFadOam
4RBGaJwWmqPGiSkAsLoRfpUDKWBwMSAO13FRiMydhEiodL7db9Ug4kddTFT/GIQf
pjEz4kscYxmYVzQ4oSjp5tG65berMBUHD3Sy7VZp/htvyF/HmbLiXfseJQF2DP0s
dqoZ5W0cS3sXjzaGWzjIqZt7/GlX+ulqgy2eQnHfF/D2oFIqmtMu7YXMH3hj/m4z
lrgGjGhy+XzVmRNujGvHs+p4tWZh7G5Hxprs/m3juoEopgcFbNsJGJW/nLHuDahL
tOJaP5zD9mptkGBMfdWfwWngpBFJcfrF9Zq2qfHgzbzRAEGWy8hOT8qK2+fad4vN
6I52axIGBFoTZjqAfs5Pg1vc4wZd/WOHA3KjxsVEvHcHLxo/inndDG6vwJoRzQwV
DjtiPTl+MRjxTQmh0+qH
=+GJ1
-----END PGP SIGNATURE-----
Merge tag 'arm-soc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
ARM: fixes for ARM platforms
Some fallout from the 3.3. merge window as well as a couple bug fixes
for older preexisting bugs that seem valid to include at this time:
* sched_clock changes broke picoxcell, fix included
* BSYM bugs causing issues with thumb2-built kernels on SMP
* Missing module.h include on msm.
* A collection of bugfixes for samsung platforms that didn't make it into
the first pull requests.
* tag 'arm-soc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: make BSYM macro assembly only
ARM: highbank: remove incorrect BSYM usage
ARM: imx: remove incorrect BSYM usage
ARM: exynos: remove incorrect BSYM usage
ARM: ux500: add missing ENDPROC to headsmp.S
ARM: msm: Add missing ENDPROC to headsmp.S
ARM: versatile: Add missing ENDPROC to headsmp.S
ARM: EXYNOS: Invert VCLK polarity for framebuffer on ORIGEN
ARM: S3C64XX: Fix interrupt configuration for PCA935x on Cragganmore
ARM: S3C64XX: Fix the memory mapped GPIOs on Cragganmore
ARM: S3C64XX: Remove hsmmc1 from Cragganmore
ARM: S3C64XX: Remove unconditional power domain disables
ARM: SAMSUNG: Declare struct platform_device in plat/s3c64xx-spi.h
ARM: SAMSUNG: dma-ops.h needs mach/dma.h
ARM: SAMSUNG: Guard against multiple inclusion of plat/dma.h
ARM: picoxcell: fix sched_clock() cleanup fallout
ARM: msm: vreg is a module and so needs module.h
JONGMAN HEO reports:
With current linus git (commit a25a2b84), I got following build error,
arch/x86/kernel/vm86_32.c: In function 'do_sys_vm86':
arch/x86/kernel/vm86_32.c:340: error: implicit declaration of function '__audit_syscall_exit'
make[3]: *** [arch/x86/kernel/vm86_32.o] Error 1
OK, I can reproduce it (32bit allmodconfig with AUDIT=y, AUDITSYSCALL=n)
It's due to commit d7e7528bcd: "Audit: push audit success and retcode
into arch ptrace.h".
Reported-by: JONGMAN HEO <jongman.heo@samsung.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit: (29 commits)
audit: no leading space in audit_log_d_path prefix
audit: treat s_id as an untrusted string
audit: fix signedness bug in audit_log_execve_info()
audit: comparison on interprocess fields
audit: implement all object interfield comparisons
audit: allow interfield comparison between gid and ogid
audit: complex interfield comparison helper
audit: allow interfield comparison in audit rules
Kernel: Audit Support For The ARM Platform
audit: do not call audit_getname on error
audit: only allow tasks to set their loginuid if it is -1
audit: remove task argument to audit_set_loginuid
audit: allow audit matching on inode gid
audit: allow matching on obj_uid
audit: remove audit_finish_fork as it can't be called
audit: reject entry,always rules
audit: inline audit_free to simplify the look of generic code
audit: drop audit_set_macxattr as it doesn't do anything
audit: inline checks for not needing to collect aux records
audit: drop some potentially inadvisable likely notations
...
Use evil merge to fix up grammar mistakes in Kconfig file.
Bad speling and horrible grammar (and copious swearing) is to be
expected, but let's keep it to commit messages and comments, rather than
expose it to users in config help texts or printouts.
pit_expect_msb() returns success wrongly in the below SMI scenario:
a. pit_verify_msb() has not yet seen the MSB transition.
b. we are close to the MSB transition though and got a SMI immediately after
returning from pit_verify_msb() which didn't see the MSB transition. PIT MSB
transition has happened somewhere during SMI execution.
c. returned from SMI and we noted down the 'tsc', saw the pit MSB change now and
exited the loop to calculate 'deltatsc'. Instead of noting the TSC at the MSB
transition, we are way off because of the SMI. And as the SMI happened
between the pit_verify_msb() and before the 'tsc' is recorded in the
for loop, 'delattsc' (d1/d2 in quick_pit_calibrate()) will be small and
quick_pit_calibrate() will not notice this error.
Depending on whether SMI disturbance happens while computing d1 or d2, we will
see the TSC calibrated value smaller or bigger than the expected value. As a
result, in a cluster we were seeing a variation of approximately +/- 20MHz in
the calibrated values, resulting in NTP failures.
[ As far as the SMI source is concerned, this is a periodic SMI that gets
disabled after ACPI is enabled by the OS. But the TSC calibration happens
before the ACPI is enabled. ]
To address this, change pit_expect_msb() so that
- the 'tsc' is the TSC in between the two reads that read the MSB
change from the PIT (same as before)
- the 'delta' is the difference in TSC from *before* the MSB changed
to *after* the MSB changed.
Now the delta is twice as big as before (it covers four PIT accesses,
roughly 4us) and quick_pit_calibrate() will loop a bit longer to get
the calibrated value with in the 500ppm precision. As the delta (d1/d2)
covers four PIT accesses, actual calibrated result might be closer to
250ppm precision.
As the loop now takes longer to stabilize, double MAX_QUICK_PIT_MS to 50.
SMI disturbance will showup as much larger delta's and the loop will take
longer than usual for the result to be with in the accepted precision. Or will
fallback to slow PIT calibration if it takes more than 50msec.
Also while we are at this, remove the calibration correction that aims to
get the result to the middle of the error bars. We really don't know which
direction to correct into, so remove it.
Reported-and-tested-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Link: http://lkml.kernel.org/r/1326843337.5291.4.camel@sbsiddha-mobl2
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
This patch provides functionality to audit system call events on the
ARM platform. The implementation was based off the structure of the
MIPS platform and information in this
(http://lists.fedoraproject.org/pipermail/arm/2009-October/000382.html)
mailing list thread. The required audit_syscall_exit and
audit_syscall_entry checks were added to ptrace using the standard
registers for system call values (r0 through r3). A thread information
flag was added for auditing (TIF_SYSCALL_AUDIT) and a meta-flag was
added (_TIF_SYSCALL_WORK) to simplify modifications to the syscall
entry/exit. Now, if either the TRACE flag is set or the AUDIT flag is
set, the syscall_trace function will be executed. The prober changes
were made to Kconfig to allow CONFIG_AUDITSYSCALL to be enabled.
Due to platform availability limitations, this patch was only tested
on the Android platform running the modified "android-goldfish-2.6.29"
kernel. A test compile was performed using Code Sourcery's
cross-compilation toolset and the current linux-3.0 stable kernel. The
changes compile without error. I'm hoping, due to the simple modifications,
the patch is "obviously correct".
Signed-off-by: Nathaniel Husted <nhusted@gmail.com>
Signed-off-by: Eric Paris <eparis@redhat.com>
Every arch calls:
if (unlikely(current->audit_context))
audit_syscall_entry()
which requires knowledge about audit (the existance of audit_context) in
the arch code. Just do it all in static inline in audit.h so that arch's
can remain blissfully ignorant.
Signed-off-by: Eric Paris <eparis@redhat.com>
In the ia32entry syscall exit audit fastpath we have assembly code which calls
__audit_syscall_exit directly. This code was, however, zeroes the upper 32
bits of the return code. It then proceeded to call code which expects longs
to be 64bits long. In order to handle code which expects longs to be 64bit we
sign extend the return code if that code is an error. Thus the
__audit_syscall_exit function can correctly handle using the values in
snprintf("%ld"). This fixes the regression introduced in 5cbf1565f2.
Old record:
type=SYSCALL msg=audit(1306197182.256:281): arch=40000003 syscall=192 success=no exit=4294967283
New record:
type=SYSCALL msg=audit(1306197182.256:281): arch=40000003 syscall=192 success=no exit=-13
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>
The audit system previously expected arches calling to audit_syscall_exit to
supply as arguments if the syscall was a success and what the return code was.
Audit also provides a helper AUDITSC_RESULT which was supposed to simplify things
by converting from negative retcodes to an audit internal magic value stating
success or failure. This helper was wrong and could indicate that a valid
pointer returned to userspace was a failed syscall. The fix is to fix the
layering foolishness. We now pass audit_syscall_exit a struct pt_reg and it
in turns calls back into arch code to collect the return value and to
determine if the syscall was a success or failure. We also define a generic
is_syscall_success() macro which determines success/failure based on if the
value is < -MAX_ERRNO. This works for arches like x86 which do not use a
separate mechanism to indicate syscall failure.
We make both the is_syscall_success() and regs_return_value() static inlines
instead of macros. The reason is because the audit function must take a void*
for the regs. (uml calls theirs struct uml_pt_regs instead of just struct
pt_regs so audit_syscall_exit can't take a struct pt_regs). Since the audit
function takes a void* we need to use static inlines to cast it back to the
arch correct structure to dereference it.
The other major change is that on some arches, like ia64, MIPS and ppc, we
change regs_return_value() to give us the negative value on syscall failure.
THE only other user of this macro, kretprobe_example.c, won't notice and it
makes the value signed consistently for the audit functions across all archs.
In arch/sh/kernel/ptrace_64.c I see that we were using regs[9] in the old
audit code as the return value. But the ptrace_64.h code defined the macro
regs_return_value() as regs[3]. I have no idea which one is correct, but this
patch now uses the regs_return_value() function, so it now uses regs[3].
For powerpc we previously used regs->result but now use the
regs_return_value() function which uses regs->gprs[3]. regs->gprs[3] is
always positive so the regs_return_value(), much like ia64 makes it negative
before calling the audit code when appropriate.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: H. Peter Anvin <hpa@zytor.com> [for x86 portion]
Acked-by: Tony Luck <tony.luck@intel.com> [for ia64]
Acked-by: Richard Weinberger <richard@nod.at> [for uml]
Acked-by: David S. Miller <davem@davemloft.net> [for sparc]
Acked-by: Ralf Baechle <ralf@linux-mips.org> [for mips]
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> [for ppc]
The Intel documentation at
http://software.intel.com/file/36945
shows the ANDN opcode and Group 17 with encoding f2 and f3 encoding
respectively. The current version of x86-opcode-map.txt shows them
with f3 and f4. Unless someone can point to documentation which shows
the currently used encoding the following patch be applied.
Signed-off-by: Ulrich Drepper <drepper@gmail.com>
Link: http://lkml.kernel.org/r/CAOPLpQdq5SuVo9=023CYhbFLAX9rONyjmYq7jJkqc5xwctW5eA@mail.gmail.com
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add missing iounmap in error handling code, in a case where the function
already preforms iounmap on some other execution path.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e;
statement S,S1;
int ret;
@@
e = \(ioremap\|ioremap_nocache\)(...)
... when != iounmap(e)
if (<+...e...+>) S
... when any
when != iounmap(e)
*if (...)
{ ... when != iounmap(e)
return ...; }
... when any
iounmap(e);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Current linux-next compiled with mpc85xx_defconfig causes this:
arch/powerpc/platforms/85xx/p1022_ds.c:341:14: error: 'udbg_progress' undeclared here (not in a function)
Add include to fix this.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Acked-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Move the ZONE_DMA kconfig symbol under a menu item instead
of having it listed before everything else in
"make {xconfig | gconfig | nconfig | menuconfig}".
This drops the first line of the top-level kernel config menu
(in 3.2) below and moves it under "Processor type and features".
[*] DMA memory allocation support
General setup --->
[*] Enable loadable module support --->
[*] Enable the block layer --->
Processor type and features --->
Power management and ACPI options --->
Bus options (PCI etc.) --->
Executable file formats / Emulations --->
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-mm@kvack.org <linux-mm@kvack.org>
Link: http://lkml.kernel.org/r/4F14811E.6090107@xenotime.net
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: David Rientjes <rientjes@google.com>
In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides
32bits for these. The new fields were reserved before.
According to the ACPI spec, the OS must disregrard reserved fields.
ia64 did handle the PXM fields almost consistently, but depending on
sgi's sn2 platform. This patch leaves the sn2 logic in, but does also
use 16/32 bits for PXM if the SRAT has rev 2 or higher.
The patch also adds __init to the two pxm accessor functions, as they
access __initdata now and are called from an __init function only anyway.
Note that the code only uses 16 bits for the PXM field in the processor
proximity field; the patch does not address this as 16 bits are more than
enough.
Signed-off-by: Kurt Garloff <kurt@garloff.de>
Signed-off-by: Len Brown <len.brown@intel.com>
In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides
32bits for these. The new fields were reserved before.
According to the ACPI spec, the OS must disregrard reserved fields.
x86/x86-64 was rather inconsistent prior to this patch; it used 8 bits
for the pxm field in cpu_affinity, but 32 bits in mem_affinity.
This patch makes it consistent: Either use 8 bits consistently (SRAT
rev 1 or lower) or 32 bits (SRAT rev 2 or higher).
cc: x86@kernel.org
Signed-off-by: Kurt Garloff <kurt@garloff.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Some firmware will access memory in ACPI NVS region via APEI. That
is, instructions in APEI ERST/EINJ table will read/write ACPI NVS
region. The original resource conflict checking in APEI code will
check memory/ioport accessed by APEI via general resource management
mechanism. But ACPI NVS region is marked as busy already, so that the
false resource conflict will prevent APEI ERST/EINJ to work.
To fix this, this patch record ACPI NVS regions, so that we can avoid
request resources for memory region inside it.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
