struct_ff_device(9) [centos man page]

STRUCT 
FF_DEVICE(9)						  Input Subsystem					       STRUCT FF_DEVICE(9)

NAME

       struct_ff_device - force-feedback part of an input device

SYNOPSIS

       struct ff_device {
	 int (* upload) (struct input_dev *dev, struct ff_effect *effect,struct ff_effect *old);
	 int (* erase) (struct input_dev *dev, int effect_id);
	 int (* playback) (struct input_dev *dev, int effect_id, int value);
	 void (* set_gain) (struct input_dev *dev, u16 gain);
	 void (* set_autocenter) (struct input_dev *dev, u16 magnitude);
	 void (* destroy) (struct ff_device *);
	 void * private;
	 unsigned long ffbit[BITS_TO_LONGS(FF_CNT)];
	 struct mutex mutex;
	 int max_effects;
	 struct ff_effect * effects;
	 struct file * effect_owners[];
       };

MEMBERS

       upload
	   Called to upload an new effect into device

       erase
	   Called to erase an effect from device

       playback
	   Called to request device to start playing specified effect

       set_gain
	   Called to set specified gain

       set_autocenter
	   Called to auto-center device

       destroy
	   called by input core when parent input device is being destroyed

       private
	   driver-specific data, will be freed automatically

       ffbit[BITS_TO_LONGS(FF_CNT)]
	   bitmap of force feedback capabilities truly supported by device (not emulated like ones in input_dev->ffbit)

       mutex
	   mutex for serializing access to the device

       max_effects
	   maximum number of effects supported by device

       effects
	   pointer to an array of effects currently loaded into device

       effect_owners[]
	   array of effect owners; when file handle owning an effect gets closed the effect is automatically erased

DESCRIPTION

       Every force-feedback device must implement upload and playback methods; erase is optional.  set_gain and set_autocenter need only be
       implemented if driver sets up FF_GAIN and FF_AUTOCENTER bits.

       Note that playback, set_gain and set_autocenter are called with dev->event_lock spinlock held and interrupts off and thus may not sleep.

COPYRIGHT

Kernel Hackers Manual 3.10					     June 2014						       STRUCT FF_DEVICE(9)

STRUCT 
DEVICE_DRIVER(9) 				   Device drivers infrastructure				   STRUCT DEVICE_DRIVER(9)

NAME

       struct_device_driver - The basic device driver structure

SYNOPSIS

       struct device_driver {
	 const char * name;
	 struct bus_type * bus;
	 struct module * owner;
	 const char * mod_name;
	 bool suppress_bind_attrs;
	 const struct of_device_id * of_match_table;
	 const struct acpi_device_id * acpi_match_table;
	 int (* probe) (struct device *dev);
	 int (* remove) (struct device *dev);
	 void (* shutdown) (struct device *dev);
	 int (* suspend) (struct device *dev, pm_message_t state);
	 int (* resume) (struct device *dev);
	 const struct attribute_group ** groups;
	 const struct dev_pm_ops * pm;
	 struct driver_private * p;
       };

MEMBERS

       name
	   Name of the device driver.

       bus
	   The bus which the device of this driver belongs to.

       owner
	   The module owner.

       mod_name
	   Used for built-in modules.

       suppress_bind_attrs
	   Disables bind/unbind via sysfs.

       of_match_table
	   The open firmware table.

       acpi_match_table
	   The ACPI match table.

       probe
	   Called to query the existence of a specific device, whether this driver can work with it, and bind the driver to a specific device.

       remove
	   Called when the device is removed from the system to unbind a device from this driver.

       shutdown
	   Called at shut-down time to quiesce the device.

       suspend
	   Called to put the device to sleep mode. Usually to a low power state.

       resume
	   Called to bring a device from sleep mode.

       groups
	   Default attributes that get created by the driver core automatically.

       pm
	   Power management operations of the device which matched this driver.

       p
	   Driver core's private data, no one other than the driver core can touch this.

DESCRIPTION

       The device driver-model tracks all of the drivers known to the system. The main reason for this tracking is to enable the driver core to
       match up drivers with new devices. Once drivers are known objects within the system, however, a number of other things become possible.
       Device drivers can export information and configuration variables that are independent of any specific device.

COPYRIGHT

Kernel Hackers Manual 3.10					     June 2014						   STRUCT DEVICE_DRIVER(9)