Forgot to include this with my original patch a few weeks ago...

Jean Delvare <khali@linux-fr.org> writes:
> So I'd suggest that you simply use the standard exit sequence in the
> it87 driver (the second one in your current patch). A patch for the 2.4
> driver would be appreciated as well.

OK.  I've attached a new version of the patch against linux-2.6.6.
I'll send a patch against current lm_sensors CVS removing the extra
exit command in a separate mail.

Greg KH <greg@kroah.com> writes:
> On Wed, May 12, 2004 at 04:38:03PM +0200, Bj?rn Mork wrote:
>> +	if (!it87_find(&addr)) {
>> +		printk("it87.o: new ISA address: 0x%04x\n", addr);
>
> That printk is wrong (no KERN_ level, or dev_printk() style use).
> Please fix it in your next revision of this patch.

Errh, I just added it to document my sloppyness.  It was never meant
to be in the patch I sent you.  Sorry.  Removed in the attached patch.
The style of these drivers seem to be "just working, making no noise"
so I assume informational printk's are unwanted.

This patch adds DID support for ICH6 and 6300ESB to i2c-i801.c(SMBus).
In order to add this support I needed to patch pci_ids.h with the SMBus
DID's.  To keep things orginized I renumbered the ICH6 and ESB entries
in pci_ids.h.  I then patched the piix IDE and i810 audio drivers to
reflect the updated #define's.  I also removed an error from irq.c;
there was a reference to a 6300ESB DID that does not exist.

Quoting myself:

> Mmm, I once proposed that I2C_ADAP_CLASS_SMBUS would be better renamed
> I2C_ADAP_CLASS_SENSORS (so I2C_CLASS_SENSORS now). What about that? I
> think it would be great to embed that change into your patch, so that
> the name changes only once.
>
> BTW, if HWMON is prefered to SENSORS, this is fine with me too, I
> have no strong preference.

Below is a patch that does that. I finally went for HWMON. Yes, it's
big, but it's actually nothing more than
s/I2C_CLASS_SMBUS/I2C_CLASS_HWMON/ (thanks perl -wip :)).

Attached patch implements the i2c calls in the saa7111 driver.

The driver is still compatible with old behaviour, so the zr36067 driver
(the original user of the saa7111 module) doesn't need any changes.  I'll
probably gradually make everything use DECODER_INIT instead of 0 (that was
a nice hack back then) somewhere later.

Can I just remove '0' later on? Or are there official ABI rules for
stable kernel versions?

Attached patch adds three new calls to the i2c video decoder API.  The changes
were requested by Michael (CC'ed) and approved by Gerd Knorr (v4l maintainer,
CC'ed).

Short explanation:

* INIT is a general initialization call with optional initialization data.
  Reason for this is that several i2c decoders (or general: clients) are being
  used by several adapters (main drivers), and in some cases, one adapter
  simply needs different settings than the other, either because the adapter
  is completely different or because the card was reverse engineered in a way
  that doesn't allow multiple adapters to run using the same original
  initialization data.  Michael faces such a problem right now.  Both he and
  me lack time to properly sit together and work out the exact details or a
  proper way to merge.

* VBI_BYPASS and GPIO set specific pins on the decoder.  This will be used
  in the saa7111 driver.  My driver (zr36067, original user of the saa7111
  driver) doesn't use any of this, but Michael's does.

Following a suggestion of Arthur Othieno, here is a trivial patch that
kills duplicate inclusions of config.h in four i2c bus drivers.

At first I was thinking of also removing inclusions of config.h wherever
it doesn't seem to be necessary but Eugene doesn't seem to think it's a
good idea. So I may give it a try later (in 2.7), but for now this
simple patch will be enough.

in the "[RFC|PATCH][2.6] Additional i2c adapter flags for i2c client
isolation" thread, the i2c people have  agreed that an ".class" field
should be added to struct i2c_driver.

Currently only drivers do checks for plausibility ("Is this an adapter I
can attach to?"), but adapters don't have a chance to keep drivers away
from their bus.

If both drivers and adapters provide a .class entry, the i2c-core can
easily compare them and let devices only probe on busses where they can
really exist.

Real world example: DVB i2c adapters cannot ensure that only known DVB
i2c chipsets probe their busses. Most client drivers probe every bus
they get their hands on. This will confuse some DVB i2c busses.

With the new I2C_CLASS_ALL flag it will be possible that an adapter can
request that really all drivers are probed on the adapter. On the other
hand, drivers can make sure that they get the chance to probe on every
i2c adapter out there (this is not encouraged, though)

The attached patch does the first step:
- add .class member to struct i2c_device
- remove unused .flags member from struct i2c_adapter
- rename I2C_ADAP_CLASS_xxx to I2C_CLASS_xxx (to be used both for
  drivers and adapters)
- add new I2C_CLASS_ALL and I2C_CLASS_SOUND classes
- follow these changes in the existing drivers with copy & paste

Quoting myself

> U-ho. I think I've introduced a memory leak with this patch :(
>
> For drivers that handle subclients (asb100 and w83781d on i2c), the
> sublient memory is never released if I read the code correctly. This
> is because we now free the private data on unload, assuming that it
> contains the i2c client data as well. That's true for the main i2c
> client, but not for the subclients (data == NULL so nothing is freed).
>
> Could someone take a look and confirm?

I could test and actually saw memory leaking when cycling the w83781d
driver at a sustained rate (5/s).

> I can see two different fixes:
>
> 1* When freeing the memory, free the data if it's not NULL (main
> client), else free client (subclients). Cleaner (I suppose?).
>
> 2* When creating subclients, do data = &client instead of data = NULL.
> Then freeing will work. Less code, faster. Are there side effects? (I
> don't think so)
>
> My preference would go to 2*.

I ended up implementing 1*. That's cleaner and there's actually almost
no extra code.

Mark, can you confirm that I'm doing the correct thing? I'll do
something similar in our CVS repository (for now, the asb100 and w83781d
drivers had not their memory allocation scheme reworked there).

The following patch rewrites the temperature conversion macros and
functions found in the via686a chip driver. Contrary to the voltage
conversions a few weeks ago, temperature conversions were numerically
correct, but artificially complex. The new ones are cleaner. It also
fixes a highly improbable array overflow (would take one of the measured
temperatures to be over 145 degrees C).

Successfully tested by Mark D. Studebaker and I, and already applied to
our CVS repository.

The following patch changes the way we invert beep bits for the AS99127F
sensor chip. This chip behaves differently from the other chips in that
a disabled bit is 1, not 0. So far we didn't handle that specificity in
the w83781d driver, so it was left to user-space applications to handle
it. For the sake of uniformity, it's obviously better if it's done in
the driver instead (although the meaning of each bit is still
chip-dependant).

I already did a similar change to the 2.4 driver and the sensors
program. I don't think that many user-space application will be
affected, since most of them don't handle the beep mask as far as I can
tell.

This also close Debian bug #209299:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=209299

Successfully tested on my AS99127F rev.1 chip. Aurelien Jarno also
checked that there were no regression on non-Asus chips.

Add support for the Epson 8564 RTC chip.

The 2.6 IXP4xx code has been cleaned up to change all references to
IXP42x/IXP425 with IXP4xx. The following patch updates the I2C bits.
Before applying, you need to 'bk move i2c-ixp42x.c ixp-4xx.c".

I have an I2C device (Samsung ks0127 video grabber) with a peculiar i2c
implementation.  When reading bytes, it only senses for the stop condition
in the place where the acknowledge bit should be.  So, to properly support
this device acks need to be turned off during reads.

There is an I2C_M_NO_RD_ACK bit already defined in i2c.h which appears to
be what I want.  Unfortunately it doesn't seem to be used anywhere in the
current tree.  At the end of this message is a patch to teach i2c_algo_bit
to honor the bit.

My previous patch was actually not correct, reading from the chip's
registers was fixed but writing limits to it wasn't. This new version of
the patch should be better. Sorry for the trouble.

The following patch adds support for the LM99 chip to the lm90 driver,
on popular request. The nVidia GeForce FX 5900 series cards have such a
chip on-board for monitoring the GPU temperature.

Relevant pointers:
http://archives.andrew.net.au/lm-sensors/msg07671.html
http://secure.netroedge.com/~lm78/readticket.cgi?ticket=1661
http://secure.netroedge.com/~lm78/readticket.cgi?ticket=1662

Additional effects of the patch:

* Do not consider the lm90 driver experimental anymore. I have had
enough testers and not a single problem report, the driver is working
OK.

* Support the LM89. According to the datasheets, it is exactly the same
chip as the LM99 (to the chip ID). We've never seen this chip in a
computer so far, but it doesn't cost anything to support it (actually we
cannot not support it, since we have no way to differenciate with the
LM99).

* Scan two addresses instead of one. The LM99 and LM89 have a "-1"
variant using an alternate address.

* Update copyright year.

* Reword the identification code a bit. It is hopefully slightly less
unreadable.

This patch was successfully tested by Corey Hickey.

 - Correctly handle wraparound on offset+len
 - fix FADV_WILLNEED handling of non-page-aligned (offset+len)

Let's hope we don't need to fix the fixed fix.

On sparc64 toolchain:

drivers/built-in.o(.init.text+0xaf8c): In function `usb_init':
: undefined reference to `usbfs_cleanup'

usb_init() is __init and usbfs_cleanup() is __exit.  No can do.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

Patch from Nicolas Pitre

Patch from Nicolas Pitre

... including the new PXA270 aka Bulverde.

Patch from Nicolas Pitre

Before previous patch this driver compiled OK but was buggy.
Now it doesn't compile anymore as the bogus macro has been
deleted.  Fix that in any case.

The same fix has been committed to the MTD CVS already, but please forward 
this to Linus otherwise Lubbock won't compile from kernel.org tree anymore
(waiting for dwmw2 to update this might prove ... hrm ... long) 

Patch from Nicolas Pitre

Too many macro with too generic names.  Let's remove unneeded code and
redundant/unused macros.  This also prevent namespace clash with upcoming 
patches.

Patch from Nicolas Pitre

Minor cleanup of Lubbock specific code, like removal of
redundant mappings. 
Also a prerequisite for some upcoming patches.

Patch from Nicolas Pitre

virtual address mapping can change.

The recent slab alignment changes broke an unknown number of architectures
(parisc and x86_64 for sure) by causing task_structs to be insufficiently
aligned.

We need good alignemnt because architectures do things like dumping FP state
into the task_struct with instructions which require particular alignment (I
think).

So change the default alignment to L1_CACHE_BYTES, which is what we used to
have, via SLAB_HW_CACHE_ALIGN.

This patch updates the MTD concatenating driver from MTD CVS, which
fixes issues found with this driver which concatenates multiple MTD
devices into one MTD device.

From David Woodhouse, through CVS:

	revision 1.8
	date: 2003/06/30 11:01:26;  author: dwmw2;  state: Exp;  lines: +5 -5
	I will not commit stuff whilst pissed
	I will not commit stuff whilst pissed

	revision 1.7
	date: 2003/06/29 21:26:34;  author: dwmw2;  state: Exp;  lines: +9 -9
	Fix ecc/oob subdev comparisions

	revision 1.6
	date: 2003/06/25 12:37:50;  author: dwmw2;  state: Exp;  lines: +14 -6
	Don't pretend to have {read,write}_{oob,ecc} functions if subdevices don't

	revision 1.5
	date: 2003/06/25 12:21:16;  author: dwmw2;  state: Exp;  lines: +390 -397
	coding style cleanup

into ppc970.osdl.org:/home/torvalds/v2.6/linux

POSIX sez: "If len is zero, all data following offset is specified."

From: David Gibson <david@gibson.dropbear.id.au>

The 32->64 bit syscall translation layer on ppc64 incorrectly sign-
extends rather than zero-extending the second parameter to shmget(),
which should be a size_t.  This means that it is impossible to shmget()
more 2GB or more from a 32-bit process.

From: "Randy.Dunlap" <rddunlap@osdl.org>

From: Pavel Machek <pavel@ucw.cz>

Kill uninformative boot-time message.

From: Arnd Bergmann <arnd@arndb.de>

Enable basic profiling code on s390 depending on CONFIG_PROFILING, not
CONFIG_OPROFILE.

CONFIG_PROFILING should enable the generic profiling code here, even if
CONFIG_OPROFILE is not set.  Note that the identical code on i386 is always
compiled in, regardless of CONFIG_PROFILING and CONFIG_OPROFILE.

From: Michael Hunold <hunold@convergence.de>

unfortunately it's possible to remove a DVB adapter module even if a DVB
network device has been set up using this adapter.

The attached patch fixes this problem.

From: Matt Tolentino <metolent@snoqualmie.dp.intel.com>

This trailing space in sysfs contents is not needed.

From: Trond Myklebust <trond.myklebust@fys.uio.no>

fs/nfs/direct.c: In function `nfs_direct_IO':
fs/nfs/direct.c:458: warning: int format, different type arg (arg 2)

From: Adam Belay <ambx1@neo.rr.com>

Fix http://bugme.osdl.org/show_bug.cgi?id=2540

It prevents PnP detection if devices were already detected by SuperIO.

Ensure that when we send the SETATTR call after doing an O_EXCL create,
we always set the atime and ctime fields.

See RFC1813 for details on why the server is allowed to clobber these
two fields in order to cache a verifier that protects CREATE in case of
a timeout+resend from the client.

Patch is by Olaf Kirch.