Let the drivers specify how many bytes they want to read with i2c_smbus_read_i2c_block_data(). So far, the block count was hard-coded to I2C_SMBUS_BLOCK_MAX (32), which did not make much sense. Many driver authors complained about this before, and I believe it's about time to fix it. Right now, authors have to do technically stupid things, such as individual byte reads or full-fledged I2C messaging, to work around the problem. We do not want to encourage that. I even found that some bus drivers (e.g. i2c-amd8111) already implemented I2C block read the "right" way, that is, they didn't follow the old, broken standard. The fact that it was never noticed before just shows how little i2c_smbus_read_i2c_block_data() was used, which isn't that surprising given how broken its prototype was so far. There are some obvious compatiblity considerations: * This changes the i2c_smbus_read_i2c_block_data() prototype. Users outside the kernel tree will notice at compilation time, and will have to update their code. * User-space has access to i2c_smbus_xfer() directly using i2c-dev, so the changed expectations would affect tools such as i2cdump. In order to preserve binary compatibility, we give I2C_SMBUS_I2C_BLOCK_DATA a new numeric value, and define I2C_SMBUS_I2C_BLOCK_BROKEN with the old numeric value. When i2c-dev receives a transaction with the old value, it can convert it to the new format on the fly. Signed-off-by: Jean Delvare <khali@linux-fr.org>
		
			
				
	
	
		
			109 lines
		
	
	
		
			3.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			109 lines
		
	
	
		
			3.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| Kernel driver max6875
 | |
| =====================
 | |
| 
 | |
| Supported chips:
 | |
|   * Maxim MAX6874, MAX6875
 | |
|     Prefix: 'max6875'
 | |
|     Addresses scanned: None (see below)
 | |
|     Datasheet:
 | |
|         http://pdfserv.maxim-ic.com/en/ds/MAX6874-MAX6875.pdf
 | |
| 
 | |
| Author: Ben Gardner <bgardner@wabtec.com>
 | |
| 
 | |
| 
 | |
| Description
 | |
| -----------
 | |
| 
 | |
| The Maxim MAX6875 is an EEPROM-programmable power-supply sequencer/supervisor.
 | |
| It provides timed outputs that can be used as a watchdog, if properly wired.
 | |
| It also provides 512 bytes of user EEPROM.
 | |
| 
 | |
| At reset, the MAX6875 reads the configuration EEPROM into its configuration
 | |
| registers.  The chip then begins to operate according to the values in the
 | |
| registers.
 | |
| 
 | |
| The Maxim MAX6874 is a similar, mostly compatible device, with more intputs
 | |
| and outputs:
 | |
|              vin     gpi    vout
 | |
| MAX6874        6       4       8
 | |
| MAX6875        4       3       5
 | |
| 
 | |
| See the datasheet for more information.
 | |
| 
 | |
| 
 | |
| Sysfs entries
 | |
| -------------
 | |
| 
 | |
| eeprom        - 512 bytes of user-defined EEPROM space.
 | |
| 
 | |
| 
 | |
| General Remarks
 | |
| ---------------
 | |
| 
 | |
| Valid addresses for the MAX6875 are 0x50 and 0x52.
 | |
| Valid addresses for the MAX6874 are 0x50, 0x52, 0x54 and 0x56.
 | |
| The driver does not probe any address, so you must force the address.
 | |
| 
 | |
| Example:
 | |
| $ modprobe max6875 force=0,0x50
 | |
| 
 | |
| The MAX6874/MAX6875 ignores address bit 0, so this driver attaches to multiple
 | |
| addresses.  For example, for address 0x50, it also reserves 0x51.
 | |
| The even-address instance is called 'max6875', the odd one is 'max6875 subclient'.
 | |
| 
 | |
| 
 | |
| Programming the chip using i2c-dev
 | |
| ----------------------------------
 | |
| 
 | |
| Use the i2c-dev interface to access and program the chips.
 | |
| Reads and writes are performed differently depending on the address range.
 | |
| 
 | |
| The configuration registers are at addresses 0x00 - 0x45.
 | |
| Use i2c_smbus_write_byte_data() to write a register and
 | |
| i2c_smbus_read_byte_data() to read a register.
 | |
| The command is the register number.
 | |
| 
 | |
| Examples:
 | |
| To write a 1 to register 0x45:
 | |
|   i2c_smbus_write_byte_data(fd, 0x45, 1);
 | |
| 
 | |
| To read register 0x45:
 | |
|   value = i2c_smbus_read_byte_data(fd, 0x45);
 | |
| 
 | |
| 
 | |
| The configuration EEPROM is at addresses 0x8000 - 0x8045.
 | |
| The user EEPROM is at addresses 0x8100 - 0x82ff.
 | |
| 
 | |
| Use i2c_smbus_write_word_data() to write a byte to EEPROM.
 | |
| 
 | |
| The command is the upper byte of the address: 0x80, 0x81, or 0x82.
 | |
| The data word is the lower part of the address or'd with data << 8.
 | |
|   cmd = address >> 8;
 | |
|   val = (address & 0xff) | (data << 8);
 | |
| 
 | |
| Example:
 | |
| To write 0x5a to address 0x8003:
 | |
|   i2c_smbus_write_word_data(fd, 0x80, 0x5a03);
 | |
| 
 | |
| 
 | |
| Reading data from the EEPROM is a little more complicated.
 | |
| Use i2c_smbus_write_byte_data() to set the read address and then
 | |
| i2c_smbus_read_byte() or i2c_smbus_read_i2c_block_data() to read the data.
 | |
| 
 | |
| Example:
 | |
| To read data starting at offset 0x8100, first set the address:
 | |
|   i2c_smbus_write_byte_data(fd, 0x81, 0x00);
 | |
| 
 | |
| And then read the data
 | |
|   value = i2c_smbus_read_byte(fd);
 | |
| 
 | |
|   or
 | |
| 
 | |
|   count = i2c_smbus_read_i2c_block_data(fd, 0x84, 16, buffer);
 | |
| 
 | |
| The block read should read 16 bytes.
 | |
| 0x84 is the block read command.
 | |
| 
 | |
| See the datasheet for more details.
 | |
| 
 |