summaryrefslogtreecommitdiffstats
path: root/drivers/char/ipmi
Commit message (Collapse)AuthorAgeFilesLines
* ipmi/bt-bmc: change compatible node to 'aspeed, ast2400-ibt-bmc'Cédric Le Goater2016-11-171-2/+2
| | | | | | | | | | | | | | The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the other is H8S/2168 compliant. The current ipmi/bt-bmc driver implements the IPMI version and we should reflect its nature in the compatible node name using 'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The latter should be used for a H8S interface driver if it is implemented one day. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Olof Johansson <olof@lixom.net>
* ipmi: fix crash on reading version from proc after unregisted bmcXie XiuQi2016-10-031-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi/bt-bmc: remove redundant return value check of platform_get_resource()Wei Yongjun2016-09-301-5/+0
| | | | | | | | | | Remove unneeded error handling on the result of a call to platform_get_resource() when the value is passed to devm_ioremap_resource(). Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Acked-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi/bt-bmc: add a dependency on ARCH_ASPEEDCédric Le Goater2016-09-291-0/+1
| | | | | Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi: Fix ioremap error handling in bt-bmcJoel Stanley2016-09-291-2/+2
| | | | | | | | devm_ioremap_resource returns ERR_PTR so we can't check for NULL. Signed-off-by: Joel Stanley <joel@jms.id.au> Acked-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi: add an Aspeed BT IPMI BMC driverAlistair Popple2016-09-293-0/+518
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a simple device driver to expose the iBT interface on Aspeed SOCs (AST2400 and AST2500) as a character device. Such SOCs are commonly used as BMCs (BaseBoard Management Controllers) and this driver implements the BMC side of the BT interface. The BT (Block Transfer) interface is used to perform in-band IPMI communication between a host and its BMC. Entire messages are buffered before sending a notification to the other end, host or BMC, that there is data to be read. Usually, the host emits requests and the BMC responses but the specification provides a mean for the BMC to send SMS Attention (BMC-to-Host attention or System Management Software attention) messages. For this purpose, the driver introduces a specific ioctl on the device: 'BT_BMC_IOCTL_SMS_ATN' that can be used by the system running on the BMC to signal the host of such an event. The device name defaults to '/dev/ipmi-bt-host' Signed-off-by: Alistair Popple <alistair@popple.id.au> Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Joel Stanley <joel@jms.id.au> [clg: - checkpatch fixes - added a devicetree binding documentation - replace 'bt_host' by 'bt_bmc' to reflect that the driver is the BMC side of the IPMI BT interface - renamed the device to 'ipmi-bt-host' - introduced a temporary buffer to copy_{to,from}_user - used platform_get_irq() - moved the driver under drivers/char/ipmi/ but kept it as a misc device - changed the compatible cell to "aspeed,ast2400-bt-bmc" ] Signed-off-by: Cédric Le Goater <clg@kaod.org> Acked-by: Arnd Bergmann <arnd@arndb.de> [clg: - checkpatch --strict fixes - removed the use of devm_iounmap, devm_kfree in cleanup paths - introduced an atomic-t to limit opens to 1 - introduced a mutex to protect write/read operations] Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
* Merge branch 'i2c/for-4.8' of ↵Linus Torvalds2016-07-271-1/+5
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c updates from Wolfram Sang: "Here is the I2C pull request for 4.8: - the core and i801 driver gained support for SMBus Host Notify - core support for more than one address in DT - i2c_add_adapter() has now better error messages. We can remove all error messages from drivers calling it as a next step. - bigger updates to rk3x driver to support rk3399 SoC - the at24 eeprom driver got refactored and can now read special variants with unique serials or fixed MAC addresses. The rest is regular driver updates and bugfixes" * 'i2c/for-4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (66 commits) i2c: i801: use IS_ENABLED() instead of checking for built-in or module Documentation: i2c: slave: give proper example for pm usage Documentation: i2c: slave: describe buffer problems a bit better i2c: bcm2835: Don't complain on -EPROBE_DEFER from getting our clock i2c: i2c-smbus: drop useless stubs i2c: efm32: fix a failure path in efm32_i2c_probe() Revert "i2c: core: Cleanup I2C ACPI namespace" Revert "i2c: core: Add function for finding the bus speed from ACPI" i2c: Update the description of I2C_SMBUS i2c: i2c-smbus: fix i2c_handle_smbus_host_notify documentation eeprom: at24: tweak the loop_until_timeout() macro eeprom: at24: add support for at24mac series eeprom: at24: support reading the serial number for 24csxx eeprom: at24: platform_data: use BIT() macro eeprom: at24: split at24_eeprom_write() into specialized functions eeprom: at24: split at24_eeprom_read() into specialized functions eeprom: at24: hide the read/write loop behind a macro eeprom: at24: call read/write functions via function pointers eeprom: at24: coding style fixes eeprom: at24: move at24_read() below at24_eeprom_write() ...
| * i2c: add a protocol parameter to the alert callbackBenjamin Tissoires2016-06-171-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | .alert() is meant to be generic, but there is currently no way for the device driver to know which protocol generated the alert. Add a parameter in .alert() to help the device driver to understand what is given in data. This patch is required to have the support of SMBus Host Notify protocol through .alert(). Tested-by: Andrew Duggan <aduggan@synaptics.com> For hwmon: Acked-by: Guenter Roeck <linux@roeck-us.net> For IPMI: Acked-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* | ipmi: remove trydefaults parameter and default initTony Camuso2016-07-273-87/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Tony Camuso <tcamuso@redhat.com> Removed the config entry and the address source entry for default, since neither were used any more. Signed-off-by: Corey Minyard <cminyard@mvista.com>
* | ipmi: Remove smi_msg from waiting_rcv_msgs list before handle_one_recv_msg()Junichi Nomura2016-06-131-2/+6
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 7ea0ed2b5be8 ("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: 7ea0ed2b5be8 ("ipmi: Make the message handler easier to use for SMI interfaces") Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com> [Added a comment to describe why this works.] Signed-off-by: Corey Minyard <cminyard@mvista.com> Cc: stable@vger.kernel.org # 3.19 Tested-by: Ye Feng <yefeng.yl@alibaba-inc.com>
* ipmi: Fix the I2C address extraction from SPMI tablesCorey Minyard2016-05-161-1/+1
| | | | | | | | | Unlike everywhere else in the IPMI specification, the I2C address specified in the SPMI table is not shifted to the left one bit with the LSB zero. Instead it is not shifted with the MSB zero. Reported-by: Sanjeev <singhsan@codeaurora.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
* IPMI: reserve memio regions separatelyCorey Minyard2016-05-161-13/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit d61a3ead2680 ("[PATCH] IPMI: reserve I/O ports separately") changed the way I/O ports were reserved and includes this comment in log: Some BIOSes reserve disjoint I/O regions in their ACPI tables for the IPMI controller. This causes problems when trying to register the entire I/O region. Therefore we must register each I/O port separately. There is a similar problem with memio regions on an arm64 platform (AMD Seattle). Where I see: ipmi message handler version 39.2 ipmi_si AMDI0300:00: probing via device tree ipmi_si AMDI0300:00: ipmi_si: probing via ACPI ipmi_si AMDI0300:00: [mem 0xe0010000] regsize 1 spacing 4 irq 23 ipmi_si: Adding ACPI-specified kcs state machine IPMI System Interface driver. ipmi_si: Trying ACPI-specified kcs state machine at mem \ address 0xe0010000, slave address 0x0, irq 23 ipmi_si: Could not set up I/O space The problem is that the ACPI core registers disjoint regions for the platform device: e0010000-e0010000 : AMDI0300:00 e0010004-e0010004 : AMDI0300:00 and the ipmi_si driver tries to register one region e0010000-e0010004. Based on a patch from Mark Salter <msalter@redhat.com>, who also wrote all the above text. Signed-off-by: Corey Minyard <cminyard@mvista.com> Tested-by: Mark Salter <msalter@redhat.com>
* ipmi: Fix some minor coding style issuesCorey Minyard2016-05-161-13/+12
| | | | Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi/watchdog: use nmi_panic() when kernel panics in NMI handlerHidehiro Kawai2016-03-221-1/+1
| | | | | | | | | | | | | | | | | | Commit 1717f2096b54 ("panic, x86: Fix re-entrance problem due to panic on NMI") introduced nmi_panic() which prevents concurrent and recursive execution of panic(). It also saves registers for the crash dump on x86 by later commit 58c5661f2144 ("panic, x86: Allow CPUs to save registers even if looping in NMI context"). ipmi_watchdog driver can call panic() from NMI handler, so replace it with nmi_panic(). Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Acked-by: Corey Minyard <cminyard@mvista.com> Acked-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* ipmi: do not probe ACPI devices if si_tryacpi is unsetJoe Lawrence2016-03-181-0/+3
| | | | | | | | | Extend the tryacpi module parameter to turn off acpi_ipmi_probe such that hard-coded options (type, ports, address, etc.) have complete control over the smi_info data structures setup by the driver. Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi_si: Avoid a wrong long timeout on transaction doneCorey Minyard2016-03-181-2/+2
| | | | | | | | | | Under some circumstances, the IPMI state machine could return a call without delay option but the driver would still do a long delay because the result wasn't checked. Instead of calling the state machine after transaction done, just go back to the top of the processing to start over. Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi_si: Fix module parameter doc namesCorey Minyard2016-03-181-2/+2
| | | | | | Several were tryacpi instead of their actual values. Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi_ssif: Fix logic around alert handlingCorey Minyard2016-03-181-9/+4
| | | | | | | There was a mistake in the logic, if an alert came in very quickly it would hang the driver. Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi: put acpi.h with the other headersTony Camuso2016-02-031-2/+1
| | | | | | | | | | | | | | | | | | | Enclosing '#include <linux/acpi.h>' within '#ifdef CONFIG_ACPI' is unnecessary, since it has its own conditional compile for CONFIG_ACPI. Commit 0fbcf4af7c83 ("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: Tony Camuso <tcamuso@redhat.com> Fixed commit reference in header to conform to standard. Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi: Remove unnecessary pci_disable_device.Dave Jones2016-01-121-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Dave Jones <dsj@fb.com>
* char: ipmi: Drop owner assignment from i2c_driverKrzysztof Kozlowski2016-01-121-1/+0
| | | | | | | i2c_driver does not need to set an owner because i2c_register_driver() will set it. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
* ipmi: constify some struct and char arraysLABBE Corentin2016-01-122-14/+20
| | | | | | | | | | 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: LABBE Corentin <clabbe.montjoie@gmail.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi: move timer init to before irq is setupJan Stancek2015-12-091-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Jan Stancek <jstancek@redhat.com> Signed-off-by: Tony Camuso <tcamuso@redhat.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> Cc: stable@vger.kernel.org # Applies cleanly to 3.10-, needs small rework before
* ipmi watchdog : add panic_wdt_timeout parameterJean-Yves Faye2015-11-161-1/+7
| | | | | | | | | | | | | | | | 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 <jean-yves.faye@c-s.fr> Signed-off-by: Corey Minyard <cminyard@mvista.com>
* char: ipmi: Move MODULE_DEVICE_TABLE() to follow structLuis de Bethencourt2015-11-151-1/+1
| | | | | | | | | The policy for drivers is to have MODULE_DEVICE_TABLE() just after the struct used in it. For clarity. Suggested-by: Corey Minyard <minyard@acm.org> Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi: Stop the timer immediately if idleCorey Minyard2015-11-151-0/+7
| | | | | | | | 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 <cminyard@mvista.com>
* ipmi: Start the timer and thread on internal msgsCorey Minyard2015-11-151-29/+44
| | | | | | | | | | | 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 <cminyard@mvista.com> Tested-by: Gouji, Masayuki <gouji.masayuki@jp.fujitsu.com> Cc: stable@vger.kernel.org
* char: ipmi: ipmi_ssif: Replace timeval with timespec64Amitoj Kaur Chawla2015-10-241-4/+5
| | | | | | | | | | | | | | | | 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 <amitoj1606@gmail.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ipmi:ssif: Add a module parm to specify that SMBus alerts don't workCorey Minyard2015-09-031-0/+8
| | | | | | | 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 <cminyard@mvista.com>
* ipmi: add of_device_id in MODULE_DEVICE_TABLEBrijesh Singh2015-09-031-0/+1
| | | | | | | | | | | Fix autoloading ipmi modules when using device tree. Signed-off-by: Brijesh 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: Corey Minyard <cminyard@mvista.com>
* ipmi: Compensate for BMCs that wont set the irq enable bitCorey Minyard2015-09-031-43/+137
| | | | | | | | | | | | 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 <cminyard@mvista.com> Tested-by: Henrik Korkuc <henrik@kirneh.eu>
* ipmi: Don't call receive handler in the panic contextHidehiro Kawai2015-09-031-1/+7
| | | | | | | | | | | | | 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 <hidehiro.kawai.ez@hitachi.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi: Avoid touching possible corrupted lists in the panic contextHidehiro Kawai2015-09-031-0/+17
| | | | | | | | | | | | | | | | | | | | | 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 <hidehiro.kawai.ez@hitachi.com> Fixed a comment typo. Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi: Don't flush messages in sender() in run-to-completion modeHidehiro Kawai2015-09-032-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Fixed up a comment and some spacing issues. Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi: Factor out message flushing procedureHidehiro Kawai2015-09-031-21/+18
| | | | | | | | Factor out message flushing procedure which is used in run-to-completion mode. This patch doesn't change the logic. Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi: Remove unneeded set_run_to_completion callHidehiro Kawai2015-09-031-2/+0
| | | | | | | | | 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: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi: Make some data const that was only readCorey Minyard2015-09-036-36/+39
| | | | | | | Several data structures were only used for reading, so make them const. Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi: constify SSIF ACPI device idsMathias Krause2015-09-031-1/+1
| | | | | | | | Constify the ACPI device ID array, it doesn't need to be writable at runtime. Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi: Delete an unnecessary check before the function call "cleanup_one_si"Markus Elfring2015-09-031-3/+1
| | | | | | | | | | 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: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Corey Minyard <cminyard@mvista.com>
* char:ipmi - Change 1 to true for bool type variables during initialization.Shailendra Verma2015-09-032-6/+6
| | | | | Signed-off-by: Shailendra Verma <shailendra.capricorn@gmail.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
* impi:Remove unneeded setting of module owner to THIS_MODULE in the platform ↵Nicholas Krause2015-09-031-1/+0
| | | | | | | | | | | | 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: Nicholas Krause <xerofoify@gmail.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi: Add a comment in how messages are delivered from the lower layerCorey Minyard2015-09-031-0/+4
| | | | | | To avoid confusion in the future. Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi/powernv: Fix potential invalid pointer dereferenceNeelesh Gupta2015-09-031-1/+8
| | | | | | | | | | | | | | | | 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: Neelesh Gupta <neelegup@linux.vnet.ibm.com> Fixed a checkpatch warning dealing with an else after a return. Signed-off-by: Corey Minyard <cminyard@mvista.com>
* ipmi: Convert the IPMI SI ACPI handling to a platform deviceCorey Minyard2015-09-031-163/+157
| | | | | | | | | | | | | | | 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: Corey Minyard <cminyard@mvista.com>
* Merge tag 'modules-next-for-linus' of ↵Linus Torvalds2015-07-011-3/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux Pull module updates from Rusty Russell: "Main excitement here is Peter Zijlstra's lockless rbtree optimization to speed module address lookup. He found some abusers of the module lock doing that too. A little bit of parameter work here too; including Dan Streetman's breaking up the big param mutex so writing a parameter can load another module (yeah, really). Unfortunately that broke the usual suspects, !CONFIG_MODULES and !CONFIG_SYSFS, so those fixes were appended too" * tag 'modules-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: (26 commits) modules: only use mod->param_lock if CONFIG_MODULES param: fix module param locks when !CONFIG_SYSFS. rcu: merge fix for Convert ACCESS_ONCE() to READ_ONCE() and WRITE_ONCE() module: add per-module param_lock module: make perm const params: suppress unused variable error, warn once just in case code changes. modules: clarify CONFIG_MODULE_COMPRESS help, suggest 'N'. kernel/module.c: avoid ifdefs for sig_enforce declaration kernel/workqueue.c: remove ifdefs over wq_power_efficient kernel/params.c: export param_ops_bool_enable_only kernel/params.c: generalize bool_enable_only kernel/module.c: use generic module param operaters for sig_enforce kernel/params: constify struct kernel_param_ops uses sysfs: tightened sysfs permission checks module: Rework module_addr_{min,max} module: Use __module_address() for module_address_lookup() module: Make the mod_tree stuff conditional on PERF_EVENTS || TRACING module: Optimize __module_address() using a latched RB-tree rbtree: Implement generic latch_tree seqlock: Introduce raw_read_seqcount_latch() ...
| * kernel/params: constify struct kernel_param_ops usesLuis R. Rodriguez2015-05-281-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* | ipmi/powernv: Convert to irq event interfaceAlistair Popple2015-05-221-17/+22
|/ | | | | | | | | | Convert the opal ipmi driver to use the new irq interface for events. Signed-off-by: Alistair Popple <alistair@popple.id.au> Acked-by: Corey Minyard <cminyard@mvista.com> Cc: Corey Minyard <minyard@acm.org> Cc: openipmi-developer@lists.sourceforge.net Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
* ipmi: Fix multi-part message handlingCorey Minyard2015-05-051-13/+38
| | | | | | | | | | | | | | | | | | 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: Corey Minyard <cminyard@mvista.com>
* ipmi: Add alert handling to SSIFCorey Minyard2015-05-051-16/+116
| | | | | | | | | | | 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: Corey Minyard <cminyard@mvista.com>
* ipmi: Fix a problem that messages are not issued in run_to_completion modeHidehiro Kawai2015-05-051-2/+1
| | | | | | | | | | | | | | | 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: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
OpenPOWER on IntegriCloud