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>
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>
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>
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()
...
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>
.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>
Commit 7ea0ed2b5b ("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: 7ea0ed2b5b ("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>
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>
Commit d61a3ead26 ("[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>
Commit 1717f2096b ("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 58c5661f21 ("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>
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>
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>
Enclosing '#include <linux/acpi.h>' within '#ifdef CONFIG_ACPI' is
unnecessary, since it has its own conditional compile for CONFIG_ACPI.
Commit 0fbcf4af7c ("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>
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>
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>
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
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>
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>
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>
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
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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.
Cheers,
Rusty.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVkgKHAAoJENkgDmzRrbjxQpwQAJVmBN6jF3SnwbQXv9vRixjH
58V33sb1G1RW+kXxQ3/e8jLX/4VaN479CufruXQp+IJWXsN/CH0lbC3k8m7u50d7
b1Zeqd/Yrh79rkc11b0X1698uGCSMlzz+V54Z0QOTEEX+nSu2ZZvccFS4UaHkn3z
rqDo00lb7rxQz8U25qro2OZrG6D3ub2q20TkWUB8EO4AOHkPn8KWP2r429Axrr0K
wlDWDTTt8/IsvPbuPf3T15RAhq1avkMXWn9nDXDjyWbpLfTn8NFnWmtesgY7Jl4t
GjbXC5WYekX3w2ZDB9KaT/DAMQ1a7RbMXNSz4RX4VbzDl+yYeSLmIh2G9fZb1PbB
PsIxrOgy4BquOWsJPm+zeFPSC3q9Cfu219L4AmxSjiZxC3dlosg5rIB892Mjoyv4
qxmg6oiqtc4Jxv+Gl9lRFVOqyHZrTC5IJ+xgfv1EyP6kKMUKLlDZtxZAuQxpUyxR
HZLq220RYnYSvkWauikq4M8fqFM8bdt6hLJnv7bVqllseROk9stCvjSiE3A9szH5
OgtOfYV5GhOeb8pCZqJKlGDw+RoJ21jtNCgOr6DgkNKV9CX/kL/Puwv8gnA0B0eh
dxCeB7f/gcLl7Cg3Z3gVVcGlgak6JWrLf5ITAJhBZ8Lv+AtL2DKmwEWS/iIMRmek
tLdh/a9GiCitqS0bT7GE
=tWPQ
-----END PGP SIGNATURE-----
Merge tag 'modules-next-for-linus' of 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()
...
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>
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>
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>
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>
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>
When probing an ACPI table, report a specific error, instead of just
returning an error, if _IFT doesn't exist.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Xie XiuQi