linux/drivers/char/ipmi, branch v4.4

ipmi: move timer init to before irq is setup

2015-12-09T19:13:06Z

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: [] start_new_msg+0x47/0x80 [ipmi_si] [] start_check_enables+0x4e/0x60 [ipmi_si] [] smi_event_handler+0x1e8/0x640 [ipmi_si] [] ? __rcu_process_callbacks+0x54/0x350 [] si_irq_handler+0x3c/0x60 [ipmi_si] [] handle_IRQ_event+0x60/0x170 [] handle_edge_irq+0xde/0x180 [] handle_irq+0x49/0xa0 [] do_IRQ+0x6c/0xf0 [] 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 CC: linux-kernel@vger.kernel.org Signed-off-by: Jan Stancek Signed-off-by: Tony Camuso Signed-off-by: Corey Minyard Cc: stable@vger.kernel.org # Applies cleanly to 3.10-, needs small rework before

ipmi watchdog : add panic_wdt_timeout parameter

2015-11-16T12:28:43Z

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:26Z

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:26Z

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:26Z

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:42Z

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:31Z

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:31Z

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:30Z

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:29Z

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