lm-sensors/doc/developers/new_drivers

These are the steps you should follow to write a new driver and
submit it to us so that it will be applied cleanly to our package.
See at the bottom for adding new chip support to an existing driver.

Don't be intimidated by the list, it's just here so we don't
forget anything.
We are more than happy to help you with any part of the process.

There are two types of drivers, chip and bus.
Steps which apply to only one type of driver are noted.


* Contact us first.
  You are of course free to write your own drivers, but it is smart to
  check first nobody else is already working on it.
  Check our "New Drivers" page for information also.
  You will also need to ask us to have an ID reserved in
  i2c-id.h in the i2c package.
  Tell us it's OK to put your name on the "New Drivers" page.
  Ask to be put on the mailing list so you get project updates.

* Check out our latest code from CVS.
  You should use this as a base for your development.
  See instructions on our download page.

* Write the new driver. 
  For a chip driver, use lm78.c as template. For an SMBus-only adapter, 
  use i2c-piix4.c. Use i2c-via.c for an I2C-level adapter.
  Usually, we make all prefixes start with the driver name. This is not
  really necessary, as these symbols will not be exported anyway. But by
  doing this, you are sure you do not shadow any global kernel names.
  Remember that you want to output the direct measurements done by the
  chip. If these sensor values need scaling, this should be done through
  the configuration file.

* Meet Kernel coding standards.
  See Documentation/CodingStyle in the kernel source.
  Be sure and use 8 column tabs.
  Also, please do not use // comments.
  Also, please do not go past column 80.
  Also, please use C99 struct initializers {.foo = blat}
  Please do this _before_ you check in your driver.

* Add sysctl definitions to kernel/include/sensors.h (for chip drivers only).
  These define the entries in the ctl_table for /proc.

* Meet /proc naming standards in the ctl_table (for chip drivers only).
  See doc/developers/proc for information.

* Add the driver to the Module.mk (the makefile).
  Usually, you can just add it to KERNEL{CHIPS,DRIVERS}TARGETS in the
  Module.mk file in the directory itself. Put it at the beginning,
  where the comment says to put drivers NOT included in mkpatch.

* Make sure it compiles cleanly.
  If you compile with 'make WARN=1', you usually get many additional
  warnings. Please resolve these too, even if you know they are
  harmless. Do the same with 'make DEBUG=1 WARN=1' if you use debugging
  information. Remember, things put between #ifdef DEBUG #endif may never
  stop the driver from functioning; they should just output additional
  information.

* Check for external symbols.
  'nm --extern --defined' should only output symbols starting with __module,
  cleanup_module, init_module and some kernel versioning symbols. Mark all
  other symbols as static in your source file.

* Test the module.
  This is usually the boring part...
  Test both with 2.2.x and 2.4.x kernels.

* Add detection information to prog/detect/sensors-detect.
  This is a perl script that automatically detects what chips and adapters
  are present. Contact us if you need help.

* Add chip information to lib/chips.{c,h} (for chip drivers only).
  Until you have done this, the chip will be invisible for user-level
  programs which use libsensors. Use standard names in lib/chips.c;
  see also the comments in etc/sensors.conf.eg for help.
  Contact us if you need more assistance.

* Add alarm definitions to kernel/include/sensors.h (for chip drivers only).
  These define the bits in the 'alarms' entry in /proc.	

* Add a procedure to prog/sensors/chips.[ch] (for chip drivers only).
  This is a function specific for your driver that
  makes the included 'sensors' program pretty-print your chip information.

* Add a call to the procedure in prog/sensors/main.c (for chip drivers only).
  Put it at the bottom of do_a_print().

* Add entries to etc/sensors.conf.eg (for chip drivers only).
  If needed, you can set defaults here.

* Add the name of the device to the README file.

* Add your name to the CONTRIBUTORS file.

* Add entries to the CHANGES file. Please keep in alphabetical order.

* Write a doc/chips/xxx or doc/busses/xxx file.

* Clearly specify licensing and copyright.
  Make sure the GPL boilerplate and your name
  (or if applicable your company's name) is at the top of the
  new driver so we know you are giving it to us under the GPL.

* Get CVS write access if you want to check in your driver yourself.
  Do this by running the script doc/developers/genpasswd.pl and following
  the instructions it gives you.

* Submit the changes to us, or check them in.
  Do a 'cvs update' to get in sync (things will have changed since
  you started), then submit the changes to us as a patch against CVS,
  or check them in.

---------------------------------------------------------------------
Checklist for us to do on the webpage:

* Add entry to 'supported drivers' page

* Update entry on 'new drivers' page

---------------------------------------------------------------------
Checklist for mkpatch support, after the driver is tested and stable:

* Add .c file to mkpatch/FILES.

* Add makefile entry in mkpatch/mkpatch.pl (2 places - old and new formats).

* Add config help to mkpatch/mkpatch.pl.

* Add config entry to mkpatch/Config.in (chip drivers only)

* Add config entry in mkpatch/mkpatch.pl (bus drivers only)

* Add declaration and init. call to kernel/sensors.c (chip drivers only)
  (verify init function name)

* Add declaration and init. call in mkpatch/mkpatch.pl (bus drivers only)
  (verify init function name)

* Move .o reference in kernel/[chips,busses]/Module.mk
  from first to second section.


---------------------------------------------------------------------
Checklist for _adding_ support for a chip to an _existing_ driver:

* Make the changes to the driver itself.

* Add detection information to prog/detect/sensors-detect.

* Add a strncmp() call for the new prefix in prog/sensors/main.c
  (chip drivers only).

* Add entries for the new prefix to etc/sensors.conf.eg (chip drivers only).

* Update config help in mkpatch/mkpatch.pl.

* Update config entry in mkpatch/Config.in (chip drivers only)

* Update config entry in mkpatch/mkpatch.pl (bus drivers only)

* Update doc/[chips,busses]/xxx file

* Update doc/chips/SUMMARY file (chip drivers only)

* Update list in README

* Submit the changes as a patch or check them in

* Update entry on 'new drivers' page