- 19 Jul, 2012 3 commits
-
-
Duan Jiong authored
Signed-off-by:
Duan Jiong <djduanjiong@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Martyn Welch authored
The memcpy_fromio() and memcpy_toio() functions use the __memcpy() function, at least on x86. This function carries out transfers smaller than 32 bits as multiple 8 bit transfers, causing a single (aligned) 16 bit transfer to be split into 2 8 bit transfers which may not be supported by the target VME device. The commit 53059aa0 fixed this for the ca91cx42, however this was not fixed for the tsi148 at the time. This patch uses the same algorithm to fix the tsi148. Reported-by:
Daniel Lambert <daniel.lambert@clermont.in2p3.fr> Signed-off-by:
Martyn Welch <martyn.welch@ge.com> Signed-off-by:
-
Stephen Rothwell authored
Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Acked-by:
Javier Muñoz <jmunhoz@igalia.com> Signed-off-by:
-
- 17 Jul, 2012 37 commits
-
-
Anton Vorontsov authored
Decoding the binary trace w/ a different kernel might be troublesome since we convert addresses to symbols. For kernels with minimal changes, the mappings would probably match, but it's not guaranteed at all. (But still we could convert the addresses by hand, since we do print raw addresses.) If we use modules, the symbols could be loaded at different addresses from the previously booted kernel, and so this would also fail, but there's nothing we can do about it. Also, the binary data format that pstore/ram is using in its ringbuffer may change between the kernels, so here we too must ensure that we're running the same kernel. So, there are two questions really: 1. How to compute the unique kernel tag; 2. Where to store it. In this patch we're using LINUX_VERSION_CODE, just as hibernation (suspend-to-disk) does. This way we are protecting from the kernel version mismatch, making sure that we're running the same kernel version and patch level. We could use CRC of a symbol table (as suggested by Tony Luck), but for now let's not be that strict. And as for storing, we are using a small trick here. Instead of allocating a dedicated buffer for the tag (i.e. another prz), or hacking ram_core routines to "reserve" some control data in the buffer, we are just encoding the tag into the buffer signature (and XOR'ing it with the actual signature value, so that buffers not needing a tag can just pass zero, which will result into the plain old PRZ signature). Suggested-by:
Steven Rostedt <rostedt@goodmis.org> Suggested-by:
Tony Luck <tony.luck@intel.com> Suggested-by:
Colin Cross <ccross@android.com> Signed-off-by:
Anton Vorontsov <anton.vorontsov@linaro.org> Signed-off-by:
-
Anton Vorontsov authored
Headers should really include all the needed prototypes, types, defines etc. to be self-contained. This is a long-standing issue, but apparently the new tracing code unearthed it (SMP=n is also a prerequisite): In file included from fs/pstore/internal.h:4:0, from fs/pstore/ftrace.c:21: include/linux/pstore.h:43:15: error: field ‘read_mutex’ has incomplete type While at it, I also added the following: linux/types.h -> size_t, phys_addr_t, uXX and friends linux/spinlock.h -> spinlock_t linux/errno.h -> Exxxx linux/time.h -> struct timespec (struct passed by value) struct module and rs_control forward declaration (passed via pointers). Signed-off-by: -
Samuel Iglesias Gonsálvez authored
Use the ANSI/VITA 4.0-1995 (S2011) naming convention for the mezzanine or daughter boards. They are called IP modules in the Standard. Signed-off-by:
Samuel Iglesias Gonsálvez <siglesias@igalia.com> Signed-off-by:
-
Samuel Iglesias Gonsálvez authored
Signed-off-by:
-
Erik Jones authored
Fixed a coding style issue. An else statement was not on the same line as the preceding if statement's closing brace. Signed-off-by:
Erik Jones <erik@ejnode.com> Signed-off-by:
-
Erik Jones authored
Fixed a coding style issue. Signed-off-by:
-
Greg Kroah-Hartman authored
Merge tag 'iio-fixes-3.6b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next IIO fixes for elements queued for 3.6 merge window. 3 types of fix here. 1) Incorrect pointer casting via phys_addr_t which causes trouble on some architectures. 2) request_irq and free_irq dev_id parameters not matching. 3) Inconsistencies in client_data for some i2c devices (writing one pointer and expecting another later).
-
Anton Vorontsov authored
Since the function accepts just one bit, we can use the switch construction instead of if/else if/... Just a cosmetic change, there should be no functional changes. Suggested-by:
-
Anton Vorontsov authored
The ftrace log size is configurable via ramoops.ftrace_size module option, and the log itself is available via <pstore-mount>/ftrace-ramoops file. Signed-off-by:
-
Anton Vorontsov authored
Don't use pstore.buf directly, instead convert the code to write_buf callback which passes a pointer to a buffer as an argument. Signed-off-by:
-
Anton Vorontsov authored
This patch introduces 'func_ptrace' option, now available in /sys/kernel/debug/tracing/options when function tracer is selected. The patch also adds some tiny code that calls back to pstore to record the trace. The callback is no-op when PSTORE=n. Signed-off-by:
-
Anton Vorontsov authored
With this support kernel can save function call chain log into a persistent ram buffer that can be decoded and dumped after reboot through pstore filesystem. It can be used to determine what function was last called before a reset or panic. We store the log in a binary format and then decode it at read time. p.s. Mostly the code comes from trace_persistent.c driver found in the Android git tree, written by Colin Cross <ccross@android.com> (according to sign-off history). I reworked the driver a little bit, and ported it to pstore. Signed-off-by:
-
Anton Vorontsov authored
For function tracing we need to stop using pstore.buf directly, since in a tracing callback we can't use spinlocks, and thus we can't safely use the global buffer. With write_buf callback, backends no longer need to access pstore.buf directly, and thus we can pass any buffers (e.g. allocated on stack). Signed-off-by:
-
Anton Vorontsov authored
If tracer->init() fails, current code will leave current_tracer pointing to an unusable tracer, which at best makes 'current_tracer' report inaccurate value. Fix the issue by pointing current_tracer to nop tracer, and only update current_tracer with the new one after all the initialization succeeds. Signed-off-by:
-
Anton Vorontsov authored
Nowadays we can use prz->ecc_size as a flag, no need for the special member in the prz struct. Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Anton Vorontsov authored
This is now pretty straightforward: instead of using bool, just pass an integer. For backwards compatibility ramoops.ecc=1 means 16 bytes ECC (using 1 byte for ECC isn't much of use anyway). Suggested-by:
Arve Hjønnevåg <arve@android.com> Signed-off-by:
-
Anton Vorontsov authored
The struct members were never used anywhere outside of persistent_ram_init_ecc(), so there's actually no need for them to be in the struct. If we ever want to make polynomial or symbol size configurable, it would make more sense to just pass initialized rs_decoder to the persistent_ram init functions. Signed-off-by:
-
Justin P. Mattock authored
Signed-off-by:
Justin P. Mattock <justinmattock@gmail.com> Signed-off-by:
-
Devendra Naga authored
with kthread_create we need to call wake_up_process to run the thread, this can be done using the macro kthread_run, which creates and if thread creation is succeeded starts the thread by calling wake_up_process, and also there are two more threads in the rts_pstor, which calls kthread_run instead calling kthread_create and another call to the wake_up_process, so with this change the creation of rtsx_scan_thread will be in consistency with the other control and poll threads. Signed-off-by:
Devendra Naga <develkernel412222@gmail.com> Signed-off-by:
-
Devendra Naga authored
instead we would have used kzalloc, so our memory which is allocated will be set to 0. codepath: the code path here is prism2sta_probe_usb, calling when ever usb-dev id and usb-vendor id e.t.c matches with what ever present in the MODULE_DEVICE_TABLE, and in prism2sta_probe_usb , we call create_wlan, and its called nowhere else... Signed-off-by:
Devendra Naga <devendra.aaru@gmail.com> Signed-off-by:
-
Devendra Naga authored
err can be used get return status of the usb_control_msg, rather using nr and assigning it to err when the function returns error. Signed-off-by:
-
H Hartley Sweeten authored
All the addi driver ttl subdevices use the range table 'range_digital' provided by the comedi core. The boardinfo value 'pr_TTLRangeList' is not used by the drivers. Remove the unused range tables and the boardinfo pointer. The unused range tables don't make sense anyway... Signed-off-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Devendra Naga authored
the following fixes... removed spaces at start of a line and used tabs Signed-off-by:
-
Devendra Naga authored
this return is at the function end, and function is returning nothing.. i.e a void. Signed-off-by:
-
Devendra Naga authored
this function seemed bit more coding style fix... The following fixes: remove spaces at start of line and use tabs use space between if and ( give a space in a multiplication operation use space after = and another variable/constant Signed-off-by:
-
Paul Bolle authored
Opening drivers/staging/wlags49_h2/dhf.h with vim triggered this warning: "drivers/staging/wlags49_h2/dhf.h" 226L, 8428C Error detected while processing modelines: line 2: E518: Unknown option: */ Press ENTER or type command to continue Since the Linux kernel coding style disallows modelines this invalid modeline can simply be removed. And since we're touching this file we might as well remove all vim modelines from this driver. vim tested only. Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
-
Samuel Iglesias Gonsálvez authored
Initialize the device when registering it. Sometimes the user access to it and the device is in an unknown state, so it could fail. Signed-off-by:
-
Samuel Iglesias Gonsálvez authored
After opening and closing the file /dev/ipoctal.X.Y.Z for the second time, it gives a kernel oops due to a dereference of a NULL pointer. The problem was that tty->driver_data was not properly initialized when accessing the file for the second time. Reported-by:
Alberto Garcia Gonzalez <agarcia@igalia.com> Signed-off-by:
-
H Hartley Sweeten authored
The macros 'update_dacsr', 'update_adcsr', and 'update_supcsr' all use the 'devpriv' macro which uses a local variable of a specific name and yeilds a pointer derived from that name. They are also just wrappers around simple 'outw' calls. Remove the macros. Signed-off-by:
-
Marek Belisko authored
Signed-off-by:
Marek Belisko <marek.belisko@open-nandra.com> Signed-off-by:
-
Marek Belisko authored
Signed-off-by:
-
Marek Belisko authored
Signed-off-by:
-
Marek Belisko authored
Signed-off-by:
-
Marek Belisko authored
Signed-off-by:
-
Marek Belisko authored
Signed-off-by:
-
Marek Belisko authored
Signed-off-by:
-
Marek Belisko authored
Signed-off-by:
-
