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>

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>

impi:Remove unneeded setting of module owner to THIS_MODULE in the platform structure, powernv_ipmi_driver

This removes the no longer required setting of the module owner
for the plaform structure,powernv_ipmi_driver to THIS_MODULE as
the driver core for ipmi drivers will directly find and
set the module owner for this driver.
Signed-off-by: NNicholas Krause <xerofoify@gmail.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

To avoid confusion in the future.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

If the OPAL call to receive the ipmi message fails, then we free up the
smi message and return. But, the driver still holds the reference to
old smi message in the 'cur_msg' which can potentially be accessed later
and freed again leading to kernel oops. To fix it up,

The kernel driver should reset the 'cur_msg' and send reply to the user
in addition to freeing the message.
Signed-off-by: NNeelesh Gupta <neelegup@linux.vnet.ibm.com>

Fixed a checkpatch warning dealing with an else after a return.
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>

Most code already uses consts for the struct kernel_param_ops,
sweep the kernel for the last offending stragglers. Other than
include/linux/moduleparam.h and kernel/params.c all other changes
were generated with the following Coccinelle SmPL patch. Merge
conflicts between trees can be handled with Coccinelle.

In the future git could get Coccinelle merge support to deal with
patch --> fail --> grammar --> Coccinelle --> new patch conflicts
automatically for us on patches where the grammar is available and
the patch is of high confidence. Consider this a feature request.

Test compiled on x86_64 against:

	* allnoconfig
	* allmodconfig
	* allyesconfig

@ const_found @
identifier ops;
@@

const struct kernel_param_ops ops = {
};

@ const_not_found depends on !const_found @
identifier ops;
@@

-struct kernel_param_ops ops = {
+const struct kernel_param_ops ops = {
};

Generated-by: Coccinelle SmPL
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Junio C Hamano <gitster@pobox.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: cocci@systeme.lip6.fr
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Convert the opal ipmi driver to use the new irq interface for events.
Signed-off-by: NAlistair Popple <alistair@popple.id.au>
Acked-by: NCorey Minyard <cminyard@mvista.com>
Cc: Corey Minyard <minyard@acm.org>
Cc: openipmi-developer@lists.sourceforge.net
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

Lots of little fixes for multi-part messages:

The values was not being re-initialized, if something went wrong
handling a multi-part message and it got left in a bad state, it
might be an issue.

The commands were not correct when issuing multi-part reads, the
code was not passing in the proper value for commands.  Also clean
up some minor formatting issues.

Get the block number from the right location, limit the maximum send
message size to 63 bytes and explain why, and fix some minor sylistic
issues.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

The SSIF interface can optionally have an SMBus alert come in when
data is ready.  Unfortunately, the IPMI spec gives wiggle room to
the implementer to allow them to always have the alert enabled,
even if the driver doesn't enable it.  So implement alerts.
If you don't in this situation, the SMBus alert handling will
constantly complain.
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>

Remove including <linux/version.h> that don't need it.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
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 of the adapters have spaces in their names, but that's really
hard to pass in as a module or kernel parameters.  So ignore the
spaces.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Returning zero is success.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

The code was using an normal completion, but that caused stuck
task errors after a while.  Use an interruptible one to avoid that.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>