Skip to contentSkip to conversation

I2C class bitmask

DISCUSSION York Sun 2 participants 3 messages May 21, 2015 – May 23, 2015 I2C subsystem host drivers

lore
Share & tools
lore

York Sun

author
#0 lore raw

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.

York

#1 lore raw
Quoted 5 lines · York Sun

Lee,

Is there any convention regarding I2C class bitmask? I see only three are defined for 3.12.19 and four for 4.0

Quoted 7 lines

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

author
#2 lore raw
Quoted 34 lines · Guenter Roeck
Quoted 5 lines · York Sun

Lee,

Is there any convention regarding I2C class bitmask? I see only three are defined for 3.12.19 and four for 4.0

Quoted 7 lines

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 ?

Quoted 8 lines

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 ?

Guenter,

Thanks for replying.

No, I don't have to use autodetect. I was curious why there weren't more classes. I failed to notice which method is preferred in the mentioned document. I used to declare the devices by the bus number but met some issue when they are behind a mux. I temporarily used auto detect before I figure out how to describe the mux with i2c_board_info.

Knowing auto-detection is not preferred, I will remove it from the proposed driver.

Thanks again.

York