I2C: Kill another macro abuse in via686a
PATCH 1/1 I2C: Kill another macro abuse in via686a
Hi Greg,
This patch kills another macro abuse in the via686a hardware monitoring driver. Using a macro just to alias an array is quite useless, isn't it?
Please apply,
thanks.
drivers/i2c/chips/via686a.c | 23 ++++++++++------------- 1 files changed, 10 insertions(+), 13 deletions(-)
drivers/i2c/chips/via686a.c +10 -13
@@ -78,15 +78,10 @@#define VIA686A_REG_FAN_MIN (nr) (0x3a + (nr))#define VIA686A_REG_FAN (nr) (0x28 + (nr)) -/* the following values are as speced by VIA: */ -static const u8 regtemp[] = {0x20 ,0x21 ,0x1f }; -static const u8 regover[] = {0x39 ,0x3d ,0x1d }; -static const u8 reghyst[] = {0x3a ,0x3e ,0x1e }; -/* temps numbered 1-3 */ -#define VIA686A_REG_TEMP (nr) (regtemp[nr]) -#define VIA686A_REG_TEMP_OVER (nr) (regover[nr]) -#define VIA686A_REG_TEMP_HYST (nr) (reghyst[nr]) +static const u8 VIA686A_REG_TEMP [] = {0x20 ,0x21 ,0x1f }; +static const u8 VIA686A_REG_TEMP_OVER [] = {0x39 ,0x3d ,0x1d }; +static const u8 VIA686A_REG_TEMP_HYST [] = {0x3a ,0x3e ,0x1e };/* bits 7-6 */ #define VIA686A_REG_TEMP_LOW1 0x4b/* 2 = bits 5-4, 3 = bits 7-6 */
@@ -441,7 +436,8 @@down (&data->update_lock); data->temp_over[nr] =TEMP_TO_REG (val); -via686a_write_value (client,VIA686A_REG_TEMP_OVER (nr), data->temp_over[nr]); +via686a_write_value (client,VIA686A_REG_TEMP_OVER [nr], + data->temp_over[nr]);up (&data->update_lock);return count; }
@@ -453,7 +449,8 @@down (&data->update_lock); data->temp_hyst[nr] =TEMP_TO_REG (val); -via686a_write_value (client,VIA686A_REG_TEMP_HYST (nr), data->temp_hyst[nr]); +via686a_write_value (client,VIA686A_REG_TEMP_HYST [nr], + data->temp_hyst[nr]);up (&data->update_lock);return count; }
@@ -763,13 +760,13 @@ }for (i =0 ; i <=2 ; i++) { data->temp[i] =via686a_read_value (client, -VIA686A_REG_TEMP (i)) <<2 ; +VIA686A_REG_TEMP [i]) <<2 ; data->temp_over[i] via686a_read_value(client, -VIA686A_REG_TEMP_OVER (i)); +VIA686A_REG_TEMP_OVER [i]); data->temp_hyst[i] via686a_read_value(client, -VIA686A_REG_TEMP_HYST (i)); +VIA686A_REG_TEMP_HYST [i]); }/* add in lower 2 bits temp1 uses bits 7-6 of VIA686A_REG_TEMP_LOW1
Signature · 6 lines
Jean Delvare _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
PATCH 1/1 I2C: Kill another macro abuse in via686a
Hi Grant,
Quoted 4 lines
Can I go kill some macros too? Silly conversion macros, make like adm9240? Was planning to put
SCALING()in withSENSORS_LIMIT()in the header somewhere, as those two static functions can be used for most of the scaling conversions.
Macros that do not actually improve the code readability are candidates to removal, as they additionally slow down the preprocessing. Removing macros is not a goal per se though, most of them are actually helpful.
Quoted 3 lines
As well, do something with the LM75 include, I see now I duplicated some of the code there, with exception that I right justify signed 9-bit temp on read to local store, rather than on delivery to sysfs.
If you can refactor some code with no side effect, this is welcome.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
PATCH 1/1 I2C: Kill another macro abuse in via686a
In reply to Jean DelvareHi Khali,
Quoted 2 lines · Jean Delvare
This patch kills another macro abuse in the via686a hardware monitoring driver. Using a macro just to alias an array is quite useless, isn't it?
Can I go kill some macros too? Silly conversion macros, make like adm9240? Was planning to put SCALING() in with SENSORS_LIMIT() in the header somewhere, as those two static functions can be used for most of the scaling conversions.
As well, do something with the LM75 include, I see now I duplicated some of the code there, with exception that I right justify signed 9-bit temp on read to local store, rather than on delivery to sysfs.
Stomping macros makes the code so much more colourful in vim :)
--Grant.
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors