View source for Linux 2.6 I2C development FAQ

This is an attempt to describe how the I2C support in Linux 2.6 is being developed.

== Mailing list ==

We have set up an [http://vger.kernel.org/vger-lists.html#linux-i2c 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.



== Bugs, fixes and improvements ==

Bugs can be reported in [http://bugzilla.kernel.org/enter_bug.cgi?product=Drivers&component=I2C bugzilla] (product Drivers, component I2C), or directly on the [http://vger.kernel.org/vger-lists.html#linux-i2c i2c mailing list].

Proposed fixes and improvements should be posted to the mailing list, as patches against either the latest Linus' tree or the latest linux-next tree. Some i2c drivers have a dedicated maintainer, so check the MAINTAINERS file first (scripts/get_maintainer.pl is your friend) 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 are sending your first patch, please first send it to yourself and make sure you can apply the copy you received. This will help you spot e-mail client configuration problems which may cause line wrapping or white space corruption.

== New I2C bus drivers ==

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 or compatible 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.

== New I2C chip drivers ==

I2C chip drivers are better handled by dedicated groups:

* RTC (real-time clock) drivers belong to the rtc subsystem
* Audio drivers belong to the sound subsystem ([http://www.alsa-project.org/ ALSA project])
* Hardware monitoring (sensors) drivers belong to the hwmon subsystem ([http://www.lm-sensors.org/ lm-sensors project])
* Video drivers belong to the media subsystem ([http://www.linuxtv.org/ LinuxTV project])
* I/O expander drivers belong to the gpio subsystem

Please do your best to find a suitable subsystem for your chip driver. Only questions related to the integration with, or use of, the I2C subsystem should be posted to the i2c mailing list.

== How to get my new driver merged? ==

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. That 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.

== Where do all the patches go? ==

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 [http://www.kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/ patch series] using [http://savannah.nongnu.org/projects/quilt quilt]. These patches are included in [http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary linux-next]. 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 [http://git-scm.com/ git] tree, from which Linus pulls. A [http://marc.info/?w=2&r=1&s=git+pull+i2c&q=t summary of the pulled patches] is posted to the i2c mailing list.

== What about this i2c SVN repository hosted on lm-sensors.org? ==

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 development. For Linux 2.6 and 3, the development happens directly in the Linux kernel tree, there is no external repository.

== Where do I get the i2c user-space tools (i2cdetect, i2cdump...)? ==

The i2c user-space tools have been part of the lm-sensors package for a long time, but they now have their own [http://www.lm-sensors.org/wiki/I2CTools SVN development tree and package], surprisingly named i2c-tools.