IPMI driver updates, part 3
Subsystems (2)
PATCH 1/1 IPMI driver updates, part 3
It has been far too long since the last IPMI driver updates, but now all the planets have aligned and all the pieces I needed are in and all seem to be working. This update is coming as four parts that must be applied in order, but the later parts do not have to be applied for the former parts to work.
This third part adds an SMBus IPMI interface. Some systems have interfaces through the SMBus to the local IPMI controller; this driver should support those interfaces.
FYI, IPMI is a standard for monitoring and maintaining a system. It provides interfaces for detecting sensors (voltage, temperature, etc.) in the system and monitoring those sensors. Many systems have extended capabilities that allow IPMI to control the system, doing things like lighting leds and controlling hot-swap. This driver allows access to the IPMI system.
-Corey
Documentation/IPMI.txt +62 -1
@@ -43,7 +43,11 @@ The driver interface depends on your hardware. If you have a board with a standard interface (These will generally be either "KCS", "SMIC", or "BT", consult your hardware manual), choose the 'IPMI SI -handler' option. +handler' option. A driver also exists for direct I2C access to the +IPMI management controller. Some boards support this, but it is +unknown if it will work on every board. For this, choose 'IPMI SMBus +handler', but be ready to try to do some figuring to see if it will +work. There is also a KCS-only driver interface supplied, but it is depracated in favor of the SI interface.
@@ -97,6 +101,10 @@ interface for IPMI. This is deprecated, ipmi_si_drv supports KCS and SMIC interfaces. +ipmi_smb_intf - A driver for accessing BMCs on the SMBus. It uses the +I2C kernel driver's SMBus interfaces to send and receive IPMI messages +over the SMBus. + Much documentation for the interface is in the include files. The IPMI include files are:
@@ -421,6 +429,59 @@ the KCS interface sucks. +The SMBus Driver +---------------- + +The SMBus driver allows up to 4 SMBus devices to be configured in the +system. By default, the driver will register any SMBus interfaces it finds +in the I2C address range of 0x20 to 0x4f on any adapter. You can change this +at module load time (for a module) with: + + insmod ipmi_smb_intf.o + smb_addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]] + smb_dbg=<flags1>,<flags2>... + [smb_defaultprobe=0] [smb_dbg_probe=1] + +The addresses are specified in pairs, the first is the adapter ID and the +second is the I2C address on that adapter. + +The debug flags are bit flags for each BMC found, they are: +IPMI messages: 1, driver state: 2, timing: 4, I2C probe: 8 + +Setting smb_defaultprobe to zero disabled the default probing of SMBus +interfaces at address range 0x20 to 0x4f. This means that only the +BMCs specified on the smb_addr line will be detected. + +Setting smb_dbg_probe to 1 will enable debugging of the probing and +detection process for BMCs on the SMBusses. + +Discovering the IPMI compilant BMC on the SMBus can cause devices +on the I2C bus to fail. The SMBus driver writes a "Get Device ID" IPMI +message as a block write to the I2C bus and waits for a response. +This action can be detrimental to some I2C devices. It is highly recommended +that the known I2c address be given to the SMBus driver in the smb_addr +parameter. The default adrress range will not be used when a smb_addr +parameter is provided. + +When compiled into the kernel, the addresses can be specified on the +kernel command line as: + + ipmi_smb=[<adapter1>.]<addr1>[:<debug1>],[<adapter2>.<addr2>[:<debug1>].... + +The [<adapterx>.]<addrx>[:<debugx>] I2C address-debug flag are value +set for each BMC. If the adapter is not given, then it defaults to +zero. The debug flag is the same as the smb_dbg flag given above. + +You may also specify "nodefaults" and "debug_probe", separated by +commas, on the ipmi_smb line. These will disable the default SMB +probe and enable debugging of the BMC probing and detection process, +respectively. + +Note that you might need some I2C changes if CONFIG_IPMI_PANIC_EVENT +is enabled along with this, so the I2C driver knows to run to +completion during sending a panic event. + + Other Pieces ------------
drivers/char/ipmi/ipmi_smb_intf.c +1314 -0
1,314 lines not on this page · raw message
drivers/char/ipmi/Kconfig +11 -0
@@ -58,6 +58,17 @@ Provides a driver for a KCS-style interface to a BMC. This is deprecated, please use the IPMI System Interface handler instead. + +config IPMI_SMB + tristate 'IPMI SMBus handler' + depends on IPMI_HANDLER && I2C + help + Provides a driver for a SMBus interface to a BMC, meaning that you + have a driver that must be accessed over an I2C bus instead of a + standard interface. This module requires I2C support. Note that + you might need some I2C changes if CONFIG_IPMI_PANIC_EVENT is + enabled along with this, so the I2C driver knows to run to + completion during sending a panic event. config IPMI_WATCHDOG tristate 'IPMI Watchdog Timer'
drivers/char/ipmi/Makefile +1 -0
@@ -9,6 +9,7 @@ obj-$(CONFIG_IPMI_DEVICE_INTERFACE) += ipmi_devintf.o obj-$(CONFIG_IPMI_SI) += ipmi_si_drv.o obj-$(CONFIG_IPMI_KCS) += ipmi_kcs_drv.o +obj-$(CONFIG_IPMI_SMB) += ipmi_smb_intf.o obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o ipmi_kcs_drv.o: $(ipmi_kcs_drv-objs)
In message <[email protected]> you write:
Documentation/IPMI.txt line 443
Quoted 4 lines
Documentation/IPMI.txt +4
-0+ insmod ipmi_smb_intf.o + smb_addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]] + smb_dbg=<flags1>,<flags2>... + [smb_defaultprobe=0] [smb_dbg_probe=1]
Please use "modprobe" not "insmod" in examples, and drop the ".o" extension.
Documentation/IPMI.txt line 469
Quoted 4 lines
Documentation/IPMI.txt +4
-0+When compiled into the kernel, the addresses can be specified on the +kernel command line as: + + ipmi_smb=[<adapter1>.]<addr1>[:<debug1>],[<adapter2>.<addr2>[:<debug1>]....
I realize this is traditional. However, I suggest you:
1) Rename the module to impi_smb.
2) Change the variable names to addr, debug, debug_probe and default_probe.
3) Change MODULE_PARM to module_param
4) Get rid of the #ifndef MODULE code.
The results will be symmetry, and less code:
modprobe ipmi_smb addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]] debug=<flags1>,<flags2>... default_probe=0 debug_probe=1
and
boot ipmi_smb.addr=... ipmi_smb.debug=... ipmi.default_probe=0 ipmi.debug_probe=1
Of course, if you really want to you can use module_param_named and keep the variable names the same as they are now, and "#undef KBUILD_MODNAME // #define KBUILD_MODNAME ipmi_smb", to avoid renaming your module.
But I really think the module name wants a revisit (although I have no idea what it does, so might be wrong).
Cheers!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Yes, I see that this is much better. I'll work on renaming all these and switching to module_param, for the 2.6 version.
Thanks,
-Corey
Quoted 53 lines · Rusty Russell
In message <[email protected]> you write:
Documentation/IPMI.txt line 443
Quoted 6 lines
Documentation/IPMI.txt +4
-0+ insmod ipmi_smb_intf.o + smb_addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]] + smb_dbg=<flags1>,<flags2>... + [smb_defaultprobe=0] [smb_dbg_probe=1]Please use "modprobe" not "insmod" in examples, and drop the ".o" extension.
Documentation/IPMI.txt line 469
Quoted 6 lines
Documentation/IPMI.txt +4
-0+When compiled into the kernel, the addresses can be specified on the +kernel command line as: + + ipmi_smb=[<adapter1>.]<addr1>[:<debug1>],[<adapter2>.<addr2>[:<debug1>]....I realize this is traditional. However, I suggest you:
1) Rename the module toimpi_smb.
2) Change the variable names to addr, debug,debug_probeanddefault_probe.
3) ChangeMODULE_PARMtomodule_param
4) Get rid of the #ifndef MODULE code.The results will be symmetry, and less code:
modprobe ipmi_smb addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]] debug=<flags1>,<flags2>... default_probe=0 debug_probe=1and
boot ipmi_smb.addr=... ipmi_smb.debug=... ipmi.default_probe=0 ipmi.debug_probe=1
Of course, if you really want to you can use
module_param_namedand keep the variable names the same as they are now, and "#undefKBUILD_MODNAME// #defineKBUILD_MODNAMEipmi_smb", to avoid renaming your module.But I really think the module name wants a revisit (although I have no idea what it does, so might be wrong).
Cheers!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.