struct_i2c_driver(9) [centos man page]
STRUCT
I2C_DRIVER(9) I2C and SMBus Subsystem STRUCT I2C_DRIVER(9) NAME
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 driver.name 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
STRUCT
BUS_TYPE(9) Device drivers infrastructure STRUCT BUS_TYPE(9) NAME
struct_bus_type - The bus type of the device SYNOPSIS
struct bus_type { const char * name; const char * dev_name; struct device * dev_root; struct bus_attribute * bus_attrs; struct device_attribute * dev_attrs; struct driver_attribute * drv_attrs; const struct attribute_group ** bus_groups; const struct attribute_group ** dev_groups; const struct attribute_group ** drv_groups; int (* match) (struct device *dev, struct device_driver *drv); int (* uevent) (struct device *dev, struct kobj_uevent_env *env); int (* probe) (struct device *dev); int (* remove) (struct device *dev); void (* shutdown) (struct device *dev); int (* online) (struct device *dev); int (* offline) (struct device *dev); int (* suspend) (struct device *dev, pm_message_t state); int (* resume) (struct device *dev); const struct dev_pm_ops * pm; struct iommu_ops * iommu_ops; struct subsys_private * p; }; MEMBERS
name The name of the bus. dev_name Used for subsystems to enumerate devices like ("foou", dev->id). dev_root Default device to use as the parent. bus_attrs Default attributes of the bus. dev_attrs Default attributes of the devices on the bus. drv_attrs Default attributes of the device drivers on the bus. bus_groups Default attributes of the bus. dev_groups Default attributes of the devices on the bus. drv_groups Default attributes of the device drivers on the bus. match Called, perhaps multiple times, whenever a new device or driver is added for this bus. It should return a nonzero value if the given device can be handled by the given driver. uevent Called when a device is added, removed, or a few other things that generate uevents to add the environment variables. probe Called when a new device or driver add to this bus, and callback the specific driver's probe to initial the matched device. remove Called when a device removed from this bus. shutdown Called at shut-down time to quiesce the device. online Called to put the device back online (after offlining it). offline Called to put the device offline for hot-removal. May fail. suspend Called when a device on this bus wants to go to sleep mode. resume Called to bring a device on this bus out of sleep mode. pm Power management operations of this bus, callback the specific device driver's pm-ops. iommu_ops IOMMU specific operations for this bus, used to attach IOMMU driver implementations to a bus and allow the driver to do bus-specific setup p The private data of the driver core, only the driver core can touch this. DESCRIPTION
A bus is a channel between the processor and one or more devices. For the purposes of the device model, all devices are connected via a bus, even if it is an internal, virtual, "platform" bus. Buses can plug into each other. A USB controller is usually a PCI device, for example. The device model represents the actual connections between buses and the devices they control. A bus is represented by the bus_type structure. It contains the name, the default attributes, the bus' methods, PM operations, and the driver core's private data. COPYRIGHT
Kernel Hackers Manual 3.10 June 2014 STRUCT BUS_TYPE(9)