This is an attempt to describe how the I2C support in Linux 2.6 is being developed.
Updated 2008-04-25
We have set up an i2c mailing list. Everything related to I2C support in Linux should be discussed there. If you want to be involved in the development of the I2C support in Linux, or want to help somehow, please subscribe. Note that you do not need to be subscribed in order to post on this list.
As is usually the case for open-source development lists, the following rules apply: no binary attachments, no large attachments, no HTML mail, inline patches are preferred (but not mandatory), remember that most people are contributing on their free time.
There is no web site dedicated to the Linux 2.6 I2C development effort.
Bugs can be reported in bugzilla (category Drivers, component I2C), or directly on the i2c mailing list.
Proposed fixes and improvements should be posted to the i2c mailing list, as patches against either the latest Linus' tree or the latest -mm tree. Some i2c drivers have a dedicated maintainer, so check the MAINTAINERS file first and make sure to include the dedicated maintainer in the discussion if there is one. That person is much more likely to be able to help as he/she knows his/her driver better.
If you want to contribute a new I2C bus driver, please first make sure that support doesn't exist for it yet. We don't want to maintain two I2C bus drivers for the same hardware.
General-purpose I2C bus drivers live under drivers/i2c/busses, documentation for these is under Documentation/i2c/busses. There is no guide available on how to write a new I2C bus driver, so the easiest way is to read the code of another driver (preferably for a device not too different from yours) and do something similar in your own driver.
If your I2C bus is software-driven, you don't have to write a full-fledged I2C bus driver. We have a generic driver (i2c-algo-bit) for bit-banged I2C, on top of which your driver can be built quickly.
New I2C bus drivers should be posted as patches, including changes to the Kconfig and Makefile files.
I2C chip drivers are, in general, better handled by dedicated groups:
Only drivers which don't fit in any of these categories should be posted to, and discussed on, the i2c mailing list.
Added 2008-04-25
It is highly recommended that you find someone willing to do a first public review of your patch, just to get the most obvious problems cleared up. The person doesn't need to be an i2c expert (although if you can find one, even better.) As a rule of thumb, the easier you make it for the busy kernel maintainers, the more likely they are to review and merge your patch quickly.
Once a patch has been accepted, you get to wait for the merge window of the next kernel version. The merge window lasts for 2 weeks after the previous kernel version has been released. In the meantime, pending i2c patches are maintained as a patch series using quilt. These patches are included in Andrew Morton's -mm kernels. This gives them some additional testing, and as a result, patches may be adjusted or even rejected if problems are reported.
When the merge window opens, the pending patch series is converted to a temporary git tree, from which Linus pulls. A summary of the pulled patches is posted to the i2c mailing list.
That repository holds a modified version of the Linux 2.4 i2c subsystem, which was needed to use lm-sensors on Linux 2.4. It has nothing to do with the current i2c developments. For Linux 2.6, the development happens directly in the Linux kernel tree, there is no external repository.
Updated 2007-10-19
The i2c user-space tools have been part of the lm-sensors package for a long time, but they now have their own SVN development tree and package, surprisingly named i2c-tools.