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 for Android: free password hash cracker in your pocket

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

Message-ID: <20080905112056.44b7b910@hyperion.delvare>
Date:	Fri, 5 Sep 2008 11:20:56 +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 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@...ux-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
--
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/