Re: qestion about I2C_CLASS_HWMON flag

Re: qestion about I2C_CLASS_HWMON flag

[Francis Moreau]

[ repost adding i2c mailing list in CC, sorry for that ]

On Thu, Sep 4, 2008 at 9:43 AM, Francis Moreau <francis.moro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hello,
>
> I'm wondering why does this flag exist ?
>
> Why is a hw monitor device so special so that an I2C bus needs
> a flag to tell the rest of the world that it support it ?
>
> Thanks
> --
> Francis
>

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: qestion about I2C_CLASS_HWMON flag

[Jean Delvare]

Hi Francis,

On Thu, Sep 4, 2008 at 9:43 AM, Francis Moreau <francis.moro@gmail.com> wrote:
> I'm wondering why does this flag exist ?
>
> Why is a hw monitor device so special so that an I2C bus needs
> a flag to tell the rest of the world that it support it ?

I don't understand your point. We have I2C_CLASS flags for many I2C
device types (analog TV, digital TV, etc.) I2C_CLASS_HWMON isn't the
exception you describe. Look at <linux/i2c.h> for a list of these flags.

-- 
Jean Delvare

Re: qestion about I2C_CLASS_HWMON flag

[Francis Moreau]

On Thu, Sep 4, 2008 at 10:37 AM, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Francis,
>
> On Thu, Sep 4, 2008 at 9:43 AM, Francis Moreau <francis.moro@gmail.com> wrote:
>> I'm wondering why does this flag exist ?
>>
>> Why is a hw monitor device so special so that an I2C bus needs
>> a flag to tell the rest of the world that it support it ?
>
> I don't understand your point. We have I2C_CLASS flags for many I2C
> device types (analog TV, digital TV, etc.) I2C_CLASS_HWMON isn't the
> exception you describe. Look at <linux/i2c.h> for a list of these flags.
>

My question (sorry if that silly) is why do we need these flags at all ?

Can't I2C bus address any kinds of I2C devices ?

What make hwmon devices special so that some I2C adapter can't
talk to them ?

Thanks
-- 
Francis

Re: qestion about I2C_CLASS_HWMON flag

[Jean Delvare]

On Thu, 4 Sep 2008 10:49:55 +0200, Francis Moreau wrote:
> On Thu, Sep 4, 2008 at 10:37 AM, Jean Delvare <khali@linux-fr.org> wrote:
> > Hi Francis,
> >
> > On Thu, Sep 4, 2008 at 9:43 AM, Francis Moreau <francis.moro@gmail.com> wrote:
> >> I'm wondering why does this flag exist ?
> >>
> >> Why is a hw monitor device so special so that an I2C bus needs
> >> a flag to tell the rest of the world that it support it ?
> >
> > I don't understand your point. We have I2C_CLASS flags for many I2C
> > device types (analog TV, digital TV, etc.) I2C_CLASS_HWMON isn't the
> > exception you describe. Look at <linux/i2c.h> for a list of these flags.
> >
> 
> My question (sorry if that silly) is why do we need these flags at all ?
> 
> Can't I2C bus address any kinds of I2C devices ?

In general they can, yes (where they can't, it's due to restrictions in
protocol implementations, not device types.) But this isn't a matter of
what devices can be on the bus. This is a matter of what devices can be
probed for on a given bus. For example, hardware monitoring drivers
which handle I2C devices, make sure that I2C_CLASS_HWMON is set before
probing I2C addresses on a given bus in search of a device to
auto-detect. On the other hand, if they are merely attaching to an I2C
device which has already been instantiated (and thus no probing is
needed) they do not care about the class. The reason for this mechanism
is that probing can be risky, so we want to limit it to what is
strictly needed. For example, there is no point in probing the I2C bus
of a TV adapter for hardware monitoring chips - there simply can't be
any there. If there ever was any, that would be such a special case
that we would instantiate the I2C device in question explicitly from
the adapter code, so we have no need for probing.

The general idea is that the class value is about what devices can be
probed for, not what devices can be present. The field should probably
have been named "probe_class" instead of just "class", but back when it
was created, all I2C in the kernel was about probing so this precision
didn't seem needed. Things have changed since then. Maybe we'll rename
it at some point but I don't want to bother driver authors uselessly.

> What make hwmon devices special so that some I2C adapter can't
> talk to them ?

Again there's nothing special about hwmon. All device types are (or
should be) handled the same way.

-- 
Jean Delvare

Re: qestion about I2C_CLASS_HWMON flag

[Francis Moreau]

Good morning Jean,

On Thu, Sep 4, 2008 at 12:08 PM, Jean Delvare <khali@linux-fr.org> wrote:
> In general they can, yes (where they can't, it's due to restrictions in
> protocol implementations, not device types.) But this isn't a matter of
> what devices can be on the bus. This is a matter of what devices can be
> probed for on a given bus. For example, hardware monitoring drivers
> which handle I2C devices, make sure that I2C_CLASS_HWMON is set before
> probing I2C addresses on a given bus in search of a device to
> auto-detect. On the other hand, if they are merely attaching to an I2C
> device which has already been instantiated (and thus no probing is
> needed) they do not care about the class. The reason for this mechanism
> is that probing can be risky, so we want to limit it to what is
> strictly needed. For example, there is no point in probing the I2C bus
> of a TV adapter for hardware monitoring chips - there simply can't be
> any there. If there ever was any, that would be such a special case
> that we would instantiate the I2C device in question explicitly from
> the adapter code, so we have no need for probing.

OK but which devices that can be connected to an I2C bus is platform specific,
isn't it ? For example, an I2C adapter can be used in a TV and in that
case there
may be no point to probe for a HW mon chips but this same I2C adapter can be
used by other platforms in a different context where there's a HW mon chip.

So the flags probably are useful, but they're are hard coded in adapters...

Sorry if I'm still missing something.
-- 
Francis

Re: qestion about I2C_CLASS_HWMON flag

[Jean Delvare]

On Fri, 5 Sep 2008 10:57:56 +0200, Francis Moreau wrote:
> Good morning Jean,
> 
> On Thu, Sep 4, 2008 at 12:08 PM, Jean Delvare <khali@linux-fr.org> wrote:
> > In general they can, yes (where they can't, it's due to restrictions in
> > protocol implementations, not device types.) But this isn't a matter of
> > what devices can be on the bus. This is a matter of what devices can be
> > probed for on a given bus. For example, hardware monitoring drivers
> > which handle I2C devices, make sure that I2C_CLASS_HWMON is set before
> > probing I2C addresses on a given bus in search of a device to
> > auto-detect. On the other hand, if they are merely attaching to an I2C
> > device which has already been instantiated (and thus no probing is
> > needed) they do not care about the class. The reason for this mechanism
> > is that probing can be risky, so we want to limit it to what is
> > strictly needed. For example, there is no point in probing the I2C bus
> > of a TV adapter for hardware monitoring chips - there simply can't be
> > any there. If there ever was any, that would be such a special case
> > that we would instantiate the I2C device in question explicitly from
> > the adapter code, so we have no need for probing.
> 
> OK but which devices that can be connected to an I2C bus is platform specific,
> isn't it ? For example, an I2C adapter can be used in a TV and in that
> case there
> may be no point to probe for a HW mon chips but this same I2C adapter can be
> used by other platforms in a different context where there's a HW mon chip.
> 
> So the flags probably are useful, but they're are hard coded in adapters...

Nothing prevents you from setting the class flags based on
platform-specific information if you have a need for that.

That being said, in cases where you have that level of information
about which devices are present on the I2C bus, you probably want to
declare the I2C devices at the platform level, and not rely on probing
at all (so .class is 0).

-- 
Jean Delvare

Re: qestion about I2C_CLASS_HWMON flag

[Francis Moreau]

On Fri, Sep 5, 2008 at 11:20 AM, Jean Delvare <khali@linux-fr.org> wrote:
> On Fri, 5 Sep 2008 10:57:56 +0200, Francis Moreau wrote:
ags probably are useful, but they're are hard coded in adapters...
>
> Nothing prevents you from setting the class flags based on
> platform-specific information if you have a need for that.
>

Just to be sure, do you mean by hacking the adapter source code ?

> That being said, in cases where you have that level of information
> about which devices are present on the I2C bus,

Isn't the case for most of all embedded platforms ?

> you probably want to
> declare the I2C devices at the platform level, and not rely on probing
> at all (so .class is 0).

do you mean by using I2C_BOARD_INFO ?

Thanks
-- 
Francis

Re: qestion about I2C_CLASS_HWMON flag

[Jean Delvare]

On Fri, 5 Sep 2008 14:44:30 +0200, Francis Moreau wrote:
> On Fri, Sep 5, 2008 at 11:20 AM, Jean Delvare <khali@linux-fr.org> wrote:
> > Nothing prevents you from setting the class flags based on
> > platform-specific information if you have a need for that.
> 
> Just to be sure, do you mean by hacking the adapter source code ?

It's not about hacking, it can be done cleanly. Just have the adapter
driver code check for information in the platform data, and if class
information is provided, use that instead of the default value. Or if
all users will provide the information, don't even have a default in
the driver. Again, the class flags are a (needed) mechanism, the policy
is left for driver authors and platform maintainers to establish.

> > That being said, in cases where you have that level of information
> > about which devices are present on the I2C bus,
> 
> Isn't the case for most of all embedded platforms ?

Indeed.

> > you probably want to
> > declare the I2C devices at the platform level, and not rely on probing
> > at all (so .class is 0).
> 
> do you mean by using I2C_BOARD_INFO ?

Exactly. Except on powerpc where they have a different mechanism, I
think.

-- 
Jean Delvare

Re: qestion about I2C_CLASS_HWMON flag

[Francis Moreau]

On Fri, Sep 5, 2008 at 3:11 PM, Jean Delvare <khali@linux-fr.org> wrote:
> On Fri, 5 Sep 2008 14:44:30 +0200, Francis Moreau wrote:
>> On Fri, Sep 5, 2008 at 11:20 AM, Jean Delvare <khali@linux-fr.org> wrote:
>> > Nothing prevents you from setting the class flags based on
>> > platform-specific information if you have a need for that.
>>
>> Just to be sure, do you mean by hacking the adapter source code ?
>
> It's not about hacking, it can be done cleanly. Just have the adapter
> driver code check for information in the platform data, and if class
> information is provided, use that instead of the default value. Or if
> all users will provide the information, don't even have a default in
> the driver. Again, the class flags are a (needed) mechanism, the policy
> is left for driver authors and platform maintainers to establish.
>

Ah OK I see now.

On v2.6.23 i2c-gpio.c had no I2C_CLASS_HWMON flag set and
had no way to pass this info from platform board.

But on v2.6.27 it is now set whatever the platforms.

Wouldn't it have been better to allow the platform code to pass this type
information through the 'i2c_gpio_platform_data' structure for example ?

Thanks Jean !
-- 
Francis

Re: qestion about I2C_CLASS_HWMON flag

[Jean Delvare]

On Fri, 5 Sep 2008 15:38:23 +0200, Francis Moreau wrote:
> On Fri, Sep 5, 2008 at 3:11 PM, Jean Delvare <khali@linux-fr.org> wrote:
> > It's not about hacking, it can be done cleanly. Just have the adapter
> > driver code check for information in the platform data, and if class
> > information is provided, use that instead of the default value. Or if
> > all users will provide the information, don't even have a default in
> > the driver. Again, the class flags are a (needed) mechanism, the policy
> > is left for driver authors and platform maintainers to establish.
> 
> Ah OK I see now.
> 
> On v2.6.23 i2c-gpio.c had no I2C_CLASS_HWMON flag set and
> had no way to pass this info from platform board.
> 
> But on v2.6.27 it is now set whatever the platforms.
> 
> Wouldn't it have been better to allow the platform code to pass this type
> information through the 'i2c_gpio_platform_data' structure for example ?

If you have a need for that, sure. If you don't, that's making the code
more complex for no good reason.

I expect I2C_CLASS_HWMON to be removed from that driver soon. Now that
almost all hwmon drivers have been converted to support instantiated
I2C devices, and given that all users of i2c-gpio are embedded
architectures with platform code, it should be no longer needed. But
again I am leaving it to whoever is actually using this driver to
decide what is best for them.

-- 
Jean Delvare

Re: qestion about I2C_CLASS_HWMON flag

[Francis Moreau]

On Fri, Sep 5, 2008 at 3:49 PM, Jean Delvare <khali@linux-fr.org> wrote:
> On Fri, 5 Sep 2008 15:38:23 +0200, Francis Moreau wrote:
>> On Fri, Sep 5, 2008 at 3:11 PM, Jean Delvare <khali@linux-fr.org> wrote:
>> > It's not about hacking, it can be done cleanly. Just have the adapter
>> > driver code check for information in the platform data, and if class
>> > information is provided, use that instead of the default value. Or if
>> > all users will provide the information, don't even have a default in
>> > the driver. Again, the class flags are a (needed) mechanism, the policy
>> > is left for driver authors and platform maintainers to establish.
>>
>> Ah OK I see now.
>>
>> On v2.6.23 i2c-gpio.c had no I2C_CLASS_HWMON flag set and
>> had no way to pass this info from platform board.
>>
>> But on v2.6.27 it is now set whatever the platforms.
>>
>> Wouldn't it have been better to allow the platform code to pass this type
>> information through the 'i2c_gpio_platform_data' structure for example ?
>
> If you have a need for that, sure. If you don't, that's making the code
> more complex for no good reason.
>
> I expect I2C_CLASS_HWMON to be removed from that driver soon. Now that
> almost all hwmon drivers have been converted to support instantiated
> I2C devices, and given that all users of i2c-gpio are embedded
> architectures with platform code, it should be no longer needed. But
> again I am leaving it to whoever is actually using this driver to
> decide what is best for them.
>

OK, thanks a lot for the clarifications
-- 
Francis