linux-toradex.git/drivers/char, branch v2.6.13.4

[PATCH] Fix drm 'debug' sysfs permissions

2005-10-10T18:50:55+00:00

Please consider for next 2.6.13, it is a minor security issue allowing
users to turn on drm debugging when they shouldn't...

This fell through the cracks. Until Josh pointed me at
http://bugs.gentoo.org/show_bug.cgi?id=107893

Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] Use SA_SHIRQ in sparc specific code.

2005-09-10T02:42:52+00:00

Based upon a report from Jason Wever.

Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright 
Signed-off-by: Greg Kroah-Hartman

[PATCH] Remove race between con_open and con_close

2005-08-28T01:03:42+00:00

[ Same race and same patch also by Steven Rostedt  ]

I have a laptop (G3 powerbook) which will pretty reliably hit a race
between con_open and con_close late in the boot process and oops in
vt_ioctl due to tty->driver_data being NULL.

What happens is this: process A opens /dev/tty6; it comes into
con_open() (drivers/char/vt.c) and assign a non-NULL value to
tty->driver_data.  Then process A closes that and concurrently process
B opens /dev/tty6.  Process A gets through con_close() and clears
tty->driver_data, since tty->count == 1.  However, before process A
can decrement tty->count, we switch to process B (e.g. at the
down(&tty_sem) call at drivers/char/tty_io.c line 1626).

So process B gets to run and comes into con_open with tty->count == 2,
as tty->count is incremented (in init_dev) before con_open is called.
Because tty->count != 1, we don't set tty->driver_data.  Then when the
process tries to do anything with that fd, it oopses.

The simple and effective fix for this is to test tty->driver_data
rather than tty->count in con_open.  The testing and setting of
tty->driver_data is serialized with respect to the clearing of
tty->driver_data in con_close by the console_sem.  We can't get a
situation where con_open sees tty->driver_data != NULL and then
con_close on a different fd clears tty->driver_data, because
tty->count is incremented before con_open is called.  Thus this patch
eliminates the race, and in fact with this patch my laptop doesn't
oops.

Signed-off-by: Paul Mackerras 
[ Same patch
Signed-off-by: Steven Rostedt 
  in http://marc.theaimsgroup.com/?l=linux-kernel&m=112450820432121&w=2 ]
Signed-off-by: Linus Torvalds

[PATCH] Kconfig fix (sparc32 drivers/char dependencies)

2005-08-24T01:43:43+00:00

since sparc32 Kconfig includes drivers/char/Kconfig (instead of duplicating
its parts) we need several new dependencies there to exclude the stuff
broken on sparc32 and not excluded by existing dependencies.

Signed-off-by: Al Viro 
Signed-off-by: Linus Torvalds

[PATCH] Kconfig fix (m32r genrtc)

2005-08-24T01:43:40+00:00

genrtc is not for m32r; marked as such.  Probably ought to put that into
arch/* - list of "don't build it on " is getting too long.

Signed-off-by: Al Viro 
Signed-off-by: Linus Torvalds

[PATCH] Kconfig fix (epca on 64bit)

2005-08-24T01:43:39+00:00

epca is broken on 64bit; marked as such

Signed-off-by: Al Viro 
Signed-off-by: Linus Torvalds

Fix up mmap of /dev/kmem

2005-08-13T21:22:59+00:00

This leaves the issue of whether we should deprecate the whole thing (or
if we should check the whole mmap range, for that matter) open. Just do
the minimal fix for now.

[PATCH] i8xx_tco.c: arm watchdog only when started

2005-08-09T19:08:21+00:00

i8xx_tco.c v0.08: only "arm" the watchdog when the watchdog has been
started.  (Kernel Bug 4251: system reset when battery is read and i8xx_tco
driver loaded)

Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] tpm_infineon: Support for new TPM 1.2 and PNPACPI

2005-08-05T19:22:37+00:00

This patch includes support for the new Infineon Trusted Platform Module
SLB 9635 TT 1.2 and does further include ACPI-support for both chip
versions (SLD 9630 TT 1.1 and SLB9635 TT 1.2).  Since the ioports and
configuration registers are not correctly set on some machines, the
configuration is now done via PNPACPI, which reads out the correct values
out of the DSDT-table.  Note that you have to have CONFIG_PNP,
CONFIG_ACPI_BUS and CONFIG_PNPACPI enabled to run this driver (assuming
that mainboards including a TPM do have the need for ACPI anyway).

Signed-off-by: Marcel Selhorst 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] rtc: msleep() cannot be used from interrupt

2005-08-05T13:57:44+00:00

Since the beginning of July my Opteron box was randomly crashing and
being rebooted by hardware watchdog.  Today it finally did it in front
of me, and this patch will hopefully fix it.

The problem is that at the end of June (the 28th, to be exact: commit
47f176fdaf8924bc83fddcf9658f2fd3ef60d573, "[PATCH] Using msleep()
instead of HZ") rtc_get_rtc_time was converted to use msleep() instead
of busy waiting.  But rtc_get_rtc_time is used by hpet_rtc_interrupt,
and scheduling is not allowed during interrupt.  So I'm reverting this
part of original change, replacing msleep() back with busy loop.

The original code was busy waiting for up to 20ms, but on my hardware in
the worst case update-in-progress bit was asserted for at most 363
passes through loop (on 2GHz dual Opteron), much less than even one
jiffie, not even talking about 20ms.  So I changed code to just wait
only as long as necessary.  Otherwise when RTC was set to generate
8192Hz timer, it stopped doing anything for 20ms (160 pulses were
skipped!) from time to time, and this is rather suboptimal as far as I
can tell.

Signed-off-by: Petr Vandrovec 
Signed-off-by: Linus Torvalds