It's only function pointers.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

When a computer has an IPMI system interface, the device interface
is most probably also desired. Autoloading of ipmi_devintf currently
works only if ipmi_si has allocated a platform device. That doesn't
happen if the SI interface was detected e.g. via ACPI. But ACPI
detection is preferred these days, see e.g. kernel.org bug 46741.

This patch introduces a softdep in place of the existing modalias
for ipmi_devintf.
Signed-off-by: NMartin Wilck <mwilck@suse.com>
Suggested-by: NTakashi Iwai <tiwai@suse.com>

I moved this to ipmi_msghandler.c, so it works for all IPMI
interfaces.  Retested by Martin.
Tested-by: NMartin Wilck <mwilck@suse.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

The IPMI message handler uses a message id that the lower-layer
preserved to track the sequence number of the message.  The macros
that handled these sequence numbers were somewhat broken as they
could result in sequence number truncation and they were not
doing an "and" of the proper number of bits.

I think this actually is not a problem, because the truncation
should be harmless and the improper "and" didn't hurt anything
because sequence number generation used the same improper "and"
and wouldn't generate a sequence number that would get
truncated wrong.  However, it should be fixed.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.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>

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>

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>

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>

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>

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>

To avoid confusion in the future.
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>

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>

Instead of manual calls of device_create_file() and
device_remove_file(), implement the condition in is_visible callback
for the attribute group and put these entries to the group, too.
This simplifies the code and avoids the possible races.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

A new harmless warning has come up on ARM builds with gcc-4.9:

drivers/char/ipmi/ipmi_msghandler.c: In function 'smi_send.isra.11':
include/linux/spinlock.h:372:95: warning: 'flags' may be used uninitialized in this function [-Wmaybe-uninitialized]
  raw_spin_unlock_irqrestore(&lock->rlock, flags);
                                                                                               ^
drivers/char/ipmi/ipmi_msghandler.c:1490:16: note: 'flags' was declared here
  unsigned long flags;
                ^

This could be worked around by initializing the 'flags' variable, but it
seems better to rework the code to avoid this.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 7ea0ed2b ("ipmi: Make the message handler easier to use for SMI interfaces")
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

There can't be more than a few IPMI messages allocated at any one time,
so converting the messages to slabs would be a waste.  So just remove
the FIXME.
Suggested-by: NNicholas Krause <xerofoify@gmail.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

The previous cleanup of BMC attributes left a few holes, and if
you run with lockdep debugging with a BMC with the proper attributes,
you could get a warning.

This patch removes all the unused attributes from the BMC structure,
since they are all declared in the .data section now.  It makes
the attributes all static.  It fixes the referencing of the
attributes in a couple of cases that dynamically added the files
depending on BMC information.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Cc: Huang Ying <ying.huang@intel.com>
Tested-by: NAlexei Starovoitov <ast@plumgrid.com>

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

The message handler expected the SMI interface to keep a queue of
messages, but that was kind of silly, the queue would be easier to
manage in the message handler itself.  As part of that, fix the
message cleanup to make sure no messages are outstanding when an
SMI interface is unregistered.  This makes it easier for an SMI
interface to unregister, it just has to call ipmi_unregister_smi()
first and all processing from the message handler will be cleaned
up.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

Getting ready for a transmit queue.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

To avoid confusion with the coming transmit message queue.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>

This avoids an oops at initialization time.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Cc: Sanjeev <singhsan@codeaurora.org>

Signed-off-by: NThomas Renninger <trenn@suse.de>
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>

Embed the platform device in the bmc device instead of externally
allocating it, use more proper form for creating the device
attributes, and other general cleanups.
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>

The code to send the channel config errors was missing an error report
in one place and needed some more information in another, and had an
extraneous bit of code.  Clean all that up.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Convert some ints to bools.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The IPMI driver would wake up periodically looking for events and
watchdog pretimeouts.  If there is nothing waiting for these events,
it's really kind of pointless to be checking for them.  So modify the
driver so the message handler can pass down if it needs the lower layer
to be waiting for these.  Modify the system interface lower layer to
turn off all timer and thread activity if the upper layer doesn't need
anything and it is not currently handling messages.  And modify the
message handler to not restart the timer if its timer is not needed.

The timers and kthread will still be enabled if:
 - the SI interface is handling a message.
 - a user has enabled watching for events.
 - the IPMI watchdog timer is in use (since it uses pretimeouts).
 - the message handler is waiting on a remote response.
 - a user has registered to receive commands.

This mostly affects interfaces without interrupts.  Interfaces with
interrupts already don't use CPU in the system interface when the
interface is idle.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

A couple of variables were getting warnings about being uninitialized.
It was a false warning, but initialize them, anyway.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Replaced calls to kmalloc followed by strcpy with a sincle call to
kstrdup.  Patch found using coccinelle.
Signed-off-by: NAlexandru Gheorghiu <gheorghiuandru@gmail.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Supply a function (proc_remove()) to remove a proc entry (and any subtree
rooted there) by proc_dir_entry pointer rather than by name and (optionally)
root dir entry pointer.  This allows us to eliminate all remaining pde->name
accesses outside of procfs.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NGrant Likely <grant.likely@linaro.or>
cc: linux-acpi@vger.kernel.org
cc: openipmi-developer@lists.sourceforge.net
cc: devicetree-discuss@lists.ozlabs.org
cc: linux-pci@vger.kernel.org
cc: netdev@vger.kernel.org
cc: netfilter-devel@vger.kernel.org
cc: alsa-devel@alsa-project.org
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

The only part of proc_dir_entry the code outside of fs/proc
really cares about is PDE(inode)->data.  Provide a helper
for that; static inline for now, eventually will be moved
to fs/proc, along with the knowledge of struct proc_dir_entry
layout.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

"Asynchronous" is misspelled in some comments. No code changes.
Signed-off-by: NAdam Buchbinder <adam.buchbinder@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

There was a spot where the compiler couldn't tell some variables
would be set.  So initialize them to make the warning go away.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The part of the IPMI driver that delivered panic information to the event
log and extended the watchdog timeout during a panic was not properly
handling the messages.  It used static messages to avoid allocation, but
wasn't properly waiting for these, or wasn't properly handling the
refcounts.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The IPMI driver would release a lock, deliver a message, then relock.
This is obviously ugly, and this patch converts the message handler
interface to use a tasklet to schedule work.  This lets the receive
handler be called from an interrupt handler with interrupts enabled.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Remove all #inclusions of asm/system.h preparatory to splitting and killing
it.  Performed with the following command:

perl -p -i -e 's!^#\s*include\s*<asm/system[.]h>.*\n!!' `grep -Irl '^#\s*include\s*<asm/system[.]h>' *`
Signed-off-by: NDavid Howells <dhowells@redhat.com>