Convert them to pr_xxx or dev_xxx.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Some logs are printed out early using smi->dev, but on a platform device
that is not created until later.  So move the creation of that device
structure earlier in the sequence so it can be used for printing.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NCorentin Labbe <clabbe.montjoie@gmail.com>

Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Commit d9b7e4f7 ("ipmi: Periodically check to see if irqs and
messages are set right") to verify the contents of global events.
However, the wrong function was being called in some cases, checking
for messages, not events.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NJason DiPietro <J.DiPietro@F5.com>

I meet a crash, which could be reproduce:
1) while true; do cat /proc/ipmi/0/version; done
2) modprobe -rv ipmi_si ipmi_msghandler ipmi_devintf

[82761.021137] IPMI BT: req2rsp=5 secs retries=2
[82761.034524] ipmi device interface
[82761.222218] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x0007db, prod_id: 0x0001, dev_id: 0x01)
[82761.222230] ipmi_si ipmi_si.0: IPMI bt interface initialized
[82903.922740] BUG: unable to handle kernel NULL pointer dereference at 00000000000002d4
[82903.930952] IP: [<ffffffffa030d9e8>] smi_version_proc_show+0x18/0x40 [ipmi_msghandler]
[82903.939220] PGD 86693a067 PUD 865304067 PMD 0
[82903.943893] Thread overran stack, or stack corrupted
[82903.949034] Oops: 0000 [#1] SMP
[82903.983091] Modules linked in: ipmi_si(-) ipmi_msghandler binfmt_misc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter
...
[82904.057285]  pps_core scsi_transport_sas dm_mod vfio_iommu_type1 vfio xt_sctp nf_conntrack_proto_sctp nf_nat_proto_sctp
                nf_nat nf_conntrack sctp libcrc32c [last unloaded: ipmi_devintf]
[82904.073169] CPU: 37 PID: 28089 Comm: cat Tainted: GF          O   ---- -------   3.10.0-327.28.3.el7.x86_64 #1
[82904.083373] Hardware name: Huawei RH2288H V3/BC11HGSA0, BIOS 3.22 05/16/2016
[82904.090592] task: ffff880101cc2e00 ti: ffff880369c54000 task.ti: ffff880369c54000
[82904.098414] RIP: 0010:[<ffffffffa030d9e8>]  [<ffffffffa030d9e8>] smi_version_proc_show+0x18/0x40 [ipmi_msghandler]
[82904.109124] RSP: 0018:ffff880369c57e70  EFLAGS: 00010203
[82904.114608] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000024688470
[82904.121912] RDX: fffffffffffffff4 RSI: ffffffffa0313404 RDI: ffff8808670ce200
[82904.129218] RBP: ffff880369c57e70 R08: 0000000000019720 R09: ffffffff81204a27
[82904.136521] R10: ffff88046f803300 R11: 0000000000000246 R12: ffff880662399700
[82904.143828] R13: 0000000000000001 R14: ffff880369c57f48 R15: ffff8808670ce200
[82904.151128] FS:  00007fb70c9ca740(0000) GS:ffff88086e340000(0000) knlGS:0000000000000000
[82904.159557] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[82904.165473] CR2: 00000000000002d4 CR3: 0000000864c0c000 CR4: 00000000003407e0
[82904.172778] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[82904.180084] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[82904.187385] Stack:
[82904.189573]  ffff880369c57ee0 ffffffff81204f1a 00000000122a2427 0000000001426000
[82904.197392]  ffff8808670ce238 0000000000010000 0000000000000000 0000000000000fff
[82904.205198]  00000000122a2427 ffff880862079600 0000000001426000 ffff880369c57f48
[82904.212962] Call Trace:
[82904.219667]  [<ffffffff81204f1a>] seq_read+0xfa/0x3a0
[82904.224893]  [<ffffffff8124ce2d>] proc_reg_read+0x3d/0x80
[82904.230468]  [<ffffffff811e102c>] vfs_read+0x9c/0x170
[82904.235689]  [<ffffffff811e1b7f>] SyS_read+0x7f/0xe0
[82904.240816]  [<ffffffff81649209>] system_call_fastpath+0x16/0x1b
[82904.246991] Code: 30 a0 e8 0c 6f ef e0 5b 5d c3 66 0f 1f 84 00 00 00 00 00 0f 1f
               44 00 00 48 8b 47 78 55 48 c7 c6 04 34 31 a0 48 89 e5 48 8b 40 50 <0f>
	       b6 90 d4 02 00 00 31 c0 89 d1 83 e2 0f c0 e9 04 0f b6 c9 e8
[82904.267710] RIP  [<ffffffffa030d9e8>] smi_version_proc_show+0x18/0x40 [ipmi_msghandler]
[82904.276079]  RSP <ffff880369c57e70>
[82904.279734] CR2: 00000000000002d4
[82904.283731] ---[ end trace a69e4328b49dd7c4 ]---
[82904.328118] Kernel panic - not syncing: Fatal exception

Reading versin from /proc need bmc device struct available. So in this patch
we move add/remove_proc_entries between ipmi_bmc_register and ipmi_bmc_unregister.

Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Remove unneeded error handling on the result of a call
to platform_get_resource() when the value is passed to
devm_ioremap_resource().
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Acked-by: NCédric Le Goater <clg@kaod.org>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Signed-off-by: NCédric Le Goater <clg@kaod.org>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

devm_ioremap_resource returns ERR_PTR so we can't check for NULL.
Signed-off-by: NJoel Stanley <joel@jms.id.au>
Acked-by: NCédric Le Goater <clg@kaod.org>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

This patch adds a simple device driver to expose the iBT interface on
Aspeed SOCs (AST2400 and AST2500) as a character device. Such SOCs are
commonly used as BMCs (BaseBoard Management Controllers) and this
driver implements the BMC side of the BT interface.

The BT (Block Transfer) interface is used to perform in-band IPMI
communication between a host and its BMC. Entire messages are buffered
before sending a notification to the other end, host or BMC, that
there is data to be read. Usually, the host emits requests and the BMC
responses but the specification provides a mean for the BMC to send
SMS Attention (BMC-to-Host attention or System Management Software
attention) messages.

For this purpose, the driver introduces a specific ioctl on the
device: 'BT_BMC_IOCTL_SMS_ATN' that can be used by the system running
on the BMC to signal the host of such an event.

The device name defaults to '/dev/ipmi-bt-host'
Signed-off-by: NAlistair Popple <alistair@popple.id.au>
Signed-off-by: NJeremy Kerr <jk@ozlabs.org>
Signed-off-by: NJoel Stanley <joel@jms.id.au>
[clg: - checkpatch fixes
      - added a devicetree binding documentation
      - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
        the BMC side of the IPMI BT interface
      - renamed the device to 'ipmi-bt-host'
      - introduced a temporary buffer to copy_{to,from}_user
      - used platform_get_irq()
      - moved the driver under drivers/char/ipmi/ but kept it as a misc
        device
      - changed the compatible cell to "aspeed,ast2400-bt-bmc"
]
Signed-off-by: NCédric Le Goater <clg@kaod.org>
Acked-by: NArnd Bergmann <arnd@arndb.de>
[clg: - checkpatch --strict fixes
      - removed the use of devm_iounmap, devm_kfree in cleanup paths
      - introduced an atomic-t to limit opens to 1
      - introduced a mutex to protect write/read operations]
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NCédric Le Goater <clg@kaod.org>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Parameter trydefaults=1 causes the ipmi_init to initialize ipmi through
the legacy port io space that was designated for ipmi. Architectures
that do not map legacy port io can panic when trydefaults=1.

Rather than implement build-time conditional exceptions for each
architecture that does not map legacy port io, we have removed legacy
port io from the driver.

Parameter 'trydefaults' has been removed. Attempts to use it hereafter
will evoke the "Unknown symbol in module, or unknown parameter" message.

The patch was built against a number of architectures and tested for
regressions and functionality on x86_64 and ARM64.
Signed-off-by: NTony Camuso <tcamuso@redhat.com>

Removed the config entry and the address source entry for default,
since neither were used any more.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

.alert() is meant to be generic, but there is currently no way
for the device driver to know which protocol generated the alert.
Add a parameter in .alert() to help the device driver to understand
what is given in data.

This patch is required to have the support of SMBus Host Notify protocol
through .alert().
Tested-by: NAndrew Duggan <aduggan@synaptics.com>
For hwmon:
Acked-by: NGuenter Roeck <linux@roeck-us.net>
For IPMI:
Acked-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Commit 7ea0ed2b ("ipmi: Make the message handler easier to use for
SMI interfaces") changed handle_new_recv_msgs() to call handle_one_recv_msg()
for a smi_msg while the smi_msg is still connected to waiting_rcv_msgs list.
That could lead to following list corruption problems:

1) low-level function treats smi_msg as not connected to list

  handle_one_recv_msg() could end up calling smi_send(), which
  assumes the msg is not connected to list.

  For example, the following sequence could corrupt list by
  doing list_add_tail() for the entry still connected to other list.

    handle_new_recv_msgs()
      msg = list_entry(waiting_rcv_msgs)
      handle_one_recv_msg(msg)
        handle_ipmb_get_msg_cmd(msg)
          smi_send(msg)
            spin_lock(xmit_msgs_lock)
            list_add_tail(msg)
            spin_unlock(xmit_msgs_lock)

2) race between multiple handle_new_recv_msgs() instances

  handle_new_recv_msgs() once releases waiting_rcv_msgs_lock before calling
  handle_one_recv_msg() then retakes the lock and list_del() it.

  If others call handle_new_recv_msgs() during the window shown below
  list_del() will be done twice for the same smi_msg.

  handle_new_recv_msgs()
    spin_lock(waiting_rcv_msgs_lock)
    msg = list_entry(waiting_rcv_msgs)
    spin_unlock(waiting_rcv_msgs_lock)
  |
  | handle_one_recv_msg(msg)
  |
    spin_lock(waiting_rcv_msgs_lock)
    list_del(msg)
    spin_unlock(waiting_rcv_msgs_lock)

Fixes: 7ea0ed2b ("ipmi: Make the message handler easier to use for SMI interfaces")
Signed-off-by: NJun'ichi Nomura <j-nomura@ce.jp.nec.com>
[Added a comment to describe why this works.]
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Cc: stable@vger.kernel.org # 3.19
Tested-by: NYe Feng <yefeng.yl@alibaba-inc.com>

Unlike everywhere else in the IPMI specification, the I2C address
specified in the SPMI table is not shifted to the left one bit with
the LSB zero.  Instead it is not shifted with the MSB zero.
Reported-by: NSanjeev <singhsan@codeaurora.org>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Commit d61a3ead ("[PATCH] IPMI: reserve I/O ports separately")
changed the way I/O ports were reserved and includes this comment in
log:

 Some BIOSes reserve disjoint I/O regions in their ACPI tables for the IPMI
 controller.  This causes problems when trying to register the entire I/O
 region.  Therefore we must register each I/O port separately.

There is a similar problem with memio regions on an arm64 platform
(AMD Seattle). Where I see:

 ipmi message handler version 39.2
 ipmi_si AMDI0300:00: probing via device tree
 ipmi_si AMDI0300:00: ipmi_si: probing via ACPI
 ipmi_si AMDI0300:00: [mem 0xe0010000] regsize 1 spacing 4 irq 23
 ipmi_si: Adding ACPI-specified kcs state machine
 IPMI System Interface driver.
 ipmi_si: Trying ACPI-specified kcs state machine at mem \
          address 0xe0010000, slave address 0x0, irq 23
 ipmi_si: Could not set up I/O space

The problem is that the ACPI core registers disjoint regions for the
platform device:

e0010000-e0010000 : AMDI0300:00
e0010004-e0010004 : AMDI0300:00

and the ipmi_si driver tries to register one region e0010000-e0010004.

Based on a patch from Mark Salter <msalter@redhat.com>, who also wrote
all the above text.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NMark Salter <msalter@redhat.com>

Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Commit 1717f209 ("panic, x86: Fix re-entrance problem due to panic
on NMI") introduced nmi_panic() which prevents concurrent and recursive
execution of panic().  It also saves registers for the crash dump on x86
by later commit 58c5661f ("panic, x86: Allow CPUs to save registers
even if looping in NMI context").

ipmi_watchdog driver can call panic() from NMI handler, so replace it
with nmi_panic().
Signed-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Acked-by: NCorey Minyard <cminyard@mvista.com>
Acked-by: NGuenter Roeck <linux@roeck-us.net>
Reviewed-by: NMichal Hocko <mhocko@suse.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Extend the tryacpi module parameter to turn off acpi_ipmi_probe such
that hard-coded options (type, ports, address, etc.) have complete
control over the smi_info data structures setup by the driver.
Signed-off-by: NJoe Lawrence <joe.lawrence@stratus.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Under some circumstances, the IPMI state machine could return
a call without delay option but the driver would still do a long
delay because the result wasn't checked.  Instead of calling
the state machine after transaction done, just go back to the
top of the processing to start over.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Several were tryacpi instead of their actual values.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

There was a mistake in the logic, if an alert came in very quickly
it would hang the driver.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Enclosing '#include <linux/acpi.h>' within '#ifdef CONFIG_ACPI' is
unnecessary, since it has its own conditional compile for CONFIG_ACPI.

Commit 0fbcf4af ("ipmi: Convert the IPMI SI ACPI handling to a
platform device") exposed this as a problem for platforms that do not
support ACPI when it introduced a call to ACPI_PTR() macro outside of
the CONFIG_ACPI conditional compile. This would have been perfectly
acceptable if acpi.h were not conditionally excluded for the non-acpi
platform, because the conditional compile within acpi.h defines
ACPI_PTR() to return NULL when compiled for non acpi platforms.
Signed-off-by: NTony Camuso <tcamuso@redhat.com>

Fixed commit reference in header to conform to standard.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

We call cleanup_one_si from ipmi_pci_remove, which calls ->addr_source_cleanup,
 which gets set to point to ipmi_pci_cleanup, which does a pci_disable_device.

On return from this, we do a second pci_disable_device, which
results in the trace below.

ipmi_si 0000:00:16.0: disabling already-disabled device
Call Trace:
 [<ffffffff818ce54c>] dump_stack+0x45/0x57
 [<ffffffff810525f7>] warn_slowpath_common+0x97/0xe0
 [<ffffffff810526f6>] warn_slowpath_fmt+0x46/0x50
 [<ffffffff81497ca1>] pci_disable_device+0xb1/0xc0
 [<ffffffffa00851a5>] ipmi_pci_remove+0x25/0x30 [ipmi_si]
 [<ffffffff8149a696>] pci_device_remove+0x46/0xc0
 [<ffffffff8156801f>] __device_release_driver+0x7f/0xf0
 [<ffffffff81568978>] driver_detach+0xb8/0xc0
 [<ffffffff81567e50>] bus_remove_driver+0x50/0xa0
 [<ffffffff8156914e>] driver_unregister+0x2e/0x60
 [<ffffffff8149a3e5>] pci_unregister_driver+0x25/0x90
 [<ffffffffa0085804>] cleanup_ipmi_si+0xd4/0xf0 [ipmi_si]
 [<ffffffff810c727a>] SyS_delete_module+0x12a/0x200
 [<ffffffff818d4d72>] system_call_fastpath+0x12/0x17
Signed-off-by: NDave Jones <dsj@fb.com>

i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>

Lots of char arrays could be set as const since they contain only literal
char arrays.
We could in the same time make const some struct members who are pointer
to those const char arrays.
Signed-off-by: NLABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

We encountered a panic on boot in ipmi_si on a dell per320 due to an
uninitialized timer as follows.

static int smi_start_processing(void       *send_info,
                                ipmi_smi_t intf)
{
        /* Try to claim any interrupts. */
        if (new_smi->irq_setup)
                new_smi->irq_setup(new_smi);

 --> IRQ arrives here and irq handler tries to modify uninitialized timer

    which triggers BUG_ON(!timer->function) in __mod_timer().

 Call Trace:
   <IRQ>
   [<ffffffffa0532617>] start_new_msg+0x47/0x80 [ipmi_si]
   [<ffffffffa053269e>] start_check_enables+0x4e/0x60 [ipmi_si]
   [<ffffffffa0532bd8>] smi_event_handler+0x1e8/0x640 [ipmi_si]
   [<ffffffff810f5584>] ? __rcu_process_callbacks+0x54/0x350
   [<ffffffffa053327c>] si_irq_handler+0x3c/0x60 [ipmi_si]
   [<ffffffff810efaf0>] handle_IRQ_event+0x60/0x170
   [<ffffffff810f245e>] handle_edge_irq+0xde/0x180
   [<ffffffff8100fc59>] handle_irq+0x49/0xa0
   [<ffffffff8154643c>] do_IRQ+0x6c/0xf0
   [<ffffffff8100ba53>] ret_from_intr+0x0/0x11

        /* Set up the timer that drives the interface. */
        setup_timer(&new_smi->si_timer, smi_timeout, (long)new_smi);

The following patch fixes the problem.

To: Openipmi-developer@lists.sourceforge.net
To: Corey Minyard <minyard@acm.org>
CC: linux-kernel@vger.kernel.org
Signed-off-by: NJan Stancek <jstancek@redhat.com>
Signed-off-by: NTony Camuso <tcamuso@redhat.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Cc: stable@vger.kernel.org # Applies cleanly to 3.10-, needs small rework before

In order to allow panic actions to be processed, the ipmi watchdog
driver sets a new timeout value on panic. The 255s timeout
was designed to allow kdump and others actions on panic, as in
http://lkml.iu.edu/hypermail/linux/kernel/0711.3/0258.html

This is counter-intuitive for a end-user who sets watchdog timeout
value to something like 30s and who expects BMC to reset the system
within 30s of a panic.

This commit allows user to configure the timeout on panic.
Signed-off-by: NJean-Yves Faye <jean-yves.faye@c-s.fr>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

The policy for drivers is to have MODULE_DEVICE_TABLE() just after the
struct used in it. For clarity.
Suggested-by: NCorey Minyard <minyard@acm.org>
Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

The IPMI driver would let the final timeout just happen, but it could
easily just stop the timer.  If the timer stop fails that's ok, that
should be rare.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

The timer and thread were not being started for internal messages,
so in interrupt mode if something hung the timer would never go
off and clean things up.  Factor out the internal message sending
and start the timer for those messages, too.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NGouji, Masayuki <gouji.masayuki@jp.fujitsu.com>
Cc: stable@vger.kernel.org

This patch replaces timeval with timespec64 as 32 bit 'struct timeval'
will not give current time beyond 2038.

The patch changes the code to use ktime_get_real_ts64() which returns
a 'struct timespec64' instead of do_gettimeofday() which returns a
'struct timeval'

This patch also alters the format string in pr_info() for now.tv_sec
to incorporate 'long long' on 32 bit architectures.
Signed-off-by: NAmitoj Kaur Chawla <amitoj1606@gmail.com>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

They are broken on some platforms, this gives people a chance to work
around it until the firmware is fixed.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Fix autoloading ipmi modules when using device tree.
Signed-off-by: NBrijesh Singh <brijeshkumar.singh@amd.com>

Moved this change up into the CONFIG_OF section to account
for changes to the probing code.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

It appears that some BMCs support interrupts but don't support setting
the irq enable bits.  The interrupts are just always on.  Sigh.
Add code to compensate.

The new code was very similar to another functions, so this also
factors out the common code into other functions.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NHenrik Korkuc <henrik@kirneh.eu>

Received handlers defined as ipmi_recv_hndl member of struct
ipmi_user_hndl can take a spinlock.  This means that if the kernel
panics while holding the lock, a deadlock may happen on the lock
while flushing queued messages in the panic context.

Calling the receive handler doesn't make much meanings in the panic
context, simply skip it to avoid possible deadlocks.
Signed-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

When processing queued messages in the panic context, IPMI driver
tries to do it without any locking to avoid deadlocks.  However,
this means we can touch a corrupted list if the kernel panicked
while manipulating the list.  Fortunately, current `add-tail and
del-from-head' style implementation won't touch the corrupted part,
but it is inherently risky.

To get rid of the risk, this patch re-initializes the message lists
on panic if the related spinlock has already been acquired.  As the
result, we may lose queued messages, but it's not so painful.
Dropping messages on the received message list is also less
problematic because no one can respond the received messages.
Signed-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>

Fixed a comment typo.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

When flushing queued messages in run-to-completion mode,
smi_event_handler() is recursively called.

flush_messages()
 smi_event_handler()
  handle_transaction_done()
   deliver_recv_msg()
    ipmi_smi_msg_received()
     smi_recv_tasklet()
      sender()
       flush_messages()
        smi_event_handler()
         ...

The depth of the recursive call depends on the number of queued
messages, so it can cause a stack overflow if many messages have
been queued.

To solve this problem, this patch removes flush_messages()
from sender()@ipmi_si_intf.c.  Instead, add flush_messages() to
caller side of sender() if needed.  Additionally, to implement this,
add new handler flush_messages to struct ipmi_smi_handlers.
Signed-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>

Fixed up a comment and some spacing issues.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Factor out message flushing procedure which is used in run-to-completion
mode.  This patch doesn't change the logic.
Signed-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

send_panic_events() calls intf->handlers->set_run_to_completion(),
but it has already been done in the caller function panic_event().
Remove it from send_panic_events().
Signed-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Several data structures were only used for reading, so make them
const.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Constify the ACPI device ID array, it doesn't need to be writable at
runtime.
Signed-off-by: NMathias Krause <minipli@googlemail.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>