1/4 WIP I2C kernel patches-config

Hello All,
I'm Albert Cranford and I'm working to get I2C ready for submission to Linus for inclusion into the 2.5 kernel.

My current base is i2c-2.6.3. I've split the patches into Linus sizes with:
1/4 being Config module.
2/4 being the core modules.
3/4 being driver modules.
4/4 being fixes needed to compile inline or modules.

I would like to get some feedback/synchronization of my suggested changes into CVS 2.6.4. My comments will be followed by each patch. Fell free to reply. After this patch set is in the kernel, I will submit i2c-2.6.4 changes.
Thanks,
Albert
Patch 1 assumes we really want to change CONFIG names to match the *.c modules that use them.
PHILIPSPAR -> BITLP
ELV -> BITELV
VELLEMAN -> BITVELLE
ELEKTOR -> PCFISA

@@ -10,14 +10,14 @@
 
    dep_tristate 'I2C bit-banging interfaces'  CONFIG_I2C_ALGOBIT $CONFIG_I2C
    if [ "$CONFIG_I2C_ALGOBIT" != "n" ]; then
-      dep_tristate '  Philips style parallel port adapter' CONFIG_I2C_PHILIPSPAR $CONFIG_I2C_ALGOBIT $CONFIG_PARPORT
-      dep_tristate '  ELV adapter' CONFIG_I2C_ELV $CONFIG_I2C_ALGOBIT
-      dep_tristate '  Velleman K9000 adapter' CONFIG_I2C_VELLEMAN $CONFIG_I2C_ALGOBIT
+      dep_tristate '  Philips style parallel port adapter' CONFIG_I2C_BITLP $CONFIG_I2C_ALGOBIT $CONFIG_PARPORT
+      dep_tristate '  ELV adapter' CONFIG_I2C_BITELV $CONFIG_I2C_ALGOBIT
+      dep_tristate '  Velleman K9000 adapter' CONFIG_I2C_BITVELLE $CONFIG_I2C_ALGOBIT
    fi
 
    dep_tristate 'I2C PCF 8584 interfaces' CONFIG_I2C_ALGOPCF $CONFIG_I2C
    if [ "$CONFIG_I2C_ALGOPCF" != "n" ]; then
-      dep_tristate '  Elektor ISA card' CONFIG_I2C_ELEKTOR $CONFIG_I2C_ALGOPCF
+      dep_tristate '  Elektor ISA card' CONFIG_I2C_PCFISA $CONFIG_I2C_ALGOPCF
    fi
 
    if [ "$CONFIG_MIPS_ITE8172" = "y" ]; then

@@ -45,6 +45,7 @@
 
    dep_tristate 'I2C device interface' CONFIG_I2C_CHARDEV $CONFIG_I2C
 
-   dep_tristate 'I2C /proc interface (required for hardware sensors)' CONFIG_I2C_PROC $CONFIG_I2C
+   dep_tristate 'I2C /proc interface (required for hardware sensors)' CONFIG_I2C_PROC $CONFIG_I2C $CONFIG_SYSCTL
+
 fi
 endmenu

Albert Cranford Deerfield Beach FL USA
[email protected]

While the 4xx stuff is out of date, in the next round of patches, feel free to include the 8xx driver. It hasn't been tested in a bit, but
8xx doesn't currently work in 2.5 right now anyways. I'll attempt to
test it out on 2.4 soon.

Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Albert,
thanks again for doing this.
Here's my comments for all 4.

- Don't submit patches for anything not patched by mkpatch, that is, anything not in mkpatch/FILES. This includes *8xx* and *405*. The 405 stuff, I have a monster patch I got a month and a half ago, the only reason I haven't put it in yet is that it renames all the files. But anyway, if it isn't in mkpatch/FILES there's some reason. i2c-pcf-epp is really new. 8xx status unclear.

- After this patch set, the next is probably sensors. There's nothing from 2.6.4 that's really ready, except for the i2c.h stuff. The PEC stuff in i2c-core is only half done.

- Be careful not to undo changes made by others in kernel 2.5. The one I saw
is in i2c-proc at about line 125 (the kmalloc return code check). I put that in CVS already. The other changes (the ones I know about I've listed at the top of TODO in CVS, be sure and look at that
document)
are not compatible with 2.2 / 2.4 kernels so I can't put them as-is into CVS. I didn't check your patches carefully to see if you did any other undo's.

- Remember the only synchronization we can do with CVS is on the changes that are compatible with 2.2 / 2.4, unless we do #ifdef kernel > 2.5 type of stuff. Or something more innovative. Suggestions anyone? I don't know how we are going to easily maintain multi-kernel support. Maybe we need to start a new CVS tree (yuck)?

- Can you submit a patch for Config.help (if necessary)? This one is patched in-line
by mkpatch.pl, it isn't listed in FILES. I guess Config.help is now split into many separate files...

Hi

albert> Hello All,
albert> I'm Albert Cranford and I'm working to get I2C ready for albert> submission to Linus for inclusion into the 2.5 kernel.

I sent a question yesterday about that. Why we changed the names of th econfig files? I am really not sure that we want that, it looks that old names are better, only reason to change is if they support more devices, but then a change in the text of the config option looks in order. also.

albert> My current base is i2c-2.6.3. I've split the patches into albert> Linus sizes with:
albert> 1/4 being Config module.
albert> 2/4 being the core modules.
albert> 3/4 being driver modules.
albert> 4/4 being fixes needed to compile inline or modules.

albert> I would like to get some feedback/synchronization of my albert> suggested changes into CVS 2.6.4. My comments will be albert> followed by each patch. Fell free to reply. albert> After this patch set is in the kernel, I will submit albert> i2c-2.6.4 changes.
albert> Thanks,
albert> Albert
albert> Patch 1 assumes we really want to change CONFIG names to albert> match the *.c modules that use them.
albert> PHILIPSPAR -> BITLP
albert> ELV -> BITELV
albert> VELLEMAN -> BITVELLE
albert> ELEKTOR -> PCFISA

albert> --- linux/drivers/i2c/Config.in.orig 2002-05-05 23:38:06.000000000 -0400
albert> +++ linux/drivers/i2c/Config.in 2002-02-18 20:06:01.000000000 -0500 albert> @@ -10,14 +10,14 @@

albert> dep_tristate 'I2C bit-banging interfaces' CONFIG_I2C_ALGOBIT $CONFIG_I2C albert> if [ "$CONFIG_I2C_ALGOBIT" != "n" ]; then

albert> -      dep_tristate '  Philips style parallel port adapter' CONFIG_I2C_PHILIPSPAR $CONFIG_I2C_ALGOBIT $CONFIG_PARPORT
albert> -      dep_tristate '  ELV adapter' CONFIG_I2C_ELV $CONFIG_I2C_ALGOBIT
albert> -      dep_tristate '  Velleman K9000 adapter' CONFIG_I2C_VELLEMAN $CONFIG_I2C_ALGOBIT
albert> +      dep_tristate '  Philips style parallel port adapter' CONFIG_I2C_BITLP $CONFIG_I2C_ALGOBIT $CONFIG_PARPORT
albert> +      dep_tristate '  ELV adapter' CONFIG_I2C_BITELV $CONFIG_I2C_ALGOBIT
albert> +      dep_tristate '  Velleman K9000 adapter' CONFIG_I2C_BITVELLE $CONFIG_I2C_ALGOBIT

albert> fi

albert> dep_tristate 'I2C PCF 8584 interfaces' CONFIG_I2C_ALGOPCF $CONFIG_I2C albert> if [ "$CONFIG_I2C_ALGOPCF" != "n" ]; then

albert> -      dep_tristate '  Elektor ISA card' CONFIG_I2C_ELEKTOR $CONFIG_I2C_ALGOPCF
albert> +      dep_tristate '  Elektor ISA card' CONFIG_I2C_PCFISA $CONFIG_I2C_ALGOPCF

albert> fi

albert> if [ "$CONFIG_MIPS_ITE8172" = "y" ]; then
albert> @@ -45,6 +45,7 @@

albert> dep_tristate 'I2C device interface' CONFIG_I2C_CHARDEV $CONFIG_I2C

albert> - dep_tristate 'I2C /proc interface (required for hardware sensors)' CONFIG_I2C_PROC $CONFIG_I2C
albert> + dep_tristate 'I2C /proc interface (required for hardware sensors)' CONFIG_I2C_PROC $CONFIG_I2C $CONFIG_SYSCTL
albert> +
albert> fi
albert> endmenu

albert> --
albert> Albert Cranford Deerfield Beach FL USA
albert> [email protected]

In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Yes, but it will be working at somepoint in 2.5. Unless someone has gone and re-tested all of these under 2.5 (which isn't a bad idea really...) the 8xx drivers should be in the same state as the rest of the group.

Tom Rini (TR1265)
http://gate.crashing.org/~trini/

drivers/i2c/

Add the GPL boilerplate. Missing due to laziness.

been tested.

It, being MPC8xx support in general, doesn't work due to the 2.5.5'ish VM changes (and the MPC8xx has hw-assisted tlb management so it's going to require some thought to fix) and then some PPC-specific exception handling cleanups, and I'm sure the latest round of TLB fixes need some thought at least. But the i2c code was known to be working when submitted and should still be working.

Tom Rini (TR1265)
http://gate.crashing.org/~trini/

If it doesn't work in 2.5 we shouldn't include it in a 2.5 patch.

- Should it go into drivers/i2c or into arch/... ?
- Do we need resolve the license with the people listed at the top of the files, there is no GPL boilerplate at the top of the 8xx.[ch] ?
- As far as we know the rest works under 2.5, of course they haven't all been tested. If you _know_ it doesn't work under 2.5 (I think that's what you said) then shouldn't it be fixed first?