Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

struct_i2c_driver(9) [centos man page]

struct_i2c_driver - represent an I2C device driver SYNOPSIS
struct i2c_driver { unsigned int class; int (* attach_adapter) (struct i2c_adapter *); int (* probe) (struct i2c_client *, const struct i2c_device_id *); int (* remove) (struct i2c_client *); void (* shutdown) (struct i2c_client *); int (* suspend) (struct i2c_client *, pm_message_t mesg); int (* resume) (struct i2c_client *); void (* alert) (struct i2c_client *, unsigned int data); int (* command) (struct i2c_client *client, unsigned int cmd, void *arg); struct device_driver driver; const struct i2c_device_id * id_table; int (* detect) (struct i2c_client *, struct i2c_board_info *); const unsigned short * address_list; struct list_head clients; }; MEMBERS
class What kind of i2c device we instantiate (for detect) attach_adapter Callback for bus addition (deprecated) probe Callback for device binding remove Callback for device unbinding shutdown Callback for device shutdown suspend Callback for device suspend resume Callback for device resume alert Alert callback, for example for the SMBus alert protocol command Callback for bus-wide signaling (optional) driver Device driver model driver id_table List of I2C devices supported by this driver detect Callback for device detection address_list The I2C addresses to probe (for detect) clients List of detected clients we created (for i2c-core use only) DESCRIPTION
The driver.owner field should be set to the module owner of this driver. The field should be set to the name of this driver. For automatic device detection, both detect and address_list must be defined. class should also be set, otherwise only devices forced with module parameters will be created. The detect function must fill at least the name field of the i2c_board_info structure it is handed upon successful detection, and possibly also the flags field. If detect is missing, the driver will still work fine for enumerated devices. Detected devices simply won't be supported. This is expected for the many I2C/SMBus devices which can't be detected reliably, and the ones which can always be enumerated in practice. The i2c_client structure which is handed to the detect callback is not a real i2c_client. It is initialized just enough so that you can call i2c_smbus_read_byte_data and friends on it. Don't do anything else with it. In particular, calling dev_dbg and friends on it is not allowed. COPYRIGHT
Kernel Hackers Manual 3.10 June 2014 STRUCT I2C_DRIVER(9)

Check Out this Related Man Page

SPI_DRIVER(9) Serial Peripheral Interface (S STRUCT SPI_DRIVER(9) NAME
struct_spi_driver - Host side "protocol" driver SYNOPSIS
struct spi_driver { const struct spi_device_id * id_table; int (* probe) (struct spi_device *spi); int (* remove) (struct spi_device *spi); void (* shutdown) (struct spi_device *spi); int (* suspend) (struct spi_device *spi, pm_message_t mesg); int (* resume) (struct spi_device *spi); struct device_driver driver; }; MEMBERS
id_table List of SPI devices supported by this driver probe Binds this driver to the spi device. Drivers can verify that the device is actually present, and may need to configure characteristics (such as bits_per_word) which weren't needed for the initial configuration done during system setup. remove Unbinds this driver from the spi device shutdown Standard shutdown callback used during system state transitions such as powerdown/halt and kexec suspend Standard suspend callback used during system state transitions resume Standard resume callback used during system state transitions driver SPI device drivers should initialize the name and owner field of this structure. DESCRIPTION
This represents the kind of device driver that uses SPI messages to interact with the hardware at the other end of a SPI link. It's called a "protocol" driver because it works through messages rather than talking directly to SPI hardware (which is what the underlying SPI controller driver does to pass those messages). These protocols are defined in the specification for the device(s) supported by the driver. As a rule, those device protocols represent the lowest level interface supported by a driver, and it will support upper level interfaces too. Examples of such upper levels include frameworks like MTD, networking, MMC, RTC, filesystem character device nodes, and hardware monitoring. COPYRIGHT
Kernel Hackers Manual 2.6. July 2010 STRUCT SPI_DRIVER(9)
Man Page

Featured Tech Videos