Sync cvs tree with latest 2.5 bk tree
PATCH 1/1 Sync cvs tree with latest 2.5 bk tree
Hi all,
Here's a patch to sync up the lmsensors cvs tree with the current 2.5 bk tree. Anyone with commit permissions want to submit it?
The header files should be renamed too, as they have been in the kernel tree, but a cvs diff can't show that :)
I'll submit a i2c sync patch, after this is applied, as that is out of date quite a bit too.
Ah, now you all see why it's tough to do work in two trees...
thanks,
greg k-h
Index: kernel/busses/i2c-ali15x3.c
=================================RCS file: /home/cvs/lm_sensors2/kernel/busses/i2c-ali15x3.c,v retrieving revision 1.28
busses/i2c-ali15x3.c +150 -198
@@ -60,6 +60,8 @@/* Note: we assume there can only be one ALI15X3, with one SMBus interface */ +/* #define DEBUG 1 */ +#include <linux/module.h> #include <linux/pci.h> #include <linux/kernel.h>
@@ -69,49 +71,48 @@#include <linux/i2c.h> #include <linux/init.h> #include <asm/io.h> -#include "version.h" /* ALI15X3 SMBus address offsets */ -#define SMBHSTSTS (0 + ali15x3_smba) -#define SMBHSTCNT (1 + ali15x3_smba) -#define SMBHSTSTART (2 + ali15x3_smba) -#define SMBHSTCMD (7 + ali15x3_smba) -#define SMBHSTADD (3 + ali15x3_smba) -#define SMBHSTDAT0 (4 + ali15x3_smba) -#define SMBHSTDAT1 (5 + ali15x3_smba) -#define SMBBLKDAT (6 + ali15x3_smba) +#define SMBHSTSTS (0 + ali15x3_smba) +#define SMBHSTCNT (1 + ali15x3_smba) +#define SMBHSTSTART (2 + ali15x3_smba) +#define SMBHSTCMD (7 + ali15x3_smba) +#define SMBHSTADD (3 + ali15x3_smba) +#define SMBHSTDAT0 (4 + ali15x3_smba) +#define SMBHSTDAT1 (5 + ali15x3_smba) +#define SMBBLKDAT (6 + ali15x3_smba)/* PCI Address Constants */ -#define SMBCOM 0x004 -#define SMBBA 0x014 -#define SMBATPC 0x05B/* used to unlock xxxBA registers */ -#define SMBHSTCFG 0x0E0 -#define SMBSLVC 0x0E1 -#define SMBCLK 0x0E2 -#define SMBREV 0x008 +#define SMBCOM 0x004 +#define SMBBA 0x014 +#define SMBATPC 0x05B/* used to unlock xxxBA registers */ +#define SMBHSTCFG 0x0E0 +#define SMBSLVC 0x0E1 +#define SMBCLK 0x0E2 +#define SMBREV 0x008/* Other settings */ -#define MAX_TIMEOUT 200/* times 1/100 sec */ -#define ALI15X3_SMB_IOSIZE 32 +#define MAX_TIMEOUT 200/* times 1/100 sec */ +#define ALI15X3_SMB_IOSIZE 32/* this is what the Award 1004 BIOS sets them to on a ASUS P5A MB. We don't use these here. If the bases aren't set to some value we tell user to upgrade BIOS and we fail. */ -#define ALI15X3_SMB_DEFAULTBASE 0xE800 +#define ALI15X3_SMB_DEFAULTBASE 0xE800/* ALI15X3 address lock bits */ -#define ALI15X3_LOCK 0x06 +#define ALI15X3_LOCK 0x06/* ALI15X3 command constants */ -#define ALI15X3_ABORT 0x02 -#define ALI15X3_T_OUT 0x04 -#define ALI15X3_QUICK 0x00 -#define ALI15X3_BYTE 0x10 -#define ALI15X3_BYTE_DATA 0x20 -#define ALI15X3_WORD_DATA 0x30 -#define ALI15X3_BLOCK_DATA 0x40 -#define ALI15X3_BLOCK_CLR 0x80 +#define ALI15X3_ABORT 0x02 +#define ALI15X3_T_OUT 0x04 +#define ALI15X3_QUICK 0x00 +#define ALI15X3_BYTE 0x10 +#define ALI15X3_BYTE_DATA 0x20 +#define ALI15X3_WORD_DATA 0x30 +#define ALI15X3_BLOCK_DATA 0x40 +#define ALI15X3_BLOCK_CLR 0x80/* ALI15X3 status register bits */ #define ALI15X3_STS_IDLE 0x04
@@ -130,77 +131,52 @@MODULE_PARM_DESC (force_addr,"Initialize the base address of the i2c controller" ); - -static void ali15x3_do_pause (unsigned int amount); -static int ali15x3_transaction (void ); -static unsigned short ali15x3_smba =0 ; -static int locked=0 ; -/* Detect whether a ALI15X3 can be found, and initialize it, where necessary. -Note the differences between kernels with the old PCI BIOS interface and -newer kernels with the real PCI interface. In compat.h some things are -defined to make the transition easier. */ -int ali15x3_setup (void ) +static int ali15x3_setup (struct pci_dev *ALI15X3_dev) {u16 a;unsigned char temp; -struct pci_dev *ALI15X3_dev; - -/* First check whether we can access PCI at all */ -if (pci_present () =0 ) { -printk ("i2c-ali15x3.o: Error: No PCI-bus found!\n" ); -return -ENODEV ; - } - -/* Look for the ALI15X3, M7101 device */ - ALI15X3_dev =NULL ; - ALI15X3_dev =pci_find_device (PCI_VENDOR_ID_AL , -PCI_DEVICE_ID_AL_M7101 , ALI15X3_dev); -if (ALI15X3_dev =NULL ) { -printk ("i2c-ali15x3.o: Error: Can't detect ali15x3!\n" ); -return -ENODEV ; - } - -/* Check the following things: -- SMB I/O address is initialized -- Device is enabled -- We can use the addresses -*/ - -/* Unlock the register. -The data sheet says that the address registers are read-only -if the lock bits are 1, but in fact the address registers -are zero unless you clear the lock bits. -*/ +/* Check the following things: +- SMB I/O address is initialized +- Device is enabled +- We can use the addresses +*/ + +/* Unlock the register. +The data sheet says that the address registers are read-only +if the lock bits are 1, but in fact the address registers +are zero unless you clear the lock bits. +*/ pci_read_config_byte (ALI15X3_dev,SMBATPC , &temp);if (temp &ALI15X3_LOCK ) { temp &= ~ALI15X3_LOCK ;pci_write_config_byte (ALI15X3_dev,SMBATPC , temp); } -/* Determine the address of the SMBus area */ +/* Determine the address of the SMBus area */ pci_read_config_word (ALI15X3_dev,SMBBA , &ali15x3_smba); ali15x3_smba &= (0xffff & ~(ALI15X3_SMB_IOSIZE -1 ));if (ali15x3_smba =0 && force_addr =0 ) { -printk - ("i2c-ali15x3.o: ALI15X3_smb region uninitialized - upgrade BIOS or use force_addr=0xaddr\n" ); +dev_err (&ALI15X3_dev->dev,"ALI15X3_smb region uninitialized " +"- upgrade BIOS or use force_addr=0xaddr\n" );return -ENODEV ; }if (force_addr) ali15x3_smba = force_addr & ~(ALI15X3_SMB_IOSIZE -1 ); -if (check_region (ali15x3_smba,ALI15X3_SMB_IOSIZE )) { -printk - ("i2c-ali15x3.o: ALI15X3_smb region 0x%x already in use!\n" , - ali15x3_smba); +if (!request_region (ali15x3_smba,ALI15X3_SMB_IOSIZE ,"ali15x3-smb" )) { +dev_err (&ALI15X3_dev->dev, +"ALI15X3_smb region 0x%x already in use!\n" , + ali15x3_smba);return -ENODEV ; }if (force_addr) { -printk ("i2c-ali15x3.o: forcing ISA address 0x%04X\n" , ali15x3_smba); +dev_info (&ALI15X3_dev->dev,"forcing ISA address 0x%04X\n" , + ali15x3_smba); if (PCIBIOS_SUCCESSFUL ! pci_write_config_word(ALI15X3_dev, SMBBA, ali15x3_smba))return -ENODEV ;
@@ -209,68 +185,60 @@return -ENODEV ;if ((a & ~(ALI15X3_SMB_IOSIZE -1 )) != ali15x3_smba) {/* make sure it works */ -printk ("i2c-ali15x3.o: force address failed - not supported?\n" ); +dev_err (&ALI15X3_dev->dev, +"force address failed - not supported?\n" );return -ENODEV ; } } -/* check if whole device is enabled */ +/* check if whole device is enabled */ pci_read_config_byte (ALI15X3_dev,SMBCOM , &temp);if ((temp &1 ) =0 ) { -printk ("i2c-ali15x3: enabling SMBus device\n" ); +dev_info (&ALI15X3_dev->dev,"enabling SMBus device\n" );pci_write_config_byte (ALI15X3_dev,SMBCOM , temp |0x01 ); } -/* Is SMB Host controller enabled? */ +/* Is SMB Host controller enabled? */ pci_read_config_byte (ALI15X3_dev,SMBHSTCFG , &temp);if ((temp &1 ) =0 ) { -printk ("i2c-ali15x3: enabling SMBus controller\n" ); +dev_info (&ALI15X3_dev->dev,"enabling SMBus controller\n" );pci_write_config_byte (ALI15X3_dev,SMBHSTCFG , temp |0x01 ); } -/* set SMB clock to 74KHz as recommended in data sheet */ +/* set SMB clock to 74KHz as recommended in data sheet */ pci_write_config_byte (ALI15X3_dev,SMBCLK ,0x20 ); -/* Everything is happy, let's grab the memory and set things up. */ -request_region (ali15x3_smba,ALI15X3_SMB_IOSIZE ,"ali15x3-smb" ); - -#ifdef DEBUG -/* -The interrupt routing for SMB is set up in register 0x77 in the -1533 ISA Bridge device, NOT in the 7101 device. -Don't bother with finding the 1533 device and reading the register. -if ((....... & 0x0F) = 1) -printk("i2c-ali15x3.o: ALI15X3 using Interrupt 9 for SMBus.\n"); -*/ +/* +The interrupt routing for SMB is set up in register 0x77 in the +1533 ISA Bridge device, NOT in the 7101 device. +Don't bother with finding the 1533 device and reading the register. +if ((....... & 0x0F) = 1) +dev_dbg(&ALI15X3_dev->dev, "ALI15X3 using Interrupt 9 for SMBus.\n"); +*/ pci_read_config_byte (ALI15X3_dev,SMBREV , &temp); -printk ("i2c-ali15x3.o: SMBREV = 0x%X\n" , temp); -printk ("i2c-ali15x3.o: ALI15X3_smba = 0x%X\n" , ali15x3_smba); -#endif /* DEBUG */ +dev_dbg (&ALI15X3_dev->dev,"SMBREV = 0x%X\n" , temp); +dev_dbg (&ALI15X3_dev->dev,"iALI15X3_smba = 0x%X\n" , ali15x3_smba);return 0 ; } -/* Internally used pause function */ -void ali15x3_do_pause (unsigned int amount) +static void ali15x3_do_pause (unsigned int amount) { current->state =TASK_INTERRUPTIBLE ;schedule_timeout (amount); }/* Another internally used function */ -int ali15x3_transaction (void ) +static int ali15x3_transaction (struct i2c_adapter *adap) {int temp;int result =0 ;int timeout =0 ; -#ifdef DEBUG -printk - ("i2c-ali15x3.o: Transaction (pre): STS=%02x, CNT=%02x, CMD=%02x, ADD=%02x, DAT0=%02x, " -"DAT1=%02x\n" ,inb_p (SMBHSTSTS ),inb_p (SMBHSTCNT ), -inb_p (SMBHSTCMD ),inb_p (SMBHSTADD ),inb_p (SMBHSTDAT0 ), -inb_p (SMBHSTDAT1 )); -#endif +dev_dbg (&adap->dev,"Transaction (pre): STS=%02x, CNT=%02x, CMD=%02x, " +"ADD=%02x, DAT0=%02x, DAT1=%02x\n" ,inb_p (SMBHSTSTS ), +inb_p (SMBHSTCNT ),inb_p (SMBHSTCMD ),inb_p (SMBHSTADD ), +inb_p (SMBHSTDAT0 ),inb_p (SMBHSTDAT1 ));/* get status */ temp =inb_p (SMBHSTSTS );
@@ -278,43 +246,32 @@/* Make sure the SMBus host is ready to start transmitting */ /* Check the busy bit first */ if (temp &ALI15X3_STS_BUSY ) { -/* -If the host controller is still busy, it may have timed out in the previous transaction, -resulting in a "SMBus Timeout" printk. -I've tried the following to reset a stuck busy bit. -1. Reset the controller with an ABORT command. -(this doesn't seem to clear the controller if an external device is hung) -2. Reset the controller and the other SMBus devices with a T_OUT command. -(this clears the host busy bit if an external device is hung, -but it comes back upon a new access to a device) -3. Disable and reenable the controller in SMBHSTCFG -Worst case, nothing seems to work except power reset. -*/ -/* Abort - reset the host controller */ -/* -#ifdef DEBUG -printk("i2c-ali15x3.o: Resetting host controller to clear busy condition\n",temp); -#endif -outb_p(ALI15X3_ABORT, SMBHSTCNT); -temp = inb_p(SMBHSTSTS); -if (temp & ALI15X3_STS_BUSY) { -*/ - -/* -Try resetting entire SMB bus, including other devices - -This may not work either - it clears the BUSY bit but -then the BUSY bit may come back on when you try and use the chip again. -If that's the case you are stuck. -*/ -printk - ("i2c-ali15x3.o: Resetting entire SMB Bus to clear busy condition (%02x)\n" , - temp); +/* +If the host controller is still busy, it may have timed out in the +previous transaction, resulting in a "SMBus Timeout" Dev. +I've tried the following to reset a stuck busy bit. +1. Reset the controller with an ABORT command. +(this doesn't seem to clear the controller if an external +device is hung) +2. Reset the controller and the other SMBus devices with a +T_OUT command. (this clears the host busy bit if an +external device is hung, but it comes back upon a new access +to a device) +3. Disable and reenable the controller in SMBHSTCFG +Worst case, nothing seems to work except power reset. +*/ +/* Abort - reset the host controller */ +/* +Try resetting entire SMB bus, including other devices - +This may not work either - it clears the BUSY bit but +then the BUSY bit may come back on when you try and use the chip again. +If that's the case you are stuck. +*/ +dev_info (&adap->dev,"Resetting entire SMB Bus to " +"clear busy condition (%02x)\n" , temp);outb_p (ALI15X3_T_OUT ,SMBHSTCNT ); temp =inb_p (SMBHSTSTS ); } -/* -} -*/ /* now check the error bits and the busy bit */ if (temp & (ALI15X3_STS_ERR |ALI15X3_STS_BUSY )) {
@@ -325,9 +282,9 @@/* this is probably going to be correctable only by a power reset as one of the bits now appears to be stuck */ /* This may be a bus or device with electrical problems. */ -printk - ("i2c-ali15x3.o: SMBus reset failed! (0x%02x) - controller or device on bus is probably hung\n" , - temp); +dev_err (&adap->dev,"SMBus reset failed! (0x%02x) - " +"controller or device on bus is probably hung\n" , + temp);return -1 ; } }else {
@@ -351,48 +308,41 @@/* If the SMBus is still busy, we give up */ if (timeout >=MAX_TIMEOUT ) { result =-1 ; -printk ("i2c-ali15x3.o: SMBus Timeout!\n" ); +dev_err (&adap->dev,"SMBus Timeout!\n" ); }if (temp &ALI15X3_STS_TERM ) { result =-1 ; -#ifdef DEBUG -printk ("i2c-ali15x3.o: Error: Failed bus transaction\n" ); -#endif +dev_dbg (&adap->dev,"Error: Failed bus transaction\n" ); } -/* -Unfortunately the ALI SMB controller maps "no response" and "bus collision" -into a single bit. No reponse is the usual case so don't -do a printk. -This means that bus collisions go unreported. -*/ +/* +Unfortunately the ALI SMB controller maps "no response" and "bus +collision" into a single bit. No reponse is the usual case so don't +do a printk. +This means that bus collisions go unreported. +*/ if (temp &ALI15X3_STS_COLL ) { result =-1 ; -#ifdef DEBUG -printk - ("i2c-ali15x3.o: Error: no response or bus collision ADD=%02x\n" , -inb_p (SMBHSTADD )); -#endif +dev_dbg (&adap->dev, +"Error: no response or bus collision ADD=%02x\n" , +inb_p (SMBHSTADD )); } -/* haven't ever seen this */ +/* haven't ever seen this */ if (temp &ALI15X3_STS_DEV ) { result =-1 ; -printk ("i2c-ali15x3.o: Error: device error\n" ); +dev_err (&adap->dev,"Error: device error\n" ); } -#ifdef DEBUG -printk - ("i2c-ali15x3.o: Transaction (post): STS=%02x, CNT=%02x, CMD=%02x, ADD=%02x, " -"DAT0=%02x, DAT1=%02x\n" ,inb_p (SMBHSTSTS ),inb_p (SMBHSTCNT ), -inb_p (SMBHSTCMD ),inb_p (SMBHSTADD ),inb_p (SMBHSTDAT0 ), -inb_p (SMBHSTDAT1 )); -#endif +dev_dbg (&adap->dev,"Transaction (post): STS=%02x, CNT=%02x, CMD=%02x, " +"ADD=%02x, DAT0=%02x, DAT1=%02x\n" ,inb_p (SMBHSTSTS ), +inb_p (SMBHSTCNT ),inb_p (SMBHSTCMD ),inb_p (SMBHSTADD ), +inb_p (SMBHSTDAT0 ),inb_p (SMBHSTDAT1 ));return result; }/* Return -1 on error. */ -s32 ali15x3_access (struct i2c_adapter * adap,u16 addr, +static s32 ali15x3_access (struct i2c_adapter * adap,u16 addr,unsigned short flags,char read_write,u8 command,int size,union i2c_smbus_data * data) {
@@ -400,9 +350,9 @@int temp;int timeout; -/* clear all the bits (clear-on-write) */ +/* clear all the bits (clear-on-write) */ outb_p (0xFF ,SMBHSTSTS ); -/* make sure SMBus is idle */ +/* make sure SMBus is idle */ temp =inb_p (SMBHSTSTS ); for (timeout = 0; (timeout < MAX_TIMEOUT) && !(temp & ALI15X3_STS_IDLE);
@@ -411,14 +361,12 @@ temp =inb_p (SMBHSTSTS ); }if (timeout >=MAX_TIMEOUT ) { -printk ("i2c-ali15x3.o: Idle wait Timeout! STS=0x%02x\n" , - temp); +dev_err (&adap->dev,"Idle wait Timeout! STS=0x%02x\n" , temp); }switch (size) {case I2C_SMBUS_PROC_CALL : -printk - ("i2c-ali15x3.o: I2C_SMBUS_PROC_CALL not supported!\n" ); +dev_err (&adap->dev,"I2C_SMBUS_PROC_CALL not supported!\n" );return -1 ;case I2C_SMBUS_QUICK : outb_p(((addr & 0x7f) << 1) | (read_write & 0x01),
@@ -465,7 +413,8 @@ data->block[0 ] = len; }outb_p (len,SMBHSTDAT0 ); -outb_p (inb_p (SMBHSTCNT ) |ALI15X3_BLOCK_CLR ,SMBHSTCNT );/* Reset SMBBLKDAT */ +/* Reset SMBBLKDAT */ +outb_p (inb_p (SMBHSTCNT ) |ALI15X3_BLOCK_CLR ,SMBHSTCNT );for (i =1 ; i <= len; i++)outb_p (data->block[i],SMBBLKDAT ); }
@@ -475,7 +424,7 @@outb_p (size,SMBHSTCNT );/* output command */ -if (ali15x3_transaction ())/* Error in transaction */ +if (ali15x3_transaction (adap))/* Error in transaction */ return -1 ;if ((read_write =I2C_SMBUS_WRITE ) || (size =ALI15X3_QUICK ))
@@ -497,22 +446,19 @@if (len >32 ) len =32 ; data->block[0 ] = len; -outb_p (inb_p (SMBHSTCNT ) |ALI15X3_BLOCK_CLR ,SMBHSTCNT );/* Reset SMBBLKDAT */ +/* Reset SMBBLKDAT */ +outb_p (inb_p (SMBHSTCNT ) |ALI15X3_BLOCK_CLR ,SMBHSTCNT );for (i =1 ; i <= data->block[0 ]; i++) { data->block[i] =inb_p (SMBBLKDAT ); -#ifdef DEBUG -printk - ("i2c-ali15x3.o: Blk: len=%d, i=%d, data=%02x\n" , - len, i, data->block[i]); -#endif /* DEBUG */ +dev_dbg (&adap->dev,"Blk: len=%d, i=%d, data=%02x\n" , + len, i, data->block[i]); }break ; }return 0 ; } - -u32 ali15x3_func (struct i2c_adapter *adapter) +static u32 ali15x3_func (struct i2c_adapter *adapter) {return I2C_FUNC_SMBUS_QUICK |I2C_FUNC_SMBUS_BYTE | I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA |
@@ -528,29 +474,37 @@static struct i2c_adapter ali15x3_adapter = { .owner =THIS_MODULE , - .name ="unset" , .id =I2C_ALGO_SMBUS |I2C_HW_SMBUS_ALI15X3 , .algo = &smbus_algorithm, + .dev = { + .name ="unset" , + }, }; - -static struct pci_device_id ali15x3_ids[]__devinitdata = { + { + .vendor =PCI_VENDOR_ID_AL , + .device =PCI_DEVICE_ID_AL_M7101 , + .subvendor =PCI_ANY_ID , + .subdevice =PCI_ANY_ID , + }, {0 , } };static int __devinit ali15x3_probe (struct pci_dev *dev,const struct pci_device_id *id) { -if (ali15x3_setup ()) { -printk - ("i2c-ali15x3.o: ALI15X3 not detected, module not inserted.\n" ); - +if (ali15x3_setup (dev)) { +dev_err (&dev->dev, +"ALI15X3 not detected, module not inserted.\n" );return -ENODEV ; } -sprintf (ali15x3_adapter.name,"SMBus ALI15X3 adapter at %04x" , - ali15x3_smba); -i2c_add_adapter (&ali15x3_adapter); +/* set up the driverfs linkage to our parent device */ + ali15x3_adapter.dev.parent = &dev->dev; + +snprintf (ali15x3_adapter.dev.name,DEVICE_NAME_SIZE , +"SMBus ALI15X3 adapter at %04x" , ali15x3_smba); +return i2c_add_adapter (&ali15x3_adapter); } static void __devexit ali15x3_remove(struct pci_dev *dev)
@@ -567,21 +521,19 @@static int __init i2c_ali15x3_init (void ) { -printk ("i2c-ali15x3.o version %s (%s)\n" ,LM_VERSION ,LM_DATE ); +printk ("i2c-ali15x3.o version %s (%s)\n" ,I2C_VERSION ,I2C_DATE );return pci_module_init (&ali15x3_driver); } - static void __exit i2c_ali15x3_exit(void) {pci_unregister_driver (&ali15x3_driver);release_region (ali15x3_smba,ALI15X3_SMB_IOSIZE ); } - - -MODULE_AUTHOR - ("Frodo Looijaard <[email protected]>, Philip Edelbrock <[email protected]>, and Mark D. Studebaker <[email protected]>" ); +MODULE_AUTHOR ("Frodo Looijaard <[email protected]>, " +"Philip Edelbrock <[email protected]>, " +"and Mark D. Studebaker <[email protected]>" );MODULE_DESCRIPTION ("ALI15X3 SMBus driver" );MODULE_LICENSE ("GPL" );
Index: kernel/busses/i2c-amd756.c
=================================RCS file: /home/cvs/lm_sensors2/kernel/busses/i2c-amd756.c,v retrieving revision 1.25
busses/i2c-amd756.c +83 -84
325 lines not on this page · raw message
Index: kernel/busses/i2c-amd8111.c
=================================RCS file: /home/cvs/lm_sensors2/kernel/busses/i2c-amd8111.c,v retrieving revision 1.10
busses/i2c-amd8111.c +28 -30
127 lines not on this page · raw message
Index: kernel/busses/i2c-i801.c
=================================RCS file: /home/cvs/lm_sensors2/kernel/busses/i2c-i801.c,v retrieving revision 1.30
busses/i2c-i801.c +188 -261
688 lines not on this page · raw message
Index: kernel/busses/i2c-isa.c
=================================RCS file: /home/cvs/lm_sensors2/kernel/busses/i2c-isa.c,v retrieving revision 1.26
busses/i2c-isa.c +3 -3
@@ -29,7 +29,6 @@#include <linux/kernel.h> #include <linux/errno.h> #include <linux/i2c.h> -#include "version.h" /* This is the actual algorithm we define */ static struct i2c_algorithm isa_algorithm = {
@@ -40,14 +39,15 @@/* There can only be one... */ static struct i2c_adapter isa_adapter = { .owner =THIS_MODULE , - .name ="ISA main adapter" , .id =I2C_ALGO_ISA |I2C_HW_ISA , .algo = &isa_algorithm, + .dev = { + .name ="ISA main adapter" , + }, };static int __init i2c_isa_init (void ) { -printk ("i2c-isa.o version %s (%s)\n" ,LM_VERSION ,LM_DATE );return i2c_add_adapter (&isa_adapter); }
Index: kernel/busses/i2c-piix4.c
=================================RCS file: /home/cvs/lm_sensors2/kernel/busses/i2c-piix4.c,v retrieving revision 1.53
busses/i2c-piix4.c +148 -185
516 lines not on this page · raw message
Index: kernel/busses/i2c-viapro.c
=================================RCS file: /home/cvs/lm_sensors2/kernel/busses/i2c-viapro.c,v retrieving revision 1.27
busses/i2c-viapro.c +209 -239
603 lines not on this page · raw message
Index: kernel/chips/adm1021.c
=================================RCS file: /home/cvs/lm_sensors2/kernel/chips/adm1021.c,v retrieving revision 1.46
chips/adm1021.c +165 -346
159 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Index: kernel/chips/it87.c
=================================RCS file: /home/cvs/lm_sensors2/kernel/chips/it87.c,v retrieving revision 1.9
chips/it87.c +409 -373
782 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Index: kernel/chips/lm75.c
=================================RCS file: /home/cvs/lm_sensors2/kernel/chips/lm75.c,v retrieving revision 1.43
chips/lm75.c +92 -126
218 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Index: kernel/chips/via686a.c
=================================RCS file: /home/cvs/lm_sensors2/kernel/chips/via686a.c,v retrieving revision 1.28
chips/via686a.c +407 -262
669 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
data->fan_min[i - 1] = via686a_read_value(client,
VIA686A_REG_FAN_MIN(i));
}
- for (i = 1; i <= 3; i++) {
- data->temp[i - 1] = via686a_read_value(client,
+ for (i = 0; i <= 2; i++) {
+ data->temp[i] = via686a_read_value(client,
VIA686A_REG_TEMP(i)) << 2;
- data->temp_over[i - 1] + data->temp_over[i] via686a_read_value(client,
VIA686A_REG_TEMP_OVER(i));
- data->temp_hyst[i - 1] + data->temp_hyst[i] via686a_read_value(client,
VIA686A_REG_TEMP_HYST(i));
}
@@ -768,150 +912,13 @@
up(&data->update_lock);
}
-
-/* The next few functions are the call-back functions of the /proc/sys and
- sysctl files. Which function is used is defined in the ctl_table in - the extra1 field. - Each function must return the magnitude (power of 10 to divide the date - with) if it is called with operation=SENSORS_PROC_REAL_INFO. It must - put a maximum of *nrels elements in results reflecting the data of this - file, and set *nrels to the number it actually put in it, if operation= - SENSORS_PROC_REAL_READ. Finally, it must get upto *nrels elements from - results and write them to the chip, if operations=SENSORS_PROC_REAL_WRITE. - Note that on SENSORS_PROC_REAL_READ, I do not check whether results is - large enough (by checking the incoming value of *nrels). This is not very - good practice, but as long as you put less than about 5 values in results, - you can assume it is large enough. */
-static void via686a_in(struct i2c_client *client, int operation, int ctl_name,
- int *nrels_mag, long *results)
-{
- struct via686a_data *data = client->data;
- int nr = ctl_name - VIA686A_SYSCTL_IN0;
-
- if (operation = SENSORS_PROC_REAL_INFO)
- *nrels_mag = 2;
- else if (operation = SENSORS_PROC_REAL_READ) {
- via686a_update_client(client);
- results[0] = IN_FROM_REG(data->in_min[nr], nr);
- results[1] = IN_FROM_REG(data->in_max[nr], nr);
- results[2] = IN_FROM_REG(data->in[nr], nr);
- *nrels_mag = 3;
- } else if (operation = SENSORS_PROC_REAL_WRITE) {
- if (*nrels_mag >= 1) {
- data->in_min[nr] = IN_TO_REG(results[0], nr);
- via686a_write_value(client, VIA686A_REG_IN_MIN(nr),
- data->in_min[nr]);
- }
- if (*nrels_mag >= 2) {
- data->in_max[nr] = IN_TO_REG(results[1], nr);
- via686a_write_value(client, VIA686A_REG_IN_MAX(nr),
- data->in_max[nr]);
- }
- }
-}
-
-void via686a_fan(struct i2c_client *client, int operation, int ctl_name,
- int *nrels_mag, long *results)
-{
- struct via686a_data *data = client->data;
- int nr = ctl_name - VIA686A_SYSCTL_FAN1 + 1;
-
- if (operation = SENSORS_PROC_REAL_INFO)
- *nrels_mag = 0;
- else if (operation = SENSORS_PROC_REAL_READ) {
- via686a_update_client(client);
- results[0] = FAN_FROM_REG(data->fan_min[nr - 1],
- DIV_FROM_REG(data->fan_div
- [nr - 1]));
- results[1] = FAN_FROM_REG(data->fan[nr - 1],
- DIV_FROM_REG(data->fan_div[nr - 1]));
- *nrels_mag = 2;
- } else if (operation = SENSORS_PROC_REAL_WRITE) {
- if (*nrels_mag >= 1) {
- data->fan_min[nr - 1] = FAN_TO_REG(results[0],
- DIV_FROM_REG(data->
- fan_div[nr -1]));
- via686a_write_value(client,
- VIA686A_REG_FAN_MIN(nr),
- data->fan_min[nr - 1]);
- }
- }
-}
-
-void via686a_temp(struct i2c_client *client, int operation, int ctl_name,
- int *nrels_mag, long *results)
-{
- struct via686a_data *data = client->data;
- int nr = ctl_name - VIA686A_SYSCTL_TEMP;
-
- if (operation = SENSORS_PROC_REAL_INFO)
- *nrels_mag = 1;
- else if (operation = SENSORS_PROC_REAL_READ) {
- via686a_update_client(client);
- results[0] = TEMP_FROM_REG(data->temp_over[nr]);
- results[1] = TEMP_FROM_REG(data->temp_hyst[nr]);
- results[2] = TEMP_FROM_REG10(data->temp[nr]);
- *nrels_mag = 3;
- } else if (operation = SENSORS_PROC_REAL_WRITE) {
- if (*nrels_mag >= 1) {
- data->temp_over[nr] = TEMP_TO_REG(results[0]);
- via686a_write_value(client,
- VIA686A_REG_TEMP_OVER(nr + 1),
- data->temp_over[nr]);
- }
- if (*nrels_mag >= 2) {
- data->temp_hyst[nr] = TEMP_TO_REG(results[1]);
- via686a_write_value(client,
- VIA686A_REG_TEMP_HYST(nr + 1),
- data->temp_hyst[nr]);
- }
- }
-}
-
-void via686a_alarms(struct i2c_client *client, int operation, int ctl_name,
- int *nrels_mag, long *results)
-{
- struct via686a_data *data = client->data;
- if (operation = SENSORS_PROC_REAL_INFO)
- *nrels_mag = 0;
- else if (operation = SENSORS_PROC_REAL_READ) {
- via686a_update_client(client);
- results[0] = ALARMS_FROM_REG(data->alarms);
- *nrels_mag = 1;
- }
-}
-
-void via686a_fan_div(struct i2c_client *client, int operation,
- int ctl_name, int *nrels_mag, long *results)
-{
- struct via686a_data *data = client->data;
- int old;
-
- if (operation = SENSORS_PROC_REAL_INFO)
- *nrels_mag = 0;
- else if (operation = SENSORS_PROC_REAL_READ) {
- via686a_update_client(client);
- results[0] = DIV_FROM_REG(data->fan_div[0]);
- results[1] = DIV_FROM_REG(data->fan_div[1]);
- *nrels_mag = 2;
- } else if (operation = SENSORS_PROC_REAL_WRITE) {
- old = via686a_read_value(client, VIA686A_REG_FANDIV);
- if (*nrels_mag >= 2) {
- data->fan_div[1] = DIV_TO_REG(results[1]);
- old = (old & 0x3f) | (data->fan_div[1] << 6);
- }
- if (*nrels_mag >= 1) {
- data->fan_div[0] = DIV_TO_REG(results[0]);
- old = (old & 0xcf) | (data->fan_div[0] << 4);
- via686a_write_value(client, VIA686A_REG_FANDIV,
- old);
- }
- }
-}
-
-
static struct pci_device_id via686a_pci_ids[] __devinitdata = {
- {PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
+ {
+ .vendor = PCI_VENDOR_ID_VIA,
+ .device = PCI_DEVICE_ID_VIA_82C686_4,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ },
{ 0, }};
@@ -927,14 +934,14 @@
addr = val & ~(VIA686A_EXTENT - 1);
if (addr = 0 && force_addr = 0) {
- printk("via686a.o: base address not set - upgrade BIOS or use force_addr=0xaddr\n");
+ dev_err(&dev->dev,"base address not set - upgrade BIOS or use force_addr=0xaddr\n");
return -ENODEV;
}
if (force_addr)
addr = force_addr; /* so detect will get called */
if (!addr) {
- printk("via686a.o: No Via 686A sensors found.\n");
+ dev_err(&dev->dev,"No Via 686A sensors found.\n");
return -ENODEV;
}
normal_isa[0] = addr;Index: kernel/chips/w83781d.c
=================================RCS file: /home/cvs/lm_sensors2/kernel/chips/w83781d.c,v retrieving revision 1.99
chips/w83781d.c +1101 -1248
2,349 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Index: kernel/include/i2c-dev.h
=================================RCS file: /home/cvs/lm_sensors2/kernel/include/i2c-dev.h,v retrieving revision 1.7
include/i2c-dev.h +8 -323
331 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Part of the diff is not shown here. View the raw message.
PATCH 1/1 Sync cvs tree with latest 2.5 bk tree
Quoted 4 lines
Namely, do we do another 2.4-compatible release.
I'm in favor of at least one more, because I would like to clear up some problems in 2.7.0. The problems are really on the i2c side though.
I'm clearly in favor of one more, too. I've been telling people far too many times to try previous versions of LM Sensors because 2.7.0 wasn't working for them... (Though it did not always worked then). Having one "clear" release would be great.
Second, I think we need to keep this 2.4-compatible branch alive. Even if we don't add a single driver to it for years, we have to think we still may encounter some critical bug. Next 2.4 kernels may generate some warnings in our code. Docs may need to be fixed. So, being able to release some more 2.7.x I2C/LM Sensors packages, even with only slight changes, would be clever IMHO. We've been dropping 2.2-kernel support just one release ago, I don't think we can decently do the same with 2.4-kernels right now, considering 90% of the Linux users are relying on these. Usable 2.6 kernels are still months away.
Then, we'll have to make clear which branch is the default branch and how one would access the non-default branch. I'm still not used to CVS (though the LM Sensors and DMI Decode projects helped me a lot) especially with branches, I don't want to break anything and I don't plan to stop commiting fixes each time I can.
Signature · 2 lines
Jean Delvare http://www.ensicaen.ismra.fr/~delvare/
PATCH 1/1 Sync cvs tree with latest 2.5 bk tree
In reply to Greg KHQuoted 16 lines · Mark D. Studebaker
thanks.
Since we haven't yet branched lmsensors, we have some things to decide before I apply this patch.
Namely, do we do another 2.4-compatible release.
I'm in favor of at least one more, because I would like to clear up some problems in 2.7.0.
The problems are really on the i2c side though.I just studied up on CVS merging. It appears that you can only merge from the branch to the trunk?
In i2c, 2.4 is the branch and 2.5 is the trunk. I want to get some changes from
the trunk (for example new ID's ini2c-id.h) over to the 2.4 branch before we
do a release from the 2.4 branch.
Quoted 4 lines
Let's decide what we want to do. I just went through 36 tickets covering almost 4 weeks.
Phil? Mark H? others? comments please
Why even worry about a 2.5 and onward version of the CVS tree? Why not just use CVS for 2.4 and older, and use the in-kernel tree version of the sensors and i2c code for that stuff?
If not, it's a lot of work to try to keep up with all of the other changes to the code, and placing it backwards into the cvs tree.
thanks,
greg k-h
PATCH 1/1 Sync cvs tree with latest 2.5 bk tree
In reply to Greg KHQuoted 1 line · Philip Pokorny
I'd personally like to see my lm85 patch make it into 2.7.x...
Have a reference to it? If it works with 2.5 right now, I'd be glad to add it.
Quoted 4 lines
Also, I've recently compiled i2c on a 64-bit Opteron and there are several type conversion issues that are not 64-bit clean. I looked into it a little bit and the conversions seemed wrong even in a 32-bit environment (ints to void *)
Hm, not good. I'll gladly take patches to fix this problem. I think I even have access to a amd64 box around here somewhere that I could test them out on.
Quoted 2 lines
If you haven't already encountered these problems, then I'll work up a patch and post it.
Patches are always welcome :)
thanks,
greg k-h
PATCH 1/1 Sync cvs tree with latest 2.5 bk tree
In reply to Greg KHQuoted 9 lines
On a release, let's call it 2.8.0 (since we removed all pre-kernel-2.4.9 compatibility) and let's release in 2-3 weeks. We'll release from the
lm_sensorstree and from the lk2-4 branch of the i2c tree. I think any "reverse merges" from the trunk to the lk2-4 branch in i2c will have to be manual. But it shouldn't be very much. Mainly the new ID's ini2c-id.h.sound like a plan?
Sounds OK to me, let me know if I can help in any way.
Signature · 2 lines
Jean Delvare http://www.ensicaen.ismra.fr/~delvare/
PATCH 1/1 Sync cvs tree with latest 2.5 bk tree
In reply to Greg KHAFK last weekend, sorry...
Quoted 5 lines · Greg KH
Quoted 3 lines · Mark D. Studebaker
Namely, do we do another 2.4-compatible release.
I'm in favor of at least one more, because I would like to clear up some problems in 2.7.0.
Seconded.
Quoted 9 lines
Quoted 9 lines
The problems are really on the i2c side though.
I just studied up on CVS merging. It appears that you can only merge from the branch to the trunk?
In i2c, 2.4 is the branch and 2.5 is the trunk. I want to get some changes from
the trunk (for example new ID's ini2c-id.h) over to the 2.4 branch before we
do a release from the 2.4 branch.
Why not this? http://www.loria.fr/~molli/cvs/doc/cvs_5.html#SEC57
Quoted 3 lines
Why even worry about a 2.5 and onward version of the CVS tree? Why not just use CVS for 2.4 and older, and use the in-kernel tree version of the sensors and i2c code for that stuff?
Won't we still need to branch lmsensors for userspace?
Quoted 2 lines
If not, it's a lot of work to try to keep up with all of the other changes to the code, and placing it backwards into the cvs tree.
Regards,
Signature · 2 lines
Mark M. Hoffman [email protected]
PATCH 1/1 Sync cvs tree with latest 2.5 bk tree
In reply to Greg KHQuoted 6 lines · Mark M. Hoffman
Quoted 3 lines · Greg KH
Why even worry about a 2.5 and onward version of the CVS tree? Why not just use CVS for 2.4 and older, and use the in-kernel tree version of the sensors and i2c code for that stuff?
Won't we still need to branch lmsensors for userspace?
Yes, lmsensors will need to. But not the kernel code. Sorry, I was thinking only the kernel code when I wrote that.
greg k-h
PATCH 1/1 Sync cvs tree with latest 2.5 bk tree
In reply to Greg KHthanks.
Since we haven't yet branched lmsensors, we have some things to decide before I apply this patch. Namely, do we do another 2.4-compatible release.
I'm in favor of at least one more, because I would like to clear up some problems in 2.7.0. The problems are really on the i2c side though.
I just studied up on CVS merging. It appears that you can only merge from the branch to the trunk? In i2c, 2.4 is the branch and 2.5 is the trunk. I want to get some changes from the trunk (for example new ID's in i2c-id.h) over to the 2.4 branch before we
do a release from the 2.4 branch.
Let's decide what we want to do. I just went through 36 tickets covering almost 4 weeks.
Phil? Mark H? others? comments please
mds
Quoted 18 lines · Greg KH
Hi all,
Here's a patch to sync up the lmsensors cvs tree with the current 2.5 bk tree. Anyone with commit permissions want to submit it?
The header files should be renamed too, as they have been in the kernel tree, but a cvs diff can't show that :)
I'll submit a i2c sync patch, after this is applied, as that is out of date quite a bit too.
Ah, now you all see why it's tough to do work in two trees...
thanks,
greg k-h
PATCH 1/1 Sync cvs tree with latest 2.5 bk tree
In reply to Greg KHI'd personally like to see my lm85 patch make it into 2.7.x...
Also, I've recently compiled i2c on a 64-bit Opteron and there are several type conversion issues that are not 64-bit clean. I looked into it a little bit and the conversions seemed wrong even in a 32-bit environment (ints to void *)
If you haven't already encountered these problems, then I'll work up a patch and post it.
:v)
Quoted 10 lines · Jean Delvare
Quoted 5 lines
Namely, do we do another 2.4-compatible release.
I'm in favor of at least one more, because I would like to clear up some problems in 2.7.0. The problems are really on the i2c side though.I'm clearly in favor of one more, too. I've been telling people far too many times to try previous versions of LM Sensors because 2.7.0 wasn't working for them... (Though it did not always worked then). Having one "clear" release would be great.
PATCH 1/1 Sync cvs tree with latest 2.5 bk tree
In reply to Greg KHOn 64-bit, I have an Intel 64-bit system, haven't recompiled in a while, but it works, last time I was really working on it I don't think I fixed all the compiler warnings. I can look at it again if it's timely.
On the lm85 patch, I can check it into CVS if it isn't in there already (can't remember where we left it - will have to check)
On a release, let's call it 2.8.0 (since we removed all pre-kernel-2.4.9 compatibility) and let's release in 2-3 weeks. We'll release from the lm_sensors tree and from the lk2-4 branch of the i2c tree.
I think any "reverse merges" from the trunk to the lk2-4 branch in
i2c will have to be manual. But it shouldn't be very much.
Mainly the new ID's in i2c-id.h.
sound like a plan?
mds
Quoted 24 lines · Greg KH
Quoted 1 line · Philip Pokorny
I'd personally like to see my lm85 patch make it into 2.7.x...
Have a reference to it? If it works with 2.5 right now, I'd be glad to add it.
Quoted 4 lines
Also, I've recently compiled i2c on a 64-bit Opteron and there are several type conversion issues that are not 64-bit clean. I looked into it a little bit and the conversions seemed wrong even in a 32-bit environment (ints to void *)
Hm, not good. I'll gladly take patches to fix this problem. I think I even have access to a amd64 box around here somewhere that I could test them out on.
Quoted 2 lines
If you haven't already encountered these problems, then I'll work up a patch and post it.
Patches are always welcome :)
thanks,
greg k-h