From 9ddf61bd09a7668279d2b208a96eba784bec3d80 Mon Sep 17 00:00:00 2001 From: Marcelo Tosatti Date: Mon, 5 Dec 2005 10:15:06 +0000 Subject: [ARM SMP] mpcore_wdt bogus fpos check drivers/char/watchdog/mpcore_wdt.c write function contains a check for (ppos != &file->f_pos). Such check used to make sense when a pointer to file->f_pos was handed by vfs_write(), not a copy of it as it stands now. Signed-off-by: Marcelo Tosatti Signed-off-by: Russell King --- drivers/char/watchdog/mpcore_wdt.c | 4 ---- 1 file changed, 4 deletions(-) (limited to 'drivers/char') diff --git a/drivers/char/watchdog/mpcore_wdt.c b/drivers/char/watchdog/mpcore_wdt.c index 9defcf861b67..b4d843489881 100644 --- a/drivers/char/watchdog/mpcore_wdt.c +++ b/drivers/char/watchdog/mpcore_wdt.c @@ -180,10 +180,6 @@ static ssize_t mpcore_wdt_write(struct file *file, const char *data, size_t len, { struct mpcore_wdt *wdt = file->private_data; - /* Can't seek (pwrite) on this device */ - if (ppos != &file->f_pos) - return -ESPIPE; - /* * Refresh the timer. */ -- cgit v1.2.1 From cda315aba34ff4fb66bbb2945b723688f3414a75 Mon Sep 17 00:00:00 2001 From: Matt Domsch Date: Mon, 12 Dec 2005 00:37:32 -0800 Subject: [PATCH] ipmi: fix panic generator ID The IPMI specifcation says the generator ID is 0x20, but that is for bits 7-1. Bit 0 is set to specify it is a software event. The correct value is 0x41. Without this fix, panic events written into the System Event Log appear to come from an "unknown" generator, rather than from the kernel. Signed-off-by: Jordan Hargrave Signed-off-by: Matt Domsch Acked-by: Corey Minyard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- drivers/char/ipmi/ipmi_msghandler.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/char') diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c index 6b302a930e5f..1f56b4cf0f58 100644 --- a/drivers/char/ipmi/ipmi_msghandler.c +++ b/drivers/char/ipmi/ipmi_msghandler.c @@ -2986,7 +2986,7 @@ static void send_panic_events(char *str) msg.cmd = 2; /* Platform event command. */ msg.data = data; msg.data_len = 8; - data[0] = 0x21; /* Kernel generator ID, IPMI table 5-4 */ + data[0] = 0x41; /* Kernel generator ID, IPMI table 5-4 */ data[1] = 0x03; /* This is for IPMI 1.0. */ data[2] = 0x20; /* OS Critical Stop, IPMI table 36-3 */ data[4] = 0x6f; /* Sensor specific, IPMI table 36-1 */ -- cgit v1.2.1 From 0de502aa44aae5712a18d471818d6c785e07c92e Mon Sep 17 00:00:00 2001 From: Andrew Morton Date: Mon, 12 Dec 2005 00:37:41 -0800 Subject: [PATCH] raw driver: Kconfig fix CONFIG_MAX_RAW_DEVS should appear immediately after CONFIG_RAW_DRIVER. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- drivers/char/Kconfig | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) (limited to 'drivers/char') diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index 970f70d498f4..b46a72d782d6 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -943,6 +943,15 @@ config RAW_DRIVER Applications should simply open the device (eg /dev/hda1) with the O_DIRECT flag. +config MAX_RAW_DEVS + int "Maximum number of RAW devices to support (1-8192)" + depends on RAW_DRIVER + default "256" + help + The maximum number of RAW devices that are supported. + Default is 256. Increase this number in case you need lots of + raw devices. + config HPET bool "HPET - High Precision Event Timer" if (X86 || IA64) default n @@ -974,15 +983,6 @@ config HPET_MMAP exposed to the user. If this applies to your hardware, say N here. -config MAX_RAW_DEVS - int "Maximum number of RAW devices to support (1-8192)" - depends on RAW_DRIVER - default "256" - help - The maximum number of RAW devices that are supported. - Default is 256. Increase this number in case you need lots of - raw devices. - config HANGCHECK_TIMER tristate "Hangcheck timer" depends on X86 || IA64 || PPC64 || ARCH_S390 -- cgit v1.2.1 From 47807ce381acc34a7ffee2b42e35e96c0f322e52 Mon Sep 17 00:00:00 2001 From: Dave Airlie Date: Tue, 13 Dec 2005 04:18:41 +0000 Subject: [drm] fix radeon aperture issue Ben noticed that on certain cards we've landed the AGP space on top of the second aperture instead of after it.. Which messes things up a lot on those machines. This just moves the gart further out, a more correct fix is in the works from Ben for after 2.6.15. Signed-off-by: Dave Airlie CC: Ben Herrenschmidt Signed-off-by: Linus Torvalds --- drivers/char/drm/radeon_cp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/char') diff --git a/drivers/char/drm/radeon_cp.c b/drivers/char/drm/radeon_cp.c index 03839ea31092..9f2b4efd0c7a 100644 --- a/drivers/char/drm/radeon_cp.c +++ b/drivers/char/drm/radeon_cp.c @@ -1522,7 +1522,7 @@ static int radeon_do_init_cp(drm_device_t * dev, drm_radeon_init_t * init) dev_priv->gart_size = init->gart_size; dev_priv->gart_vm_start = dev_priv->fb_location - + RADEON_READ(RADEON_CONFIG_APER_SIZE); + + RADEON_READ(RADEON_CONFIG_APER_SIZE) * 2; #if __OS_HAS_AGP if (!dev_priv->is_pci) -- cgit v1.2.1