[PATCH 4/4] sh: bring syscall_set_return_value in line with other architectures

Other architectures expect that syscall_set_return_value gets an already negative value as error. That's also what kernel/seccomp.c provides. Signed-off-by: Michael Karcher --- arch/sh/include/asm/syscall_32.h | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/ar

[PATCH 3/4] sh: Add SECCOMP_FILTER

Port sh to use the new SECCOMP_FILTER code. Signed-off-by: Michael Karcher --- arch/sh/Kconfig | 1 + arch/sh/kernel/entry-common.S | 2 ++ arch/sh/kernel/ptrace_32.c| 5 +++-- tools/testing/selftests/seccomp/seccomp_bpf.c | 8

[PATCH 1/4] sh: Fix validation of system call number

The slow path for traced system call entries accessed a wrong memory location to get the number of the maximum allowed system call number. Renumber the numbered "local" label for the correct location to avoid collisions with actual local labels. Signed-off-by: Michael Karcher --- arch

[PATCH 2/4] sh: Rearrange blocks in entry-common.S

This avoids out-of-range jumps that get auto-replaced by the assembler and prepares for the changes needed to implement SECCOMP_FILTER cleanly. Signed-off-by: Michael Karcher --- arch/sh/kernel/entry-common.S | 57 ++- 1 file changed, 29 insertions(+), 28

Re: [PATCH] sh: Implement __get_user_u64() required for 64-bit get_user()

n the hot path to ensure full zeroing is acceptable - maintainance of arch-specific asm on many 32-bit architectures is acceptable. I don't want to endorse one of these three options, as I am out of the loop regarding kernel development priorities and philosophy, I just intend to point out the different options the kernel has to pick the one that fits best. Regards, Michael Karcher

Re: [PATCH] sh: Implement __get_user_u64() required for 64-bit get_user()

; this code is not in a hot path? >> > Yes, that's an option, too. >> That's the solution that Michael Karcher suggested to me as an >> alternative when I talked to him off-list. There is a functional argument agains using get_user_32 twice, which I overlooked in my pri

[PATCH 1/1] fujitsu-laptop: use FB_BLANK_* constants

Replace the magic numbers in fujitsu-laptop.c by the appropriate FB_BLANK constants, as indicated by the comment for backlight_properties.power in include/linux/backlight.h. Signed-off-by: Michael Karcher --- drivers/platform/x86/fujitsu-laptop.c | 7 --- 1 file changed, 4 insertions(+), 3

[PATCH] fujitsu-laptop: use FB_BLANK_* constants

From: Michael Karcher Signed-off-by: Michael Karcher --- drivers/platform/x86/fujitsu-laptop.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c index 7c21c1c..2a9afa2 100644 --- a/drivers

[PATCH 1/1] fujitsu-laptop: use FB_BLANK_* constants

From: Michael Karcher --- drivers/platform/x86/fujitsu-laptop.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c index 7c21c1c..2a9afa2 100644 --- a/drivers/platform/x86/fujitsu-laptop.c

[PATCH 1/1] scripts/recordmcount.pl: There is no -m32 option on Super-H

Signed-Off-By: Michael Karcher --- scripts/recordmcount.pl | 1 - 1 file changed, 1 deletion(-) diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl index 56ea99a..537c38c 100755 --- a/scripts/recordmcount.pl +++ b/scripts/recordmcount.pl @@ -255,7 +255,6 @@ if ($arch eq "x

[PATCH] Support Jess/Saitek Color Rumble Pad

ot; gamepad. The pad has been tested to support rumble strengths up to 255, not just 127. Signed-off-by: Michael Karcher --- drivers/hid/hid-core.c |1 + drivers/hid/hid-ids.h |3 +++ drivers/hid/hid-pl.c | 13 +++-- 3 files changed, 15 insertions(+), 2 deletions(-) diff --git a/

Rumble support for Jess/Saitek "color rumble pad"

4-field green asia pad to verify whether the maximum rumble strength is indeed only 127, otherwise the condition should be removed entirely and 255 used in all cases. Regards, Michael Karcher >From 935b0e9f08bf7b4d271eab3356eacc1b7c47eb73 Mon Sep 17 00:00:00 2001 From: Michael Karcher Date: Mon,

Crash in request_region while handling kernel parameters

eck_region and request_region in the umc8672.c file, but I know it smells. Please send me a cc if you think you have a decision how to fix the crash. Michael Karcher - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Mo