linux/drivers/char, branch v2.6.15.2

[PATCH] moxa serial: add proper capability check

2006-01-15T06:15:30Z

This requires the proper capabilities for the moxa bios update ioctl's. Signed-off-by: Alan Cox Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

Revert radeon AGP aperture offset changes

2005-12-29T21:01:54Z

This reverts the series of commits 67dbb4ea33731415fe09c62149a34f472719ac1d 281ab031a8c9e5b593142eb4ec59a87faae8676a 47807ce381acc34a7ffee2b42e35e96c0f322e52 that changed the GART VM start offset. It fixed some machines, but seems to continually interact badly with some X versions. Quoth Ben Herrenschmidt: "So I think at this point, the best is that we keep the old bogus code that at least is consistent with the bug in the server. I'm working on a big patch to X that reworks the memory map stuff completely and fixes those issues on the server side, I'll do a DRM patch matching this X fix as well so that the memory map is only ever set in one place and with what I hope is a correct algorithm..." Signed-off-by: Linus Torvalds

[PATCH] fix ia64 compile failure with gcc4.1

2005-12-29T18:19:21Z

__get_unaligned creates a typeof the var its passed, and writes to it, which on gcc4.1, spits out the following error: drivers/char/vc_screen.c: In function 'vcs_write': drivers/char/vc_screen.c:422: error: assignment of read-only variable 'val' Signed-off-by: Dave Jones [ The "right" fix would be to try to fix but that's hard to do with the tools gcc gives us. So this simpler patch is preferable -- Linus ] Signed-off-by: Linus Torvalds

[PATCH] Fix more radeon GART start calculation cases

2005-12-28T03:57:52Z

As reported by Jules Villard and some others, the recent GART aperture start reconfiguration causes problems on some setups. What I _think_ might be happening is that the X server is also trying to muck around with the card memory map and is forcing it back into a wrong setting that also happens to no longer match what the DRM wants to do and blows up. There are bugs all over the place in that code (and still some bugs in the DRM as well anyway). This patch attempts to avoid that by using the largest of the 2 values, which I think will cause it to behave as it used to for you and will still fix the problem with machines that have an aperture size smaller than the video memory. Acked-by: Jules Villard Signed-off-by: Linus Torvalds

[SPARC]: introduce a SPARC Kconfig symbol

2005-12-23T07:09:54Z

Introduce a Kconfig symbol SPARC that is defined on both the sparc and sparc64 architectures. This symbol makes some dependencies more readable. Signed-off-by: Adrian Bunk Signed-off-by: David S. Miller

[SPARC]: Fix RTC build failure.

2005-12-19T22:52:24Z

On sparc and sparc64, the rtc driver doesn't compile with PCI support disabled. Signed-off-by: Adrian Bunk Signed-off-by: David S. Miller

[PATCH] radeon drm: fix compilation breakage with gcc 2.95.3

2005-12-19T00:19:35Z

Fix a typo which breaks radeon drm compilation with gcc 2.95.3. The offending line was added back in 2.6.11-rc3, but was harmless back then. A recent addition nearby changed it into a compilation breaker: commit 281ab031a8c9e5b593142eb4ec59a87faae8676a. The doubled semi-colon ends up being an empty instruction, and the variable declaration thus ends up being in the middle of "code". Signed-off-by: Jean Delvare Cc: Benjamin Herrenschmidt Cc: Mark M. Hoffman Cc: Paul Mackerras Signed-off-by: Linus Torvalds

[PATCH] ppc: booke_wdt compile fix

2005-12-16T22:43:05Z

booke_wdt.c had been missed in cpu_specs[] removal sweep Signed-off-by: Al Viro Signed-off-by: Linus Torvalds

[PATCH] radeon drm: fix agp aperture map offset

2005-12-16T06:22:57Z

This finally fixes the radeon memory mapping bug that was incorrectly fixed by the previous patch. This time, we use the actual vram size as the size to calculate how far to move the AGP aperture from the framebuffer in card's memory space. If there are still issues with this patch, they are due to bugs in the X driver that I'm working on fixing too. Signed-off-by: Benjamin Herrenschmidt Cc: Mark M. Hoffman Cc: Paul Mackerras Signed-off-by: Linus Torvalds

[PATCH] IPMI oops fix

2005-12-15T22:22:45Z

While doing some testing I discovered that if the BIOS on a board does not properly setup the DMI information it leads to a panic in the IPMI code. The panic is due to dereferencing a pointer which is not initialized. The pointer is initialized in port_setup() and/or mem_setup() and used in init_one_smi() and cleanup_one_si(), however if either port_setup() or mem_setup() return ENODEV the pointer does not get initialized. Signed-off-by: Paolo Galtieri Acked-by: Corey Minyard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds