Here is the big staging tree pull request for the 3.5-rc1 merge window.
Loads of changes here, and we just narrowly added more lines than we
added:
622 files changed, 28356 insertions(+), 26059 deletions(-)
But, good news is that there is a number of subsystems that moved out of
the staging tree, to their respective "real" portions of the kernel.
Code that moved out was:
- iio core code
- mei driver
- vme core and bridge drivers
There was one broken network driver that moved into staging as a step
before it is removed from the tree (pc300), and there was a few new
drivers added to the tree:
- new iio drivers
- gdm72xx wimax USB driver
- ipack subsystem and 2 drivers
All of the movements around have acks from the various subsystem
maintainers, and all of this has been in the linux-next tree for a
while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk+7q8MACgkQMUfUDdst+ymjogCguo8fANFVlPWeZGeoBTL+aQfQ
yTkAoLE0codmh+2SvhulYgyU1Wh6ZDK2
=nJ2F
-----END PGP SIGNATURE-----
Merge tag 'staging-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging tree changes from Greg Kroah-Hartman:
"Here is the big staging tree pull request for the 3.5-rc1 merge
window.
Loads of changes here, and we just narrowly added more lines than we
added:
622 files changed, 28356 insertions(+), 26059 deletions(-)
But, good news is that there is a number of subsystems that moved out
of the staging tree, to their respective "real" portions of the
kernel.
Code that moved out was:
- iio core code
- mei driver
- vme core and bridge drivers
There was one broken network driver that moved into staging as a step
before it is removed from the tree (pc300), and there was a few new
drivers added to the tree:
- new iio drivers
- gdm72xx wimax USB driver
- ipack subsystem and 2 drivers
All of the movements around have acks from the various subsystem
maintainers, and all of this has been in the linux-next tree for a
while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"
Fixed up various trivial conflicts, along with a non-trivial one found
in -next and pointed out by Olof Johanssen: a clean - but incorrect -
merge of the arch/arm/boot/dts/at91sam9g20.dtsi file. Fix up manually
as per Stephen Rothwell.
* tag 'staging-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (536 commits)
Staging: bcm: Remove two unused variables from Adapter.h
Staging: bcm: Removes the volatile type definition from Adapter.h
Staging: bcm: Rename all "INT" to "int" in Adapter.h
Staging: bcm: Fix warning: __packed vs. __attribute__((packed)) in Adapter.h
Staging: bcm: Correctly format all comments in Adapter.h
Staging: bcm: Fix all whitespace issues in Adapter.h
Staging: bcm: Properly format braces in Adapter.h
Staging: ipack/bridges/tpci200: remove unneeded casts
Staging: ipack/bridges/tpci200: remove TPCI200_SHORTNAME constant
Staging: ipack: remove board_name and bus_name fields from struct ipack_device
Staging: ipack: improve the register of a bus and a device in the bus.
staging: comedi: cleanup all the comedi_driver 'detach' functions
staging: comedi: remove all 'default N' in Kconfig
staging: line6/config.h: Delete unused header
staging: gdm72xx depends on NET
staging: gdm72xx: Set up parent link in sysfs for gdm72xx devices
staging: drm/omap: initial dmabuf/prime import support
staging: drm/omap: dmabuf/prime mmap support
pstore/ram: Add ECC support
pstore/ram: Switch to persistent_ram routines
...
This is a first step for adding ECC support for pstore RAM backend: we
will use the persistent_ram routines, kindly provided by Google.
Basically, persistent_ram is a set of helper routines to deal with the
[optionally] ECC-protected persistent ram regions.
A bit of Makefile, Kconfig and header files adjustments were needed
because of the move.
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is a transition patch to keep things bisectable, just moves
some routines under '#ifndef MODULE'. The code inside the #ifndef
will go away soon, but so far we must support pstore and ram_console.
So, we are about to use persistent_ram with pstore, with the ability
to compile persistent_ram routines as modules. Some parts of
persistent_ram uses memblock_reserve() routine, which is should be
only used built-in code, and thus it is not exported.
These persistent_ram bits are only used by Android's ram_console,
which is always built-in.
Without this patch, we won't able to compile persistent_ram as a
module:
ERROR: "memblock_reserve" [fs/pstore/ramoops.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
(As alternative, we could export memblock_reserve, but the thing
is: we won't need it later.)
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove 'old_log_footer_size' and 'early' members of struct
persistent_ram_zone, as these were never used at all.
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A corresponding function to persistent_ram_new().
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This includes devices' memory (e.g. framebuffers or memory mapped
EEPROMs on a local bus), as well as the normal RAM that we don't use
for the main memory.
For the normal (but unused) ram we could use kmaps, but this assumes
highmem support, so we don't bother and just use the memory via
ioremap.
As a side effect, the following hack is possible: when used together
with pstore_ram (new ramoops) module, we can limit the normal RAM region
with mem= and then point ramoops to use the rest of the memory, e.g.
mem=128M ramoops.mem_address=0x8000000
Sure, we could just reserve the region with memblock_reserve() early in
the arch/ code, and then register a pstore_ram platform device pointing
to the reserved region. It's still a viable option if platform wants
to do so.
Also, we might want to use IO accessors in case of a real device,
but for now we don't bother (the old ramoops wasn't using it either, so
at least we don't make things worse).
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Factor out vmap logic out of persistent_ram_buffer_map(), this will
make the code a bit more understandable when we'll add support for
non-bootmem memory.
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The routine just creates a persistent ram zone at a specified address.
For persistent_ram_init_ringbuffer() we'd need to add a
'struct persistent_ram' to the global list, and associate it with a
device. We don't need all this complexity in pstore_ram, so we introduce
the simple function.
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Factor post init logic out of __persistent_ram_init(), we'll need
it for the new persistent_ram_new() routine.
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is a longstanding bug, almost unnoticeable when calling
persistent_ram_write() for small buffers.
But when called for large data buffers, the write routine behaves
incorrectly, as the size may never update: instead of clamping
the size to the maximum buffer size, buffer_size_add_clamp() returns
an error (which is never checked by the write routine, btw).
To fix this, we now use buffer_size_add() that actually clamps the
size to the max value.
Also remove buffer_size_add_clamp(), it is no longer needed.
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: Colin Cross <ccross@android.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The 'node' struct member is unused, so remove it.
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix a few sparse warnings, and improve whitespace.
Cc: Brian Swetland <swetland@google.com>
Signed-off-by: Tim Bird <tim.bird@am.sony.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This changes the log initialization to be dynamic, but still
at boot time. These changes are a predecessor to implementing
runtime allocation and freeing of logs, to make the Android logger
less hard-coded.
Change from a fixed set of static log structures, to allocation
at init time into a list. Return proper error numbers on log
allocation failure.
Cc: Brian Swetland <swetland@google.com>
Signed-off-by: Tim Bird <tim.bird@am.sony.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This was done to resolve a merge issue with the init/main.c file.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(Life cycle of timed output device driver)
1) register the device as the timed output
2) enable() ops is called via the sysfs
timeout > 0 : timer is activated and device is turned on
timeout = 0 : timer is cancelled and device is off
3) unregister the timed output device if not used any more
So the registered device should be disabled explicitly when the module is removed.
('disabled' means the timer is stopped and the device is turned off)
Rather than implementing that code in each driver,
just call enable() with timeout = 0 to clean up the driver.
Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com>
Cc: Mike Lockwood <lockwood@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In their current AOSP tree, the Android in-kernel wakelock
infrastructure has been reimplemented in terms of wakeup
sources:
http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=commitdiff;h=e9911f4efdc55af703b8b3bb8c839e6f5dd173bb
The Android alarm driver currently has stubbed out calls
to wakelock functionality. So this patch simply converts
the stubbed out wakelock calls to wakeup source calls, and
removes the empty wakelock macros
Greg, would you mind queuing this in staging-next?
CC: Colin Cross <ccross@android.com>
CC: Arve Hjønnevåg <arve@android.com>
CC: Greg KH <gregkh@linuxfoundation.org>
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Because extcon can also be a switch class for legacy userspace (Android)
and is a superset of switch class in drivers/staging/android/switch,
switch class may be removed.
- Remove switch class
- Remove switch class consideration in extcon class
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that alarm-dev.c uses the upstreamed alarmtimer interfaces,
we can remove the otherwise unused in-kernel android alarm api.
CC: Colin Cross <ccross@android.com>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reworks the alarm-dev.c to use the upstreamed alarmtimers
interface.
CC: Colin Cross <ccross@android.com>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The ALARM_ELAPSED_REALTIME clock domain in Android pointed
to the need for something similar in linux system-wide
(instead of limited to just the alarm interface).
Thus CLOCK_BOOTTIME was introduced into the upstream kernel
in 2.6.39.
This patch attempts to convert the android alarm timer to utilize
the kernel's CLOCK_BOOTTIME clockid for ALARM_ELAPSED_REALTIME,
instead of managing it itself.
CC: Colin Cross <ccross@android.com>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix printk format warnings by using 't' modifier for ptrdiff_t.
drivers/staging/android/alarm.c:344:2: warning: format '%ld' expects type 'long int', but argument 2 has type 'int'
drivers/staging/android/alarm.c:367:3: warning: format '%ld' expects type 'long int', but argument 2 has type 'int'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Brian Swetland <swetland@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here are a number of bugfixes for the drivers/staging/ portion of the kernel
that have been reported recently.
Nothing major here, with maybe the exception of the ramster code can now be
built so it is enabled in the build again, and lots of memory leaks that people
like to have fixed on their systems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk+HTnkACgkQMUfUDdst+ylk8wCfXi65bqb6VEKr9QmfLlmBU5sf
E54AnRpxLNw7ckt7eWZMhtCUAvg4ts1I
=8siZ
-----END PGP SIGNATURE-----
Merge tag 'staging-3.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging tree fixes from Greg KH:
"Here are a number of bugfixes for the drivers/staging/ portion of the
kernel that have been reported recently.
Nothing major here, with maybe the exception of the ramster code can
now be built so it is enabled in the build again, and lots of memory
leaks that people like to have fixed on their systems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"
* tag 'staging-3.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging: android: fix mem leaks in __persistent_ram_init()
staging: vt6656: Don't leak memory in drivers/staging/vt6656/ioctl.c::private_ioctl()
staging: iio: hmc5843: Fix crash in probe function.
staging/xgifb: fix display on XGI Volari Z11m cards
Staging: android: timed_gpio: Fix resource leak in timed_gpio_probe error paths
android: make persistent_ram based drivers depend on HAVE_MEMBLOCK
staging: iio: ak8975: Remove i2c client data corruption
staging: drm/omap: move where DMM driver is registered
staging: zsmalloc: fix memory leak
Staging: rts_pstor: off by one in for loop
staging: ozwpan: Added new maintainer for ozwpan
staging:rts_pstor:Avoid "Bad target number" message when probing driver
staging:rts_pstor:Fix possible panic by NULL pointer dereference
Staging: vt6655-6: check keysize before memcpy()
staging/media/as102: Don't call release_firmware() on uninitialized variable
staging:iio:core add missing increment of loop index in iio_map_array_unregister()
staging: ramster: unbreak my heart
staging/vme: Fix module parameters
staging: sep: Fix sign of error
If, in __persistent_ram_init(), the call to
persistent_ram_buffer_init() fails or the call to
persistent_ram_init_ecc() fails then we fail to free the memory we
allocated to 'prz' with kzalloc() - thus leaking it.
To prevent the leaks I consolidated all error exits from the function
at a 'err:' label at the end and made all error cases jump to that
label where we can then make sure we always free 'prz'. This is safe
since all the situations where the code bails out happen before 'prz'
has been stored anywhere and although we'll do a redundant kfree(NULL)
call in the case of kzalloc() itself failing that's OK since kfree()
deals gracefully with NULL pointers and I felt it was more important
to keep all error exits at a single location than to avoid that one
harmless/redundant kfree() on a error path.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Colin Cross <ccross@android.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix printk format warnings in android/persistent_ram.c:
drivers/staging/android/persistent_ram.c:426:4: warning: format '%ld' expects type 'long int', but argument 2 has type 'size_t'
drivers/staging/android/persistent_ram.c:426:4: warning: format '%ld' expects type 'long int', but argument 3 has type 'size_t'
drivers/staging/android/persistent_ram.c:430:4: warning: format '%ld' expects type 'long int', but argument 2 has type 'size_t'
drivers/staging/android/persistent_ram.c:430:4: warning: format '%ld' expects type 'long int', but argument 3 has type 'size_t'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Brian Swetland <swetland@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If gpio_request fails, we need to free all allocated resources.
Current code uses wrong array index to access gpio_data array.
So current code actually frees gpio_data[i].gpio by j times.
This patch moves the error handling code to err_out and thus improves
readability.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
m68k doesn't have memblock_reserve, which causes a build failure
with allmodconfig. Make PERSISTENT_RAM and RAM_CONSOLE depend on
HAVE_MEMBLOCK.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The task handoff notifier leaks task_struct since it never gets freed
after the callback returns NOTIFY_OK, which means it is responsible for
doing so.
It turns out the lowmemorykiller actually doesn't need this notifier at
all. It's used to prevent unnecessary killing by waiting for a thread
to exit as a result of lowmem_shrink(), however, it's possible to do
this in the same way the kernel oom killer works by setting TIF_MEMDIE
and avoid killing if we're still waiting for it to exit.
The kernel oom killer will already automatically set TIF_MEMDIE for
threads that are attempting to allocate memory that have a fatal signal.
The thread selected by lowmem_shrink() will have such a signal after the
lowmemorykiller sends it a SIGKILL, so this won't result in an
unnecessary use of memory reserves for the thread to exit.
This has the added benefit that we don't have to rely on
CONFIG_PROFILING to prevent needlessly killing tasks.
Reported-by: Werner Landgraf <w.landgraf@ru.ru>
Cc: stable@vger.kernel.org
Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Colin Cross <ccross@android.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull x32 support for x86-64 from Ingo Molnar:
"This tree introduces the X32 binary format and execution mode for x86:
32-bit data space binaries using 64-bit instructions and 64-bit kernel
syscalls.
This allows applications whose working set fits into a 32 bits address
space to make use of 64-bit instructions while using a 32-bit address
space with shorter pointers, more compressed data structures, etc."
Fix up trivial context conflicts in arch/x86/{Kconfig,vdso/vma.c}
* 'x86-x32-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (71 commits)
x32: Fix alignment fail in struct compat_siginfo
x32: Fix stupid ia32/x32 inversion in the siginfo format
x32: Add ptrace for x32
x32: Switch to a 64-bit clock_t
x32: Provide separate is_ia32_task() and is_x32_task() predicates
x86, mtrr: Use explicit sizing and padding for the 64-bit ioctls
x86/x32: Fix the binutils auto-detect
x32: Warn and disable rather than error if binutils too old
x32: Only clear TIF_X32 flag once
x32: Make sure TS_COMPAT is cleared for x32 tasks
fs: Remove missed ->fds_bits from cessation use of fd_set structs internally
fs: Fix close_on_exec pointer in alloc_fdtable
x32: Drop non-__vdso weak symbols from the x32 VDSO
x32: Fix coding style violations in the x32 VDSO code
x32: Add x32 VDSO support
x32: Allow x32 to be configured
x32: If configured, add x32 system calls to system call tables
x32: Handle process creation
x32: Signal-related system calls
x86: Add #ifdef CONFIG_COMPAT to <asm/sys_ia32.h>
...
Fix build error when CONFIG_PRINTK is not selected.
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
binder_update_page_range could read freed memory if the vma of the
selected process was freed right before the check that the vma
belongs to the mm struct it just locked.
If the vm_mm pointer in that freed vma struct had also been rewritten
with a value that matched the locked mm struct, then the code would
proceed and possibly modify the freed vma.
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
WARNING: vmlinux.o(.text+0xfcf6e): Section mismatch in reference
from the function ram_console_driver_probe() to the function
.init.text:persistent_ram_init_ringbuffer()
The function ram_console_driver_probe() references
the function __init persistent_ram_init_ringbuffer().
This is often because ram_console_driver_probe lacks a __init
annotation or the annotation of persistent_ram_init_ringbuffer is
wrong.
Move this driver to platform_driver_probe() because ram console
devices aren't going to be added and removed at runtime. Also
shorten the probe function name since driver is redundant and
makes the function name long.
Cc: Android Kernel Team <kernel-team@android.com>
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Linux kernel has a setting called dmesg_restrict. When true,
only processes with CAP_SYSLOG can view the kernel dmesg logs. This
helps prevent leaking of kernel information into user space.
On Android, it's possible to bypass these restrictions by viewing
/proc/last_kmsg.
This change makes /proc/last_kmsg require the same permissions as
dmesg.
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Nick Kralevich <nnk@google.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the persistent ram buffer is not available, ram_console_late_init
would crash when dereferencing ram_console_zone. Return early if
ram console was not initialized.
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add the notrace attribute to persistent_ram_write and the
non-ecc functions that it calls to allow persistent_ram to
be used for ftracing (only when ecc is disabled).
CC: Greg KH <gregkh@linuxfoundation.org>
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Allow persistent_ram_write to be called on multiple cpus at
the same time, as long as ecc is not in use. Uses atomics
for the buffer->start and buffer->size counters.
[jstultz: Fix up some pr_info casting issues on 64bit]
CC: Greg KH <gregkh@linuxfoundation.org>
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace the ioremapped memory passed in from the drivers with
a memblock_reserve and vmap. Adds a new function,
persistent_ram_early_init, designed to be called from the machine
init_early callback, that calls memblock_remove and saves the
provided persistent ram area layout.
Drivers only pass in their struct device * and ecc settings.
Locating and mapping the memory is now handled entirely within
persistent_ram.
Also, convert ram_console to the new persistent_ram_init
parameters that only take a struct device * and ecc settings.
[jstultz: Fix pr_info casting issues on 64bit, folded two
patches as the build breaks if they are apart. Also replaced
phys_to_page() w/ pfn_to_page(addr>>PAGE_SHIFT), as phys_to_page
is only on a few arches.]
CC: Greg KH <gregkh@linuxfoundation.org>
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION and related
#ifdefs. Also allow persistent ram zones without ecc enabled.
For some use cases, like the data portion of the upcoming
persistent_vars patches, or a persistent ftrace ringbuffer,
ecc on every update is too expensive.
CC: Greg KH <gregkh@linuxfoundation.org>
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Split ram_console into two halves.
persistent_ram is a set of apis that handle a block of memory
that does not get erased across a reboot. It provides functions
to fill it as a single buffer or a ring buffer, and to extract
the old data after a reboot. It handles ecc on the data to
correct bit errors introduced during reboot.
ram_console is now a small wrapper around persistent_ram that
feeds console data into the ringbuffer, and exports the old
data to /proc/last_kmsg after a reboot.
[jstultz: Moved persistent_ram.h to staging dir]
CC: Greg KH <gregkh@linuxfoundation.org>
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Equivalent functionality can be obtained with loglevel=15
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Early ramconsole is not very useful, an early crash will prevent
getting the logged data out on the next boot, and CONFIG_DEBUG_LL=y
will get the same information. Drop it to simplify a future
refactoring.
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Don't store the bootinfo string and the ecc status string with
the recovered old log data. This will simplify refactoring the
persistent ram code out of the ram console code later.
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We want to ensure that we get all the console messages, even ones
that occur while the printing CPU is not yet online.
[jstultz: tweaked commit subject line]
CC: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Dima Zavin <dima@android.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix compiler warning about the type of the module parameter.
Cc: San Mehat <san@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The lowmemorykiller registers an atomic notifier for notfication of when
the task is freed. From this atomic notifier callback, it removes the
atomic notifier via task_free_unregister(). This is incorrect because
atomic_notifier_chain_unregister() calls syncronize_rcu(), which can
sleep, which shouldn't be done from an atomic notifier.
Fix this by registering the notifier during init, and only unregister it
if the lowmemorykiller is unloaded.
Rebased to -next by Paul E. McKenney.
Rebased to -next again by Anton Vorontsov.
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: Christian Bejram <christian.bejram@stericsson.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reported-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
GCC warns that module_param_named() indirectly returns a bool type value
which is different from 'int' type binder_debug_no_lock declared. Change
it to bool because it is a internal switch for debugging.
Signed-off-by: Zhengwang Ruan <ruan.zhengwang@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The readers list is traversed under the log->mutex lock
(for example from fix_up_readers()), but the deletion of
elements from this list is not being done under this lock.
Cc: Brian Swetland <swetland@google.com>
Cc: Dima Zavin <dima@android.com>
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
