Re: Driver Merge Questions

[Tony Lindgren <tony@atomide.com>]

* Chris Hudson <chudson@kionix.com> [091103 06:48]:
> Hello all,
> 
> I've never submitted any software to Linux before, but I've been
> working on some new accelerometer drivers that should be ready for
> review soon (pending company approval).  I've read lots of
> documentation on patch and driver submissions, but I still have some
> questions that I was hoping someone could help me find the answers
> to.
> 
> 1- My drivers use i2c for hardware communications, miscdevice for
> IOCTLs, and input_dev for data and interrupt status outputs.  Most
> of the other accelerometer drivers that I've looked at use similar
> designs and are located in drivers/hwmon, but I just wanted to
> confirm that this is the correct location currently.

Sounds correct.
 
> 2- I have done all of my hardware testing with OMAP development
> platforms, so I thought it would be best to send my patch
> submissions to this list for review.  The hardware monitoring tree
> is listed in MAINTAINERS as an orphan, but I was planning on
> including lm-sensors@lm-sensors.org as well.  If either of these
> assumptions is incorrect, please let me know.

Yes, please send the patches to both. Also, please run the patches
through scripts/checkpatch.pl --strict, and read the files under
Documentation/Submit* ;)
 
> 3- Should my patch set consist of source, header, kconfig, and
> makefile patches, or should I include my custom changes to mux.c,
> mux.h, and board-zoom2.c as well?  The former are necessary for
> adding driver support, but the latter are specific for my hardware
> testing platform (which others may want to duplicate for testing
> purposes).  I noticed that recent versions of board-zoom2.c are nice
> and clean, so it's probably not a good idea to wedge
> infrequently-used code in there with a bunch of #ifdefs.  I just
> want to get an idea of what is generally included with a new driver.

Compile should work throughout the series for each patch to keep
git bisect working. To me it sounds like one patch for the driver,
and then one to enable the driver in some hardware.

Please not that we're reworking the mux code for omap3 to make it
easier to use. So please make the mux changes yet another patch.
 
> Any help or advice would be greatly appreciated.

Hope this helps!

Regards,

Tony