* 'v4l_for_2.6.35' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: (243 commits)
V4L/DVB: sms: Convert IR support to use the Remote Controller core
V4L/DVB: sms: properly initialize IR phys and IR name
V4L/DVB: standardize names at rc-dib0700 tables
V4L/DVB: smsusb: enable IR port for Hauppauge WinTV MiniStick
V4L/DVB: dib0700: Fix RC protocol logic to properly handle NEC/NECx and RC-5
V4L/DVB: dib0700: properly implement IR change_protocol
V4L/DVB: dib0700: break keytable into NEC and RC-5 variants
V4L/DVB: dib0700: avoid bad repeat
V4L/DVB: Port dib0700 to rc-core
V4L/DVB: Add a keymap file with dib0700 table
V4L/DVB: dvb-usb: add support for rc-core mode
V4L/DVB: dvb-usb: prepare drivers for using rc-core
V4L/DVB: dvb-usb: get rid of struct dvb_usb_rc_key
V4L/DVB: rj54n1cb0c: fix a comment in the driver
V4L/DVB: V4L2: sh_vou: VOU does support the full PAL resolution too
V4L/DVB: V4L2: sh_mobile_camera_ceu: add support for CSI2
V4L/DVB: V4L2: soc-camera: add a MIPI CSI-2 driver for SH-Mobile platforms
V4L/DVB: V4L2: soc-camera: export soc-camera bus type for notifications
V4L/DVB: V4L2: mediabus: add 12-bit Bayer and YUV420 pixel formats
V4L/DVB: mediabus: fix ambiguous pixel code names
...
* 'stable/swiotlb-0.8.3' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb-2.6:
swiotlb: Make swiotlb bookkeeping functions visible in the header file.
swiotlb: search and replace "int dir" with "enum dma_data_direction dir"
swiotlb: Make internal bookkeeping functions have 'swiotlb_tbl' prefix.
swiotlb: add the swiotlb initialization function with iotlb memory
swiotlb: add swiotlb_tbl_map_single library function
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6: (90 commits)
AppArmor: fix build warnings for non-const use of get_task_cred
selinux: convert the policy type_attr_map to flex_array
AppArmor: Enable configuring and building of the AppArmor security module
TOMOYO: Use pathname specified by policy rather than execve()
AppArmor: update path_truncate method to latest version
AppArmor: core policy routines
AppArmor: policy routines for loading and unpacking policy
AppArmor: mediation of non file objects
AppArmor: LSM interface, and security module initialization
AppArmor: Enable configuring and building of the AppArmor security module
AppArmor: update Maintainer and Documentation
AppArmor: functions for domain transitions
AppArmor: file enforcement routines
AppArmor: userspace interfaces
AppArmor: dfa match engine
AppArmor: contexts used in attaching policy to system objects
AppArmor: basic auditing infrastructure.
AppArmor: misc. base functions and defines
TOMOYO: Update version to 2.3.0
TOMOYO: Fix quota check.
...
Comment in unregister_trace_probe() says probe_lock will be held when it
gets called. However there is a case where it might called without the
probe_lock being held. Also since we are traversing the probe_list and
deleting an element from the probe_list, probe_lock should be held.
This was first pointed in uprobes traceevent review by Frederic
Weisbecker here. (http://lkml.org/lkml/2010/5/12/106)
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
LKML-Reference: <20100630084548.GA10325@linux.vnet.ibm.com>
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The event__process function is useful in processing /proc/<pid>/maps. All of
the functions that are called from event__process are defined in util/event.c.
Though its defined in builtin-top.c, it could be reused for perf probe for
uprobes. Hence moving it to util/event.c and exporting the function.
LKML-Reference: <20100802123851.GD22812@linux.vnet.ibm.com>
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Fix buggy-looking code which unnecessarily adjusts the file offset
fields read from /proc/*/maps.
This may have gone unnoticed since the offset is usually 0 (and the
logic in util/symbol.c may work incorrectly for other offset values).
Commiter note:
This fixes a bug introduced in 4af8b35, there is no need to shift pgoff
twice, the show_map_vma routine in fs/proc/task_mmu.c already converts
it from the number of pages to the size in bytes, and that is what
appears in /proc/PID/map.
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Will Deacon <Will.Deacon@arm.com>
LKML-Reference: <1280836116-6654-2-git-send-email-dave.martin@linaro.org>
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Below you will find an updated version from the original series bunching all patches into one big patch
updating broken web addresses that are located in Documentation/*
Some of the addresses date as far far back as 1995 etc... so searching became a bit difficult,
the best way to deal with these is to use web.archive.org to locate these addresses that are outdated.
Now there are also some addresses pointing to .spec files some are located, but some(after searching
on the companies site)where still no where to be found. In this case I just changed the address
to the company site this way the users can contact the company and they can locate them for the users.
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Thomas Weber <weber@corscience.de>
Signed-off-by: Mike Frysinger <vapier.adi@gmail.com>
Cc: Paulo Marques <pmarques@grupopie.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Michael Neuling <mikey@neuling.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
EDAC MC3: CE page 0xc32281, offset 0x8a0, grain 0, syndrome 0x1, row 2, channel 1, label "": amd64_edac
EDAC MC3: CE - no information available: amd64_edacError Overflow
Add the missing space before "Error Overflow" on the second line.
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
This file seeks to explain the nuances in various delays;
many driver writers are not necessarily familiar with the
various kernel timers, their shortfalls, and quirks. When
faced with
ndelay, udelay, mdelay, usleep_range, msleep, and msleep_interrubtible
the question "How do I just wait 1 ms for my hardware to
latch?" has the non-intuitive "best" answer:
usleep_range(1000,1500)
This patch is followed by a series of checkpatch additions
that seek to help kernel hackers pick the best delay.
Signed-off-by: Patrick Pannuto <ppannuto@codeaurora.org>
Cc: apw@canonical.com
Cc: corbet@lwn.net
Cc: arjan@linux.intel.com
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
LKML-Reference: <1280786467-26999-3-git-send-email-ppannuto@codeaurora.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
usleep_range is a finer precision implementations of msleep
and is designed to be a drop-in replacement for udelay where
a precise sleep / busy-wait is unnecessary.
Since an easy interface to hrtimers could lead to an undesired
proliferation of interrupts, we provide only a "range" API,
forcing the caller to think about an acceptable tolerance on
both ends and hopefully avoiding introducing another interrupt.
INTRO
As discussed here ( http://lkml.org/lkml/2007/8/3/250 ), msleep(1) is not
precise enough for many drivers (yes, sleep precision is an unfair notion,
but consistently sleeping for ~an order of magnitude greater than requested
is worth fixing). This patch adds a usleep API so that udelay does not have
to be used. Obviously not every udelay can be replaced (those in atomic
contexts or being used for simple bitbanging come to mind), but there are
many, many examples of
mydriver_write(...)
/* Wait for hardware to latch */
udelay(100)
in various drivers where a busy-wait loop is neither beneficial nor
necessary, but msleep simply does not provide enough precision and people
are using a busy-wait loop instead.
CONCERNS FROM THE RFC
Why is udelay a problem / necessary? Most callers of udelay are in device/
driver initialization code, which is serial...
As I see it, there is only benefit to sleeping over a delay; the
notion of "refactoring" areas that use udelay was presented, but
I see usleep as the refactoring. Consider i2c, if the bus is busy,
you need to wait a bit (say 100us) before trying again, your
current options are:
* udelay(100)
* msleep(1) <-- As noted above, actually as high as ~20ms
on some platforms, so not really an option
* Manually set up an hrtimer to try again in 100us (which
is what usleep does anyway...)
People choose the udelay route because it is EASY; we need to
provide a better easy route.
Device / driver / boot code is *currently* serial, but every few
months someone makes noise about parallelizing boot, and IMHO, a
little forward-thinking now is one less thing to worry about
if/when that ever happens
udelay's could be preempted
Sure, but if udelay plans on looping 1000 times, and it gets
preempted on loop 200, whenever it's scheduled again, it is
going to do the next 800 loops.
Is the interruptible case needed?
Probably not, but I see usleep as a very logical parallel to msleep,
so it made sense to include the "full" API. Processors are getting
faster (albeit not as quickly as they are becoming more parallel),
so if someone wanted to be interruptible for a few usecs, why not
let them? If this is a contentious point, I'm happy to remove it.
OTHER THOUGHTS
I believe there is also value in exposing the usleep_range option; it gives
the scheduler a lot more flexibility and allows the programmer to express
his intent much more clearly; it's something I would hope future driver
writers will take advantage of.
To get the results in the NUMBERS section below, I literally s/udelay/usleep
the kernel tree; I had to go in and undo the changes to the USB drivers, but
everything else booted successfully; I find that extremely telling in and
of itself -- many people are using a delay API where a sleep will suit them
just fine.
SOME ATTEMPTS AT NUMBERS
It turns out that calculating quantifiable benefit on this is challenging,
so instead I will simply present the current state of things, and I hope
this to be sufficient:
How many udelay calls are there in 2.6.35-rc5?
udealy(ARG) >= | COUNT
1000 | 319
500 | 414
100 | 1146
20 | 1832
I am working on Android, so that is my focus for this. The following table
is a modified usleep that simply printk's the amount of time requested to
sleep; these tests were run on a kernel with udelay >= 20 --> usleep
"boot" is power-on to lock screen
"power collapse" is when the power button is pushed and the device suspends
"resume" is when the power button is pushed and the lock screen is displayed
(no touchscreen events or anything, just turning on the display)
"use device" is from the unlock swipe to clicking around a bit; there is no
sd card in this phone, so fail loading music, video, camera
ACTION | TOTAL NUMBER OF USLEEP CALLS | NET TIME (us)
boot | 22 | 1250
power-collapse | 9 | 1200
resume | 5 | 500
use device | 59 | 7700
The most interesting category to me is the "use device" field; 7700us of
busy-wait time that could be put towards better responsiveness, or at the
least less power usage.
Signed-off-by: Patrick Pannuto <ppannuto@codeaurora.org>
Cc: apw@canonical.com
Cc: corbet@lwn.net
Cc: arjan@linux.intel.com
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Kgdb uses brki r16, 0x18 instruction to call
low level _debug_exception function which save
current state to pt_regs and call microblaze_kgdb_break
function. _debug_exception should be called only from
the kernel space. User space calling is not supported
because user application debugging uses different handling.
pt_regs_to_gdb_regs loads additional special registers
which can't be changed
* Enable KGDB in Kconfig
* Remove ancient not-tested KGDB support
* Remove ancient _debug_exception code from entry.S
Only MMU KGDB support is supported.
Signed-off-by: Michal Simek <monstr@monstr.eu>
CC: Jason Wessel <jason.wessel@windriver.com>
CC: John Williams <john.williams@petalogix.com>
CC: Edgar E. Iglesias <edgar.iglesias@petalogix.com>
CC: linux-kernel@vger.kernel.org
Acked-by: Jason Wessel <jason.wessel@windriver.com>
This is the first patch which add support for
user application debugging through brki rX, 0x18 vector.
This patch has side effect which also remove security issue
to use brki rX, 0x18 to freeze kernel.
Support for old gdb support via priviledged exception
(brk r0, r0) is still there. It will be remove in future.
Signed-off-by: Michal Simek <monstr@monstr.eu>
Syscall can be called only from userspace that's why
we don't need to check which space kernel come from.
Kernel syscall calling is not check and shouldn't come
throught this part of code.
Signed-off-by: Michal Simek <monstr@monstr.eu>
We are not working with values from MSR that's why
we can discard it and use r11 for different purpose without
saving/restoring.
Signed-off-by: Michal Simek <monstr@monstr.eu>
Remove set_vms because UMS is cleared and VMS is already setup.
Optimize function calling which save one additional instruction.
Signed-off-by: Michal Simek <monstr@monstr.eu>
VMS is always setup because VM mode was before
exception/syscall/interrupt. Kernel continues in kernel mode
that's why we have to clear UMS bit if kernel comes from
user space.
Signed-off-by: Michal Simek <monstr@monstr.eu>
PT_MODE stores information if kernel comes from user
or kernel space. If come from user space, PT_MODE
contains 0. If come from kernel store, PT_MODE contains
non zero value. We don't need to save value 1. I am using
r1 register which contains non zero value.
This change save one additional instruction.
Signed-off-by: Michal Simek <monstr@monstr.eu>
Keep together all arguments for send_sig function.
Move returning address to delay slot which is executed.
Remove additional send_sig loading. I am using IMM part of
rtbd instruction with r0.
old solution:
addik r11, r0, send_sig
rtbd r11, 0
nop
new solution:
rtbd r0, send_sig
nop
There is one instruction saving.
Signed-off-by: Michal Simek <monstr@monstr.eu>
It is necessary to setup BIP and EE and clear EIP
only for unaligned exception handler. The rest of
hw exception handlers don't require it.
HW exception occured and we are not in virtual mode.
That's why we can do operations protected by EIP.
Interrupt, next hw exception or syscall can't occur.
EIP is cleared by rted.
This change speedup page_fault hw exception handler
which is critical path.
There is also necessary to save R11 content before
flag setup for unaligned exception.
Signed-off-by: Michal Simek <monstr@monstr.eu>
