Don't rely on i2c_algorithm.id to alter the i2c adapter's id, use the
I2C_ALGO_* value directly instead, because i2c_algorithm will soon
have no id member no more.
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>

The 24RF08 corruption would better be prevented at i2c-core level than
at chip driver level, for several reasons:
* The second quick write should happen as soon as possible after the
  first one, so as to limit the risk that another command is issued on
  the bus inbetween, causing the corruption.
* As a matter of fact, the protection code at driver level was reworked
  at least three times already, which proves how hard it is to get it
  right there, while it's straightforward at i2c-core level.
* It's easy to add a new driver that would need the protection, and
  forget to add it. This did happen already.
* As additional probing addresses can be passed to most i2c chip drivers
  as module parameters, virtually every i2c chip driver would need the
  protection if we want to be really safe.
* Why duplicate code when we can easily avoid it?
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

i2c_probe was quite complex and slow, so I rewrote it in a more
efficient and hopefully clearer way.

Note that this slightly changes the way the module parameters are
handled. This shouldn't change anything for the most common cases
though.

For one thing, the function now respects the order of the parameters
for address probing. It used to always do lower addresses first. The
new approach gives the user more control.

For another, ignore addresses don't overrule probe addresses anymore.
This could have been restored the way it was at the cost of a few more
lines of code, but I don't think it's worth it. Both lists are given
as module parameters, so a user would be quite silly to specify the
same addresses in both lists. The normal addresses list is the only
one that isn't controlled by a module parameter, thus is the only one
the user may reasonably want to remove an address from.

Another significant change is the fact that i2c_probe() will no more
stop when a detection function returns -ENODEV. Just because a driver
found a chip it doesn't support isn't a valid reason to stop all
probings for this one driver. This closes the long standing lm_sensors
ticket #1807.

  http://www2.lm-sensors.nu/~lm78/readticket.cgi?ticket=1807

I updated the documentation accordingly.

In terms of algorithmic complexity, the new code is way better. If
I is the ignore address count, P the probe address count, N the
normal address count and F the force address count, the old code
was doing 128 * (F + I + P + N) iterations max, while the new code
does F + P + ((I+1) * N) iterations max. For the most common case
where F, I and P are empty, this is down from 128 * N to N.
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>

i2c_probe and i2c_detect now do the exact same thing and operate on
the same data structure, so we can have everyone call i2c_probe.
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>

The debugging messages in i2c-core are more confusing than helpful. Some
lack their trailing newline, some lack a prefix, some are redundant,
some lack precious information. Here is my attempt to introduce some
standardization in there.

I also changed two messages in i2c-dev to make it clear they come from
i2c-dev.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

I've been running with this patch for a while now, and while I've never
seen it trigger except with buggy hardware I think it is a cleaner way
to handle a busy bus. I had -EBUSY until about 10 minutes ago but -EIO
seems to be what most of the existing algo drivers will return in the
same circumstances.
Signed-off-by: NIan Campbell <icampbell@arcom.com>
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>

We could refactor the error message 34 different i2c drivers print if
i2c_detach_client() fails in this function itself. Saves quite a few
lines of code. Documentation is updated to reflect that change.

Note that this patch should be applied after Rudolf Marek's w83792d
patches.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
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>

Kill all isa-related stuff from i2c_detect, it's not used anymore.

This is one major step in the directiom of merging i2c_probe and
i2c_detect. The last obstacle I can think of is the different way forced
addresses work between sensors and non-sensors i2c drivers. I'll deal
with that in a later patchset.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

All ISA hardware monitoring drivers (including hybrid drivers) now have
a hard dependency on i2c-isa, so they must select I2C_ISA. As a result,
CONFIG_I2C_ISA doesn't need to be left visible to the user. The good
thing here is that users will stop complaining that some driver doesn't
work just because they forgot to compile or load i2c-isa.

At this point, all drivers are working again and the cleanup phase can
begin.
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>

Remove an unused local variable and change the subclient name.
Signed-off-by: NBen Gardner <bgardner@wabtec.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Move the inline function kobj_to_i2c_client() from max6875.c to i2c.h.
Signed-off-by: NBen Gardner <bgardner@wabtec.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

attached is a small patch that removes unused code from i2c-nforce2 and
adds a single debug message. The patch is against 2.6.13-rc3-mm1.
I have tested the patch with 2.6.13-rc3: compiles cleanly and works as
without the patch (as expected).
Signed-off-by: NHans-Frieder Vogt <hfvogt@arcor.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This is an update to the max6875 driver.
It no longer does any detection, so the address must be forced on module load.
It only makes available the user EEPROM (read-only).

This patch is based off 2.6.13-rc2-mm2.
Signed-off-by: NBen Gardner <bgardner@wabtec.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Compile fix for the BCM1250 I2C driver.

Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Seems that both Greg and I submitted the same patch and it just kept on
applying...

Cc: Greg KH <greg@kroah.com>
Cc: Kumar Gala <galak@freescale.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The 24RF08 corruption prevention in the eeprom and max6875 drivers wasn't
complete. For one thing, the additional quick write should happen as soon
as possible and unconditionally, while both drivers had error paths before.
For another, when a given chip is forced, the core does not emit a quick
write, so a second quick write would cause the corruption rather than
prevent it.

I plan to move the corruption prevention in the core in the long run, so
that individual drivers don't have to care anymore. But I need to merge
i2c_probe and i2c_detect before I do (work in progress).
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Two log messages lack their trailing new line in i2c-core. I'd swear I had
fixed them already, but it seems not. Bonus: improved coding style.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

A few split string in i2c (and now hwmon) drivers lack a joining space,
causing them to display incorrectly. This trivial patch fixes that up.
Please apply, thanks.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

DS1339 manual, page 6, chapter Date and time operation:
  The DS1339 can be run in either 12-hour or 24-hour mode. Bit 6 of the
  hours register is defined as the 12-hour or 24-hour mode-select bit.
  When high, the 12-hour mode is selected.

Patch below makes ds1337 driver work as documented in manual.
Signed-off-by: NLadislav Michl <ladis@linux-mips.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

I2C-MPC: Restore code removed

A previous patch to remove support for the OCP device model was way
to generious and moved some of the platform device model code, oops.
Signed-off-by: NKumar Gala <kumar.gala@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

A previous patch to remove support for the OCP device model was way to
generious and moved some of the platform device model code, oops.
Signed-off-by: NKumar Gala <kumar.gala@freescale.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Part 2: Move the driver files themselves.

Note that the patch "adds trailing whitespace", because it does move the
files as-is, and some files happen to have trailing whitespace.

From: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Part 1: Configuration files and Makefiles.

From: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

On Thu, Jun 30, 2005 at 11:47:09PM +0200, Sebastian Pigulak wrote:
> I've tried patching linux-2.6.13-RC1 with patch-2.6.13-rc1-git2 and
> building atxp1(it allows Vcore voltage changing) into the kernel.
> Unfortunately, the kernel compilation stops with:
>
> LD      init/built-in.o
> LD      vmlinux
> drivers/built-in.o(.text+0x92298): In function `atxp1_detect':
> : undefined reference to `i2c_which_vrm'
> drivers/built-in.o(.text+0x921ae): In function `atxp1_attach_adapter':
> : undefined reference to `i2c_detect'
> make: *** [vmlinux] B??d 1
> ==> ERROR: Build Failed.  Aborting...
>
> Could someone have a look at the module and possibly fix it up?

SENSORS_ATXP1 must select I2C_SENSOR.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This simple patch drops an out-of-date comment in the eeprom i2c chip
driver.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch uses the already existing IDR mechanism to simplify and
improve the i2c_get_adapter function in i2c-core.
Signed-off-by: NMark M. Hoffman <mhoffman@lightlink.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Here is a simple path fixing an incorrect kfree in the m41t00 i2c chip
driver. The current code happens to work by accident, but the freed
pointer isn't the one which was allocated in the first place, which
could cause problems later.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>