twitter: linux.kernel - 26 new messages in 23 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* x86: apic: Fix mismerge, add arch_probe_nr_irqs() again - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/8d79051b75e0b2aa?hl=en
* Question about policy of calling lockdep functions in trylocks - 2 messages,
2 authors
http://groups.google.com/group/linux.kernel/t/7ad22c2c3d4c9155?hl=en
* use of setjmp/longjmp in x86 emulator. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7b2acc7ec923cec7?hl=en
* [PATCH] Synchronization required before release the lock: sem_post/8-1.c - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/684e0e5d8a32aa0d?hl=en
* input/mc13783-ts: Don't use deprecated mc13783 API calls - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/6d12d84576a0840e?hl=en
* Selinux: Remove unused headers slab.h in selinux/ss/symtab.c - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/ae9a24511f0c90e9?hl=en
* linux-next: build failure after merge of the ext3 tree - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/0970bfd2b4d13c7b?hl=en
* linux-next: build failure after merge of the blackfin tree - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/fd2c5fb0618be29b?hl=en
* perf_events: add sampling period randomization support - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/54108222cc877582?hl=en
* ACPI, APEI, PCIE AER, use general HEST table parsing in AER firmware_first
setup - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7603bbf89a910ed1?hl=en
* input/touchscreen: Synaptics Touchscreen Driver - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/35b4266c46f84616?hl=en
* [PATCH 3/7] xen/hvm: Xen PV extension of HVM initialization - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/fbe37dafcb007f26?hl=en
* gpio: add Intel SCH GPIO controller driver - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3076c00a1ad323ba?hl=en
* RFC directio: partial writes support - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5f95397237af6d75?hl=en
* Oops while booting 2.6.34-rc0 (block pull busted) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f7420e106a3c28db?hl=en
* ocfs2: ensure trusted xattrs are not returned to unprivileged users via
listxattr - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5b44e2eb8c050e04?hl=en
* [patch] should use scheduler sync hint in tcp_prequeue()? - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/e8dcdc3429ff4045?hl=en
* drivers: bluetooth: hci_ldisc: Fixed multiple coding style issues - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/e740dc8705b6857c?hl=en
* rtc/mc13783: implement alarm - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d3b862189b14d388?hl=en
* i8253: Convert i8253_lock to raw_spinlock - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/58293bf897ffa251?hl=en
* [PATCH]Support MCP89 and GT21x hdmi audio - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/16c949f2d92ac0a6?hl=en
* tracing: fix warning in s_next - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7e5be06cf5b04dec?hl=en
* memcg: dirty pages accounting and limiting infrastructure - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/98b8f3d66410be44?hl=en

==============================================================================
TOPIC: x86: apic: Fix mismerge, add arch_probe_nr_irqs() again
http://groups.google.com/group/linux.kernel/t/8d79051b75e0b2aa?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 12:40 am
From: Thomas Gleixner

On Mon, 1 Mar 2010, Eric W. Biederman wrote:
> Ian Campbell <ijc@hellion.org.uk> writes:
> > On Mon, 2010-03-01 at 10:34 -0800, Eric W. Biederman wrote:
> It is going to take a bit but our next big step for the irq methods
> is to make them all take struct irq_desc pointers instead of unsigned
> int irq, so we don't have to repeat the lookups.

That should hit 2.6.35.

> >> - Xen has an array irq_info[NR_IRQS] one of the last static arrays
> >> sized at NR_IRQs in the entire kernel.
> >
> > Hopefully the same info as is in that array could (and indeed should) be
> > instead stored in irq_desc->chip_data. Would you object to
> > arch_init_copy_chip_data and arch_free_chip_data becoming function
> > pointers within the struct irq_chip?
>
> No objections. Now that I see those methods it looks like they always
> should have been in irq_chip.

Agreed.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Question about policy of calling lockdep functions in trylocks
http://groups.google.com/group/linux.kernel/t/7ad22c2c3d4c9155?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 12:50 am
From: Hitoshi Mitake

Hi,

I have a question about policy of callings lockdep functions in trylocks.

Normal locks like __raw_spin_lock are defined like this:

static inline void __raw_spin_lock(raw_spinlock_t *lock)
{
preempt_disable();
spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
}

And LOCK_CONTENDED is defined:
#define LOCK_CONTENDED(_lock, try, lock) \
do { \
if (!try(_lock)) { \
lock_contended(&(_lock)->dep_map, _RET_IP_); \
lock(_lock); \
} \
lock_acquired(&(_lock)->dep_map, _RET_IP_); \
} while (0)

So, acquiring and releasing lock with no contention calls lockdep
functions like this:

lock_acquire -> lock_acquired -> lock_release

And acquiring and releasing lock with contention calls lockdep functions
like this:

lock_acquire -> lock_contended -> lock_acquired -> lock_release

But I found that locks with try like __raw_spin_trylock is defined like
this:

static inline int __raw_spin_trylock(raw_spinlock_t *lock)
{
preempt_disable();
if (do_raw_spin_trylock(lock)) {
spin_acquire(&lock->dep_map, 0, 1, _RET_IP_);
return 1;
}
preempt_enable();
return 0;
}

So, trying acquiring and releasing lock with no contention calls lockdep
functions like this:

lock_acquire -> lock_release

And failed trying acquiring calls no lockdep function.

I felt that policy of calling lockdep functions is strange.
Trylocks should be like this:

static inline int __raw_spin_trylock(raw_spinlock_t *lock)
{
preempt_disable();
spin_acquire(&lock->dep_map, 0, 1, _RET_IP_);
if (do_raw_spin_trylock(lock)) {
spin_acquire(&lock->dep_map, 0, 1, _RET_IP_);
lock_acquired(&lock->dep_map, _RET_IP_);
return 1;
}
lock_contended(&lock->dep_map, _RET_IP_);
preempt_enable();
return 0;
}

This is my question.
Are there some reasons current calling lockdep functions of trylocks?
If not, can I change these trylocks like I described above?

The reason why I'm asking about it is perf lock.
For state machine of perf lock, these event sequenses are very confusable.
Because sequence of trylock is subset of normal lock. This is ambiguity.

Thanks,
Hitoshi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Tues, Mar 2 2010 1:20 am
From: Peter Zijlstra

On Tue, 2010-03-02 at 17:44 +0900, Hitoshi Mitake wrote:
> Hi,
>
> I have a question about policy of callings lockdep functions in trylocks.
>
> Normal locks like __raw_spin_lock are defined like this:
>
> static inline void __raw_spin_lock(raw_spinlock_t *lock)
> {
> preempt_disable();
> spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
> LOCK_CONTENDED(lock, do_raw_spin_trylock, do_raw_spin_lock);
> }
>
> And LOCK_CONTENDED is defined:
> #define LOCK_CONTENDED(_lock, try, lock) \
> do { \
> if (!try(_lock)) { \
> lock_contended(&(_lock)->dep_map, _RET_IP_); \
> lock(_lock); \
> } \
> lock_acquired(&(_lock)->dep_map, _RET_IP_); \
> } while (0)
>
> So, acquiring and releasing lock with no contention calls lockdep
> functions like this:
>
> lock_acquire -> lock_acquired -> lock_release
>
> And acquiring and releasing lock with contention calls lockdep functions
> like this:
>
> lock_acquire -> lock_contended -> lock_acquired -> lock_release
>
> But I found that locks with try like __raw_spin_trylock is defined like
> this:
>
> static inline int __raw_spin_trylock(raw_spinlock_t *lock)
> {
> preempt_disable();
> if (do_raw_spin_trylock(lock)) {
> spin_acquire(&lock->dep_map, 0, 1, _RET_IP_);
> return 1;
> }
> preempt_enable();
> return 0;
> }
>
> So, trying acquiring and releasing lock with no contention calls lockdep
> functions like this:
>
> lock_acquire -> lock_release
>
> And failed trying acquiring calls no lockdep function.
>
> I felt that policy of calling lockdep functions is strange.
> Trylocks should be like this:
>
> static inline int __raw_spin_trylock(raw_spinlock_t *lock)
> {
> preempt_disable();
> spin_acquire(&lock->dep_map, 0, 1, _RET_IP_);
> if (do_raw_spin_trylock(lock)) {
> spin_acquire(&lock->dep_map, 0, 1, _RET_IP_);
> lock_acquired(&lock->dep_map, _RET_IP_);
> return 1;
> }
> lock_contended(&lock->dep_map, _RET_IP_);
> preempt_enable();
> return 0;
> }

Did you mean to call acquire twice?

>
> This is my question.
> Are there some reasons current calling lockdep functions of trylocks?
> If not, can I change these trylocks like I described above?
>
> The reason why I'm asking about it is perf lock.
> For state machine of perf lock, these event sequenses are very confusable.
> Because sequence of trylock is subset of normal lock. This is ambiguity.

Well, trylocks cannot contend, so the lock_contended() call doesn't make
sense, I don't think it will confuse lockstat, since acquire will simply
reset the state again, but it will waste cycles, nor is there a reason
to call acquired without first having call contended. So no.

What exactly is the problem, the lack of callbacks for a failed trylock?
Why would you want one?

Because other than that I see no problem, you get an acquire(.try=1) and
a release() to match and lockstat measure and accounts the hold-time.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: use of setjmp/longjmp in x86 emulator.
http://groups.google.com/group/linux.kernel/t/7b2acc7ec923cec7?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 12:50 am
From: Gleb Natapov

On Mon, Mar 01, 2010 at 02:56:59PM -0800, H. Peter Anvin wrote:
> On 03/01/2010 02:31 PM, H. Peter Anvin wrote:
> > On 03/01/2010 11:18 AM, Zachary Amsden wrote:
> >>
> >> It's going to be ugly to emulate segmentation, NX and write protect
> >> support without hardware to do this checking for you, but it's just what
> >> you have to do in this slow path - tedious, fully specified emulation.
> >>
> >> Just because it's tedious doesn't mean we need to use setjmp / longjmp.
> >> Throw / catch might be effective, but it's still pretty bizarre to do
> >> tricks like that in C.
> >>
> >
> > Well, setjmp/longjmp really is not much more than exception handling in C.
> >
>
> For what it's worth, I think that setjmp/longjmp is not anywhere near as
> dangerous as people want to make it out to be. gcc will warn for
> dangerous uses (and a lot of non-dangerous uses), but generally the
> difficult problems can be dealt with by moving the setjmp-protected code
> into a separate function.
>
Can I consider this as ACK for something like the patch blow? :) (with
proper x86 version of setjmp/longjmp of course).

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index cfcb6f0..089a405 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -35,6 +35,45 @@
#include "x86.h"
#include "tss.h"

+typedef unsigned long jmp_buf[8];
+int setjmp(jmp_buf);
+void longjmp(jmp_buf, int);
+
+asm (
+" .align 4\n"
+" .type setjmp, @function\n"
+"setjmp:\n"
+" pop %rsi # Return address, and adjust the stack\n"
+" xorl %eax,%eax # Return value\n"
+" movq %rbx,(%rdi)\n"
+" movq %rsp,8(%rdi) # Post-return %rsp!\n"
+" push %rsi # Make the call/return stack happy\n"
+" movq %rbp,16(%rdi)\n"
+" movq %r12,24(%rdi)\n"
+" movq %r13,32(%rdi)\n"
+" movq %r14,40(%rdi)\n"
+" movq %r15,48(%rdi)\n"
+" movq %rsi,56(%rdi) # Return address\n"
+" ret\n"
+" .size setjmp,.-setjmp\n"
+
+" .align 4\n"
+" .type longjmp, @function\n"
+"longjmp:\n"
+" movl %esi,%eax # Return value (int)\n"
+" movq (%rdi),%rbx\n"
+" movq 8(%rdi),%rsp\n"
+" movq 16(%rdi),%rbp\n"
+" movq 24(%rdi),%r12\n"
+" movq 32(%rdi),%r13\n"
+" movq 40(%rdi),%r14\n"
+" movq 48(%rdi),%r15\n"
+" jmp *56(%rdi)\n"
+" .size longjmp,.-longjmp\n"
+ );
+
+static jmp_buf jb;
+
/*
* Opcode effective-address decode tables.
* Note that we only emulate instructions that have at least one memory
@@ -1729,7 +1768,7 @@ static inline int writeback(struct x86_emulate_ctxt *ctxt,
c->dst.bytes,
ctxt->vcpu);
if (rc != X86EMUL_CONTINUE)
- return rc;
+ longjmp(jb, 1);
break;
case OP_NONE:
/* no writeback */
@@ -2391,6 +2430,11 @@ x86_emulate_insn(struct x86_emulate_ctxt *ctxt, struct x86_emulate_ops *ops)
memcpy(c->regs, ctxt->vcpu->arch.regs, sizeof c->regs);
saved_eip = c->eip;

+ if (setjmp(jb)) {
+ printk(KERN_ERR"setjump() == 1\n");
+ return 0;
+ }
+
if (ctxt->mode == X86EMUL_MODE_PROT64 && (c->d & No64)) {
kvm_queue_exception(ctxt->vcpu, UD_VECTOR);
goto done;
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: [PATCH] Synchronization required before release the lock: sem_post/8-1.
c
http://groups.google.com/group/linux.kernel/t/684e0e5d8a32aa0d?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 1:00 am
From: Rishikesh K Rajak

On Thu, Feb 25, 2010 at 07:15:42PM +0530, naresh kamboju wrote:
> Hi,
>
> I have found abnormal behavior of sem_post/8-1.c test case under posix.
> This test case passes in some times and failed in many times :-(
>
> After my investigation found synchronization is missing between the
> child processes.
> Made a patch to fix this issue.
>
> Patch includes
> 1. Reverting back changes made by mreed on Sep 25 2006. Making sure
> child has been waiting for the lock (below Refs).
> 2. using sleep in while loop is not a good idea, so sleep is removed
> from while loop
> 3. For the synchronization I have added sleep before releasing the lock.
>
>
> After applying this patch I have tested this test case 1000 times continuously.
> All the times test case reported as Test Pass :-)
>
>
> Signed-off-by: Naresh Kamboju < naresh.kernel@gmail.com >

Looks good to me though i needed few clarification below.

Acked-By: Rishikesh K Rajak <risrajak@linux.vnet.ibm.com>

> ---
> testcases/open_posix_testsuite/conformance/interfaces/sem_post/8-1.c
> | 15 8 + 7 - 0 !
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> Index: b/testcases/open_posix_testsuite/conformance/interfaces/sem_post/8-1.c
> ===================================================================
> --- a/testcases/open_posix_testsuite/conformance/interfaces/sem_post/8-1.c
> +++ b/testcases/open_posix_testsuite/conformance/interfaces/sem_post/8-1.c
> @@ -161,7 +161,6 @@ int main()
> }
> fprintf(stderr, "P: child_1:%d forked\n", c_1);
>
> - sleep(1);
> c_2 = fork();
> if (c_2 == 0)
> {
> @@ -176,13 +175,13 @@ int main()
> }
> fprintf(stderr, "P: child_2: %d forked\n", c_2);
>
> + /* Step 3 Implementation */
> /* Make sure the two children has been waiting */
> - /*do {
> - sleep(1);
I feel before getting semaphore value, we need to sync first so here
sleep is require,though your point is valid that there is no use of
using sleep inside while loop.

> + do {
> sem_getvalue(sem_1, &val);
> //printf("val = %d\n", val);
> } while (val != 1);
> - */
> +
> c_3 = fork();
> if (c_3 == 0)
> {
> @@ -191,13 +190,15 @@ int main()
> }
> fprintf(stderr, "P: child_3: %d forked\n", c_3);
>
> + /* Step 3 Implementation */
> /* Make sure child 3 has been waiting for the lock */
> - /*do {
> - sleep(1);
> + do {
> sem_getvalue(sem_1, &val);
> //printf("val = %d\n", val);
> } while (val != 0);
> - */
> +
> + /* Synchronization required before release the lock */
> + sleep(1);
> /* Ok, let's release the lock */
> fprintf(stderr, "P: release lock\n");
> sem_post(sem);
>
>
> Test script to test 1000 times:
> /*****************************************************/
> #!/bin/sh
>
> for (( i = 0 ; i < 1000; i++ ))
>
> do
>
> ./8-1.test >> /tmp/sem-post-8-1.log
> done
> /*****************************************************/
>
> Refs:
> http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/open_posix_testsuite/conformance/interfaces/sem_post/8-1.c?view=log
>
> Please review this patch and let me know if you have any issues.
>
> Best regards
> Naresh Kamboju

> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev

> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list

--
Thanks & Regards
Rishi
LTP Maintainer
IBM, LTC, Bangalore
Please join IRC #ltp @ irc.freenode.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: input/mc13783-ts: Don't use deprecated mc13783 API calls
http://groups.google.com/group/linux.kernel/t/6d12d84576a0840e?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 1:00 am
From: Uwe Kleine-König

On Mon, Mar 01, 2010 at 11:55:13PM -0800, Dmitry Torokhov wrote:
> On Mon, Mar 01, 2010 at 11:53:41AM +0100, Uwe Kleine-K�nig wrote:
> > mc13783_ackirq is deprecated, use the drop in replacement mc13783_irq_ack.
> >
> > Signed-off-by: Uwe Kleine-K�nig <u.kleine-koenig@pengutronix.de>
>
> I assume it will go thourgh MFD tree?
I don't know. I would have suggest to let it go via Andrew[1] as the
biggest changes in this series are rtc related and these usually go via
him. But MFD would be OK for me, too.

Best regards
Uwe

[1] hmm, forgot to Cc: him. This is done now.

--
Pengutronix e.K. | Uwe Kleine-K�nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Selinux: Remove unused headers slab.h in selinux/ss/symtab.c
http://groups.google.com/group/linux.kernel/t/ae9a24511f0c90e9?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 1:10 am
From: wzt.wzt@gmail.com

slab.h is unused in symtab.c, so remove it.

Signed-off-by: Zhitong Wang <zhitong.wangzt@alibaba-inc.com>

---
security/selinux/ss/symtab.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/security/selinux/ss/symtab.c b/security/selinux/ss/symtab.c
index 837658a..bcf9f62 100644
--- a/security/selinux/ss/symtab.c
+++ b/security/selinux/ss/symtab.c
@@ -4,7 +4,6 @@
* Author : Stephen Smalley, <sds@epoch.ncsc.mil>
*/
#include <linux/kernel.h>
-#include <linux/slab.h>
#include <linux/string.h>
#include <linux/errno.h>
#include "symtab.h"
--
1.6.5.3

==============================================================================
TOPIC: linux-next: build failure after merge of the ext3 tree
http://groups.google.com/group/linux.kernel/t/0970bfd2b4d13c7b?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 1:10 am
From: Christoph Hellwig

On Tue, Mar 02, 2010 at 11:36:34AM +1100, Stephen Rothwell wrote:
> Hi Jan,
>
> After merging the ext3 tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/jfs/jfs_xtree.c: In function 'xtSplitRoot':
> fs/jfs/jfs_xtree.c:1256: error: 'rec' undeclared (first use in this function)
>
> Caused by commit bff3333e868578990f6fe794a7cba0c74bd433ac ("dquot:
> cleanup space allocation / freeing routines").
>
> This is annoying ... this file system could be build tested on any
> architecture, so why wasn't it?

I did test the compile, but the version in your tree does not match the
one I submitted.

==============================================================================
TOPIC: linux-next: build failure after merge of the blackfin tree
http://groups.google.com/group/linux.kernel/t/fd2c5fb0618be29b?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 1:20 am
From: Mike Frysinger

On Sun, Feb 28, 2010 at 20:03, Stephen Rothwell wrote:
> After merging the blackfin tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> kernel/trace/trace_syscalls.c:402: error: redefinition of 'arch_syscall_addr'
> kernel/trace/trace_syscalls.c:397: note: previous definition of 'arch_syscall_addr' was here
>
> Caused by commit d156d1881ea54ec609d92388601661c2679439bb ("ftrace: unify
> arch_syscall_addr() implementations") from the blackfin tree interacting
> with commit e7b8e675d9c71b868b66f62f725a948047514719 ("tracing: Unify
> arch_syscall_addr() implementations") from Linus' tree.
>
> These are slightly different versions of the same patch. but merging with the blackfin tree managed to add a second copy of the above function. I have applied the following patch for today.

i'm traveling atm and wont be able to clean up my tree for a few more
days. i'd suggest you just drop the Blackfin tree as well as your
local patch. i'll drop a line once things are sane again on my side.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: perf_events: add sampling period randomization support
http://groups.google.com/group/linux.kernel/t/54108222cc877582?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 1:20 am
From: Peter Zijlstra

On Mon, 2010-03-01 at 22:07 -0800, eranian@google.com wrote:
> This patch adds support for randomizing the sampling period.
> Randomization is very useful to mitigate the bias that exists
> with sampling. The random number generator does not need to
> be sophisticated. This patch uses the builtin random32()
> generator.
>
> The user activates randomization by setting the perf_event_attr.random
> field to 1 and by passing a bitmask to control the range of variation
> above the base period. Period will vary from period to period & mask.
> Note that randomization is not available when a target interrupt rate
> (freq) is enabled.
>
> The last used period can be collected using the PERF_SAMPLE_PERIOD flag
> in sample_type.
>
> The patch has been tested on X86. There is also code for PowerPC but
> I could not test it.

I don't thikn we need to touch the arch code, we didn't need to for
frequency driven sampling, so I don't see a reason to do so for
randomization either.

==============================================================================
TOPIC: ACPI, APEI, PCIE AER, use general HEST table parsing in AER firmware_
first setup
http://groups.google.com/group/linux.kernel/t/7603bbf89a910ed1?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 1:20 am
From: Huang Ying

On Tue, 2010-03-02 at 16:09 +0800, Hidetoshi Seto wrote:
> (2010/03/02 10:55), Huang Ying wrote:
> > ... The firmware_first setup code is moved from PCI core to
> > AER driver too, because it is only AER related.
> (snip)
> > diff --git a/drivers/pci/pcie/aer/aerdrv_core.c b/drivers/pci/pcie/aer/aerdrv_core.c
> > index c843a79..cc527c1 100644
> > --- a/drivers/pci/pcie/aer/aerdrv_core.c
> > +++ b/drivers/pci/pcie/aer/aerdrv_core.c
> > @@ -858,6 +858,8 @@ void aer_delete_rootport(struct aer_rpc *rpc)
> > */
> > int aer_init(struct pcie_device *dev)
> > {
> > + aer_set_firmware_first(dev);
> > +
> > if (dev->port->aer_firmware_first) {
> > dev_printk(KERN_DEBUG, &dev->device,
> > "PCIe errors handled by platform firmware.\n");
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index 2a94309..ccfaf19 100644
> (snip)
> > @@ -935,7 +928,6 @@ int pci_setup_device(struct pci_dev *dev)
> > dev->multifunction = !!(hdr_type & 0x80);
> > dev->error_state = pci_channel_io_normal;
> > set_pcie_port_type(dev);
> > - set_pci_aer_firmware_first(dev);
> >
> > list_for_each_entry(slot, &dev->bus->slots, list)
> > if (PCI_SLOT(dev->devfn) == slot->number)
>
> The aer_init() will be called for root ports, but not for end point
> devices or so on. So please remain the firmware_first setup code in
> PCI core. Otherwise endpoint drivers will get success on call of
> pci_enable_pcie_error_reporting() regardless of the firmware first.

Or we can call firmware_first setup code in
pci_enable_pcie_error_reporting(), because

1. I think AER related code should be put in drivers/pci/pcie/aer
instead of PCI core or drivers/acpi, if it is possible.

2. pci_setup_device is called so early, so that it is hard to do some
HEST related initialization (such as checking bad format) before it.

Best Regards,
Huang Ying

==============================================================================
TOPIC: input/touchscreen: Synaptics Touchscreen Driver
http://groups.google.com/group/linux.kernel/t/35b4266c46f84616?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 1:20 am
From: Dmitry Torokhov

Hi Christofer,

On Wed, Feb 17, 2010 at 02:37:38PM -0800, Christopher Heiny wrote:
> Initial driver for Synaptics touchscreens using RMI4 protocol.
>

I assume that since you sent it with git-send-email it was your
corporate mail server that murdered all identation and whitespace.
Please try sending next version using alternative server, like gmail or
maybe your personal account. On the off chance that the formatting used
in the driver was preserved intact - please remember that kernel uses
hard tabs for identation (8 chars, no expanding). Camel-casing is also
frowned upon.

> Signed-off-by: William Manson <WManson@synaptics.com>
> Signed-off-by: Allie Xiong <axiong@synaptics.com>
> Signed-off-by: Christopher Heiny <cheiny@synaptics.com>
> ---
>
> drivers/input/touchscreen/Kconfig | 13 +
> drivers/input/touchscreen/Makefile | 1 +
> drivers/input/touchscreen/rmi.h | 214 +++++++++
> drivers/input/touchscreen/rmi_app_touchpad.c | 490 +++++++++++++++++++++
> drivers/input/touchscreen/rmi_core.c | 602 ++++++++++++++++++++++++++
> drivers/input/touchscreen/rmi_core.h | 59 +++
> drivers/input/touchscreen/rmi_function_11.c | 333 ++++++++++++++
> drivers/input/touchscreen/rmi_function_11.h | 41 ++
> drivers/input/touchscreen/rmi_functions.h | 107 +++++
> drivers/input/touchscreen/rmi_i2c.h | 57 +++
> drivers/input/touchscreen/rmi_i2c_gta01.c | 125 ++++++
> drivers/input/touchscreen/rmi_phys_i2c.c | 555 ++++++++++++++++++++++++
> 12 files changed, 2597 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> index dfafc76..319cb45 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -295,6 +295,19 @@ config TOUCHSCREEN_MIGOR
> To compile this driver as a module, choose M here: the
> module will be called migor_ts.
>
> +config TOUCHSCREEN_SYNAPTICS_RMI4_I2C
> + tristate "Synaptics RMI4 I2C touchscreens"
> + depends on I2C
> + help
> + Say Y here if you have a Synaptics RMI4 I2C touchscreen connected to
> + your system. This enables support for Synaptics RMI4 over I2C based

Spaces followed by tabs.

> + touchscreens.

Wierd identation.
> +
> + If unsure, say N.
> +
> + To compile this driver as a set of modules, choose M here: the
> + modules will be called rmi, rmi_app_touchpad, rmi_phys_i2c.
> +
> config TOUCHSCREEN_TOUCHRIGHT
> tristate "Touchright serial touchscreen"
> select SERIO
> diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
> index d61a3b4..8e7b708 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_TOUCHSCREEN_USB_COMPOSITE) += usbtouchscreen.o
> obj-$(CONFIG_TOUCHSCREEN_PCAP) += pcap_ts.o
> obj-$(CONFIG_TOUCHSCREEN_PENMOUNT) += penmount.o
> obj-$(CONFIG_TOUCHSCREEN_S3C2410) += s3c2410_ts.o
> +obj-$(CONFIG_TOUCHSCREEN_SYNAPTICS_RMI4_I2C) += rmi_core.o rmi_app_touchpad.o rmi_function_11.o rmi_phys_i2c.o rmi_i2c_gta01.o

You have separated RMI core from touchpad. It would be prudent to build
these as separate modules as well (have touchpad "select" RMI).

> obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213) += touchit213.o
> obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT) += touchright.o
> obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o
> diff --git a/drivers/input/touchscreen/rmi.h b/drivers/input/touchscreen/rmi.h
> new file mode 100755
> index 0000000..aa45578
> --- /dev/null
> +++ b/drivers/input/touchscreen/rmi.h
> @@ -0,0 +1,214 @@
> +/**
> + * \file
> + * Synaptics Register Mapped Interface (RMI4) Header File.
> + * Copyright (c) 2007-2009 Synaptics Incorporated
> + *
> + *
> + */
> +/*
> + * This file is licensed under the GPL2 license.
> + *
> + *#############################################################################
> + * GPL
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> + * by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> + * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
> + * for more details.
> + *
> + *#############################################################################
> + */
> +
> +#ifndef _RMI_H
> +#define _RMI_H
> +
> +/** RMI4 Protocol Support
> + */
> +
> +/** For each function present on the RMI device, we need to get the RMI4 Function
> + * Descriptor info from the Page Descriptor Table. This will give us the
> + * addresses for Query, Command, Control, Data and the Source Count (number
> + * of sources for this function) and the function id.
> + */
> +struct rmi_function_descriptor {
> + unsigned char queryBaseAddr;
> + unsigned char commandBaseAddr;
> + unsigned char controlBaseAddr;
> + unsigned char dataBaseAddr;
> + unsigned char interruptSrcCnt;
> + unsigned char functionNum;
> +};
> +
> +/** For each function present on the RMI device, there will be a corresponding
> + * entry in the functions list of the rmi_module_info structure. This entry
> + * gives information about the number of data sources and the number of data
> + * registers associated with the function.
> + * \see rmi_module_info
> + */

If you want to use markups for functions/data structures please forllow
kerneldoc format:

Documentation/kernel-doc-nano-HOWTO.txt

Nothing in kernel understands \xxx (\node, \see, etc) tags.

> +struct rmi_function_info {
> + unsigned char functionNum;
> +
> + /** This is the number of data sources associated with the function.
> + * \note This is not the total number of data registers associated with
> + * this function!
> + * \see data_regs
> + */
> + unsigned char numSources;
> +
> + /** This is the number of data points supported - for example, for
> + * function $11 (2D sensor) the number of data points is equal to the number
> + * of fingers - for function $19 (buttons)it is the number of buttons.
> + */
> + unsigned char numDataPoints;
> + /** This is the number of data registers to read.
> + */
> + unsigned char dataRegBlockSize;
> +
> + /** This is the interrupt register and mask - needed for enabling the interrupts
> + * and for checking what source had caused the attention line interrupt.
> + */
> + unsigned char interruptRegister;
> + unsigned char interruptMask;
> +
> + /** This is the RMI function descriptor associated with this function.
> + * It contains the Base addresses for the functions query, command,
> + * control, and data registers.
> + */
> + struct rmi_function_descriptor funcDescriptor;
> +
> + /** Standard kernel linked list implementation.
> + * Documentation on how to use it can be found at
> + * http://isis.poly.edu/kulesh/stuff/src/klist/.
> + */

Yep, we know ;)

> + struct list_head link;
> +};
> +
> +/** This encapsulates the information found using the RMI4 Function $01
> + * query registers. There is only one Function $01 per device.
> + *
> + * Assuming appropriate endian-ness, you can populate most of this
> + * structure by reading query registers starting at the query base address
> + * that was obtained from RMI4 function 0x01 function descriptor info read
> + * from the Page Descriptor Table.
> + *
> + * Specific register information is provided in the comments for each field.
> + * For further reference, please see the <i>Synaptics RMI4 Interfacing
> + * Guide</i> document.

Is it publicly available?

> + */
> +struct rmi_module_info {
> + /** The Protocol Major Version number.
> + */
> + unsigned rmi_maj_ver;
> +
> + /** The Protocol Minor Version number.
> + */
> + unsigned rmi_min_ver;
> +
> + /** The manufacturer identification byte.
> + */
> + unsigned char mfgid;
> +
> + /** The Product Properties information.
> + */
> + unsigned char properties;
> +
> + /** The product info bytes.
> + * You can build a product info string using the following printf
> + * format and args:
> + * \code printf("%i %02i", productInfo[0], productInfo[1]); \endcode
> + */
> + unsigned char prod_info[2];
> +
> + /** Date Code - Year, Month, Day.
> + */
> + unsigned char date_code[3];
> +
> + /** Tester ID (14 bits).
> + */
> + unsigned short tester_id;
> +
> + /** Serial Number (14 bits).
> + */
> + unsigned short serial_num;
> +
> + /** A null-terminated string that identifies this particular product.
> + */
> + char prod_id[10];
> +
> + /** A list of the function presence queries.
> + * This list uses the standard kernel linked list implementation.
> + * Documentation on on how to use it can be found at
> + * http://isis.poly.edu/kulesh/stuff/src/klist/.
> + * \see rmi_function_info
> + */
> + struct list_head functions;
> +};
> +
> +struct rmi_phys_driver {
> + char *name;
> + int (*write)(struct rmi_phys_driver *pd, unsigned short address, char data);
> + int (*read)(struct rmi_phys_driver *pd, unsigned short address, char *buffer);
> + int (*write_multiple)(struct rmi_phys_driver *pd, unsigned short address, char *buffer, int length);
> + int (*read_multiple)(struct rmi_phys_driver *pd, unsigned short address, char *buffer, int length);
> + void (*attention)(struct rmi_phys_driver *pd, int instance);
> + int (*get_attention)(struct rmi_phys_driver *pd);
> + int polling_required;
> + /* Private elements of the structure */
> + /** Standard kernel linked list implementation.
> + * Documentation on how to use it can be found at
> + * http://isis.poly.edu/kulesh/stuff/src/klist/.
> + */
> + struct list_head drivers;
> + struct rmi_application *app;
> + struct rmi_module_info rmi;
> + struct module *module;
> +};
> +
> +int rmi_read(struct rmi_application *app, unsigned short address, char *dest);
> +int rmi_write(struct rmi_application *app, unsigned short address, unsigned char data);
> +int rmi_read_multiple(struct rmi_application *app, unsigned short address, char *dest, int length);
> +int rmi_write_multiple(struct rmi_application *app, unsigned short address, unsigned char *data, int length);
> +int rmi_register_phys_driver(struct rmi_phys_driver *rpd);
> +int rmi_unregister_phys_driver(struct rmi_phys_driver *rpd);
> +
> +struct rmi_application *rmi_register_application(const char *name,
> + void (*attention)(struct rmi_phys_driver *pd, int instance),
> + int (*probe)(struct rmi_application *app, const struct rmi_module_info *rmi),
> + void (*config)(struct rmi_application *app));
> +
> +void rmi_unregister_application(struct rmi_application *app);
> +int rmi_polling_required(struct rmi_application *app);
> +int rmi_get_attn(struct rmi_application *app);
> +
> +/** Set this to 1 to turn on code used in detecting buffer leaks. */
> +#define RMI_ALLOC_STATS 1
> +
> +#if RMI_ALLOC_STATS
> +extern int appallocsrmi;
> +extern int rfiallocsrmi;
> +extern int fnallocsrmi;
> +
> +# define INC_ALLOC_STAT(X) (X##allocsrmi++)
> +# define DEC_ALLOC_STAT(X) \
> + do { \
> + if (X##allocsrmi) X##allocsrmi--; \
> + else printk(KERN_DEBUG "Too many " #X " frees\n"); \
> + } while (0)
> +# define CHECK_ALLOC_STAT(X) \
> + do { \
> + if (X##allocsrmi) printk(KERN_DEBUG "Left over " #X " buffers: %d\n", \
> + X##allocsrmi); \
> + } while (0)
> +#else
> +# define INC_ALLOC_STAT(X) do { } while (0)
> +# define DEC_ALLOC_STAT(X) do { } while (0)
> +# define CHECK_ALLOC_STAT(X) do { } while (0)
> +

twitter

Tuesday, March 2, 2010

linux.kernel - 26 new messages in 23 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts