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: Corey 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: Joe Perches <joe@perches.com>
Signed-off-by: Corey 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: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
This adds a loop through the elements in the linked list, recv_msgs using
list_for_entry_safe in order to free messages in this list. In addition
we are using the safe version of this marco in order to prevent use after
bugs related to deleting the element we are on currently by holding a
pointer to the next element after the current one we are on and freeing
with the function, ipmi_free_recv_msg internally in this loop.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
Signed-off-by: Corey 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: Arnd Bergmann <arnd@arndb.de>
Fixes: 7ea0ed2b5b ("ipmi: Make the message handler easier to use for SMI interfaces")
Signed-off-by: Corey 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: John Stultz <john.stultz@linaro.org>
Signed-off-by: Corey 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: John Stultz <john.stultz@linaro.org>
Signed-off-by: Corey 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: Nicholas Krause <xerofoify@gmail.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
A few new i2c-drivers came into the kernel which clear the clientdata-pointer
on exit or error. This is obsolete meanwhile, the core will do it.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Corey 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: Nicholas Krause <xerofoify@gmail.com>
Signed-off-by: Corey 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: Corey Minyard <cminyard@mvista.com>
Cc: Huang Ying <ying.huang@intel.com>
Tested-by: Alexei Starovoitov <ast@plumgrid.com>
Here's the set of driver core patches for 3.19-rc1.
They are dominated by the removal of the .owner field in platform
drivers. They touch a lot of files, but they are "simple" changes, just
removing a line in a structure.
Other than that, a few minor driver core and debugfs changes. There are
some ath9k patches coming in through this tree that have been acked by
the wireless maintainers as they relied on the debugfs changes.
Everything has been in linux-next for a while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlSOD20ACgkQMUfUDdst+ylLPACg2QrW1oHhdTMT9WI8jihlHVRM
53kAoLeteByQ3iVwWurwwseRPiWa8+MI
=OVRS
-----END PGP SIGNATURE-----
Merge tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core update from Greg KH:
"Here's the set of driver core patches for 3.19-rc1.
They are dominated by the removal of the .owner field in platform
drivers. They touch a lot of files, but they are "simple" changes,
just removing a line in a structure.
Other than that, a few minor driver core and debugfs changes. There
are some ath9k patches coming in through this tree that have been
acked by the wireless maintainers as they relied on the debugfs
changes.
Everything has been in linux-next for a while"
* tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (324 commits)
Revert "ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries"
fs: debugfs: add forward declaration for struct device type
firmware class: Deletion of an unnecessary check before the function call "vunmap"
firmware loader: fix hung task warning dump
devcoredump: provide a one-way disable function
device: Add dev_<level>_once variants
ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries
ath: use seq_file api for ath9k debugfs files
debugfs: add helper function to create device related seq_file
drivers/base: cacheinfo: remove noisy error boot message
Revert "core: platform: add warning if driver has no owner"
drivers: base: support cpu cache information interface to userspace via sysfs
drivers: base: add cpu_device_create to support per-cpu devices
topology: replace custom attribute macros with standard DEVICE_ATTR*
cpumask: factor out show_cpumap into separate helper function
driver core: Fix unbalanced device reference in drivers_probe
driver core: fix race with userland in device_add()
sysfs/kernfs: make read requests on pre-alloc files use the buffer.
sysfs/kernfs: allow attributes to request write buffer be pre-allocated.
fs: sysfs: return EGBIG on write if offset is larger than file size
...
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: Corey Minyard <cminyard@mvista.com>
Tested-by: Tony Rex <tony.rex@ericsson.com>
Tested-by: Magnus 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: Corey Minyard <cminyard@mvista.com>
Tested-by: Tony Rex <tony.rex@ericsson.com>
Tested-by: Magnus 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: Corey Minyard <cminyard@mvista.com>
Tested-by: Tony Rex <tony.rex@ericsson.com>
Tested-by: Magnus Johansson E <magnus.e.johansson@ericsson.com>
This change adds an initial IPMI driver for powerpc OPAL firmware. The
interface is exposed entirely through firmware: we have two functions to
send and receive IPMI messages, and an interrupt notification from the
firmware to signify that a message is available.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Corey 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: Corey 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: Corey 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: Corey 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: Corey Minyard <cminyard@mvista.com>
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/741
Signed-off-by: Takao Indoh <indou.takao@jp.fujitsu.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus 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: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If an IPMI controller is used by the firmware and as such marked with
a reserved status, we shouldn't use it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus 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: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The default probing can cause problems with some system, slow booting,
extra CPU usages, etc. Turn it off by default and give a config option
to enable it.
From: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The OBF timer in KCS was not reset in one situation when error recovery
was started, resulting in an immediate timeout.
Reported-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
With recent changes it is possible for the timer handler to detect an
idle interface and not start the timer, but the thread to start an
operation at the same time. The thread will not start the timer in that
instance, resulting in the timer not running.
Instead, move all timer operations under the lock and start the timer in
the thread if it detect non-idle and the timer is not already running.
Moving under locks allows the last timeout to be set in both the thread
and the timer. 'Timer is not running' means that the timer is not
pending and smi_timeout() is not running. So we need a flag to detect
this correctly.
Also fix a few other timeout bugs: setting the last timeout when the
interrupt has to be disabled and the timer started, and setting the last
timeout in check_start_timer_thread possibly racing with the timer
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In read_all_bytes, we do
unsigned char i;
...
bt->read_data[0] = BMC2HOST;
bt->read_count = bt->read_data[0];
...
for (i = 1; i <= bt->read_count; i++)
bt->read_data[i] = BMC2HOST;
If bt->read_data[0] == bt->read_count == 255, we loop infinitely in the
'for' loop. Make 'i' an 'int' instead of 'char' to get rid of the
overflow and finish the loop after 255 iterations every time.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-and-debugged-by: Rui Hui Dian <rhdian@novell.com>
Cc: Tomas Cech <tcech@suse.cz>
Cc: Corey Minyard <minyard@acm.org>
Cc: <openipmi-developer@lists.sourceforge.net>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
None of these files are actually using any __init type directives
and hence don't need to include <linux/init.h>. Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.
Cc: David Airlie <airlied@linux.ie>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Corey Minyard <minyard@acm.org>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Peter Huewe <peterhuewe@gmx.de>
Cc: Ashley Lai <ashley@ashleylai.com>
Cc: Marcel Selhorst <tpmdd@selhorst.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix
drivers/char/ipmi/ipmi_si_intf.c: In function 'ipmi_parisc_probe':
drivers/char/ipmi/ipmi_si_intf.c:2752:2: error: 'rv' undeclared (first use in this function)
drivers/char/ipmi/ipmi_si_intf.c:2752:2: note: each undeclared identifier is reported only once for each function it appears in
Introduced by commit d02b3709ff ("ipmi: Cleanup error return")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Return proper errors for a lot of IPMI failure cases. Also call
pci_disable_device when IPMI PCI devices are removed.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Loading ipmi_si module while bmc is disconnected, we found the timeout
is longer than 5 secs. Actually it takes about 3 mins and 20
secs.(HZ=250)
error message as below:
Dec 12 19:08:59 linux kernel: IPMI BT: timeout in RD_WAIT [ ] 1 retries left
Dec 12 19:08:59 linux kernel: BT: write 4 bytes seq=0x01 03 18 00 01
[...]
Dec 12 19:12:19 linux kernel: IPMI BT: timeout in RD_WAIT [ ]
Dec 12 19:12:19 linux kernel: failed 2 retries, sending error response
Dec 12 19:12:19 linux kernel: IPMI: BT reset (takes 5 secs)
Dec 12 19:12:19 linux kernel: IPMI BT: flag reset [ ]
Function wait_for_msg_done() use schedule_timeout_uninterruptible(1) to
sleep 1 tick, so we should subtract jiffies_to_usecs(1) instead of 100
usecs from timeout.
Reported-by: Hu Shiyuan <hushiyuan@huawei.com>
Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Use USEC_PER_SEC instead of 1000000, that making the later bugfix
more clearly.
Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>