some months ago but we omitted to do the same in i2c-dev.h.
Drop I2C_FUNC_SMBUS_EMUL, it is meant as a convenient shortcut for plain
I2C bus drivers and has no use in user-space.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@3107 7894878c-1315-0410-8ee3-d5d059ff63e0
extra byte is required for block process call SMBus transactions. This
has been true for three weeks around June 2002, but no more since, so
it is about time that we drop this comment and fix the definition.
Spotted by Hideki Iwamoto.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@3100 7894878c-1315-0410-8ee3-d5d059ff63e0
On 5/1/05, Sergey Vlasov <vsu@altlinux.ru> wrote:
>> Hello!
>>
>> http://openipmi.sourceforge.net/ provides patches for 2.4.x kernels
>> with updated IPMI code. However, these patches change the IPMI driver
>> API by adding an additional argument to ipmi_request():
>>
>> int ipmi_request(ipmi_user_t user,
>> struct ipmi_addr *addr,
>> long msgid,
>> struct ipmi_msg *msg,
>> + void *user_msg_data,
>> int priority);
>>
>> (user_msg_data is later returned in the struct ipmi_recv_msg field).
>> This API change breaks compilation of some lm_sensors drivers
>> (i2c-ipmb, i2c-ipmi).
>>
>> The patch below adds compatibility with the new IPMI API to i2c-ipmb
>> and i2c-ipmi drivers. <linux/ipmi.h> does not provide a real
>> API-version #define, therefore IPMI_RESPONSE_RESPONSE_TYPE (also added
>> by the openipmi.sf.net patch) is (ab)used as a new API indicator.
>>
>> Compile tested only due to lack of hardware.
(Yani I.):
Hi Sergey,
Actually there was a patch to the 2.6 i2c-ipmi/bmcsensors for this
problem (after Bene Martin notified me of the problem and how to fix
it), but from what I understand Corey re-included the ipmi_request
method in the next version once he learned of a driver using it (it
was removed because there was thought to be no usage). He was eager to
learn when bmcsensors would make it into the kernel so that he could
stop being nagged by the 'unused function police' as he put it .
It might be wise to apply a patch like this in 2.4 to support the
openipmi that went 'wrong', I changed the 2.6 driver to use the
ipmi_request_settime function to no ill effect, but you should
consider that Corey notes that it is preferred to use the old one:
(extract from some e-mail between Corey, Martin and I about the problem):
>>>>>>Interestingly enough the ipmi_request_settime still has a comment in
>>>>>>the header "Don't use this unless you *really* have to.", making me
>>>>>>wonder if there is a reason not to be using it instead of ipmi_request
>>>>>>if its re-incorporated into the kernel.
>>>>>>
>>>>>>
>>
>>>>
>>>>I guess the only one qualified to answer that one would be corey.
>>>>
>>>>Bye, Martin
>>>>
>>>>
>
>>You wouldn't generally use it because it sets the timeouts and for most
>>purposes the timeouts are defined by the spec (sort of).
>>
>>Do you have any feeling when the BMC sensors package will go into the
>>mainstream kernel? That would be the time to coordinate adding the
>>normal function back in so I'm not constantly fighting the unused
>>function police.
>>
>>-Corey
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2987 7894878c-1315-0410-8ee3-d5d059ff63e0
This is done by not taking care of additional status bits. This is a
backport from Linux 2.6.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2953 7894878c-1315-0410-8ee3-d5d059ff63e0
temperature conversion macros quite a bit, and fixes a bug with negative
temperatures as a side effect.
This is a backport from Linux 2.6.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2947 7894878c-1315-0410-8ee3-d5d059ff63e0
(+5V) scaling
> I have been hunting down an issue related to the IN10 input of the
> LM93. I have observed that there is a rather large error between the
> actual voltage and the voltage level displayed by sensors(1) (~ .12V).
>
> Please find attached a small patch that fixes this problem. The data
> sheet is very ambiguous and I and another engineer made the same mistake
> calculating the voltage per DAC step the first time we read the spec sheet.
>
> The confusion stems from an entry in the "maximum voltage" column that
> is higher than the value in the "absolute maximum range" column. For 5V
> only, the value in the "register reading at maximum voltage" is for the
> voltage in the "absolute maximum range", NOT the "maximum voltage". Whew!
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2924 7894878c-1315-0410-8ee3-d5d059ff63e0
Jean Delvare