Revert 7e92b4fc34. It broke Sébastien Dugué's
machine and Jeff said (persuasively)
This seems like it will break decades-long-working stuff, in favor of
breaking new ground in our favorite area, "trusting the BIOS."
It's just not worth it for serial ports, IMO. Serial ports are something
that just shouldn't break at this late stage in the game. My new Intel
platform boxes don't even have serial ports, so I question the value of
messing with serial port probing even more... because... just wait a year,
and your box won't have a serial port either! :)
I certainly don't object to the use of platform devices (or isa_driver),
but the probe change seems questionable. That's sorta analagous to
rewriting the floppy driver probe routine. Sure you could do it... but why
risk all that damage and go through debugging all over again?
It seems clear from this report that we cannot, should not, trust BIOS for
something (a) so simple and (b) that has been working for over a decade.
Much discussion ensued and we've decided to have another go at all of this.
Cc: Sébastien Dugué <sebastien.dugue@bull.net>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Adam Belay <ambx1@neo.rr.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Jeff Garzik <jeff@garzik.org>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Cc: Sascha Sommer <saschasommer@freenet.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix PNP docbook warnings:
Warning(linux-2623-rc1g4//drivers/pnp/core.c): no structured comments found
Warning(linux-2623-rc1g4//drivers/pnp/driver.c): no structured comments found
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Updates based on recent .gitignore updates:
*.o.*: Says Alexey Dobriyan:
These are presumably temporary gcc files, which aren't interesting.
setup.bin, setup.elf: new x86 boot code files (from Matthew Wilcox)
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://git390.osdl.marist.edu/pub/scm/linux-2.6:
[S390] Fix sclp_vt220 error handling.
[S390] cio: Reorganize initialization.
[S390] cio: Make CIO_* macros safe if dbfs are not available.
[S390] cio: Clean up messages.
[S390] Fix IRQ tracing.
[S390] vmur: fix diag14_read.
[S390] Wire up sys_fallocate.
[S390] add types.h include to s390_ext.h
[S390] cio: Remove deprecated rdc/rcd.
[S390] Get rid of new section mismatch warnings.
[S390] sclp: kill unused SCLP config option.
[S390] cio: Remove remains of _ccw_device_get_device_number().
[S390] cio: css_sch_device_register() can be made static.
[S390] Improve __smp_call_function_map.
[S390] Convert to smp_call_function_single.
* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
docbook: add pipes, other fixes
blktrace: use cpu_clock() instead of sched_clock()
bsg: Fix build for CONFIG_BLOCK=n
[patch] QUEUE_FLAG_READFULL QUEUE_FLAG_WRITEFULL comment fix
http://marc.info/?l=linux-kernel&m=118481061928246&w=2 seems to
indicate disfavour of "deprecated", so let's just kill it now.
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Fix some typos in pipe.c and splice.c.
Add pipes API to kernel-api.tmpl.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Documentation: The FIXMEs
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Documentation: The Launcher
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The netfilter code had very good documentation: the Netfilter Hacking HOWTO.
Noone ever read it.
So this time I'm trying something different, using a bit of Knuthiness.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
While learning about schedstats I found that the documentation in the tree
is old. I updated it and found some interesting stuff like schedstats
version 14 is the same as version and version 13 never saw a kernel
release! Also there are 6 fields in the current schedstats that are not
used anymore. Nick had made them irrelevant in commit
476d139c21 but never removed them.
Thanks to Rick's perl script who I borrowed some of the updated descriptions
from.
Signed-off-by: Joachim Deguara <joachim.deguara@amd.com>
Acked-by: Nick Piggin <npiggin@suse.de>
Cc: Rick Lindsley <ricklind@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
* 'request-queue-t' of git://git.kernel.dk/linux-2.6-block:
[BLOCK] Add request_queue_t and mark it deprecated
[BLOCK] Get rid of request_queue_t typedef
Fix doc bug noted by Uwe Kleine-König: gpio_set_direction() is long
gone, replaced by gpio_direction_input() and gpio_direction_output().
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
S.Caglar Onur points out that many distributions don't ship a static
zlib. Unfortunately the launcher currently maps virtual device memory
where shared libraries want to go.
The solution is to pre-scan the args to figure out how much memory we
have, then allocate devices above that, rather than down from the top
possible address. This also turns out to be simpler.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some of the code has been gradually transitioned to using the proper
struct request_queue, but there's lots left. So do a full sweet of
the kernel and get rid of this typedef and replace its uses with
the proper type.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Fix a typo in SubmittingPatches where "probably" was spelt "probabally".
Signed-off-by: Linus Nilsson <lajnold@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Change a headline to reflect that there are three main types of kernel
locking, not two.
Signed-off-by: Linus Nilsson <lajnold@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ACPI sysfs conversion is not finished yet and
some user space tools still depend on the ACPI proc I/F.
We plan to finish all the sysfs conversion by January 2008
and remove the ACPI proc I/F in July 2008.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The /sys/firmware/acpi/namespace has already been removed in 2.6.21.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Reading the 16 thermal sensors directly from the EC has been stable for
about one year, in all supported ThinkPad models. Remove its
"experimental" label.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Lenovo ThinkPads have a slightly different key map layout from IBM
ThinkPads (fn+f2 and fn+f3 are swapped). Knowing which one we are dealing
with, we can properly set a few more hot keys up by default.
Also, export the correct vendor in the input device, as that information
might be useful to userspace.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
It appears that Lenovo decided to break the EC brightness control interface
in a weird way in their latest BIOSes. Fortunately, the old CMOS NVRAM
interface works just fine in such BIOSes.
Add a module parameter that allows the user to select which strategy to use
for brightness control: EC, NVRAM, or both. By default, do both (which is
the way thinkpad-acpi used to work until now) on IBM ThinkPads, and use
NVRAM only on Lenovo ThinkPads.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
The change in the way hotkey events are handled by default, and the use of
the input layer for the hotkey events are important enough features to
warrant increasing the major field of the sysfs interface version.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Make the input layer the default way to deal with thinkpad-acpi hot keys,
but add a kernel config option to retain the old way of doing things.
This means we map a lot more keys to useful stuff by default, and also that
we enable hot key handling by default on driver load (like Windows does).
The documentation for proper use of this resource is also updated.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Richard Hughes <hughsient@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Add input device support to the hotkey subdriver.
Hot keys that have a valid keycode mapping are reported through the input
layer if the input device is open. Otherwise, they will be reported as
ACPI events, as they were before.
Scan codes are reported (using EV_MSC MSC_SCAN events) along with EV_KEY
KEY_UNKNOWN events.
For backwards compatibility purposes, hot keys that used to be reported
through ACPI events are not mapped to anything meaningful by default.
Userspace is supposed to remap them if it wants to use the input device for
hot key reporting.
This patch is based on a patch by Richard Hughes <hughsient@gmail.com>.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Richard Hughes <hughsient@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The CMOS set of commands is often just used to keep the CMOS NVRAM in sync
with whatever the ACPI BIOS has been doing in modern ThinkPads. In older
ThinkPads, it actually carried out real actions. Document this.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
The change in the size of the hotkey mask, the hability to report the keys
that use the higher bits, and the addition of the hotkey_radio_sw attribute
are important enough features to warrant increasing the minor field of the
sysfs interface version.
Also, document a bit better how and when the thinkpad-acpi sysfs interface
version will be updated.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Some ThinkPad models, notably the T60 and X60, have a slider switch to
enable and disable the radios. The switch has the capability of
force-disabling the radios in hardware on most models, and it is supposed
to affect all radios (WLAN, WWAN, BlueTooth).
Export the switch state as a sysfs attribute, on ThinkPads where it is
available.
Thanks to Henning Schild for asking for this feature, and for tracking down
the EC register that holds the radio switch state.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Henning Schild <henning@wh9.tu-dresden.de>
Signed-off-by: Len Brown <len.brown@intel.com>
The firmware knows how many hot keys it supports, so export this
information in a sysfs attribute.
And the driver knows which keys are always handled by the firmware in all
known ThinkPad models too, so export this information as well in a sysfs
attribute. Unless you know which events need to be handled in a passive
way, do *not* enable hotkeys that are always handled by the firmware.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Revise ACPI HKEY functionality to better interface with the firmware, and
enable up to 32 regular hotkeys, instead of just 16 of them. Ouch.
This takes care of most keys one used to have to do CMOS NVRAM polling on,
and should drop the need for tpb, thinkpad-keys, and other such 5Hz NVRAM
polling power vampires on most modern ThinkPads ;-)
And, just to add insult to injury, this was sort of working since forever
through the procfs interface, but nobody noticed or tried an echo
0xffffffff > /proc/acpi/ibm/hotkey and told me it would generate weird
events. ARGH!
Thanks to Richard Hughes for kicking off the work that ended up with this
discovery, and to Matthew Garret for calling my attention to the fact that
newer ThinkPads were indeed generating ACPI GPEs when such hot keys were
pressed.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Richard Hughes <hughsient@gmail.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Update the documentation with some extra data on the T43 thermal sensor
@0xc1, thanks to Alexey Fisher.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Background:
The MCE handler has several paths that it can take, depending on various
conditions of the MCE status and the value of the 'tolerant' knob. The
exact semantics are not well defined and the code is a bit twisty.
Description:
This patch makes the MCE handler's behavior more clear by documenting the
behavior for various 'tolerant' levels. It also fixes or enhances
several small things in the handler. Specifically:
* If RIPV is set it is not safe to restart, so set the 'no way out'
flag rather than the 'kill it' flag.
* Don't panic() on correctable MCEs.
* If the _OVER bit is set *and* the _UC bit is set (meaning possibly
dropped uncorrected errors), set the 'no way out' flag.
* Use EIPV for testing whether an app can be killed (SIGBUS) rather
than RIPV. According to docs, EIPV indicates that the error is
related to the IP, while RIPV simply means the IP is valid to
restart from.
* Don't clear the MCi_STATUS registers until after the panic() path.
This leaves the status bits set after the panic() so clever BIOSes
can find them (and dumb BIOSes can do nothing).
This patch also calls nonseekable_open() in mce_open (as suggested by akpm).
Result:
Tolerant levels behave almost identically to how they always have, but
not it's well defined. There's a slightly higher chance of panic()ing
when multiple errors happen (a good thing, IMHO). If you take an MBE and
panic(), the error status bits are not cleared.
Alternatives:
None.
Testing:
I used software to inject correctable and uncorrectable errors. With
tolerant = 3, the system usually survives. With tolerant = 2, the system
usually panic()s (PCC) but not always. With tolerant = 1, the system
always panic()s. When the system panic()s, the BIOS is able to detect
that the cause of death was an MC4. I was not able to reproduce the
case of a non-PCC error in userspace, with EIPV, with (tolerant < 3).
That will be rare at best.
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
.. and adjust documentation to properly reflect options that are
x86-64 specific.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This implements new vDSO for x86-64. The concept is similar
to the existing vDSOs on i386 and PPC. x86-64 has had static
vsyscalls before, but these are not flexible enough anymore.
A vDSO is a ELF shared library supplied by the kernel that is mapped into
user address space. The vDSO mapping is randomized for each process
for security reasons.
Doing this was needed for clock_gettime, because clock_gettime
always needs a syscall fallback and having one at a fixed
address would have made buffer overflow exploits too easy to write.
The vdso can be disabled with vdso=0
It currently includes a new gettimeofday implemention and optimized
clock_gettime(). The gettimeofday implementation is slightly faster
than the one in the old vsyscall. clock_gettime is significantly faster
than the syscall for CLOCK_MONOTONIC and CLOCK_REALTIME.
The new calls are generally faster than the old vsyscall.
Advantages over the old x86-64 vsyscalls:
- Extensible
- Randomized
- Cleaner
- Easier to virtualize (the old static address range previously causes
overhead e.g. for Xen because it has to create special page tables for it)
Weak points:
- glibc support still to be written
The VM interface is partly based on Ingo Molnar's i386 version.
Includes compile fix from Joachim Deguara
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
freezing-of-tasks.txt mentions firmware issues without mentioning the use
of the new notifier API to overcome them. Here's an update.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Nigel Cunningham <nigel@nigel.suspend2.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This fixes up the usage in libsas (which are easy to miss, since they're
only in the scsi-misc tree) ... and also corrects the documentation on
the point of what these two function pointers actually return.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
