Re: [PATCH][2.6] Add command function to struct i2c_adapter

[Jean Delvare]

Hi Michael,

See my various questions inline.

> the attached patch adds a command function to struct i2c_adapter,
> similar to the command function that is already there for struct
> i2c_client.

I didne't even know that. Is this command function in struct i2c_client used
somewhere? What for?

> The reason behind this is as follows:
> In the DVB subsystem, the tuners are accessed via normal kernel i2c
> drivers. One big problem is, that tuners can be wired very differently
> depending on the surrounding hardware. Currently, we need to keep
> specific settings which are unique to a hardware design in the
> independent i2c tuner driver. This is both very ugly and makes it
> impossible to support DVB drivers which are not in the official Linux
> kernel tree, but could otherwise use in-kernel frontend driver.

What is the i2c tuner driver "independent" of? Do you simply mean that it
holds the common code for all DVB adapters?

> If the struct i2c_adapter has a command function, it would be possible
> to get additional informations from the adapter in the i2c client's
> attach_adapter() function *before* probing the device and guessing
> things like i2c addresses or other hardware settings.

I see what you want to do, but I don't exactly see how it solves your problem.
Your new command callback function will provide an adapter-specific interface
to adapter internal data. You will have to fill the data before you can access
it, so there still is hardware-specific data involved. Is your point that this
data would be located in (and split among) adapter drivers instead of the
common tuner driver as is now?

I am interested in your proposal because we (the sensors side of the i2c bus)
are facing a similar problem with hardware monitoring chips on motherboads.
The same chip can be wired differently on various motherboads, and most of the
time there is no way to guess (either because the hardware just doesn't
provide any way, or because the BIOS failed to do its job properly). We have
not come to any solution yet, and most of the time users have to use
user-space tools (such as i2cset) prior to loading the drivers. Looks like the
problem you are dealing with is of similar nature.

My initial thoughts about this were that we could use DMI data and/or PCI
information to identify systems, and trigger motherboard-specific code
whenever needed. It's really just a wild guess, I don't know if it is the
correct way. Wouldn't it work for you as well?

I would appreciate if you could show us some (pseudo)code with explanations on
what you have for now, and what you would have after the change. I have some
difficulties to understand what the change would actually change, most
probably because the video and sensors sides of the i2c subsystem work rather
differently.

On a completely different matter, what about the i2c subsystem class flags and
checking mechanism? You had come with a first step some months ago (adding a
class member to i2c clients), and your proposal (generalized check of i2c
client class against adapter class) looked very good to me, but then we did
not finish the job. What about it? I am willing to help on the sensors front
if you are going into this again someday. If I remember correctly, step 2 was
about clearing manual class checks and filling all class members, and step 3
was about implementing the generalized check in i2c-core. Am I right?

Thanks.

-- 
Jean Delvare
http://khali.linux-fr.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/