linux-kernel - Re: qestion about I2C_CLASS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080904120855.7e7b9720@hyperion.delvare>
Date:	Thu, 4 Sep 2008 12:08:55 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	"Francis Moreau" <francis.moro@...il.com>
Cc:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	i2c@...sensors.org
Subject: Re: qestion about I2C_CLASS_HWMON flag

On Thu, 4 Sep 2008 10:49:55 +0200, Francis Moreau wrote:
> On Thu, Sep 4, 2008 at 10:37 AM, Jean Delvare <khali@...ux-fr.org> wrote:
> > Hi Francis,
> >
> > On Thu, Sep 4, 2008 at 9:43 AM, Francis Moreau <francis.moro@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/