This cleans up the mismatch of ways we could enable debugging messages.

I replaced all dependancies on algos with dependancies on
I2C + select algo. There are some cases outside of the i2c subdirectory.

Also note that I slightly altered the condition to display the PCILynx
comment. I think it's more logical that way. Without it, the user could
get the message he/she needs I2C, go to enable it, come back and still
not see the option.

Here is a patch that adds a new chip driver to Linux 2.6.1 (+ previous
patches). The w83l785ts driver handles a single chipset, the Winbond
W83L785TS-S. I am the author of the original driver as found in
lm_sensors 2.8.3. Wolfgang Ziegler AKA fago made an initial port to
Linux 2.6, which I reviewed, and here it is.

Two bus drivers (i2c-via and scx200_acb.c) generate warnings when the
whole i2c subsystem is compiled with -DDEBUG. Suggested changes follow.

At the moment, i2c-core.c fails compiling with DEBUG. Following patch
should fix that.

The recent patch that fixes lm83.c with DEBUG also applies to lm90.c. No
wonder since I used the first as a template when porting the second.
Patch follows.

Basically, I divide the eeprom in 8 32-byte slices. Each of it has a
"valid" boolean (combined together into a bitfield) and a jiffies
counter. Eeprom_update_client() is added a new parameter to specify
which slice to update. Code updated accordingly. Finally, the read
function updates only slices that need to be. The code is heavily
inspired from what was done in the CVS driver, of course.

Three additional notes:

1* This fixes a bug in eeprom_update_client()'s refresh condition. We
used to check jiffies before valid, although jiffies are not defined if
valid isn't true. That was already fixed in our CVS driver but for some
reason the fix did not go into 2.6 yet.

2* This also skips the update if the read if out of bounds. I think this
is the thing to do.

3* It can be discussed wether eeprom_update_client() should take two
slice parameters instead of one (start slice, end slice). This would
make things slightly faster when consecutive slices are requested. Maybe
the code would even be clearer. It wasn't done so far because the CVS
driver wouldn't benefit from it (because the EEPROM's contents are split
over several "output" files in that version of the driver) but I'll
probably give it a try in 2.6.

Quoting myself:

> 1* Elektor depends on ISA.
> 2* ELV and Velleman do not depend on ISA.
> 3* i2c-isa is M by default, and has an additional help text
> 4* via686a autoselects i2c-isa
> 5* i2c-isa doesn't depend on ISA

Here's the patch:

Here is a patch to the eeprom driver in 2.6.1 that changes the way Vaio
eeproms are handled. In 2.6.1, the eeprom is readable only by root,
which isn't consistent with the 2.4 driver which simple hides (i.e.
fills it with zeroes) the first row (16 bytes) of the eeprom to regular
users.

The patch restores a similar behaviour in the 2.6 driver.

This patch attempts to reduce the number of inappropriate questions being
asked by menuconfig.

The following patch fixes lm83 failing to compile if DEBUG is set.

This patch fixes the temperature handling in the w83781d driver:
1* Fix bad magnitude.
2* Use MMH's lm75.h.
3* Allow negative temperatures.

This is my LM90/ADM1032 i2c chip driver ported to Linux 2.6

These are replacements for the i2c-philips-par, i2c-elv and i2c-velleman
drivers, as well as for the i2c-old i2c-parport driver as found under
drivers/media/video in linux 2.4. My reason for writing them, as already
discussed on the sensors and linux-kernel mailing-lists, is that all
these drivers basically do the same thing, so I thought it would be
easier to maintain a single driver instead of four. As Simon Vogl
pointed out that using a direct I/O access (as done in i2c-elv and
i2c-velleman) could be prefered over clean parport access (as done in
i2c-philips-par) on embedded devices, I finally wrote two drivers
instead of one. But both drivers support all devices, it's just a matter
of how they are accessed (and wether the driver depends on the parport
driver).

I made it so that the definition of the adapters (i.e. how to set and
get SDA and SCL, basically) is completely separated from the code
itself. Thus, adding support for a new adapter is simply adding a new
set of data to the definition table, describing how the adapter works,
in a single file.

This means that all simple parallel port adapters are virtually
supported. The i2c-pport driver we have in i2c CVS isn't supported yet
because it works a bit differently, but I believe that extending the
current driver(s) to support it should be possible (although it can be
discussed wether it's worth it).

You'll have to pass the type parameter that is correct for your board:
 0 = Philips
 2 = Velleman
 3 = ELV
 4 = ADM evaluation board

I could only test with my ADM eval board, and it worked OK with
both drivers. If they are confirmed to work, we could get rid of all
other parallel port i2c drivers in 2.6.
***

I think we should mark the i2c-philips-par, i2c-elv and i2c-velleman drivers as "deprecated" in i2c/busses/Kconfig. Is there a standard way to do so (like there is "&& EXPERIMENTAL" for new drivers)?

Thanks.

One more simple patch... These headers are useless as far as I can see.

Another simple patch for your collection. BTW I don't think that i2c-rpx
can be used in 2.6 since it relies on an algorithm that hasn't been
ported yet.

please apply this trivial one-liner. It fixes compilation of IBM IIC
driver.

* Jean Delvare <khali@linux-fr.org> [2004-01-09 22:58:58 +0100]:

> Shouldn't the asb100 be listed first, the same way the w83781d is, since
> it has subclients? I would even put asb100 before w83781d, since for now
> the w83781d driver will try to handle ASB100 chips too, thus preventing
> the asb100 driver from being used if both drivers are built-in.

You're right, thanks

* * * * *

This patch fixes the link order for asb100 sensors chip driver.

This patch adds support for the ASB100 Bach sensor chip, which
is found on some Asus mainboards.  The port corresponds to
lm_sensors CVS revision 1.5.  The patch applies to and was tested
against 2.6.1-rc1.

> > They should be converted.  From module.h:
> > 	/* DEPRECATED: Do not use. */
> > 	#define MODULE_PARM(var,type) 	\
> > 	...
>
> Note that realistically, it's not going away in 2.6, so mass migration
> doesn't really win anything.  However, I never implemented mixing old
> and new style in the same module, so if you're adding a parameter, it
> makes sense to convert them all.

OK, I don't have much time for a mass conversion anyway. Greg, could you
please apply the following patch to the "porting-clients" document so
that at least the new drivers don't need to be converted afterwards?

to generate the duplicate area at 0x0000 and 0x100000.

There's no downside to it, so allow it even though it's
a tad strange.

into home.osdl.org:/home/torvalds/v2.5/linux

Spotted by Matteo Croce 

into home.osdl.org:/home/torvalds/v2.5/linux

From Martin Diehl.

From Martin Diehl.

Also, make sir-dev locking compatible with irport.
From Martin Diehl.

[ATM]: br2684 incorrectly handles frames recvd with FCS (by Alex Zeffertt <ajz@cambridgebroadband.com>)