 7a8d29cec7
			
		
	
	
	7a8d29cec7
	
	
	
		
			
			i2c-stub: Chip address as a module parameter Add a mandatory chip_addr parameter to i2c-stub. This parameter defines to which chip address the driver will respond, instead of reponding to all addresses as before. The idea is to prevent the users from loading i2c-stub at random and being then confused by the results of sensors-detect or other user-space tools. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
		
			
				
	
	
		
			49 lines
		
	
	
	
		
			1.7 KiB
			
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			49 lines
		
	
	
	
		
			1.7 KiB
			
		
	
	
	
		
			Text
		
	
	
	
	
	
| MODULE: i2c-stub
 | |
| 
 | |
| DESCRIPTION:
 | |
| 
 | |
| This module is a very simple fake I2C/SMBus driver.  It implements four
 | |
| types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, and
 | |
| (r/w) word data.
 | |
| 
 | |
| You need to provide a chip address as a module parameter when loading
 | |
| this driver, which will then only react to SMBus commands to this address.
 | |
| 
 | |
| No hardware is needed nor associated with this module.  It will accept write
 | |
| quick commands to one address; it will respond to the other commands (also
 | |
| to one address) by reading from or writing to an array in memory.  It will
 | |
| also spam the kernel logs for every command it handles.
 | |
| 
 | |
| A pointer register with auto-increment is implemented for all byte
 | |
| operations.  This allows for continuous byte reads like those supported by
 | |
| EEPROMs, among others.
 | |
| 
 | |
| The typical use-case is like this:
 | |
| 	1. load this module
 | |
| 	2. use i2cset (from lm_sensors project) to pre-load some data
 | |
| 	3. load the target sensors chip driver module
 | |
| 	4. observe its behavior in the kernel log
 | |
| 
 | |
| PARAMETERS:
 | |
| 
 | |
| int chip_addr:
 | |
| 	The SMBus address to emulate a chip at.
 | |
| 
 | |
| CAVEATS:
 | |
| 
 | |
| There are independent arrays for byte/data and word/data commands.  Depending
 | |
| on if/how a target driver mixes them, you'll need to be careful.
 | |
| 
 | |
| If your target driver polls some byte or word waiting for it to change, the
 | |
| stub could lock it up.  Use i2cset to unlock it.
 | |
| 
 | |
| If the hardware for your driver has banked registers (e.g. Winbond sensors
 | |
| chips) this module will not work well - although it could be extended to
 | |
| support that pretty easily.
 | |
| 
 | |
| Only one chip address is supported - although this module could be
 | |
| extended to support more.
 | |
| 
 | |
| If you spam it hard enough, printk can be lossy.  This module really wants
 | |
| something like relayfs.
 | |
| 
 |