linux.git/drivers/char/ipmi, branch v4.4-rc2

ipmi watchdog : add panic_wdt_timeout parameter

2015-11-16T12:28:43+00:00

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: Jean-Yves Faye 
Signed-off-by: Corey Minyard

char: ipmi: Move MODULE_DEVICE_TABLE() to follow struct

2015-11-16T03:08:26+00:00

The policy for drivers is to have MODULE_DEVICE_TABLE() just after the
struct used in it. For clarity.

Suggested-by: Corey Minyard 
Signed-off-by: Luis de Bethencourt 
Signed-off-by: Corey Minyard

ipmi: Stop the timer immediately if idle

2015-11-16T03:08:26+00:00

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: Corey Minyard

ipmi: Start the timer and thread on internal msgs

2015-11-16T03:08:26+00:00

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: Corey Minyard 
Tested-by: Gouji, Masayuki 
Cc: stable@vger.kernel.org

char: ipmi: ipmi_ssif: Replace timeval with timespec64

2015-10-25T02:46:42+00:00

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: Amitoj Kaur Chawla 
Reviewed-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

ipmi:ssif: Add a module parm to specify that SMBus alerts don't work

2015-09-03T20:02:31+00:00

They are broken on some platforms, this gives people a chance to work
around it until the firmware is fixed.

Signed-off-by: Corey Minyard

ipmi: add of_device_id in MODULE_DEVICE_TABLE

2015-09-03T20:02:31+00:00

Fix autoloading ipmi modules when using device tree.

Signed-off-by: Brijesh Singh 

Moved this change up into the CONFIG_OF section to account
for changes to the probing code.

Signed-off-by: Corey Minyard

ipmi: Compensate for BMCs that wont set the irq enable bit

2015-09-03T20:02:30+00:00

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: Corey Minyard 
Tested-by: Henrik Korkuc

ipmi: Don't call receive handler in the panic context

2015-09-03T20:02:29+00:00

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: Hidehiro Kawai 
Signed-off-by: Corey Minyard

ipmi: Avoid touching possible corrupted lists in the panic context

2015-09-03T20:02:29+00:00

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: Hidehiro Kawai 

Fixed a comment typo.

Signed-off-by: Corey Minyard