Change the /proc/sysvipc/shm|sem|msg files to use the generic seq_file
implementation for struct ipc_ids.
Signed-off-by: NMike Waychison <mikew@google.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When registering an RPC cache, cache_register() always sets the owner as the
sunrpc module.  However, there are RPC caches owned by other modules.  With
the incorrect owner setting, the real owning module can be removed potentially
with an open reference to the cache from userspace.

For example, if one were to stop the nfs server and unmount the nfsd
filesystem, the nfsd module could be removed eventhough rpc.idmapd had
references to the idtoname and nametoid caches (i.e.
/proc/net/rpc/nfs4.<cachename>/channel is still open).  This resulted in a
system panic on one of our machines when attempting to restart the nfs
services after reloading the nfsd module.

The following patch adds a 'struct module *owner' field in struct
cache_detail.  The owner is further assigned to the struct proc_dir_entry
in cache_register() so that the module cannot be unloaded while user-space
daemons have an open reference on the associated file under /proc.
Signed-off-by: NBruce Allan <bwa@us.ibm.com>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Seems pointless to require .c files to test CONFIG_PNP_DEBUG and
conditionally define DEBUG before including <linux/pnp.h>.  Just test
CONFIG_PNP_DEBUG directly in pnp.h.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Adam Belay <ambx1@neo.rr.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Newer Sony VAIO models (VGN-S480, VGN-S460, VGN-S3XP etc) use a new method to
initialize the SPIC device.  The new way to initialize (and disable) the
device comes directly from the AML code in the _CRS, _SRS and _DIS methods
from the DSDT table.  This patch adds support for the new models.
Signed-off-by: NErik Waling <erikw@acc.umu.se>
Signed-off-by: NStelian Pop <stelian@popies.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

These no longer have any users.
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

If /etc/mtab is a regular file all of the mount options (of a file system)
are written to /etc/mtab by the mount command.  The quota tools look there
for the quota strings for their operation.  If, however, /etc/mtab is a
symlink to /proc/mounts (a "good thing" in some environments) the tools
don't write anything - they assume the kernel will take care of things.

While the quota options are sent down to the kernel via the mount system
call and the file system codes handle them properly unfortunately there is
no code to echo the quota strings into /proc/mounts and the quota tools
fail in the symlink case.

The attached patchs modify the EXT[2|3] and JFS codes to add the necessary
hooks.  The show_options function of each file system in these patches
currently deal with only those things that seemed related to quotas;
especially in the EXT3 case more can be done (later?).

Jan Kara also noted the difficulty in moving these changes above the FS
codes responding similarly to myself to Andrew's comment about possible
VFS migration. Issue summary:

 - FS codes have to process the entire string of options anyway.

 - Only FS codes that use quotas must have a show_options function (for
   quotas to work properly) however quotas are only used in a small number
   of FS.

 - Since most of the quota using FS support other options these FS codes
   should have the a show_options function to show those options - and the
   quota echoing becomes virtually negligible.

Based on feedback I have modified my patches from the original:

   JFS a missing patch has been restored to the posting
   EXT[2|3] and JFS always use the show_options function
       - Each FS has at least one FS specific option displayed
       - QUOTA output is under a CONFIG_QUOTA ifdef
       - a follow-on patch will add a multitude of options for each FS
   EXT[2|3] and JFS "quota" is treated as "usrquota"
   EXT3 journalled data check for journalled quota removed
   EXT[2|3] mount when quota specified but not compiled in

 - no changes from my original patch.  I tested the patch and the codes
   warn but

 - still mount.  With all due respection I believe the comments
   otherwise were a

 - misread of the patch.  Please reread/test and comment.  XFS patch
   removed - the XFS team already made the necessary changes EXT3 mixing
   old and new quotas are handled differently (not purely exclusive)

 - if old and new quotas for the same type are used together the old
   type is silently depricated for compatability (e.g.  usrquota and
   usrjquota)

 - mixing of old and new quotas is an error (e.g.  usrjquota and
   grpquota)
Signed-off-by: NMark Bellon <mbellon@mvista.com>
Acked-by: NDave Kleikamp <shaggy@austin.ibm.com>
Cc: Jan Kara <jack@ucw.cz>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The size of auxiliary vector is fixed at 42 in linux/sched.h.  But it isn't
very obvious when looking at linux/elf.h.  This patch adds AT_VECTOR_SIZE
so that we can change it if necessary when a new vector is added.

Because of include file ordering problems, doing this necessitated the
extraction of the AT_* symbols into a standalone header file.
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

All users have been converted.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Jens:

->bi_set is totally unnecessary bloat of struct bio.  Just define a proper
destructor for the bio and it already knows what bio_set it belongs too.

Peter:

Fixed the bugs.
Signed-off-by: NJens Axboe <axboe@suse.de>
Signed-off-by: NPeter Osterlund <petero2@telia.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch contains the following cleanups:
- make needlessly global functions static
- journal.c: remove the unused global function __journal_internal_check
             and move the check to journal_init
- remove the following write-only global variable:
  - journal.c: current_journal
- remove the following unneeded EXPORT_SYMBOL:
  - journal.c: journal_recover
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Acked-by: NAndreas Dilger <adilger@clusterfs.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When I first wrote the compat layer patches, I was somewhat cavalier about
the definition of compat_uid_t and compat_gid_t (or maybe I just
misunderstood :-)).  This patch makes the compat types much more consistent
with the types we are being compatible with and hopefully will fix a few
bugs along the way.

	compat type		type in compat arch
	__compat_[ug]id_t	__kernel_[ug]id_t
	__compat_[ug]id32_t	__kernel_[ug]id32_t
	compat_[ug]id_t		[ug]id_t

The difference is that compat_uid_t is always 32 bits (for the archs we
care about) but __compat_uid_t may be 16 bits on some.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Here's the latest version of relayfs, against linux-2.6.11-mm2.  I'm hoping
you'll consider putting this version back into your tree - the previous
rounds of comment seem to have shaken out all the API issues and the number
of comments on the code itself have also steadily dwindled.

This patch is essentially the same as the relayfs redux part 5 patch, with
some minor changes based on reviewer comments.  Thanks again to Pekka
Enberg for those.  The patch size without documentation is now a little
smaller at just over 40k.  Here's a detailed list of the changes:

- removed the attribute_flags in relay open and changed it to a
  boolean specifying either overwrite or no-overwrite mode, and removed
  everything referencing the attribute flags.
- added a check for NULL names in relayfs_create_entry()
- got rid of the unnecessary multiple labels in relay_create_buf()
- some minor simplification of relay_alloc_buf() which got rid of a
  couple params
- updated the Documentation

In addition, this version (through code contained in the relay-apps tarball
linked to below, not as part of the relayfs patch) tries to make it as easy
as possible to create the cooperating kernel/user pieces of a typical and
common type of logging application, one where kernel logging is kicked off
when a user space data collection app starts and stops when the collection
app exits, with the data being automatically logged to disk in between.  To
create this type of application, you basically just include a header file
(relay-app.h, included in the relay-apps tarball) in your kernel module,
define a couple of callbacks and call an initialization function, and on
the user side call a single function that sets up and continuously monitors
the buffers, and writes data to files as it becomes available.  Channels
are created when the collection app is started and destroyed when it exits,
not when the kernel module is inserted, so different channel buffer sizes
can be specified for each separate run via command-line options.  See the
README in the relay-apps tarball for details.

Also included in the relay-apps tarball are a couple examples
demonstrating how you can use this to create quick and dirty kernel
logging/debugging applications.  They are:

- tprintk, short for 'tee printk', which temporarily puts a kprobe on
  printk() and writes a duplicate stream of printk output to a relayfs
  channel.  This could be used anywhere there's printk() debugging code
  in the kernel which you'd like to exercise, but would rather not have
  your system logs cluttered with debugging junk.  You'd probably want
  to kill klogd while you do this, otherwise there wouldn't be much
  point (since putting a kprobe on printk() doesn't change the output
  of printk()).  I've used this method to temporarily divert the packet
  logging output of the iptables LOG target from the system logs to
  relayfs files instead, for instance.

- klog, which just provides a printk-like formatted logging function
  on top of relayfs.  Again, you can use this to keep stuff out of your
  system logs if used in place of printk.

The example applications can be found here:

http://prdownloads.sourceforge.net/dprobes/relay-apps.tar.gz?download

From: Christoph Hellwig <hch@lst.de>

  avoid lookup_hash usage in relayfs
Signed-off-by: NTom Zanussi <zanussi@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NNishanth Aravamudan <nacc@us.ibm.com>
Signed-Off-By: NMatthias Urlichs <smurf@smurf.noris.de>
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NIngo 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: NYoichi Yuasa <yuasa@hh.iij4u.or.jp>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NAshok Raj <ashok.raj@intel.com>
Acked-by: NZwane Mwaikambo <zwane@holomorphy.com>
Grudgingly-acked-by: NAndi Kleen <ak@muc.de>
Signed-off-by: NCoywolf Qi Hunt <coywolf@lovecn.org>
Signed-off-by: NAshok Raj <ashok.raj@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NJames Bottomley <James.Bottomley@SteelEye.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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.hSigned-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Delete an outdated comment about i2c_algorithm.id being computed
from algo->id.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There are no more users of i2c_algorithm.id, so we can finally drop
this structure member.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Delete DEFAULT_VRM from hwmon-vid.h, it has no more users.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NJean Delvare <khali@linux-fr>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The i2c_detect function has no more user, delete it.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Move SENSORS_LIMIT from i2c-sensor.h to hwmon.h, as it is in no way
related to i2c.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NRudolf Marek <r.marek@sh.cvut.cz>
Signed-off-by: NChunhao Huang <DZShen@Winbond.com.tw>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NGreg Kroah-Hartman <gregkh@suse.de>

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: NGreg Kroah-Hartman <gregkh@suse.de>

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: NGreg Kroah-Hartman <gregkh@suse.de>

Temporarily export a few structures and functions from i2c-core, because we
will soon need them in i2c-isa.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>