[i2c] [PATCH 5/6] i2c: i2c_adapter drivers need no driver
Jean Delvare
khali at linux-fr.org
Sun Feb 18 10:23:02 CET 2007
Dave,
On Fri, 16 Feb 2007 13:53:06 -0800, David Brownell wrote:
> On Thursday 15 February 2007 10:49 pm, Jean Delvare wrote:
> > Good point. However, this only works (properly) if the i2c adapter
> > pseudo-device actually has a parent, which you know isn't always the
> > case at the moment.
>
> And I thought we had earlier agreed that was something that need
> to be fixed ... in fact I thought you chose your parport example
> specifically to be awkward, because the parport subsystem doesn't
> seem to expose a device that an i2c bitbanger could even use!
I wanted to fix it because it appeared to be mandatory to go on with
the more important i2c-core cleanups and improvements. With Greg's plan
however, I thought it was no longer mandatory and decided to postpone
it. This is why I degraded the "no physical device" warning to a debug
message, probably a bit too quickly.
Many of the offending drivers were easy to fix and 14.5 of them are
already fixed in Linus' tree:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=12a917f69d1468c91d646dbad8408dd0d39d6207
According to my notes, this leaves 11.5 drivers to fix:
drivers/acorn/char/i2c.c
drivers/i2c/busses/i2c-au1550.c
drivers/i2c/busses/i2c-elektor.c
drivers/i2c/busses/i2c-parport-light.c
drivers/i2c/busses/i2c-parport.c
drivers/i2c/busses/i2c-pca-isa.c
drivers/i2c/busses/i2c-sibyte.c
drivers/i2c/busses/i2c-stub.c
drivers/i2c/busses/scx200_acb.c (50%)
drivers/i2c/busses/scx200_i2c.c
drivers/media/dvb/frontends/dibx000_common.c
drivers/media/video/vino.c
I planned to take care of i2c-parport-light and i2c-stub myself
because I can test them, and maybe i2c-elektor too.
I used my parport device as an example because that's what I use on my
laptop to test i2c and hwmon, so this is how I noticed the problem.
There was no hidden meaning.
> That's a fixable bug, of course. I have a copy of that driver
> stack's source code around here somewhere, I'm sure of it ... ;)
Would be nice, indeed. I was surprised to notice that the parport stack
wasn't integrated into the device driver model yet, I thought i2c was
the last missing one ;)
> > I'll go through your original patches today and port them to do what
> > you suggest above. Let's see what we get.
>
> A *LOT* of work going through a scarey number of I2C adapters, that's
> for darn sure! But: much more useful diagnostics, overall, since
> they would be made to point at the real hardware which indicates the
> trouble ... either the adapter/controler, or the I2C slave chip.
I agree it's better, no question about that. My main concern was to put
my time where it was more needed.
We can start fixing individual bus and chip drivers. For all the
drivers which do have a physical device properly declared, we can use
it right now. However we can't fix the uses in i2c-core until all the
bus drivers have a physical device. So I guess I'll need to promote the
debug message in i2c-core to a warning again.
--
Jean Delvare
More information about the i2c
mailing list