Skip to contentSkip to conversation

lm93 driver for 2.6, second try]

PATCH New Eric J. Bowersox 1 participant 1 message Aug 3, 2005

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 lm93 driver for 2.6, second try]

(Dang...I keep forgetting to turn my auto-signature OFF before sending to the mailing list...)

Quoted 1 line · Mark M. Hoffman

"Hosation" - that's a new one. You from up north eh? ;)

No, actually, a coworker of mine came up with that many years ago, in the phrase "Enable hosation without representation." :-)

Quoted 9 lines

CVS/lm93.c, line 450:

result = i2c_smbus_read_block_data(client,

Your patch, at the equivalent place:

result = i2c_smbus_read_i2c_block_data(client,

Those two aren't synonyms - you changed the transaction type. Why?

Well, for one thing, the function i2c_smbus_read_block_data doesn't seem to exist anymore, though its twin, i2c_smbus_write_block_data, does. (See: include/linux/i2c.h, lines 99-103, in 2.6.13-rc3-mm3.)

You're right that there is a difference in the underlying implementations, but the old (and presumably correct, in this instance) function appears to have been removed sometime between 2.6.5 and 2.6.13-rc3-mm3. Anyone have any idea why that was done? As a workaround, should I basically create my own implementation of the old i2c_smbus_read_block_data by calling i2c_smbus_xfer myself?

Quoted 2 lines

(You also reminded me that i2c-i801.c in 2.6.x should get synced up a bit with its twin in lm-sensors CVS. I'll do that later.)

Yeah, in particular, in the "prochot" reporting, I noticed that you seemed to be reporting the "average" return value twice. In kernel/chips/lm93.c, lines 1113-1115, it reads:

                results[0] = data->prochot_max[nr];
                results[1] = data->block4[nr].avg;
                results[2] = data->block4[nr].avg;

I'm thinking that middle line (1114) should be more like:

                results[1] = data->block4[nr].cur;

At least if it's to be consistent with what the docs say that /proc file should report. (That actually threw me for awhile, and it's only in this version of my own patch that I think I've got that reporting correctly. Not that it really concerns us here; we're more focused on getting the basic sensor readings.)

Eric

Signature · 4 lines
Eric J. Bowersox, Software Engineer     Aspen Systems, Inc.
<[email protected]>                      3900 Youngfield Street
Tel: +01 303 431 4606 x113              Wheat Ridge, CO  80033, USA
Fax: +01 303 431 7196                   <http://www.aspsys.com>