[i2c] Where do all the patches go?

[Jean Delvare]

On Sat, 05 May 2007 13:17:49 -0500, Nishanth Menon wrote:
> Jean Delvare stated on 5/5/2007 11:17 AM:
> > I've been thinking of splitting away the i2c tools to a separate
> > package, but then there's a problem with isadump, which isn't related
> > to i2c, but isn't specific to lm_sensors either. Having a separate
> > package just for isadump sounds overkill. And i2cdump and isadump share
> > some code (a small amount.) But maybe it'll happen; I wonder what
> > the others think.
>
> yes - the idea is to have i2c test apps as a seperate set for folks like
> me to play around. To give an example: I have been thinking of
> integrating multibyte CCI transfer (CSI2 variant of i2c) and wanted to
> modify the i2c core for this (hypothetically). I should be able to

I never heard of CCI nor CSI2... What are you talking about?

> present two patches: one for the driver/core; the second for the
> test-tool used to test the functionality. this way all of us can be on
> the same page - instead of multiple variants of the same. Ofcourse, I

"Multiple variants of the same" what? What do you mean?

> agree that the number of patches coming in for the test tool is going to
> be small - given thier generic nature, but it is a nice place to look
> for... that is my two cents ;)

Right now, the i2c tools are in the lm_sensors package. This might not
be very practical, but this doesn't change anything with regards to the
above scenario. You'd send a patch against the kernel tree for
i2c-core, and one against the lm_sensors tree for the tools.

-- 
Jean Delvare