Define two device PM QoS flags, PM_QOS_FLAG_NO_POWER_OFF
and PM_QOS_FLAG_REMOTE_WAKEUP, and introduce routines
dev_pm_qos_expose_flags() and dev_pm_qos_hide_flags() allowing the
caller to expose those two flags to user space or to hide them
from it, respectively.

After the flags have been exposed, user space will see two
additional sysfs attributes, pm_qos_no_power_off and
pm_qos_remote_wakeup, under the device's /sys/devices/.../power/
directory.  Then, writing 1 to one of them will update the
PM QoS flags request owned by user space so that the corresponding
flag is requested to be set.  In turn, writing 0 to one of them
will cause the corresponding flag in the user space's request to
be cleared (however, the owners of the other PM QoS flags requests
for the same device may still request the flag to be set and it
may be effectively set even if user space doesn't request that).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NJean Pihet <j-pihet@ti.com>
Acked-by: Nmark gross <markgross@thegnar.org>

Modify the device PM QoS core code to support PM QoS flags requests.

First, add a new field of type struct pm_qos_flags called "flags"
to struct dev_pm_qos for representing the list of PM QoS flags
requests for the given device.  Accordingly, add a new "type" field
to struct dev_pm_qos_request (along with an enum for representing
request types) and a new member called "flr" to its data union for
representig flags requests.

Second, modify dev_pm_qos_add_request(), dev_pm_qos_update_request(),
the internal routine apply_constraint() used by them and their
existing callers to cover flags requests as well as latency
requests.  In particular, dev_pm_qos_add_request() gets a new
argument called "type" for specifying the type of a request to be
added.

Finally, introduce two routines, __dev_pm_qos_flags() and
dev_pm_qos_flags(), allowing their callers to check which PM QoS
flags have been requested for the given device (the caller is
supposed to pass the mask of flags to check as the routine's
second argument and examine its return value for the result).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NJean Pihet <j-pihet@ti.com>
Reviewed-by: Nmark gross <markgross@thegnar.org>

The subsequent patches will use struct dev_pm_qos_request for
representing both latency requests and flags requests.  To make that
easier, put the node member of struct dev_pm_qos_request (under the
name "pnode") into a union called "data" that will represent the
request's  value and list node depending on its type.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NJean Pihet <j-pihet@ti.com>
Reviewed-by: Nmark gross <markgross@thegnar.org>

Introduce struct pm_qos_flags_request and struct pm_qos_flags
representing PM QoS flags request type and PM QoS flags constraint
type, respectively.  With these definitions the data structures
will be arranged so that the list member of a struct pm_qos_flags
object will contain the head of a list of struct pm_qos_flags_request
objects representing all of the "flags" requests present for the
given device.  Then, the effective_flags member of a struct
pm_qos_flags object will contain the bitwise OR of the flags members
of all the struct pm_qos_flags_request objects in the list.

Additionally, introduce helper function pm_qos_update_flags()
allowing the caller to manage the list of struct pm_qos_flags_request
pointed to by the list member of struct pm_qos_flags.

The flags are of type s32 so that the request's "value" field
is always of the same type regardless of what kind of request it
is (latency requests already have value fields of type s32).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NJean Pihet <j-pihet@ti.com>
Acked-by: Nmark gross <markgross@thegnar.org>

Currently struct dev_pm_info contains only one PM QoS constraints
pointer reserved for latency requirements.  Since one more device
constraints type (i.e. flags) will be necessary, introduce a new
structure, struct dev_pm_qos, that eventually will contain all of
the available device PM QoS constraints and replace the "constraints"
pointer in struct dev_pm_info with a pointer to the new structure
called "qos".
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NJean Pihet <j-pihet@ti.com>

free_pid_ns() operates in a recursive fashion:

free_pid_ns(parent)
  put_pid_ns(parent)
    kref_put(&ns->kref, free_pid_ns);
      free_pid_ns

thus if there was a huge nesting of namespaces the userspace may trigger
avalanche calling of free_pid_ns leading to kernel stack exhausting and a
panic eventually.

This patch turns the recursion into an iterative loop.

Based on a patch by Andrew Vagin.

[akpm@linux-foundation.org: export put_pid_ns() to modules]
Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
Cc: Andrew Vagin <avagin@openvz.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 5ab1c309 ("coredump: pass siginfo_t* to do_coredump() and
below, not merely signr") added siginfo_t to linux/coredump.h but forgot
to include asm/siginfo.h.  This breaks the build for UML/i386.  (And any
other arch where asm/siginfo.h is not magically preincluded...)

  In file included from arch/x86/um/elfcore.c:2:0: include/linux/coredump.h:15:25: error: unknown type name 'siginfo_t'
  make[1]: *** [arch/x86/um/elfcore.o] Error 1
Signed-off-by: NRichard Weinberger <richard@nod.at>
Cc: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Amerigo Wang <amwang@redhat.com>
Cc: "Jonathan M. Foote" <jmfoote@cert.org>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Pedro Alves <palves@redhat.com>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

drivers/of/irq.c:195:57: warning: restricted __be32 degrades to integer
drivers/of/irq.c:196:51: warning: restricted __be32 degrades to integer
drivers/of/irq.c:199:57: warning: restricted __be32 degrades to integer
drivers/of/irq.c:201:58: warning: restricted __be32 degrades to integer
drivers/of/irq.c:470:37: warning: incorrect type in assignment (different modifiers)
drivers/of/irq.c:470:37:    expected int ( *[usertype] irq_init_cb )( ... )
drivers/of/irq.c:470:37:    got void const *const data
drivers/of/irq.c:96:5: error: symbol 'of_irq_map_raw' redeclared with different type (originally declared at include/linux/of_irq.h:61) - incompatible argument 2 (different base types)

drivers/of/of_pci_irq.c:91:40: warning: incorrect type in argument 2 (different base types)
drivers/of/of_pci_irq.c:91:40:    expected unsigned int const [usertype] *intspec
drivers/of/of_pci_irq.c:91:40:    got restricted __be32 *<noident>
drivers/of/of_pci_irq.c:91:53: warning: incorrect type in argument 4 (different base types)
drivers/of/of_pci_irq.c:91:53:    expected unsigned int const [usertype] *addr
drivers/of/of_pci_irq.c:91:53:    got restricted __be32 *<noident>
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
Signed-off-by: NRob Herring <rob.herring@calxeda.com>

drivers/of/address.c:66:29: warning: incorrect type in argument 1 (different base types)
drivers/of/address.c:66:29:    expected restricted __be32 const [usertype] *cell
drivers/of/address.c:66:29:    got unsigned int [usertype] *addr
drivers/of/address.c:87:32: warning: incorrect type in argument 1 (different base types)
drivers/of/address.c:87:32:    expected restricted __be32 const [usertype] *cell
drivers/of/address.c:87:32:    got unsigned int [usertype] *addr
drivers/of/address.c:91:30: warning: incorrect type in assignment (different base types)
drivers/of/address.c:91:30:    expected unsigned int [unsigned] [usertype] <noident>
drivers/of/address.c:91:30:    got restricted __be32 [usertype] <noident>
drivers/of/address.c:92:22: warning: incorrect type in assignment (different base types)
drivers/of/address.c:92:22:    expected unsigned int [unsigned] [usertype] <noident>
drivers/of/address.c:92:22:    got restricted __be32 [usertype] <noident>
drivers/of/address.c:147:35: warning: incorrect type in argument 1 (different base types)
drivers/of/address.c:147:35:    expected restricted __be32 const [usertype] *addr
drivers/of/address.c:147:35:    got unsigned int [usertype] *addr
drivers/of/address.c:157:34: warning: incorrect type in argument 1 (different base types)
drivers/of/address.c:157:34:    expected restricted __be32 const [usertype] *cell
drivers/of/address.c:157:34:    got unsigned int [usertype] *
drivers/of/address.c:256:29: warning: restricted __be32 degrades to integer
drivers/of/address.c:256:36: warning: restricted __be32 degrades to integer
drivers/of/address.c:262:34: warning: incorrect type in argument 1 (different base types)
drivers/of/address.c:262:34:    expected restricted __be32 const [usertype] *cell
drivers/of/address.c:262:34:    got unsigned int [usertype] *
drivers/of/address.c:372:41: warning: incorrect type in argument 1 (different base types)
drivers/of/address.c:372:41:    expected restricted __be32 const [usertype] *cell
drivers/of/address.c:372:41:    got unsigned int [usertype] *addr
drivers/of/address.c:395:53: warning: incorrect type in argument 2 (different base types)
drivers/of/address.c:395:53:    expected restricted __be32 const [usertype] *addr
drivers/of/address.c:395:53:    got unsigned int [usertype] *addr
drivers/of/address.c:443:50: warning: incorrect type in argument 2 (different base types)
drivers/of/address.c:443:50:    expected restricted __be32 const [usertype] *addr
drivers/of/address.c:443:50:    got unsigned int *<noident>
drivers/of/address.c:455:49: warning: incorrect type in argument 1 (different base types)
drivers/of/address.c:455:49:    expected restricted __be32 const [usertype] *cell
drivers/of/address.c:455:49:    got unsigned int *<noident>
drivers/of/address.c:480:60: warning: incorrect type in argument 2 (different base types)
drivers/of/address.c:480:60:    expected restricted __be32 const [usertype] *addr
drivers/of/address.c:480:60:    got unsigned int *<noident>
drivers/of/address.c:412:5: warning: symbol '__of_translate_address' was not declared. Should it be static?
drivers/of/address.c:520:14: error: symbol 'of_get_address' redeclared with different type (originally declared at include/linux/of_address.h:22) - different base types
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
Signed-off-by: NRob Herring <rob.herring@calxeda.com>

Fixes build error on s3c6400_defconfig, introduced by commit
06455bbc, "dt/s3c64xx/spi: Use
of_get_child_by_name to get a named child".

drivers/spi/spi-s3c64xx.c: In function 's3c64xx_get_slave_ctrldata':
drivers/spi/spi-s3c64xx.c:838:2: error: implicit declaration of function
    'of_get_child_by_name' [-Werror=implicit-function-declaration]
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NRob Herring <rob.herring@calxeda.com>

There are no users of this macro anymore in the kernel tree, so finally
delete it.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NMichael Kerrisk <mtk.manpages@gmail.com>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Make uapi/asm-generic/kvm_para.h non-empty by addition of a comment to stop
the patch program from deleting it when it creates it.

Then delete empty arch-specific uapi/asm/kvm_para.h files and tell the Kbuild
files to use the generic instead.

Should this perhaps instead be a #warning or #error that the facility is
unsupported on this arch?
Signed-off-by: NDavid Howells <dhowells@redhat.com>
cc: Arnd Bergmann <arnd@arndb.de>
cc: Avi Kivity <avi@redhat.com>
cc: Marcelo Tosatti <mtosatti@redhat.com>
cc: kvm@vger.kernel.org

Remove non-UAPI Kbuild files that have become empty as a result of UAPI
disintegration.  They used to have only header-y lines in them and those have
now moved to the Kbuild files in the corresponding uapi/ directories.

Possibly these should not be removed but rather have a comment inserted to say
they are intentionally left blank.  This would make it easier to add generated
header lines in future without having to restore the infrastructure.

Note that at this point not all the UAPI disintegration parts have been merged,
so it is likely that more empty Kbuild files will turn up.

It is probably necessary to make the files non-empty to prevent the patch
program from automatically deleting them when it reduces them to nothing.
Signed-off-by: NDavid Howells <dhowells@redhat.com>

Remove empty conditionals from include/linux/Kbuild as the contents, with new
conditionals, have moved to include/uapi/linux/Kbuild.
Signed-off-by: NDavid Howells <dhowells@redhat.com>

uapi/linux/irqnr.h was emitted by the UAPI disintegration script as an empty
file because the parent linux/irqnr.h had no UAPI stuff in it, despite being
marked with "header-y".

Unfortunately, the patch program deletes the empty file when applying a kernel
patch.

It's not clear why this file is part of the UAPI at all.  Looking in:

	/usr/include/linux/irqnr.h

there's nothing there but a header reinclusion guard and a comment.

So just stick a comment in there as a placeholder.

Without this, if the kernel is fabricated from, say, a tarball and a patch, you
can get this error when building x86_64 or usermode Linux (and probably
others):

include/linux/irqnr.h:4:30: fatal error: uapi/linux/irqnr.h: No such file or directory
Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
Reported-by: NAlessandro Suardi <alessandro.suardi@gmail.com>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
cc: Randy Dunlap <rdunlap@xenotime.net>
cc: Alessandro Suardi <alessandro.suardi@gmail.com>

It seems I accidentally switched the guard on linux/elf-fdpic.h from #ifdef
__KERNEL__ to #ifndef __KERNEL__ when attempting to expand the guarded region
to cover the elf_fdpic_params struct when doing the UAPI split - with the
result that the struct became unavailable to kernel code.

Move incorrectly guarded bits back to the kernelspace header.

Whilst we're at it, the __KERNEL__ guards can be deleted as they're no longer
necessary.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Reported-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
cc: Fengguang Wu <fengguang.wu@intel.com>
cc: Lars-Peter Clausen <lars@metafoo.de>
cc: uclinux-dev@uclinux.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

	Had not been used for more than a decade and half; it used
to be a part of (in-kernel) ->select() API and it has been pining
for fjords since 2.1.23pre1.  This is an ex-parrot...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

There are some bits of linux/fs.h which are only used within the kernel and
shouldn't be in the UAPI.  Move these from uapi/linux/fs.h into linux/fs.h.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NMichael Kerrisk <mtk.manpages@gmail.com>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>

Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NMichael Kerrisk <mtk.manpages@gmail.com>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>

It seems that was linux/blk_types.h incorrectly exported to fix up some missing
bits required by the exported parts of linux/fs.h (READ, WRITE, READA, etc.).

So unexport linux/blk_types.h and unexport the relevant bits of linux/fs.h.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
cc: Jens Axboe <jaxboe@fusionio.com>
cc: Tejun Heo <tj@kernel.org>
cc: Al Viro <viro@ZenIV.linux.org.uk>

Unexport part of linux/ppp-comp.h as userspace can't make use of that bit.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
cc: Paul Mackerras <paulus@samba.org>
cc: David Miller <davem@davemloft.net>

In the common case where a name is much smaller than PATH_MAX, an extra
allocation for struct filename is unnecessary. Before allocating a
separate one, try to embed the struct filename inside the buffer first. If
it turns out that that's not long enough, then fall back to allocating a
separate struct filename and redoing the copy.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Keep a pointer to the audit_names "slot" in struct filename.

Have all of the audit_inode callers pass a struct filename ponter to
audit_inode instead of a string pointer. If the aname field is already
populated, then we can skip walking the list altogether and just use it
directly.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

...and fix up the callers. For do_file_open_root, just declare a
struct filename on the stack and fill out the .name field. For
do_filp_open, make it also take a struct filename pointer, and fix up its
callers to call it appropriately.

For filp_open, add a variant that takes a struct filename pointer and turn
filp_open into a wrapper around it.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Currently, if we call getname() on a userland string more than once,
we'll get multiple copies of the string and multiple audit_names
records.

Add a function that will allow the audit_names code to satisfy getname
requests using info from the audit_names list, avoiding a new allocation
and audit_names records.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

getname() is intended to copy pathname strings from userspace into a
kernel buffer. The result is just a string in kernel space. It would
however be quite helpful to be able to attach some ancillary info to
the string.

For instance, we could attach some audit-related info to reduce the
amount of audit-related processing needed. When auditing is enabled,
we could also call getname() on the string more than once and not
need to recopy it from userspace.

This patchset converts the getname()/putname() interfaces to return
a struct instead of a string. For now, the struct just tracks the
string in kernel space and the original userland pointer for it.

Later, we'll add other information to the struct as it becomes
convenient.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

* allow kernel_execve() leave the actual return to userland to
caller (selected by CONFIG_GENERIC_KERNEL_EXECVE).  Callers
updated accordingly.
* architecture that does select GENERIC_KERNEL_EXECVE in its
Kconfig should have its ret_from_kernel_thread() do this:
	call schedule_tail
	call the callback left for it by copy_thread(); if it ever
returns, that's because it has just done successful kernel_execve()
	jump to return from syscall
IOW, its only difference from ret_from_fork() is that it does call the
callback.
* such an architecture should also get rid of ret_from_kernel_execve()
and __ARCH_WANT_KERNEL_EXECVE

This is the last part of infrastructure patches in that area - from
that point on work on different architectures can live independently.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

The con_debug_leave/con_debug_enter functions are stubbed out
by defining them to (0), which causes harmless build warnings.
Using proper inline functions is the normal way to deal with
this.

Without this patch, building the ARM bcm2835_defconfig results in:

drivers/tty/serial/kgdboc.c: In function 'kgdboc_pre_exp_handler':
drivers/tty/serial/kgdboc.c:279:3: warning: statement with no effect [-Wunused-value]
drivers/tty/serial/kgdboc.c: In function 'kgdboc_post_exp_handler':
drivers/tty/serial/kgdboc.c:293:3: warning: statement with no effect [-Wunused-value]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Anton Vorontsov <anton.vorontsov@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>

First, it's incorrect to call putname() after __getname_gfp() since the
bare __getname_gfp() call skips the auditing code, while putname()
doesn't.

mount_block_root allocates a PATH_MAX buffer via __getname_gfp, and then
calls get_fs_names to fill the buffer. That function can call
get_filesystem_list which assumes that that buffer is a full page in
size. On arches where PAGE_SIZE != 4k, then this could potentially
overrun.

In practice, it's hard to imagine the list of filesystem names even
approaching 4k, but it's best to be safe. Just allocate a page for this
purpose instead.

With this, we can also remove the __getname_gfp() definition since there
are no more callers.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

In order to accomodate retrying path-based syscalls, we need to add a
new "type" argument to audit_inode_child. This will tell us whether
we're looking for a child entry that represents a create or a delete.

If we find a parent, don't automatically assume that we need to create a
new entry. Instead, use the information we have to try to find an
existing entry first. Update it if one is found and create a new one if
not.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Currently, this gets set mostly by happenstance when we call into
audit_inode_child. While that might be a little more efficient, it seems
wrong. If the syscall ends up failing before audit_inode_child ever gets
called, then you'll have an audit_names record that shows the full path
but has the parent inode info attached.

Fix this by passing in a parent flag when we call audit_inode that gets
set to the value of LOOKUP_PARENT. We can then fix up the pathname for
the audit entry correctly from the get-go.

While we're at it, clean up the no-op macro for audit_inode in the
!CONFIG_AUDITSYSCALL case.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

For now, we just have two possibilities:

UNKNOWN: for a new audit_names record that we don't know anything about yet
NORMAL: for everything else

In later patches, we'll add other types so we can distinguish and update
records created under different circumstances.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Most of the callers get called with an inode and dentry in the reverse
order. The compiler then has to reshuffle the arg registers and/or
stack in order to pass them on to audit_inode_child.

Reverse those arguments for a micro-optimization.
Reported-by: NEric Paris <eparis@redhat.com>
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NMichael Kerrisk <mtk.manpages@gmail.com>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

__attribute__((error(msg))) was introduced in gcc 4.3 (not 4.4) and as I
was unable to find any gcc bugs pertaining to it, I'm presuming that it
has functioned as advertised since 4.3.0.
Signed-off-by: NDaniel Santos <daniel.santos@pobox.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Tested-by: NDavid Rientjes <rientjes@google.com>
Signed-off-by: NMichal Marek <mmarek@suse.cz>

Some device types support a form of power management in which
the device suggests to the host that the device may be suspended
now. Support for that is best located in usbnet.
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Follow-on MIPS patch will put an object here that needs 64K alignment
to minimize padding.

For those architectures that don't define BSS_FIRST_SECTIONS, there is
no change.
Signed-off-by: NDavid Daney <david.daney@cavium.com>
Cc: linux-mips@linux-mips.org
Cc: linux-arch@vger.kernel.org,
Cc: linux-kernel@vger.kernel.org
Acked-by: NArnd Bergmann <arnd@arndb.de>
Patchwork: https://patchwork.linux-mips.org/patch/4221/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>