Several were tryacpi instead of their actual values.
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>

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

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

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>

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>

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

The cleanup_one_si() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Signed-off-by: NShailendra Verma <shailendra.capricorn@gmail.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

The IPMI SI driver was using direct PNP, but that was not really
ideal because the IPMI device is a platform device.  There was
some special handling in the acpi_pnp.c code for making this work,
but that was breaking ACPI handling for the IPMI SSIF driver.

So without this patch there were significant issues getting the
SSIF driver to work with ACPI.

So use a platform device for ACPI detection and remove the
entry from acpi_pnp.c.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

start_next_msg() issues a message placed in smi_info->waiting_msg
if it is non-NULL.  However, sender() sets a message to
smi_info->curr_msg and NULL to smi_info->waiting_msg in the context
of run_to_completion mode.  As the result, it leads an infinite
loop by waiting the completion of unissued message when leaving
dying message after kernel panic.

sender() should set the message to smi_info->waiting_msg not
curr_msg.
Signed-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

When probing an ACPI table, report a specific error, instead of just
returning an error, if _IFT doesn't exist.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Really ignore them by returning -ENODEV from the probe, but not
doing anything.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

commit d6c5dc18 ("ipmi: Remove uses of return value of seq_printf")
incorrectly changed the return value of various proc_show functions
to use seq_has_overflowed().

These functions should return 0 on completion rather than 1/true
on overflow.  1 is the same as #define SEQ_SKIP which would cause
the output to not be emitted (skipped) instead.

This is a logical defect only as the length of these outputs are
all smaller than the initial allocation done by the seq filesystem.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Some BMCs don't let you clear the receive irq bit in the global
enables.  This is kind of silly, but they give an error if you
try to clear it.  Compensate for this by detecting the situation
and working around it.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NThomas D <whissi@whissi.de>
Reviewed-by: NThomas D <whissi@whissi.de>

of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

From a locking point of view it is safe to check waiting_msg without
a lock, but there is a memory ordering issue that causes it to
possibly not be set right when viewed from another processor.  We are
already claiming a lock right after that, move the check to inside
the lock to enforce the memory ordering.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

The seq_printf like functions will soon be changed to return void.

Convert these uses to check seq_has_overflowed instead.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

As part of the internal y2038 cleanup, this patch removes
timespec usage in the ipmi driver, replacing it timespec64

Cc: openipmi-developer@lists.sourceforge.net
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NCorey Minyard <minyard@mvista.com>

The driver uses #ifdef DEBUG_TIMING in order to conditionally print out
timestamped debug messages. Unfortunately it adds the ifdefs all over the
usage sites.

This patch cleans it up by adding a debug_timestamp() function which
is compiled out if DEBUG_TIMING isn't present. This cleans up all
the ugly ifdefs in the function logic.

Cc: openipmi-developer@lists.sourceforge.net
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NCorey Minyard <minyard@mvista.com>

Removes a no longer needed FIXME comment in the function,acpi_gpe_irq_setup
for the file,ipmi_si_intf.c. This comment is no longer needed as clearly we
are passing the correct level of  ACPI_GPE_LEVEL_TRIGGERED to the installer
function,acpi_install_gpe_handler due to no breakage after years of using
this ACPI level in the function,acpi_install_gpe_handler.
Signed-off-by: NNicholas Krause <xerofoify@gmail.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

On a reset, the BMC may reset the BT enable in the processor
registers (different than the global enables in the BMC).  Check
it periodically and fix it if necessary.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NTony Rex <tony.rex@ericsson.com>
Tested-by: NMagnus Johansson E <magnus.e.johansson@ericsson.com>

If an attention came in while handling a message response, it
could cause the state machine to go into the wrong mode and lock
things up if the state machine wasn't in normal mode.  So if the
state machine is not in normal mode, save the attention flag for
later.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NTony Rex <tony.rex@ericsson.com>
Tested-by: NMagnus Johansson E <magnus.e.johansson@ericsson.com>
Cc: Per Fogelström <per.fogelstrom@ericsson.com>

The BMC can be reset while we are running; that means the interrupt
and event message buffer settings may be wrong.  So periodically
check to see if these values are correct, and fix them if they
are wrong.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Tested-by: NTony Rex <tony.rex@ericsson.com>
Tested-by: NMagnus Johansson E <magnus.e.johansson@ericsson.com>

Since the queue was moved into the message handler, the priority
field is now irrelevant.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

A message queue was added to the message handler, so the SMI
interfaces only need to handle one message at a time.  Pull out
the message queue.  This also leads to some significant
simplification in the shutdown of an interface, since the
message handler now does a lot of the cleanup.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

The handling of BMC flags wasn't quite right in a few places, mainly
around enabling and disabling interrupts in the BMC.  Clean up the
code and fix the handling of the flags.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

There was a wrong variable used in the name parsing.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

It was always "bmc", so just hardcode it.  It makes no sense to
pass that in.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

It was in the system interface driver, but is generic functionality.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

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

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch fixes a bug on hotmod removing.

After ipmi interface is removed using hotmod, kernel panic occurs when
rmmod impi_si.  For example, try this:

 # echo "remove,"`cat /proc/ipmi/0/params` > \
 /sys/module/ipmi_si/parameters/hotmod
 # rmmod ipmi_si

Then, rmmod fails with the following messages.

  ------------[ cut here ]------------
  WARNING: CPU: 12 PID: 10819 at /mnt/repos/linux/lib/list_debug.c:53 __list_del_entry+0x63/0xd0()
  CPU: 12 PID: 10819 Comm: rmmod Not tainted 3.17.0-rc1 #19
  Hardware name: FUJITSU-SV PRIMERGY BX920 S2/D3030, BIOS 080015 Rev.3D81.3030 02/10/2012
  Call Trace:
    dump_stack+0x45/0x56
    warn_slowpath_common+0x7d/0xa0
    warn_slowpath_fmt+0x4c/0x50
    __list_del_entry+0x63/0xd0
    list_del+0xd/0x30
    cleanup_one_si+0x2a/0x230 [ipmi_si]
    ipmi_pnp_remove+0x15/0x20 [ipmi_si]
    pnp_device_remove+0x24/0x40
    __device_release_driver+0x7f/0xf0
    driver_detach+0xb0/0xc0
    bus_remove_driver+0x55/0xd0
    driver_unregister+0x2c/0x50
    pnp_unregister_driver+0x12/0x20
    cleanup_ipmi_si+0xbc/0xf0 [ipmi_si]
    SyS_delete_module+0x132/0x1c0
    system_call_fastpath+0x16/0x1b
  ---[ end trace 70b4377268f85c23 ]---

list_del in cleanup_one_si() fails because the smi_info is already
removed when hotmod removing.

When ipmi interface is removed by hotmod, smi_info is removed by
cleanup_one_si(), but is is still set in drvdata.  Therefore when rmmod
ipmi_si, ipmi_pnp_remove tries to remove it again and fails.

By this patch, a pointer to smi_info in drvdata is cleared when hotmod
removing so that it will be not accessed when rmmod.

changelog:
v2:
- Clear drvdata in cleanup_one_si
- Change subject

v1:
https://lkml.org/lkml/2014/9/8/741Signed-off-by: NTakao Indoh <indou.takao@jp.fujitsu.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Building ipmi on arm with gcc-4.9 results in this warning for an
allmodconfig build:

  drivers/char/ipmi/ipmi_si_intf.c: In function 'ipmi_thread':
  include/linux/time.h:28:5: warning: 'busy_until.tv_sec' may be used uninitialized in this function [-Wmaybe-uninitialized]
    if (lhs->tv_sec > rhs->tv_sec)
       ^
  drivers/char/ipmi/ipmi_si_intf.c:1007:18: note: 'busy_until.tv_sec' was declared here
    struct timespec busy_until;
                    ^

The warning is bogus and this case can not occur.  Apparently this is a
false positive resulting from gcc getting a little smarter about
tracking assignments but not smart enough.

Marking the ipmi_thread_busy_wait function as inline gives the gcc
optimization logic enough information to figure out for itself that the
case cannot happen, which gets rid of the warning without adding any
fake initialization.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>