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
<klh@google.com> received Sept. '04.
No changes by me other than include file path fixups.
Compiles, but will not insmod without i2c-core changes
or stubs to add xxx_nolock() functions.
-----------------
Here you go. I apologize for the fact this code is not integrated
into the lm_sensors package structure and thus will require you to
make various little updates. But I really wanted to get this out
before I'm yanked away again, and am pretty sure you can do it much
faster than I can figure out what needs to be done!
BTW the kernel files are built against 2.4.x where x varies; 18 and 19
should work.
Feel free to clean up anything.
--Ken
On Sat, 18 Sep 2004, Mark Studebaker wrote:
>>> > On Tue, 7 Sep 2004, Mark Studebaker wrote:
>>
>>>> >>sure, send it over.
>>>> >>Sorry for delay, your mail got buried by other mail and just now spotted it.
>>>> >>mds
>>>> >>
>>>> >>Ken Harrenstien wrote:
>>>> >>
>>>
>>>>> >>>It turned out to be a while before I could get back to this, but
>>>>> >>>everything's been working for a while now and I'd like to send in the
>>>>> >>>new pca954x driver.
>>>>> >>>
>>>>> >>>I was looking at the list in the "new_drivers" file -- it *is* kind of
>>>>> >>>intimidating. Since some of the changes affect core i2c files, I was
>>>>> >>>hoping that what I could do to start with is just send you a tar of
>>>>> >>>the modified files in their entirety, or a patch-diff of the changes
>>>>> >>>against the 2.8.7 distribution, so you can scope things out and verify
>>>>> >>>they're on the right track for acceptance. The following files are
>>>>> >>>the ones I've changed so far:
>>>>> >>>
>>>>> >>> New:
>>>>> >>> Documentation/i2c/virtual_i2c
>>>>> >>> drivers/i2c/i2c-virtual.c
>>>>> >>> drivers/sensors/pca954x.c
>>>>> >>> include/linux/i2c-virtual.h
>>>>> >>> Patched:
>>>>> >>> Documentation/Configure.help
>>>>> >>> drivers/i2c/Makefile
>>>>> >>> drivers/i2c/Config.in
>>>>> >>> drivers/i2c/i2c-core.c
>>>>> >>> drivers/sensors/Makefile
>>>>> >>> drivers/sensors/Config.in
>>>>> >>> include/linux/i2c-id.h
>>>>> >>> include/linux/i2c.h
>>>>> >>>
>>>>> >>>
>>>>> >>>I plan to write some additional doc once I know that the code itself
>>>>> >>>is acceptable, and you then can tell me what other files need to be
>>>>> >>>updated.
>>>>> >>>
>>>>> >>>To answer a couple other issues you raised:
>>>>> >>>
>>>>> >>>On Thu, 24 Jun 2004, Mark Studebaker wrote:
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>
>>>>>> >>>>(copying the mailing list, already forwarded the first mail to the list)
>>>>>> >>>>
>>>>>> >>>>First I want to ask whether you are working on kernel 2.4 or 2.6.
>>>>
>>>>> >>>
>>>>> >>>
>>>>> >>>2.4.
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>
>>>>>> >>>>Third, you may not have realized that Khali recently did a (2.4 kernel) pca9540 driver.
>>>>>> >>>>It is in our sensors package. It however doesn't do any of the bootstrapping or
>>>>>> >>>>bus registering either. It may or may not help you.
>>>>
>>>>> >>>
>>>>> >>>
>>>>> >>>I saw it in the 2.8.7 distrib, and used parts of it as a template.
>>>>> >>>The pca954x driver will support that chip, although the external /proc
>>>>> >>>interface it presents is necessarily different.
>>>>> >>>
>>>>> >>>--Ken
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2765 7894878c-1315-0410-8ee3-d5d059ff63e0
I'm sending you this little obvious patch which should enable i2c-piix
to work on IBM servers with ServerWorks chipsets. It still will treat
any IBM/Intel machine as a laptop and refuse to work, but it's better
than before.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2570 7894878c-1315-0410-8ee3-d5d059ff63e0
patch from Ken Healy <k.healy@student.ucc.ie>
This patch experimentally enables SiS 655 support by the i2c-sis645 driver.
It simply modifies the driver to also accept the SiS 655 as a valid host
bridge.
Partially tested on a Gigabyte GA-SINXP1394 (SiS655/963), no problems so far.
Driver successfully enables the SMBus controller, i2cdetect finds the usual
devices, and i2cdump successfully reads the DIMM SPD eeprom's.
The patch is against the lm_sensors-2.8.5 release.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2415 7894878c-1315-0410-8ee3-d5d059ff63e0
This patch fixes a "Trying to release non-existent resource" error that
occurs during rmmod when the device isn't actually present. It includes
some other cleanups too: error paths, whitespace, magic numbers, __devinit.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2248 7894878c-1315-0410-8ee3-d5d059ff63e0
Date: Thu, 18 Dec 2003 22:42:36 +0100
From: Haakon Riiser <haakon.riiser@fys.uio.no>
To: sensors@Stimpy.netroedge.com
Subject: lm_sensors 2.8.2 / DESTDIR / root
The reason for this email is that I always try to avoid running
Makefiles as root, even during 'make install'. Therefore, I
always use the DESTDIR feature, when it's available. Until today,
I always built i2c and lm_sensors by doing
$ make
$ make -i install DESTDIR=/foo
$ cd /foo && su root && fix permissions/ownership && install
The -i flag to make install is a kludge to avoid having to be root
while installing to the DESTDIR, and it's only required because
the files are installed with "-o root -g root". Using the -i
flag is of course not a good idea, since more fatal errors can
easily fly by undetected.
Today, I upgraded to Linux 2.6.0, and tried a similar install
procedure for lm_sensors, except that the make target is now "user"
and the install target is "user_install". I now noticed that the
DESTDIR variable is not used everywhere in "user_install", so I
couldn't use the -i kludge anymore. Instead, I wrote a patch that
removes the "-o root -g root" arguments to install everywhere, and
I also tried to add DESTDIR to all files/directories installed.
(The patch only applies to lm_sensors, not i2c, since only
lm_sensors is required in Linux 2.6.0.)
There's really no reason to say -o root -g root anyway, since if you
do install directly with make install, you have to be logged in as
root, and then the files will get the right ownership by default.
Much of the point of installing to a temporary DESTDIR is that you
don't have to be root, and that you can prepare the installation
by hand. Fixing the ownership is trivial:
chown -R root.root $DESTDIR
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2189 7894878c-1315-0410-8ee3-d5d059ff63e0
Jean Delvare