Boot the remote processor only after setting up the virtqueues,
and shut it down before deleting them.
Remote processors should obey virtio status changes, and
therefore not manipulate/trigger the virtqueues while the virtio
driver isn't ready, but it's just safer not to rely on that
(plus a vq access might already be inflight while a vdev
status is changed).
We also don't have yet status change notifications, but that's
a temporary limitation.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Brian Swetland <swetland@google.com>
Cc: Iliyan Malchev <malchev@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Mark Grosen <mgrosen@ti.com>
Cc: John Williams <john.williams@petalogix.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
Cc: Guzman Lugo Fernando <fernando.lugo@ti.com>
Cc: Anna Suman <s-anna@ti.com>
Cc: Clark Rob <rob@ti.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Saravana Kannan <skannan@codeaurora.org>
Cc: David Brown <davidb@codeaurora.org>
Cc: Kieran Bingham <kieranbingham@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
At this point remoteproc can only register a single VIRTIO_ID_RPMSG virtio
device.
This limitation is going away soon: remoteproc is getting support for
registering any number of virtio devices and of any type (as
published by the firmware of the remote processor).
Rename remoteproc_rpmsg.c to remoteproc_virtio.c in preparation of
this generalization work.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Brian Swetland <swetland@google.com>
Cc: Iliyan Malchev <malchev@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Mark Grosen <mgrosen@ti.com>
Cc: John Williams <john.williams@petalogix.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
Cc: Guzman Lugo Fernando <fernando.lugo@ti.com>
Cc: Anna Suman <s-anna@ti.com>
Cc: Clark Rob <rob@ti.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Saravana Kannan <skannan@codeaurora.org>
Cc: David Brown <davidb@codeaurora.org>
Cc: Kieran Bingham <kieranbingham@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
The resource table is an array of 'struct fw_resource' members, where
each resource entry is expressed as a single member of that array.
This approach got us this far, but it has a few drawbacks:
1. Different resource entries end up overloading the same members of 'struct
fw_resource' with different meanings. The resulting code is error prone
and hard to read and maintain.
2. It's impossible to extend 'struct fw_resource' without breaking the
existing firmware images (and we already want to: we can't introduce the
new virito device resource entry with the current scheme).
3. It doesn't scale: 'struct fw_resource' must be as big as the largest
resource entry type. As a result, smaller resource entries end up
utilizing only small part of it.
This is fixed by defining a dedicated structure for every resource type,
and then converting the resource table to a list of type-value members.
Instead of a rigid array of homogeneous structs, the resource table
is turned into a collection of heterogeneous structures.
This way:
1. Resource entries consume exactly the amount of bytes they need.
2. It's easy to extend: just create a new resource entry structure, and assign
it a new type.
3. The code is easier to read and maintain: the structures' members names are
meaningful.
While we're at it, this patch has several other resource table changes:
1. The resource table gains a simple header which contains the
number of entries in the table and their offsets within the table. This
makes the parsing code simpler and easier to read.
2. A version member is added to the resource table. Should we change the
format again, we'll bump up this version to prevent breakage with
existing firmware images.
3. The VRING and VIRTIO_DEV resource entries are combined to a single
VDEV entry. This paves the way to supporting multiple VDEV entries.
4. Since we don't really support 64-bit rprocs yet, convert two stray u64
members to u32.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Brian Swetland <swetland@google.com>
Cc: Iliyan Malchev <malchev@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Mark Grosen <mgrosen@ti.com>
Cc: John Williams <john.williams@petalogix.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
Cc: Guzman Lugo Fernando <fernando.lugo@ti.com>
Cc: Anna Suman <s-anna@ti.com>
Cc: Clark Rob <rob@ti.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Saravana Kannan <skannan@codeaurora.org>
Cc: David Brown <davidb@codeaurora.org>
Cc: Kieran Bingham <kieranbingham@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
dev_dbg() in rpmsg_probe() made use of the %x formatting that
expects an 'unsigned int' which dma_addr_t is not in cases where
dma_addr_t is 64-bit (CONFIG_ARCH_DMA_ADDR_T_64BIT). Casting to
a 'unsigned long long' and using %llx will avoid this.
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
CC: Ohad Ben-Cohen <ohad@wizery.com>
CC: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
After processing an incoming message, always publish the real size
of its containing buffer when putting it back on the available rx ring.
Using any different value might erroneously limit the remote processor
(leading it to think the buffer is smaller than it really is).
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Grosen <mgrosen@ti.com>
Cc: Suman Anna <s-anna@ti.com>
Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Cc: Rob Clark <rob@ti.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
When an inbound message arrives, validate its reported length before
propagating it, otherwise buggy (or malicious) remote processors might
trick us into accessing memory which we really shouldn't.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Grosen <mgrosen@ti.com>
Cc: Suman Anna <s-anna@ti.com>
Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Cc: Rob Clark <rob@ti.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
The name service endpoint wasn't destroyed, so fix it.
This is achieved by introducing an internal __rpmsg_destroy_ept
function which doesn't assume the given ept is bound to an rpmsg
channel (much like the existing __rpmsg_create_ept).
This is needed because the name service ept belongs to the rpmsg bus,
and is never bound with a specific rpdev.
Reported-by: Omar Ramirez Luna <omar.ramirez@ti.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Grosen <mgrosen@ti.com>
Cc: Suman Anna <s-anna@ti.com>
Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Cc: Rob Clark <rob@ti.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
1. Depend on OMAP_IOMMU instead of selecting it, to fix an unmet
direct dependency of it (and its imminent build error)
2. Set default to 'no' (achieved implicitly by dropping the 'default'
line)
Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Grosen <mgrosen@ti.com>
Cc: Suman Anna <s-anna@ti.com>
Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Cc: Rob Clark <rob@ti.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
Cc: Russell King <linux@arm.linux.org.uk>
Make sure we're parsing a 32bit image, since we only support
the ELF32 binary format at this point.
This should prevent unexpected behavior with non 32bit binaries.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Grosen <mgrosen@ti.com>
Cc: Suman Anna <s-anna@ti.com>
Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
Cc: Rob Clark <rob@ti.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
A lookup table would be easier to extend, and the resulting
code is a bit cleaner.
Reported-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
At this point we don't support remote processors that have
a different endianess than the host.
Look out for these unsupported scenarios, and bail out if
encountered.
Reported-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Mark Grosen <mgrosen@ti.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
When creating a virtqueue for rpmsg, tell virtio we're not interested
in "weak" smp barriers, since we're talking to a real device.
On ARM, this means using a DSB instead of a DMB, which is needed
for platforms that kick the remote processor using some kind of
a mailbox device mapped to Device memory (otherwise the kick can
jump ahead and wake the remote processor before it has observed
the changes to the vrings).
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Since commit 7bb7aef2 "virtio: rename virtqueue_add_buf_gfp to virtqueue_add_buf",
virtqueue_add_buf_gfp is already rename to virtqueue_add_buf now.
This patch fixes below build error:
CC [M] drivers/rpmsg/virtio_rpmsg_bus.o
drivers/rpmsg/virtio_rpmsg_bus.c: In function 'rpmsg_send_offchannel_raw':
drivers/rpmsg/virtio_rpmsg_bus.c:723: error: implicit declaration of function 'virtqueue_add_buf_gfp'
make[2]: *** [drivers/rpmsg/virtio_rpmsg_bus.o] Error 1
make[1]: *** [drivers/rpmsg] Error 2
make: *** [drivers] Error 2
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
There isn't any binary change in sight or evidence of any stability
issue, but as we just begin to get traction we can't rule them out
completely.
To be on the safe side, let's mark rpmsg as EXPERIMENTAL, and remove
it later on after we have several happy users.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Rob Clark <rob@ti.com>
Cc: Mark Grosen <mgrosen@ti.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
Remoteproc is still under development and as it gets traction we
definitely expect to do some changes in the binary format (most probably
only in the resource table, e.g. the upcoming move to TLV-based entries).
Active testing and use of remoteproc is most welcome, but we don't want
users to expect backward binary compatibility with the preliminary
images we have today.
Therefore mark remoteproc as EXPERIMENTAL, and explicitly inform the user
about this when a new remote processor is registered.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Rob Clark <rob@ti.com>
Cc: Mark Grosen <mgrosen@ti.com>
Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
Add a dedicated Kconfig menu for the remoteproc drivers, so they
don't show up in the main driver menu.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Make sure firmware isn't truncated before accessing its data.
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
RSC_VIRTIO_CFG isn't being used, so remove it.
Originally it was introduced to overcome a resource table limitation
that prevented describing a virtio device in a single resource table
entry.
The plan though is to describe resource table entries in a TLV fashion,
where each entry will consume the amount of space it requires,
so the original limitation is anyway temporary.
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Let remoteproc know when the firmware doesn't support any virtio
functionality, so registering a virtio device can be avoided.
This is needed for remote processors that doesn't require any
virtio-based communications, but are still controlled via remoteproc.
[ohad@wizery.com: write commit log]
Signed-off-by: Mark Grosen <mgrosen@ti.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Not all remote processors employ an IOMMU, so do not error out
on !iommu_present().
Note: we currently still use iommu_present() to tell whether we need
to configure an IOMMU or not. That works for simple cases, but will
easily fail with more complicated ones (e.g. where an IOMMU exists,
but not all remote processors use it). When those use cases show up,
we will solve them by introducing something like remoteproc hw
capabilities.
[ohad@wizery.com: write commit log]
Signed-off-by: Mark Grosen <mgrosen@ti.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Add an rpmsg driver sample, which demonstrates how to communicate with
an AMP-configured remote processor over the rpmsg bus.
Note how once probed, the driver can immediately start sending messages
using the rpmsg_send() API, without having to worry about creating endpoints
or allocating rpmsg addresses: all that work is done by the rpmsg bus,
and the required information is already embedded in the rpmsg channel
that the driver is probed with.
In this sample, the driver simply sends a "Hello World!" message to the remote
processor repeatedly.
Designed with Brian Swetland <swetland@google.com>.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Brian Swetland <swetland@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Add a virtio-based inter-processor communication bus, which enables
kernel drivers to communicate with entities, running on remote
processors, over shared memory using a simple messaging protocol.
Every pair of AMP processors share two vrings, which are used to send
and receive the messages over shared memory.
The header of every message sent on the rpmsg bus contains src and dst
addresses, which make it possible to multiplex several rpmsg channels on
the same vring.
Every rpmsg channel is a device on this bus. When a channel is added,
and an appropriate rpmsg driver is found and probed, it is also assigned
a local rpmsg address, which is then bound to the driver's callback.
When inbound messages carry the local address of a bound driver,
its callback is invoked by the bus.
This patch provides a kernel interface only; user space interfaces
will be later exposed by kernel users of this rpmsg bus.
Designed with Brian Swetland <swetland@google.com>.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Acked-by: Rusty Russell <rusty@rustcorp.com.au> (virtio_ids.h)
Cc: Brian Swetland <swetland@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Add a remoteproc driver for OMAP4, so we can boot the dual-M3 and
and DSP subsystems.
Use the omap_device_* API to control the hardware state, and utilize
the OMAP mailbox to interrupt the remote processor when a new message
is pending (the mailbox payload is used to tell it which virtqueue was
the message placed in).
Conversely, when an inbound mailbox message arrives, tell the remoteproc
core which virtqueue is triggered.
Later we will also use the mailbox payload to signal omap-specific
events like remote crashes (which will be used to trigger remoteproc
recovery) and power management transitions. At that point we will also
extend the remoteproc core to support this.
Based on (but now quite far from) work done by Fernando Guzman Lugo
<fernando.lugo@ti.com> and Hari Kanigeri <h-kanigeri2@ti.com>.
Designed with Brian Swetland <swetland@google.com>.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Cc: Brian Swetland <swetland@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Create an rpmsg virtio device to allow message-based communication
with the remote processor (but only if supported by its firmware).
There are several advantages to provide this functionality at
the remoteproc-level:
- to support it, platforms only have to provide their own ->kick()
handler; no need to duplicate the rest of the code.
- the virtio device is created only when the remote processor is
registered and ready to go. No need to depend on initcall magic.
moreover, we only add the virtio device if the firmware really
supports it, and only after we know the supported virtio device features.
- correct device model hierarchy can be set, and that is useful
for natural power management and DMA API behavior.
- when the remote processor crashes (or removed) we only need
to remove the virtio device, and the driver core will take care of
the rest. No need to implement any out-of-bound notifiers.
- we can now easily bind the virtio device to its rproc handle, and
this way we don't need any name-based remoteproc ->get() API.
Currently we only support creating a single rpmsg virtio device per
remote processor, but later this is going to be extended to support
creating numerous virtio devices of other types too (block, net,
console...).
Designed with Brian Swetland <swetland@google.com>.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Brian Swetland <swetland@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Expose several remote processor properties (name, state, trace buffer)
that are helpful for debugging.
This part is extracted to a separate patch just to keep the review load
down.
Designed with Brian Swetland <swetland@google.com>.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Brian Swetland <swetland@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Modern SoCs typically employ a central symmetric multiprocessing (SMP)
application processor running Linux, with several other asymmetric
multiprocessing (AMP) heterogeneous processors running different instances
of operating system, whether Linux or any other flavor of real-time OS.
Booting a remote processor in an AMP configuration typically involves:
- Loading a firmware which contains the OS image
- Allocating and providing it required system resources (e.g. memory)
- Programming an IOMMU (when relevant)
- Powering on the device
This patch introduces a generic framework that allows drivers to do
that. In the future, this framework will also include runtime power
management and error recovery.
Based on (but now quite far from) work done by Fernando Guzman Lugo
<fernando.lugo@ti.com>.
ELF loader was written by Mark Grosen <mgrosen@ti.com>, based on
msm's Peripheral Image Loader (PIL) by Stephen Boyd <sboyd@codeaurora.org>.
Designed with Brian Swetland <swetland@google.com>.
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Brian Swetland <swetland@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/accounting, proc: Fix /proc/stat interrupts sum
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
tracepoints/module: Fix disabling tracepoints with taint CRAP or OOT
x86/kprobes: Add arch/x86/tools/insn_sanity to .gitignore
x86/kprobes: Fix typo transferred from Intel manual
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, syscall: Need __ARCH_WANT_SYS_IPC for 32 bits
x86, tsc: Fix SMI induced variation in quick_pit_calibrate()
x86, opcode: ANDN and Group 17 in x86-opcode-map.txt
x86/kconfig: Move the ZONE_DMA entry under a menu
x86/UV2: Add accounting for BAU strong nacks
x86/UV2: Ack BAU interrupt earlier
x86/UV2: Remove stale no-resources test for UV2 BAU
x86/UV2: Work around BAU bug
x86/UV2: Fix BAU destination timeout initialization
x86/UV2: Fix new UV2 hardware by using native UV2 broadcast mode
x86: Get rid of dubious one-bit signed bitfield
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
qnx4: don't leak ->BitMap on late failure exits
qnx4: reduce the insane nesting in qnx4_checkroot()
qnx4: di_fname is an array, for crying out loud...
vfs: remove printk from set_nlink()
wake up s_wait_unfrozen when ->freeze_fs fails
In checkin
303395ac3b x86: Generate system call tables and unistd_*.h from tables
the feature macros in <asm/unistd.h> were unified between 32 and 64
bits. Unfortunately 32 bits requires __ARCH_WANT_SYS_IPC and this was
inadvertently dropped.
Reported-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Link: http://lkml.kernel.org/r/CALLzPKbeXN5gdngo8uYYU8mAow=XhrwBFBhKfG811f37BubQOg@mail.gmail.com
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
KEYS: Permit key_serial() to be called with a const key pointer
keys: fix user_defined key sparse messages
ima: fix cred sparse warning
MPILIB: Add a missing ENOMEM check
Permit key_serial() to be called with a const key pointer.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Replace the rcu_assign_pointer() calls with rcu_assign_keypointer().
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Fix ima_policy.c sparse "warning: dereference of noderef expression"
message, by accessing cred->uid using current_cred().
Changelog v1:
- Change __cred to just cred (based on David Howell's comment)
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Randy Dunlap reports that we get
arch/x86/um/shared/sysdep/ptrace.h:7:20: error: redefinition of 'regs_return_value'
arch/x86/um/shared/sysdep/ptrace.h:7:20: note: previous definition of 'regs_return_value' was here
when compiling UML for x86-64.
Stephen Rothwell root-caused it and says:
"Caused by commit d7e7528bcd ("Audit: push audit success and retcode
into arch ptrace.h") (another patch that was never in linux-next :-().
This file now needs protection against double inclusion."
so let's do as the man says.
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Analyzed-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending: (26 commits)
target: Set additional sense length field in sense data
target: Remove legacy device status check from transport_execute_tasks
target: Remove __transport_execute_tasks() for each processing context
target: Remove extra se_device->execute_task_lock access in fast path
target: Drop se_device TCQ queue_depth usage from I/O path
target: Fix possible NULL pointer with __transport_execute_tasks
target: Remove TFO->check_release_cmd() fabric API caller
tcm_fc: Convert ft_send_work to use target_submit_cmd
target: Add target_submit_cmd() for process context fabric submission
target: Make target_put_sess_cmd use target_release_cmd_kref
target: Set response format in INQUIRY response
target: tcm_mod_builder: small fixups
Documentation/target: Fix tcm_mod_builder.py build breakage
target: remove overagressive ____cacheline_aligned annoations
tcm_loop: bump max_sectors
target/configs: remove trailing newline from udev_path and alias
iscsi-target: fix chap identifier simple_strtoul usage
target: remove useless casts
target: simplify target_check_cdb_and_preempt
target: Move core_scsi3_check_cdb_abort_and_preempt
...
This includes initial support for the recently published ACPI 5.0 spec.
In particular, support for the "hardware-reduced" bit that eliminates
the dependency on legacy hardware.
APEI has patches resulting from testing on real hardware.
Plus other random fixes.
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux: (52 commits)
acpi/apei/einj: Add extensions to EINJ from rev 5.0 of acpi spec
intel_idle: Split up and provide per CPU initialization func
ACPI processor: Remove unneeded variable passed by acpi_processor_hotadd_init V2
ACPI processor: Remove unneeded cpuidle_unregister_driver call
intel idle: Make idle driver more robust
intel_idle: Fix a cast to pointer from integer of different size warning in intel_idle
ACPI: kernel-parameters.txt : Add intel_idle.max_cstate
intel_idle: remove redundant local_irq_disable() call
ACPI processor: Fix error path, also remove sysdev link
ACPI: processor: fix acpi_get_cpuid for UP processor
intel_idle: fix API misuse
ACPI APEI: Convert atomicio routines
ACPI: Export interfaces for ioremapping/iounmapping ACPI registers
ACPI: Fix possible alignment issues with GAS 'address' references
ACPI, ia64: Use SRAT table rev to use 8bit or 16/32bit PXM fields (ia64)
ACPI, x86: Use SRAT table rev to use 8bit or 32bit PXM fields (x86/x86-64)
ACPI: Store SRAT table revision
ACPI, APEI, Resolve false conflict between ACPI NVS and APEI
ACPI, Record ACPI NVS regions
ACPI, APEI, EINJ, Refine the fix of resource conflict
...
This patch fixes an (ACPI S3) suspend regression introduced in commit
68d6e6713f ("tpm: Introduce function to poll for result of self test")
and occurring with an Infineon TPM and tpm_tis and tpm_infineon drivers
active.
The suspend problem occurred if the TPM was disabled and/or deactivated
and therefore the TPM_PCRRead checking the result of the (asynchronous)
self test returned an error code which then caused the tpm_tis driver to
become inactive and this then seemed to have negatively influenced the
suspend support by the tpm_infineon driver... Besides that the tpm_tis
drive may stay active even if the TPM is disabled and/or deactivated.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Tested-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The type of 'make_request_fn' changed in 5a7bbad27a ("block: remove
support for bio remapping from ->make_request"), but the merge of the
nvme driver didn't take that into account, and as a result the driver
would compile with a warning:
drivers/block/nvme.c: In function 'nvme_alloc_ns':
drivers/block/nvme.c:1336:2: warning: passing argument 2 of 'blk_queue_make_request' from incompatible pointer type [enabled by default]
include/linux/blkdev.h:830:13: note: expected 'void (*)(struct request_queue *, struct bio *)' but argument is of type 'int (*)(struct request_queue *, struct bio *)'
It's benign, but the warning is annoying.
Reported-by: Stephen Rothwell <sfr@canb.auug.org>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix these warnings:
drivers/xen/biomerge.c:14:1: warning: data definition has no type or storage class [enabled by default]
drivers/xen/biomerge.c:14:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' [-Wimplicit-int]
drivers/xen/biomerge.c:14:1: warning: parameter names (without types) in function declaration [enabled by default]
And this build error:
ERROR: "xen_biovec_phys_mergeable" [drivers/block/nvme.ko] undefined!
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus/i2c-33' of git://git.fluff.org/bjdooks/linux:
i2c-eg20t: Change-company-name-OKI-SEMICONDUCTOR to LAPIS Semiconductor
i2c-eg20t: Support new device LAPIS Semiconductor ML7831 IOH
i2c-eg20t: modified the setting of transfer rate.
i2c-eg20t: use i2c_add_numbered_adapter to get a fixed bus number
i2c: OMAP: Add DT support for i2c controller
I2C: OMAP: NACK without STP
I2C: OMAP: correct SYSC register offset for OMAP4
Ohad Ben-Cohen
Mark Asselstine
Axel Lin
Mark Grosen
Linus Torvalds
H. Peter Anvin
H. Peter Anvin
Al Viro
David Howells
Mimi Zohar
Stefan Berger
Stephen Rothwell