Commit graph

2197 commits

Author SHA1 Message Date
Ingo Molnar
8446f1d391 [PATCH] detect soft lockups
This patch adds a new kernel debug feature: CONFIG_DETECT_SOFTLOCKUP.

When enabled then per-CPU watchdog threads are started, which try to run
once per second.  If they get delayed for more than 10 seconds then a
callback from the timer interrupt detects this condition and prints out a
warning message and a stack dump (once per lockup incident).  The feature
is otherwise non-intrusive, it doesnt try to unlock the box in any way, it
only gets the debug info out, automatically, and on all CPUs affected by
the lockup.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-Off-By: Matthias Urlichs <smurf@smurf.noris.de>
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-07 16:57:17 -07:00
Jakub Jelinek
4732efbeb9 [PATCH] FUTEX_WAKE_OP: pthread_cond_signal() speedup
ATM pthread_cond_signal is unnecessarily slow, because it wakes one waiter
(which at least on UP usually means an immediate context switch to one of
the waiter threads).  This waiter wakes up and after a few instructions it
attempts to acquire the cv internal lock, but that lock is still held by
the thread calling pthread_cond_signal.  So it goes to sleep and eventually
the signalling thread is scheduled in, unlocks the internal lock and wakes
the waiter again.

Now, before 2003-09-21 NPTL was using FUTEX_REQUEUE in pthread_cond_signal
to avoid this performance issue, but it was removed when locks were
redesigned to the 3 state scheme (unlocked, locked uncontended, locked
contended).

Following scenario shows why simply using FUTEX_REQUEUE in
pthread_cond_signal together with using lll_mutex_unlock_force in place of
lll_mutex_unlock is not enough and probably why it has been disabled at
that time:

The number is value in cv->__data.__lock.
        thr1            thr2            thr3
0       pthread_cond_wait
1       lll_mutex_lock (cv->__data.__lock)
0       lll_mutex_unlock (cv->__data.__lock)
0       lll_futex_wait (&cv->__data.__futex, futexval)
0                       pthread_cond_signal
1                       lll_mutex_lock (cv->__data.__lock)
1                                       pthread_cond_signal
2                                       lll_mutex_lock (cv->__data.__lock)
2                                         lll_futex_wait (&cv->__data.__lock, 2)
2                       lll_futex_requeue (&cv->__data.__futex, 0, 1, &cv->__data.__lock)
                          # FUTEX_REQUEUE, not FUTEX_CMP_REQUEUE
2                       lll_mutex_unlock_force (cv->__data.__lock)
0                         cv->__data.__lock = 0
0                         lll_futex_wake (&cv->__data.__lock, 1)
1       lll_mutex_lock (cv->__data.__lock)
0       lll_mutex_unlock (cv->__data.__lock)
          # Here, lll_mutex_unlock doesn't know there are threads waiting
          # on the internal cv's lock

Now, I believe it is possible to use FUTEX_REQUEUE in pthread_cond_signal,
but it will cost us not one, but 2 extra syscalls and, what's worse, one of
these extra syscalls will be done for every single waiting loop in
pthread_cond_*wait.

We would need to use lll_mutex_unlock_force in pthread_cond_signal after
requeue and lll_mutex_cond_lock in pthread_cond_*wait after lll_futex_wait.

Another alternative is to do the unlocking pthread_cond_signal needs to do
(the lock can't be unlocked before lll_futex_wake, as that is racy) in the
kernel.

I have implemented both variants, futex-requeue-glibc.patch is the first
one and futex-wake_op{,-glibc}.patch is the unlocking inside of the kernel.
 The kernel interface allows userland to specify how exactly an unlocking
operation should look like (some atomic arithmetic operation with optional
constant argument and comparison of the previous futex value with another
constant).

It has been implemented just for ppc*, x86_64 and i?86, for other
architectures I'm including just a stub header which can be used as a
starting point by maintainers to write support for their arches and ATM
will just return -ENOSYS for FUTEX_WAKE_OP.  The requeue patch has been
(lightly) tested just on x86_64, the wake_op patch on ppc64 kernel running
32-bit and 64-bit NPTL and x86_64 kernel running 32-bit and 64-bit NPTL.

With the following benchmark on UP x86-64 I get:

for i in nptl-orig nptl-requeue nptl-wake_op; do echo time elf/ld.so --library-path .:$i /tmp/bench; \
for j in 1 2; do echo ( time elf/ld.so --library-path .:$i /tmp/bench ) 2>&1; done; done
time elf/ld.so --library-path .:nptl-orig /tmp/bench
real 0m0.655s user 0m0.253s sys 0m0.403s
real 0m0.657s user 0m0.269s sys 0m0.388s
time elf/ld.so --library-path .:nptl-requeue /tmp/bench
real 0m0.496s user 0m0.225s sys 0m0.271s
real 0m0.531s user 0m0.242s sys 0m0.288s
time elf/ld.so --library-path .:nptl-wake_op /tmp/bench
real 0m0.380s user 0m0.176s sys 0m0.204s
real 0m0.382s user 0m0.175s sys 0m0.207s

The benchmark is at:
http://sourceware.org/ml/libc-alpha/2005-03/txt00001.txt
Older futex-requeue-glibc.patch version is at:
http://sourceware.org/ml/libc-alpha/2005-03/txt00002.txt
Older futex-wake_op-glibc.patch version is at:
http://sourceware.org/ml/libc-alpha/2005-03/txt00003.txt
Will post a new version (just x86-64 fixes so that the patch
applies against pthread_cond_signal.S) to libc-hacker ml soon.

Attached is the kernel FUTEX_WAKE_OP patch as well as a simple-minded
testcase that will not test the atomicity of the operation, but at least
check if the threads that should have been woken up are woken up and
whether the arithmetic operation in the kernel gave the expected results.

Acked-by: Ingo Molnar <mingo@redhat.com>
Cc: Ulrich Drepper <drepper@redhat.com>
Cc: Jamie Lokier <jamie@shareable.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-07 16:57:17 -07:00
Ashok Raj
54d5d42404 [PATCH] x86/x86_64: deferred handling of writes to /proc/irqxx/smp_affinity
When handling writes to /proc/irq, current code is re-programming rte
entries directly. This is not recommended and could potentially cause
chipset's to lockup, or cause missing interrupts.

CONFIG_IRQ_BALANCE does this correctly, where it re-programs only when the
interrupt is pending. The same needs to be done for /proc/irq handling as well.
Otherwise user space irq balancers are really not doing the right thing.

- Changed pending_irq_balance_cpumask to pending_irq_migrate_cpumask for
  lack of a generic name.
- added move_irq out of IRQ_BALANCE, and added this same to X86_64
- Added new proc handler for write, so we can do deferred write at irq
  handling time.
- Display of /proc/irq/XX/smp_affinity used to display CPU_MASKALL, instead
  it now shows only active cpu masks, or exactly what was set.
- Provided a common move_irq implementation, instead of duplicating
  when using generic irq framework.

Tested on i386/x86_64 and ia64 with CONFIG_PCI_MSI turned on and off.
Tested UP builds as well.

MSI testing: tbd: I have cards, need to look for a x-over cable, although I
did test an earlier version of this patch.  Will test in a couple days.

Signed-off-by: Ashok Raj <ashok.raj@intel.com>
Acked-by: Zwane Mwaikambo <zwane@holomorphy.com>
Grudgingly-acked-by: Andi Kleen <ak@muc.de>
Signed-off-by: Coywolf Qi Hunt <coywolf@lovecn.org>
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-07 16:57:15 -07:00
Jeff Garzik
bbeec90b98 [wireless] build fixes after merging WE-19 2005-09-07 00:27:54 -04:00
Jean Tourrilhes
6582c164f2 [PATCH] WE-19 for kernel 2.6.13
Hi Jeff,

	This is version 19 of the Wireless Extensions. It was supposed
to be the fallback of the WPA API changes, but people seem quite happy
about it (especially Jouni), so the patch is rather small.
	The patch has been fully tested with 2.6.13 and various
wireless drivers, and is in its final version. Would you mind pushing
that into Linus's kernel so that the driver and the apps can take
advantage ot it ?

	It includes :
	o iwstat improvement (explicit dBm). This is the result of
long discussions with Dan Williams, the authors of
NetworkManager. Thanks to him for all the fruitful feedback.
	o remove pointer from event stream. I was not totally sure if
this pointer was 32-64 bits clean, so I'd rather remove it and be at
peace with it.
	o remove linux header from wireless.h. This has long been
requested by people writting user space apps, now it's done, and it
was not even painful.
	o final deprecation of spy_offset. You did not like it, it's
now gone for good.
	o Start deprecating dev->get_wireless_stats -> debloat netdev
	o Add "check" version of event macros for ieee802.11
stack. Jiri Benc doesn't like the current macros, we aim to please ;-)
	All those changes, except the last one, have been bit-roting on
my web pages for a while...

	Patches for most kernel drivers will follow. Patches for the
Orinoco and the HostAP drivers have been sent to their respective
maintainers.

	Have fun...

	Jean
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-09-06 22:40:24 -04:00
Jens Osterkamp
aaec0fab5f [PATCH] net: add driver for the NIC on Cell Blades
This patch adds a driver for a new 1000 Mbit ethernet NIC.  It is
integrated on the south bridge that is used for our Cell Blades.

The code gets the MAC address from the Open Firmware device tree, so it
won't compile on platforms other than ppc64.

This is the first public release, so I don't expect the first version to
get merged, but I'd aim for integration within the 2.6.13 time frame.

Cc: Utz Bacher <utz.bacher@de.ibm.com>
Signed-off-by: Arnd Bergmann <arndb@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-09-06 22:17:49 -04:00
James Bottomley
17fa53da12 Merge by hand (conflicts in sd.c) 2005-09-06 17:52:54 -05:00
Stephen Hemminger
f2c383988d [NET]: skb_get/set_timestamp use const
The new timestamp get/set routines should have const attribute
on parameters (helps to indicate direction).

Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-06 15:48:03 -07:00
Pablo Neira Ayuso
49719eb355 [NETFILTER]: kill __ip_ct_expect_unlink_destroy
The following patch kills __ip_ct_expect_unlink_destroy and export
unlink_expect as ip_ct_unlink_expect. As it was discussed [1], the function
__ip_ct_expect_unlink_destroy is a bit confusing so better do the following
sequence: ip_ct_destroy_expect and ip_conntrack_expect_put.

[1] https://lists.netfilter.org/pipermail/netfilter-devel/2005-August/020794.html

Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-06 15:10:46 -07:00
Patrick McHardy
03486a4f83 [NETFILTER]: Handle NAT module load race
When the NAT module is loaded when connections are already confirmed
it must not change their tuples anymore. This is especially important
with CONFIG_NETFILTER_DEBUG, the netfilter listhelp functions will
refuse to remove an entry from a list when it can not be found on
the list, so when a changed tuple hashes to a new bucket the entry
is kept in the list until and after the conntrack is freed.

Allocate the exact conntrack tuple for NAT for already confirmed
connections or drop them if that fails.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-06 15:09:43 -07:00
Patrick McHardy
2248bcfcd8 [NETFILTER]: Add support for permanent expectations
A permanent expectation exists until timeing out and can expect
multiple related connections.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-06 15:06:42 -07:00
David S. Miller
93c37f2921 [SERIAL]: Avoid 'statement with no effect' warnings.
When SUPPORT_SYSRQ is false, gcc can emit warnings for
the uart_handle_sysrq_char() that results.  Using an
empty inline returning zero kills the warning.

Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-06 13:57:08 -07:00
Linus Torvalds
f65e77693a Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6 2005-09-06 00:32:12 -07:00
James Bottomley
d856f1e337 [PATCH] klist: fix klist to have the same klist_add semantics as list_head
at the moment, the list_head semantics are

list_add(node, head)

whereas current klist semantics are

klist_add(head, node)

This is bound to cause confusion, and since klist is the newcomer, it
should follow the list_head semantics.

I also added missing include guards to klist.h

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 16:03:13 -07:00
Jean Delvare
77ae84554c [PATCH] I2C: Drop the I2C_ACK_TEST ioctl
Drop the I2C_ACK_TEST ioctl, which was commented out. It never really
existed (not after 1999 anyway), and there is no such thing as a ack
test on I2C/SMBus anyway.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:26:56 -07:00
4e0c64cfc1 Merge HEAD from gregkh@master.kernel.org:/pub/scm/linux/kernel/git/gregkh/i2c-2.6.git 2005-09-05 09:20:31 -07:00
Jean Delvare
fae91e72b7 [PATCH] I2C: Drop I2C_DEVNAME and i2c_clientname
I2C_DEVNAME and i2c_clientname were introduced in 2.5.68 [1] to help
media/video driver authors who wanted their code to be compatible with
both Linux 2.4 and 2.6. The cause of the incompatibility has gone since
[2], so I think we can get rid of them, as they tend to make the code
harder to read and longer to preprocess/compile for no more benefit.

I'd hope nobody seriously attempts to keep media/video driver compatible
across Linux trees anymore, BTW.

[1] http://marc.theaimsgroup.com/?l=linux-kernel&m=104930186524598&w=2
[2] http://www.linuxhq.com/kernel/v2.6/0-test3/include/linux/i2c.h

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:35 -07:00
Jean Delvare
020789e9cb [PATCH] I2C: Outdated i2c_adapter comment
Delete an outdated comment about i2c_algorithm.id being computed
from algo->id.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:33 -07:00
Jean Delvare
c2459cf257 [PATCH] I2C: Kill i2c_algorithm.id (7/7)
The I2C_ALGO_* constants have no more users, delete them. Also update
the comments in i2c-id.h so that they reflect the current state of the
file.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:33 -07:00
Jean Delvare
1684a98430 [PATCH] I2C: Kill i2c_algorithm.id (6/7)
In theory, there should be no more users of I2C_ALGO_* at this point.
However, it happens that several drivers were using I2C_ALGO_* for
adapter ids, so we need to correct these before we can get rid of all
the I2C_ALGO_* definitions.

Note that this also fixes a bug in media/video/tvaudio.c:

	/* don't attach on saa7146 based cards,
	   because dedicated drivers are used */
	if ((adap->id & I2C_ALGO_SAA7146))
		return 0;

This test was plain broken, as it would succeed for many more adapters
than just the saa7146: any those id would share at least one bit with
the saa7146 id. We are really lucky that the few other adapters we want
this driver to work with did not fulfill that condition.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:32 -07:00
Jean Delvare
c7a46533ff [PATCH] I2C: Kill i2c_algorithm.id (5/7)
Merge the algorithm id part (16 upper bits) of the i2c adapters ids
into the definition of the adapters ids directly. After that, we don't
need to OR both ids together for each i2c_adapter structure.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:31 -07:00
Jean Delvare
1d8b9e1bad [PATCH] I2C: Kill i2c_algorithm.id (4/7)
There are no more users of i2c_algorithm.id, so we can finally drop
this structure member.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:29 -07:00
Jean Delvare
e51cc6b3a3 [PATCH] I2C: Kill i2c_algorithm.id (2/7)
Use the adapter id rather than the algorithm id to detect the i2c-isa
pseudo-adapter. This saves one level of dereferencing, and the
algorithm ids will soon be gone anyway.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:28 -07:00
Jean Delvare
975185880d [PATCH] I2C: Kill i2c_algorithm.name (1/7)
The name member of the i2c_algorithm is never used, although all
drivers conscientiously fill it. We can drop it completely, this
structure doesn't need to have a name.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:27 -07:00
Jean Delvare
d0f282706d [PATCH] hwmon: hwmon vs i2c, second round (10/11)
I see very little reason why vid_from_reg is inlined. It is not
exactly short, its parameters are seldom known in advance, and it is
never called in speed critical areas. Uninlining it should cause
little performance loss if any, and saves a signficant space as well
as compilation time.

As suggested by Alexey Dobriyan, I am leaving vid_to_reg inline for now,
as it is short and has a single user so far.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:23 -07:00
Jean Delvare
ee70d3a333 [PATCH] hwmon: hwmon vs i2c, second round (09/11)
Delete DEFAULT_VRM from hwmon-vid.h, it has no more users.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:23 -07:00
Jean Delvare
303760b44a [PATCH] hwmon: hwmon vs i2c, second round (07/11)
The only part left in i2c-sensor is the VRM/VRD/VID handling code.
This is in no way related to i2c, so it doesn't belong there. Move
the code to hwmon, where it belongs.

Note that not all hardware monitoring drivers do VRM/VRD/VID
operations, so less drivers depend on hwmon-vid than there were
depending on i2c-sensor.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:22 -07:00
Jean Delvare
f4b5026120 [PATCH] hwmon: hwmon vs i2c, second round (06/11)
The only thing left in i2c-sensor.h are module parameter definition
macros. It's only an extension of what i2c.h offers, and this extension
is not sensors-specific. As a matter of fact, a few non-sensors drivers
use them. So we better merge them in i2c.h, and get rid of i2c-sensor.h
altogether.

Signed-off-by: Jean Delvare <khali@linux-fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:21 -07:00
Jean Delvare
96478ef3f3 [PATCH] hwmon: hwmon vs i2c, second round (05/11)
The i2c_detect function has no more user, delete it.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:20 -07:00
Jean Delvare
b78ec31582 [PATCH] hwmon: hwmon vs i2c, second round (03/11)
We now have two identical structures, i2c_address_data in i2c-sensor.h
and i2c_client_address_data in i2c.h. We can kill one of them, I choose
to keep the one in i2c.h as it makes more sense (this structure is not
specific to sensors.)

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:19 -07:00
Jean Delvare
ef8dec5d8b [PATCH] hwmon: hwmon vs i2c, second round (02/11)
The way i2c-sensor handles forced addresses could be optimized. It
defines a structure (i2c_force_data) to associate a module parameter
with a given kind value, but in fact this kind value is always the
index of the structure in each array it is used in. So this additional
value can be omitted, and still be deduced in the code handling these
arrays.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:18 -07:00
Jean Delvare
9fc6adfa9a [PATCH] hwmon: hwmon vs i2c, second round (01/11)
Add support for kind-forced addresses to i2c_probe, like i2c_detect
has for (essentially) hardware monitoring drivers.

Note that this change will slightly increase the size of the drivers
using I2C_CLIENT_INSMOD, with no immediate benefit. This is a
requirement if we want to merge i2c_probe and i2c_detect though, and
seems a reasonable price to pay in comparison with the previous
cleanups which saved much more than that (such as the i2c-isa cleanup
or the i2c address ranges removal.)

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:18 -07:00
Jean Delvare
53ae11b083 [PATCH] hwmon: move SENSORS_LIMIT to hwmon.h
Move SENSORS_LIMIT from i2c-sensor.h to hwmon.h, as it is in no way
related to i2c.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:17 -07:00
Jean Delvare
cdcb192197 [PATCH] I2C: inline i2c_adapter_id
We could inline i2c_adapter_id, as it is really, really short. Doing
so saves a few bytes both in i2c-core and in the drivers using this
function.

                                            before     after      diff
drivers/hwmon/adm1026.ko                     41344     41305       -39
drivers/hwmon/asb100.ko                      27325     27246       -79
drivers/hwmon/gl518sm.ko                     20824     20785       -39
drivers/hwmon/it87.ko                        26419     26380       -39
drivers/hwmon/lm78.ko                        21424     21385       -39
drivers/hwmon/lm85.ko                        41034     40939       -95
drivers/hwmon/w83781d.ko                     39561     39514       -47
drivers/hwmon/w83792d.ko                     32979     32932       -47
drivers/i2c/i2c-core.ko                      24708     24531      -177

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:15 -07:00
R.Marek@sh.cvut.cz
5563e27d3a [PATCH] I2C: W83792D driver 1/3
I would like to announce support for W83792D chip. This driver was developed
by Winbond Electronics Corp. I added sysfs attributes callbacks infrastructure
plus various code fixes and codingstyle cleanups. I would like to thank Winbond
for supporting free software.

This patch is against 2.6.13rc3 plus hwmon-class and hwmon-split.
Separate patch for documantation and hwmon class register will follow.

Signed-off-by: Rudolf Marek <r.marek@sh.cvut.cz>
Signed-off-by: Chunhao Huang <DZShen@Winbond.com.tw>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:13 -07:00
Jean Delvare
570aefc361 [PATCH] I2C: Separate non-i2c hwmon drivers from i2c-core (9/9)
Move the definitions of i2c_is_isa_client and i2c_is_isa_adapter from
i2c.h to i2c-isa.h. Only hybrid drivers still need them.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:12 -07:00
Jean Delvare
5071860aba [PATCH] I2C: Separate non-i2c hwmon drivers from i2c-core (7/9)
Kill normal_isa in header files, documentation and all chip drivers, as
it is no more used.

normal_i2c could be renamed to normal, but I decided not to do so at the
moment, so as to limit the number of changes. This might be done later
as part of the i2c_probe/i2c_detect merge.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:12 -07:00
Jean Delvare
400c455eaa [PATCH] I2C: Separate non-i2c hwmon drivers from i2c-core (2/9)
Convert i2c-isa from a dumb i2c_adapter into a pseudo i2c-core for ISA
hardware monitoring drivers. The isa i2c_adapter is no more registered
with i2c-core, drivers have to explicitely connect to it using the new
i2c_isa_{add,del}_driver interface.

At this point, all ISA chip drivers are useless, because they still
register with i2c-core in the hope i2c-isa is registered there as well,
but it isn't anymore.

The fake bus will be named i2c-9191 in sysfs. This is the number it
already had internally in various places, so it's not exactly new,
except that now the number is seen in userspace as well. This shouldn't
be a problem until someone really has 9192 I2C busses in a given system
;)

The fake bus will no more show in "i2cdetect -l", as it won't be seen by
i2c-dev anymore (not being registered with i2c-core), which is a good
thing, as i2cdetect/i2cdump/i2cset cannot operate on this fake bus
anyway.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:09 -07:00
Jean Delvare
efde723fda [PATCH] I2C: Separate non-i2c hwmon drivers from i2c-core (1/9)
Temporarily export a few structures and functions from i2c-core, because we
will soon need them in i2c-isa.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:09 -07:00
Mark M. Hoffman
1236441f38 [PATCH] I2C hwmon: hwmon sysfs class
This patch adds the sysfs class "hwmon" for use by hardware monitoring
(sensors) chip drivers.  It also fixes up the related Kconfig/Makefile
bits.

Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:07 -07:00
bgardner@wabtec.com
a61fc683ae [PATCH] I2C: add kobj_to_i2c_client
Move the inline function kobj_to_i2c_client() from max6875.c to i2c.h.

Signed-off-by: Ben Gardner <bgardner@wabtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-05 09:14:05 -07:00
Linus Torvalds
94f8c66e5e Merge branch 'upstream' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev 2005-09-05 05:50:36 -07:00
Jeff Garzik
d0bd99299b /spare/repo/libata-dev branch 'iomap-try3' 2005-09-05 05:20:33 -04:00
Jeff Garzik
586a4ac509 /spare/repo/libata-dev branch 'master' 2005-09-05 05:16:50 -04:00
Jeff Garzik
a9053d0494 /spare/repo/libata-dev branch 'master' 2005-09-05 05:14:25 -04:00
Linus Torvalds
da1f136c26 Merge master.kernel.org:/home/rmk/linux-2.6-mmc 2005-09-05 00:18:09 -07:00
Linus Torvalds
48467641bc Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 2005-09-05 00:11:50 -07:00
Bodo Stroesser
1b38f0064e [PATCH] Uml support: add PTRACE_SYSEMU_SINGLESTEP option to i386
This patch implements the new ptrace option PTRACE_SYSEMU_SINGLESTEP, which
can be used by UML to singlestep a process: it will receive SINGLESTEP
interceptions for normal instructions and syscalls, but syscall execution will
be skipped just like with PTRACE_SYSEMU.

Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-05 00:06:20 -07:00
Laurent Vivier
ed75e8d580 [PATCH] UML Support - Ptrace: adds the host SYSEMU support, for UML and general usage
Jeff Dike <jdike@addtoit.com>,
      Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it>,
      Bodo Stroesser <bstroesser@fujitsu-siemens.com>

Adds a new ptrace(2) mode, called PTRACE_SYSEMU, resembling PTRACE_SYSCALL
except that the kernel does not execute the requested syscall; this is useful
to improve performance for virtual environments, like UML, which want to run
the syscall on their own.

In fact, using PTRACE_SYSCALL means stopping child execution twice, on entry
and on exit, and each time you also have two context switches; with SYSEMU you
avoid the 2nd stop and so save two context switches per syscall.

Also, some architectures don't have support in the host for changing the
syscall number via ptrace(), which is currently needed to skip syscall
execution (UML turns any syscall into getpid() to avoid it being executed on
the host).  Fixing that is hard, while SYSEMU is easier to implement.

* This version of the patch includes some suggestions of Jeff Dike to avoid
  adding any instructions to the syscall fast path, plus some other little
  changes, by myself, to make it work even when the syscall is executed with
  SYSENTER (but I'm unsure about them). It has been widely tested for quite a
  lot of time.

* Various fixed were included to handle the various switches between
  various states, i.e. when for instance a syscall entry is traced with one of
  PT_SYSCALL / _SYSEMU / _SINGLESTEP and another one is used on exit.
  Basically, this is done by remembering which one of them was used even after
  the call to ptrace_notify().

* We're combining TIF_SYSCALL_EMU with TIF_SYSCALL_TRACE or TIF_SINGLESTEP
  to make do_syscall_trace() notice that the current syscall was started with
  SYSEMU on entry, so that no notification ought to be done in the exit path;
  this is a bit of a hack, so this problem is solved in another way in next
  patches.

* Also, the effects of the patch:
"Ptrace - i386: fix Syscall Audit interaction with singlestep"
are cancelled; they are restored back in the last patch of this series.

Detailed descriptions of the patches doing this kind of processing follow (but
I've already summed everything up).

* Fix behaviour when changing interception kind #1.

  In do_syscall_trace(), we check the status of the TIF_SYSCALL_EMU flag
  only after doing the debugger notification; but the debugger might have
  changed the status of this flag because he continued execution with
  PTRACE_SYSCALL, so this is wrong.  This patch fixes it by saving the flag
  status before calling ptrace_notify().

* Fix behaviour when changing interception kind #2:
  avoid intercepting syscall on return when using SYSCALL again.

  A guest process switching from using PTRACE_SYSEMU to PTRACE_SYSCALL
  crashes.

  The problem is in arch/i386/kernel/entry.S.  The current SYSEMU patch
  inhibits the syscall-handler to be called, but does not prevent
  do_syscall_trace() to be called after this for syscall completion
  interception.

  The appended patch fixes this.  It reuses the flag TIF_SYSCALL_EMU to
  remember "we come from PTRACE_SYSEMU and now are in PTRACE_SYSCALL", since
  the flag is unused in the depicted situation.

* Fix behaviour when changing interception kind #3:
  avoid intercepting syscall on return when using SINGLESTEP.

  When testing 2.6.9 and the skas3.v6 patch, with my latest patch and had
  problems with singlestepping on UML in SKAS with SYSEMU.  It looped
  receiving SIGTRAPs without moving forward.  EIP of the traced process was
  the same for all SIGTRAPs.

What's missing is to handle switching from PTRACE_SYSCALL_EMU to
PTRACE_SINGLESTEP in a way very similar to what is done for the change from
PTRACE_SYSCALL_EMU to PTRACE_SYSCALL_TRACE.

I.e., after calling ptrace(PTRACE_SYSEMU), on the return path, the debugger is
notified and then wake ups the process; the syscall is executed (or skipped,
when do_syscall_trace() returns 0, i.e.  when using PTRACE_SYSEMU), and
do_syscall_trace() is called again.  Since we are on the return path of a
SYSEMU'd syscall, if the wake up is performed through ptrace(PTRACE_SYSCALL),
we must still avoid notifying the parent of the syscall exit.  Now, this
behaviour is extended even to resuming with PTRACE_SINGLESTEP.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-05 00:06:20 -07:00
Pavel Machek
ca078bae81 [PATCH] swsusp: switch pm_message_t to struct
This adds type-checking to pm_message_t, so that people can't confuse it
with int or u32.  It also allows us to fix "disk yoyo" during suspend (disk
spinning down/up/down).

[We've tried that before; since that cpufreq problems were fixed and I've
tried make allyes config and fixed resulting damage.]

Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Alexander Nyberg <alexn@telia.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-05 00:06:16 -07:00