The event handler mechanism in the IPMI driver had a limit on the number of
received events, but the counts were not being updated. Update the counts
to impose a limit. This is not a critical fix, as this function (the
sending of the events) has to be turned on by the user, anyway. This
avoids problems if they forget to turn it back off.
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Convert the remaining semaphores to mutexes in the IPMI driver. The
watchdog was using a semaphore as a real semaphore (for IPC), so the
conversion there required adding a completion.
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Tidy up various coding standard things, mostly removing the space after !,
but also break some long lines and fix a few other spacing inconsistencies.
Also fixes some bad error reporting when deleting an IPMI user.
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Matt Domsch noticed a startup race with the IPMI kernel thread, it was
possible (though extraordinarly unlikely) that a message could come in
before the upper layer was ready to handle it. This patch splits the
startup processing of an IPMI interface into two parts, one to get ready
and one to actually start the processes to receive messages from the
interface.
[akpm@osdl.org: cleanups]
Signed-off-by: Corey Minyard <minyard@acm.org>
Cc: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The kernel's implementation of notifier chains is unsafe. There is no
protection against entries being added to or removed from a chain while the
chain is in use. The issues were discussed in this thread:
http://marc.theaimsgroup.com/?l=linux-kernel&m=113018709002036&w=2
We noticed that notifier chains in the kernel fall into two basic usage
classes:
"Blocking" chains are always called from a process context
and the callout routines are allowed to sleep;
"Atomic" chains can be called from an atomic context and
the callout routines are not allowed to sleep.
We decided to codify this distinction and make it part of the API. Therefore
this set of patches introduces three new, parallel APIs: one for blocking
notifiers, one for atomic notifiers, and one for "raw" notifiers (which is
really just the old API under a new name). New kinds of data structures are
used for the heads of the chains, and new routines are defined for
registration, unregistration, and calling a chain. The three APIs are
explained in include/linux/notifier.h and their implementation is in
kernel/sys.c.
With atomic and blocking chains, the implementation guarantees that the chain
links will not be corrupted and that chain callers will not get messed up by
entries being added or removed. For raw chains the implementation provides no
guarantees at all; users of this API must provide their own protections. (The
idea was that situations may come up where the assumptions of the atomic and
blocking APIs are not appropriate, so it should be possible for users to
handle these things in their own way.)
There are some limitations, which should not be too hard to live with. For
atomic/blocking chains, registration and unregistration must always be done in
a process context since the chain is protected by a mutex/rwsem. Also, a
callout routine for a non-raw chain must not try to register or unregister
entries on its own chain. (This did happen in a couple of places and the code
had to be changed to avoid it.)
Since atomic chains may be called from within an NMI handler, they cannot use
spinlocks for synchronization. Instead we use RCU. The overhead falls almost
entirely in the unregister routine, which is okay since unregistration is much
less frequent that calling a chain.
Here is the list of chains that we adjusted and their classifications. None
of them use the raw API, so for the moment it is only a placeholder.
ATOMIC CHAINS
-------------
arch/i386/kernel/traps.c: i386die_chain
arch/ia64/kernel/traps.c: ia64die_chain
arch/powerpc/kernel/traps.c: powerpc_die_chain
arch/sparc64/kernel/traps.c: sparc64die_chain
arch/x86_64/kernel/traps.c: die_chain
drivers/char/ipmi/ipmi_si_intf.c: xaction_notifier_list
kernel/panic.c: panic_notifier_list
kernel/profile.c: task_free_notifier
net/bluetooth/hci_core.c: hci_notifier
net/ipv4/netfilter/ip_conntrack_core.c: ip_conntrack_chain
net/ipv4/netfilter/ip_conntrack_core.c: ip_conntrack_expect_chain
net/ipv6/addrconf.c: inet6addr_chain
net/netfilter/nf_conntrack_core.c: nf_conntrack_chain
net/netfilter/nf_conntrack_core.c: nf_conntrack_expect_chain
net/netlink/af_netlink.c: netlink_chain
BLOCKING CHAINS
---------------
arch/powerpc/platforms/pseries/reconfig.c: pSeries_reconfig_chain
arch/s390/kernel/process.c: idle_chain
arch/x86_64/kernel/process.c idle_notifier
drivers/base/memory.c: memory_chain
drivers/cpufreq/cpufreq.c cpufreq_policy_notifier_list
drivers/cpufreq/cpufreq.c cpufreq_transition_notifier_list
drivers/macintosh/adb.c: adb_client_list
drivers/macintosh/via-pmu.c sleep_notifier_list
drivers/macintosh/via-pmu68k.c sleep_notifier_list
drivers/macintosh/windfarm_core.c wf_client_list
drivers/usb/core/notify.c usb_notifier_list
drivers/video/fbmem.c fb_notifier_list
kernel/cpu.c cpu_chain
kernel/module.c module_notify_list
kernel/profile.c munmap_notifier
kernel/profile.c task_exit_notifier
kernel/sys.c reboot_notifier_list
net/core/dev.c netdev_chain
net/decnet/dn_dev.c: dnaddr_chain
net/ipv4/devinet.c: inetaddr_chain
It's possible that some of these classifications are wrong. If they are,
please let us know or submit a patch to fix them. Note that any chain that
gets called very frequently should be atomic, because the rwsem read-locking
used for blocking chains is very likely to incur cache misses on SMP systems.
(However, if the chain's callout routines may sleep then the chain cannot be
atomic.)
The patch set was written by Alan Stern and Chandra Seetharaman, incorporating
material written by Keith Owens and suggestions from Paul McKenney and Andrew
Morton.
[jes@sgi.com: restructure the notifier chain initialization macros]
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com>
Signed-off-by: Jes Sorensen <jes@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Need to increment the version number because of the new PCI and sysfs
capabilities of the driver. People maintaining things for distros have
asked that I do this after interface or major functional changes.
Signed-off-by: Corey Minyard <minyard@acm.org>
Acked-by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add full driver model support for the IPMI driver. It links in the proper
bus and device support.
It adds an "ipmi" driver interface that has each BMC discovered by the
driver (as a device). These BMCs appear in the devices/platform directory.
If there are multiple interfaces to the same BMC, the driver should
discover this and will only have one BMC entry. The BMC entry will have
pointers to each interface device that connects to it.
The device information (statistics and config information) has not yet been
ported over to the driver model from proc, that will come later.
This work was based on work by Yani Ioannou. I basically rewrote it using
that code as a guide, but he still deserves credit :).
[bunk@stusta.de: make ipmi_find_bmc_guid() static]
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Yani Ioannou <yani.ioannou@gmail.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Modify the PCI hanling code for the IPMI driver to use the new method of
tables and registering, and adds more generic PCI handling for IPMI.
Unfortunately, this required a rather large rework of the way the driver
did detection so it would be more event-driven.
[bunk@stusta.de: make a struct static]
Signed-off-by: Corey Minyard <minyard@acm.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The Coverity checker found this memory leak.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Use the global define of pm_power_off
Signed-off-by: Olaf Hering <olh@suse.de>
Cc: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
While looking to the report by Coverity in ipmi, I came across the
following issue:
The IPMI message handler relies on two defines which are the same -one in
include/linux/ipmi.h
#define IPMI_NUM_CHANNELS 0x10
and one in drivers/char/ipmi/ipmi_msghandler.
#define IPMI_MAX_CHANNELS 16
These are used interchangeably in ipmi_msghandler.c, but since the array
addr->channels[] is of size IPMI_MAX_CHANNELS, I have made a patch that
uses IPMI_MAX_CHANNELS for all the checks for the array index.
NOTE: You could probably remove the line that defines IPMI_NUM_CHANNELS
from ipmi.h, or move IPMI_MAX_CHANNELS to ipmi.h
Signed-off-by: Jayachandran C. <c.jayachandran@gmail.com>
Cc: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
On mips:
drivers/char/ipmi/ipmi_si_intf.c:1274: error: conflicting types for 'mem_inb'
include/asm/io.h:436: error: previous definition of 'mem_inb' was here
Don't look at line 436 unless you really know what you're doing.
Move those static functions out of more or less generic namespace.
Signed-off-by: Alexey "## should be banned" Dobriyan <adobriyan@gmail.com>
Acked-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
At the 2.6.12 timeframe ipmi_si_intf.c was patched to provide default
register spacings in try_init_acpi() if the register spacing was set to
zero, similar to code in other routines.
Unfortunately, another patch was simultaneously added that exits early from
try_init_acpi() if the register spacings are set to zero, circumventing the
new defaults. This patch removes the early exit code and some incorrect
comments that aren't present in other common code snippets.
Signed-off-by: Rocky Craig <rocky.craig@hp.com>
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
With Andi Kleen's x86_64 patch to use DMI, and my ia64 to use DMI, there is
now a new CONFIG_DMI option which takes the place of CONFIG_X86 to denote
the availability of the DMI functions. Make the IPMI driver use CONFIG_DMI
instead.
Tested on ia64 2.6.15 kernel plus the previous patch, on a Dell PowerEdge
7250 Itanium2 server, and it now autodetects the IPMI KCS driver as
expected.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Acked-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
...
CC [M] drivers/char/ipmi/ipmi_msghandler.o
drivers/char/ipmi/ipmi_msghandler.c:3301: `proc_ipmi_root' undeclared here (not in a function)
drivers/char/ipmi/ipmi_msghandler.c:3301: initializer element is not constant
drivers/char/ipmi/ipmi_msghandler.c:3301: (near initialization for `__ksymtab_proc_ipmi_root.value')
drivers/char/ipmi/ipmi_msghandler.c:1535: warning: `ipmb_file_read_proc' defined but not used
drivers/char/ipmi/ipmi_msghandler.c:1551: warning: `version_file_read_proc' defined but not used
drivers/char/ipmi/ipmi_msghandler.c:1561: warning: `stat_file_read_proc' defined but not used
...
CC [M] drivers/char/ipmi/ipmi_poweroff.o
drivers/char/ipmi/ipmi_poweroff.c: In function `ipmi_poweroff_init':
drivers/char/ipmi/ipmi_poweroff.c:616: warning: implicit declaration of function `unregister_sysctl_table'
drivers/char/ipmi/ipmi_poweroff.c:616: `ipmi_table_header' undeclared (first use in this function)
drivers/char/ipmi/ipmi_poweroff.c:616: (Each undeclared identifier is reported only once
drivers/char/ipmi/ipmi_poweroff.c:616: for each function it appears in.)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Cc: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I missed a use of list_for_each_rcu_safe() in -mm tree. Here is an updated
patch to fix it. This time tested on a machine that actually uses IPMI...
(Thanks to Serge Hallyn for spotting this.)
Signed-off-by: "Paul E. McKenney" <paulmck@us.ibm.com>
Cc: Corey Minyard <minyard@acm.org>
Cc: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
While doing some testing I discovered that if the BIOS on a board does not
properly setup the DMI information it leads to a panic in the IPMI code.
The panic is due to dereferencing a pointer which is not initialized. The
pointer is initialized in port_setup() and/or mem_setup() and used in
init_one_smi() and cleanup_one_si(), however if either port_setup() or
mem_setup() return ENODEV the pointer does not get initialized.
Signed-off-by: Paolo Galtieri <pgaltieri@mvista.com>
Acked-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The IPMI specifcation says the generator ID is 0x20, but that is for bits
7-1. Bit 0 is set to specify it is a software event. The correct value is
0x41. Without this fix, panic events written into the System Event Log
appear to come from an "unknown" generator, rather than from the kernel.
Signed-off-by: Jordan Hargrave <Jordan_Hargrave@dell.com>
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Acked-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
On IPMI systems with BT interfaces, we don't start the kernel thread, so
smi_info->thread is NULL. Test for NULL when stopping the thread, because
kthread_stop() doesn't, and an oops ensues otherwise.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Acked-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Lots of good changes to the driver lately that userspace will care about
the version of the driver. Bump the version from 36.0 to 38.0 to be higher
than 37 that the 2.4 driver came out with a few weeks ago which doesn't
have all the same changes.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Part of a patch was accidentally reverted, this corrects an
inconsistent spinlock use in the IPMI message handler.
Signed-off-by: Hironobu Ishii <hishii@soft.fujitsu.com>
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
If a panic came from the IPMI watchdog pretimeout and that was reported via
an NMI, it would also be reported via the standard IPMI flags, which would
get picked up when reporting panic events and cause another panic. This
adds an atomic to avoid calling panic twice.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Use rcu_read_lock for the cmd_rcvrs list, since that was what what
intended, anyway. This means that all the users of the cmd_rcvrs_lock are
tasks, so the irq disables are no longer required for that lock and it can
become a semaphore.
Signed-off-by: Corey Minyard <minyard@acm.org>
Acked-by: "Paul E. McKenney" <paulmck@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Convert ipmi driver thread to kthread API, only sleep when interface is
idle.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Cc: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We must poll for responses to commands when interrupts aren't in use. The
default poll interval is based on using a kernel timer, which varies with HZ.
For character-based interfaces like KCS and SMIC though, that can be way too
slow (>15 minutes to flash a new firmware with KCS, >20 seconds to retrieve
the sensor list).
This creates a low-priority kernel thread to poll more often. If the state
machine is idle, so is the kernel thread. But if there's an active command,
it polls quite rapidly. This decrease a firmware flash time from 15 minutes
to 1.5 minutes, and the sensor list time to 4.5 seconds, on a Dell PowerEdge
x8x system.
The timer-based polling remains, to ensure some amount of responsiveness even
under high user process CPU load.
Checking for a stopped timer at rmmod now uses atomics and del_timer_sync() to
ensure safe stoppage.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
BMCs can get into ERROR0 state while flashing new firmware, particularly while
the BMC is erasing the next flash block, which may take a just under 2 seconds
on a Dell PowerEdge 2800 (1.75 seconds typical), during which time the
single-threaded firmware may not be able to process new commands. In
particular, clearing OBF may not take effect immediately.
We want it to delay in ERROR0 after clearing OBF a bit waiting for OBF to
actually be clear before proceeding.
This introduces a new return value from the LLDD's event loop,
SI_SM_CALL_WITH_TICK_DELAY. This means the calling thread/timer should
schedule_timeout() at least 1 tick, rather than busy-wait. This is a longer
delay than SI_SM_CALL_WITH_DELAY, which is typically a 250us busy-wait.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The current BT retry/reset mechanism fails to succeed on a PowerEdge 1650,
when the controller is wedged with B2H_ATN asserted at XACTION_START. If this
occurs, no further commands will ever succeed unless the state of the
controller is first cleared out.
Furthermore, the soft reset would only occur if the first command after insmod
was the one that timed out, not if a later command timed out.
This patch changes the retry/reset mechanism to be as follows:
Before retrying a command, clear the state of the BT controller such that the
flags represent ready for a new transaction. This increases the chance of
success of the restarted transaction.
After 2 retries, issue a soft reset and retry one more time before giving up
and reporting back a failure.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Acked-by: Rocky Craig <rocky.craig@hp.com>
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Some commands, on some system BMCs, don't respond at at all. This is seen on
Dell PowerEdge x6xx and x7xx systems with IPMI 1.0 BT controllers when a "Get
SDR" command is issued, with a length field of 0x3A, which happens to be the
length of about SDR entries. If another length is passed, this command
succeeds.
This patch adds general infrastructure for receiving commands before they're
passed down to the low-level drivers, such that they can be completed
immediately, or modified, prior to being sent to ->start_transaction().
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Make SMIC driver ignore EVT_AVAIL and SMS_ATN bits in flags register, as
they're used by systems management interrupts, not the host OS.
Make the OEM0 Data Available handler work for pre-IPMI 1.5 systems from Dell
too.
Without these two fixes, PowerEdge 2650 and other similar systems with SMIC
may hang a process (modprobe or anything using /dev/ipmi0).
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Make module_param and MODULE_PARAM_DESC agree on poweroff_powercycle name.
There was an extraneous ifdef in the IPMI poweroff code that prevented it from
working if PROC_FS was disabled.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Modify the IPMI watchdog parameters (the ones that make sense) to be exported
from sysfs. This is somewhat complicated because these parameters have
side-effects that must be handled.
Signed-off-by: Corey Minyard <minyard@acm.org>
Cc: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
A number of small changes for the various system interface drivers,
consolidated from a number of patches from Matt Domsch.
Clear B2H_ATN and drain the BMC message buffer on command timeout. This
prevents further commands from failing after a timeout.
Add bt_debug and smic_debug module parameters, expose them in sysfs. This
lets you enable and disable debugging messages at runtime.
Unsigned jiffies math in ipmi_si_intf.c causes a too-large value to be passed
to ->event() after jiffies wrap-around. The BT driver had caught this, but
didn't know how to fix it. Now all calls to ->event() use a sane value for
time.
Increase timeout for commands handed to the BT driver from 2 seconds to 5
seconds. This is necessary particularly when the previous command was a
"Clear SEL", as that command completes, yet the BMC isn't really ready to
handle another command yet.
Silence BT debugging messages which were being printed on the console.
Increase SMIC timeout form 1/10s to 2s. This is needed on Dell PowerEdge 2650
and PowerEdge 750 with ERA/O cards to allow commands to complete without
timing out.
Adds kcs_debug module param, to match behavior of BT and SMIC. This also
prevents messages from being sent to the console unless explicitly requested.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch is rather large, but it really can't be done in smaller chunks
easily and I believe it is an important change. This has been out and tested
for a while in the latest IPMI driver release. There are no functional
changes, just changes as necessary to convert the locking over (and a few
minor style updates).
The IPMI driver uses read/write locks to ensure that things exist while they
are in use. This is bad from a number of points of view. This patch removes
the rwlocks and uses refcounts and RCU lists to manage what the locks did.
Signed-off-by: Corey Minyard <minyard@acm.org>
Cc: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The previous patch adding the ability to nest struct class_device
changed the paramaters to the call class_device_create(). This patch
fixes up all in-kernel users of the function.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Put the IPMI poweroff_powercycle parameter into sysfs. This field is
dynamically settable and is valuable to have in sysfs.
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I found an inconsistent spin_lock usage in ipmi_smi_msg_received.
Signed-off-by: Hironobu Ishii <hishii@soft.fujitsu.com>
Cc: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The IPMI power control function proc_write_chassctrl was badly written, it
directly used userspace pointers, it assumed that strings were NULL
terminated, and it used the evil sscanf function. This converts over to
using the sysctl interface for this data and changes the semantics to be a
little more logical.
Signed-off-by: Corey Minyard <minyard@acm.org>
Cc: <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This removes the unused "all_cmd_rcvr" variable from the IPMI driver.
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Clean up various style issues in the IPMI driver. Should be no functional
changes.
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch allows Dell servers with IPMI controllers that predate IPMI 1.5
to use the standard poweroff or powercycle commands. These systems
firmware don't set the chassis capability bit in the Get Device ID, but
they do implement the standard poweroff and powercycle commands.
Tested on RHEL3 kernel 2.4.21-20.ELsmp on a PowerEdge 2600. The standard
ipmi_poweroff driver cannot drive these systems. With this patch, they
power off or powercycle as expected.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The "null message handler" in the IPMI driver is used in startup and panic
situations to handle messages. It was only designed to work with messages
from the local management controller, but in some cases it was used to get
messages from remote managmenet controllers, and the system would then
panic. This patch makes the "null message handler" in the IPMI driver more
general so it works with any kind of message.
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This adds MODULE_VERSION, MODULE_DESCRIPTION, and MODULE_AUTHOR tags to the
IPMI driver modules. Also changes the MODULE_VERSION to remove the
prepended 'v' on each value, consistent with the module versioning policy.
This patch also removes all the version information from everything except
the ipmi_msghandler module.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The ipmi driver does not have a way to handle firmware-generated events
which have the OEM[012] Data Available flags set. In such a case, the
SMS_ATN bit may never get cleared by firmware, leaving the driver looping
infinitely but never able to make any progress.
This patch first simplifies storage and use of the data returned from an
IPMI Get Device ID command.
It then creates a new per-OEM handler hook, which should know how to handle
events with the OEM[012] Data Available flags set. It then uses this to
implement a workaround for IPMI 1.5-capable Dell PowerEdge servers which
are susceptable to setting the OEM[012] Data Available flags when the
driver can't handle it.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
There are some interactions between IPMI NMI timeouts and the other operations
of the IPMI driver. This make sure those interactions are handled properly.
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix some problems with the high-res timer support.
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
IPMI allows multiple IPMB channels on a single interface, and each channel
might have a different IPMB address. However, the driver has only one IPMB
address that it uses for everything. This patch adds new IOCTLS and a new
internal interface for setting per-channel IPMB addresses and LUNs. New
systems are coming out with support for multiple IPMB channels, and they are
broken without this patch.
Signed-off-by: Corey Minyard <minyard@acm.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Corey Minyard