Date: Sat, 23 May 2015 09:27:37 -0700
From: Guenter Roeck <linux@roeck-us.net>
To: York Sun <yorksun@freescale.com>
Cc: Lee Jones <lee.jones@linaro.org>, linux-kernel@vger.kernel.org,
        linux-i2c@vger.kernel.org
Subject: Re: I2C class bitmask
Message-ID: <20150523162737.GA4981@roeck-us.net>
References: <555E4913.9070805@freescale.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <555E4913.9070805@freescale.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Authenticated_sender: guenter@roeck-us.net
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net
X-AntiAbuse: Original Domain - vger.kernel.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - roeck-us.net
X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: guenter@roeck-us.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2401
Lines: 49

On Thu, May 21, 2015 at 02:07:31PM -0700, York Sun wrote:
> Lee,
> 
> Is there any convention regarding I2C class bitmask? I see only three are
> defined for 3.12.19 and four for 4.0
> 
> I2C_CLASS_HWMON, I2C_CLASS_DDC, I2C_CLASS_SPD, I2C_CLASS_DEPRECATED
> 
> I am working on a clock chip driver (SI5338) and trying to detect them (multiple
> chips in i2c mux). It would be a lot easier to have its own class, like
> I2C_CLASS_CLOCK. It is trivial to add a line to i2c.h file. Just checking if
> this is a bad idea.
> 

A class is supposed to indicate if a specific chip class is likely to be seen
on an i2c adapter, and that it may be necessary to auto-detect it (an example
are I2C_CLASS_HWMON type devices on PCs). The tendency, though, is to drop
existing markers for I2C_CLASS_xxx from adapter drivers as much as possible
because it slows down the boot process (see upstream commit 0c176170089c3).

Auto-detection (with the _detect function) is not a preferred means to
instantiate a device. It takes time, and it is more or less unreliable.
For some chips, a read on its i2c register space can result in a chip reset,
or it can cause it to lose its programming. Worst case it can turn a system
into a brick.

Preferred instantiations are listed in Documentation/i2c/instantiating-devices.
Instantiation with devicetree, ACPI, or through i2c_register_board_info()
would probably be the best available methods to instantiate a clock chip.

Given that, first question is why you would want to have the chip auto-detected
in the first place. Is there any reason to believe that explicit instantiation
would not work in your system ?  What are those reasons ?

On top of that, the SI5338 does not have a clean way to detect the chip.
It does not have a chip ID register, and it is multi-banked. Given the
similarities of the various Silicon Labs clock chips, it may not even be
possible to reliably distinguish it from other SI chips. So even if you
had a good reason to auto-detect the chip, it would be _very_ unreliable.
This seems to be quite undesirable and risky for a clock chip.
Are you really sure that you want and need that ?

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