Re: [BK PATCH] I2C update for 2.6.10-rc1

Jean Delvare
2004-11-09T09:41:35Z

Hi Greg,

>Greg Kroah-Hartman:
> o I2C: delete normal_i2c_range logic from sensors as there are no more
> users
> o I2C: moved from all sensor drivers from normal_i2c_range to normal_i2c
> o I2C: fix i2c_detect to allow NULL fields in adapter address structure
> o I2C: remove normal_isa_range from I2C sensor drivers, as it's not used
> o I2C: remove ignore_range from I2C sensor drivers, as it's not used
> o I2C: remove probe_range from I2C sensor drivers, as it's not used

I'm very happy with that :) A documentation update will be needed though.

Also, while we're at it, is there any reason why I2C_CLIENT_END and
I2C_CLIENT_ISA_END are two different constants? We could probably go
with 0xffff (or 0xfffd if you don't like 0xffff) for both. We never saw
a non-even-aligned ISA address anyway, did we? Just a though anyway, I
agree it doesn't matter much.

As a side note, I could never understand why the I2C-ISA kind of
emulation was implemented the way it is. It could make sense if the
clients really didn't know that they are accessing the ISA bus. It's
not the case though, clients are accessing the ISA I/O space directly.
The i2c-isa driver is almost empty. Client drivers with both I2C and ISA
bus accesses (lm78, w83781d, it87) are a mess. I understand that the
original idea was to avoid code duplication for chips supporting both
bus interfaces, but in the end the benefit is questionable. In
particular, people only using ISA chips have to bear the overhead of the
whole I2C subsystem with little benefit. There must be a better way.
Greg, do you have plans to clean it up? I can think of two completely
different approaches, either a true i2c-isa emulation, or a complete
separation of the ISA stuff. We may consider different approaches for
I2C+ISA chips and ISA only chips, by the way.

Thanks,
Jean