Andi Kleen [Mon, 6 Oct 2003 08:15:45 +0000 (01:15 -0700)]
[PATCH] cpufreq for x86-64
Reuses the i386 cpufreq code and add an notifier to the x86-64
timer code to track frequency changes.
All previous criticism of earlier patches should be addressed:
- it doesn't touch i386 now
- Doesn't include the ACPI P states driver anymore following brodo's request.
Andi Kleen [Mon, 6 Oct 2003 08:15:36 +0000 (01:15 -0700)]
[PATCH] UID16 fixes
This fixes CONFIG_UID16 problems on x86-64 as discussed earlier.
CONFIG_UID16 now only selects the inclusion of kernel/uid16.c, all
conversions are triggered dynamically based on type sizes. This allows
x86-64 to both include uid16.c for emulation purposes, but not truncate
uids to 16bit in sys_newstat.
- Replace the old macros from linux/highuid.h with new SET_UID/SET_GID
macros that do type checking. Based on Linus' proposal.
- Fix everybody to use them.
- Clean up some cruft in the x86-64 32bit emulation allowed by this
(other 32bit emulations could be cleaned too, but I'm too lazy for
that right now)
- Add one missing EOVERFLOW check in x86-64 32bit sys_newstat while
I was at it.
there's one call to strncpy() in vfat that really should be a memcpy().
The source, msdos_name, is a space-filled char array, not a
NUL-terminated string.
The rest of the patch eliminates duplicate occurencies of the
CURRENT_TIME macro inside functions. This shrinks vfat.o by a few
bytes.
Russell King [Mon, 6 Oct 2003 01:18:43 +0000 (18:18 -0700)]
[PATCH] Fix sysrq-t free stack output
It seems that we're attempting to work out the free stack size using two
unrelated pointers for the lowest address of the stack. Fix this to use
the correct pointer.
- Remove dynamic allocation of major numbers. Just use static major 94.
- Use bus_id instead of device number where possible.
- Don't check open_count in dasd_generic_set_offline.
- Remove atomic_read hack to test for presence of ccw device directory.
- Add dummy release function to channel path object and cu3088 group devices.
- Don't rely on the chaining bit of the channel report word.
- Don't call schedule while holding a lock in read_dev_chars/read_conf_data.
- Makefile fix: default make target builds the kernel image.
- Add export statement for cpcmd.
- Add tgkill system call.
- Reserve system call number for vserver.
Achim Leubner [Mon, 6 Oct 2003 00:44:15 +0000 (17:44 -0700)]
[PATCH] gdth driver update
- Maintainers email address and copyright messages updated
- Scanning for EISA and ISA controllers disabled due to a resource conflict
with the Adaptec aic driver
- Switch "probe_eisa_isa" added to give the possibility to enable the
EISA/ISA scan if required
- Driver version increased to 2.08
Bjorn Helgaas [Sun, 5 Oct 2003 22:58:04 +0000 (23:58 +0100)]
[SERIAL] removing legacy UART cruft
I'm trying to remove all the legacy UART cruft from ia64. In theory
we should be able to discover all UARTs on ia64 via ACPI and PCI
enumeration, so we shouldn't need SERIAL_PORT_DFNS.
But SERIAL_PORT_DFNS currently does two things:
1) it tells you about legacy devices you can't discover
via a standard enumeration method, and
2) it sizes old_serial_port[], which determines UART_NR,
which is the maximum number of ports the driver will
support
So here's a proposal to make SERIAL_PORT_DFNS optional and
provide another mechanism for configuring the number of ports
to support.
Michael Hunold [Sun, 5 Oct 2003 04:42:37 +0000 (21:42 -0700)]
[PATCH] Update V4L2 "Hexium" driver
This updates my two Video4Linux-2 drivers for the "Hexium Gemini" and
"Hexium Orion" cards.
It adds the long missing input handling for the "Gemini" card and
removes the annoying compile time warning about unused structures.
- remove various hexium header files, put all driver relevant
informations into the drivers. these informations are not needed
anywhere else.
- fix driver names in information printk()s
- fix device initialization for Hexium Gemini cards
- add input switching for Hexium Gemini cards
- fix all remaining "fixme"s
Andi Kleen [Sun, 5 Oct 2003 04:42:19 +0000 (21:42 -0700)]
[PATCH] Fix -Wdeclaration-after-statement warnings for x86-64
Fix warnings on compilers that support -Wdeclaration-after-statement
in the x86-64 specific code. x86-64 was happily using ISO-C99 code
before because it only uses gcc 3+ which is ISO-C99 compliant, but
unfortunately this warning was added in the top level Makefile.
Andrew Morton [Sun, 5 Oct 2003 04:04:20 +0000 (21:04 -0700)]
[PATCH] fix "compat ioctl consolidation" for "move job
A little fix which is needed if both the "compat ioctl consolidation" and
"move job control fields from task_struct to signal_struct" patches are
applied.
Andrew Morton [Sun, 5 Oct 2003 04:04:11 +0000 (21:04 -0700)]
[PATCH] move job control fields from task_struct to
From: Roland McGrath <roland@redhat.com>
This patch completes what was started with the `process_group' accessor
function, moving all the job control-related fields from task_struct into
signal_struct and using process_foo accessor functions to read them. All
these things are per-process in POSIX, none per-thread. Off hand it's hard
to come up with the hairy MT scenarios in which the existing code would do
insane things, but trust me, they're there. At any rate, all the uses
being done via inline accessor functions now has got to be all good.
I did a "make allyesconfig" build and caught the few random drivers and
whatnot that referred to these fields. I was surprised to find how few
references to ->tty there really were to fix up. I'm sure there will be a
few more fixups needed in non-x86 code. The only actual testing of a
running kernel with these patches I've done is on my normal minimal x86
config. Everything works fine as it did before as far as I can tell.
One issue that may be of concern is the lack of any locking on multiple
threads diddling these fields. I don't think it really matters, though
there might be some obscure races that could produce inconsistent job
control results. Nothing shattering, I'm sure; probably only something
like a multi-threaded program calling setsid while its other threads do tty
i/o, which never happens in reality. This is the same situation we get by
using ->group_leader->foo without other synchronization, which seemed to be
the trend and noone was worried about it.