If the early MMU mapping of the UART happens to get booted out of the
TLB between the start of paging_init() and when we finally re-add the
UART at the very end of s3c_init_cpu(), we'll get a hang at bootup if
we've got early_printk enabled.  Avoid this hang by calling
debug_ll_io_init() early.

Without this patch, you can reliably reproduce a hang when early
printk is enabled by adding flush_tlb_all() at the start of
exynos_init_io().  After this patch the hang goes away.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Acked-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Printing low-level debug messages make an assumption that the specified
UART port has been preconfigured by the bootloader. Incorrectly
specified UART port results in system getting stalled while printing the
message "Uncompressing Linux... done, booting the kernel"
This UART port number is specified through S3C_LOWLEVEL_UART_PORT. Since
the UART port might different for different board, it is not possible to
specify it correctly for every board that use a common defconfig file.

Calling this print subroutine only when DEBUG_LL fixes the problem. By
disabling DEBUG_LL in default config file, we would be able to boot
multiple boards with different default UART ports.

With this current approach, we miss the print "Uncompressing Linux...
done, booting the kernel." when DEBUG_LL is not defined.
Signed-off-by: NTushar Behera <tushar.behera@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

omap36xx_pwrdn_clk_enable_with_hsdiv_restore expects the parent hw of
the clock to be a clk_hw_omap. However, looking at cclock3xxx_data.c,
all concerned clock have parent defined as clk_divider.  Fix the
function to use clk_divider.  Tested with 3.9 on dm3730.
Signed-off-by: NJean-Philippe François <jp.francois@cynove.com>
Cc: NeilBrown <neilb@suse.de>
Cc: Mike Turquette <mturquette@linaro.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Update the CMT clockevent rating from 125 to 80.

This resolves a boot-failure regression for kzm9g-reference in v3.10-rc1
introduced by f7db706b ("ARM: 7674/1: smp:
Avoid dummy clockevent being preferred over real").

The patch noted above reduces the rating of dummy clockevent from 400 to 100.
This patch reduces the rating of CMT so that it is once again less than that
of the dummy clockevent.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

OMAP5 has 6 timers (GPTimers 5, 6, 8 to 11) that are capable of PWM.
The PWM capability property is missing from the node definitions of
couple of timers.

Add ti,timer-pwm attribute for timer 5, 6, 8 and 11.
Signed-off-by: NSuman Anna <s-anna@ti.com>
[benoit.cousson@linaro.org: Update changelog and subject to highlight
the fix]
Signed-off-by: NBenoit Cousson <benoit.cousson@linaro.org>

Earlier commits ensured proper muxing of pins related to proper
TWL6030 behavior: see commit 265a2bc8 (ARM: OMAP3: TWL4030: ensure
sys_nirq1 is mux'd and wakeup enabled) and commit 1ef43369 (ARM:
OMAP4: TWL: mux sys_drm_msecure as output for PMIC).

However these only fixed legacy boot and not DT boot.  For DT boot,
the default mux values need to be set properly in DT.

Special thanks to Nishanth Menon for the review and catching some
major flaws in earlier versions.

Tested on OMAP4430/Panda and OMAP4460/Panda-ES.

Cc: Nishanth Menon <nm@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NKevin Hilman <khilman@linaro.org>
Acked-by: NGrygorii Strashko <grygorii.strashko@ti.com>
[benoit.cousson@linaro.org: Slightly change the subject to align
board name with file name]
Signed-off-by: NBenoit Cousson <benoit.cousson@linaro.org>

The gpmc driver is actually looking for "gpmc,num-cs" and
"gpmc,num-waitpins" properties in DT. The binding doc also states
this.
Correct the properties in the dts to provide the right values for the
gpmc driver.
Signed-off-by: NLars Poeschel <poeschel@lemonage.de>
Acked-by: NPeter Korsgaard <jacmet@sunsite.dk>
Acked-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBenoit Cousson <benoit.cousson@linaro.org>

The UART2 hwmod structure is pointing to the EDMA channels of UART1,
which doesn't look right. This patch fixes this by making the UART2
hwmod structure to a new structure that lists the EDMA channels to be
used by the UART2.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The AXI clock mux should be as below:

00: periph;
01: pll2_pfd2_396m;
10: periph;
11: pll3_pfd1_540m;
Signed-off-by: NAnson Huang <b20788@freescale.com>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>

Stephen Warren reported the recent commit 78506f22 (add support for
extended FIFO-size of PL011-r1p5) breaks the serial port on the
BCM2835 ARM SoC.

A UART compatible with the ARM PL011-r1p5 should have 32-deep FIFOs.
The BCM2835 UART just looks like an ARM PL011-r1p5, but has 16-deep
FIFOs just like PL011-r1p4 or earlier revisions. As a workaround for
this compatibility issue, this patch overrides the HW UART periphid
register values with the actually compatible UART periphid 0x00241011
(r1p3 or r1p4).
Reported-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NJongsung Kim <neidhard.kim@lge.com>
Signed-off-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

'boot_args' is an input args, and 'boot_command_line' has a fix length.
So use strlcpy() instead of strcpy() to avoid memory overflow.
Signed-off-by: NChen Gang <gang.chen@asianux.com>
Acked-by: NKyle McMartin <kyle@mcmartin.ca>
Signed-off-by: NHelge Deller <deller@gmx.de>

There's a Makefile line setting cflags for CONFIG_PA7100. But that
Kconfig macro doesn't exist. There is a Kconfig symbol PA7000, which
covers both PA7000 and PA7100 processors. So let's use the corresponding
Kconfig macro.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NHelge Deller <deller@gmx.de>

With CONFIG_DISCONTIGMEM=y and multiple physical memory areas,
cat /proc/kpageflags triggers this kernel bug:

kernel BUG at arch/parisc/include/asm/mmzone.h:50!
CPU: 2 PID: 7848 Comm: cat Tainted: G      D W 3.10.0-rc3-64bit #44
 IAOQ[0]: kpageflags_read0x128/0x238
 IAOQ[1]: kpageflags_read0x12c/0x238
 RP(r2): proc_reg_read0xbc/0x130
Backtrace:
 [<00000000402ca2d4>] proc_reg_read0xbc/0x130
 [<0000000040235bcc>] vfs_read0xc4/0x1d0
 [<0000000040235f0c>] SyS_read0x94/0xf0
 [<0000000040105fc0>] syscall_exit0x0/0x14

kpageflags_read() walks through the whole memory, even if some memory
areas are physically not available. So, we should better not BUG on an
unavailable pfn in pfn_to_nid() but just return the expected value -1 or
0.
Signed-off-by: NHelge Deller <deller@gmx.de>

'path.bc[i]' can be asigned by PCI_SLOT() which can '> 10', so sizeof(6
* "%u:" + "%u" + '\0') may be 21.

Since 'name' length is 20, it may be memory overflow.

And 'path.bc[i]' is 'unsigned char' for printing, we can be sure the
max length of 'name' must be less than 28.

So simplify thinking, we can use 28 instead of 20 directly, and do not
think of whether 'patchc.bc[i]' can '> 100'.
Signed-off-by: NChen Gang <gang.chen@asianux.com>
Signed-off-by: NHelge Deller <deller@gmx.de>

Fix a typo in setting COMMON_USER2_POWER7 bits to .cpu_user_features2
cpu specs table.
Signed-off-by: NWill Schmidt <will_schmidt@vnet.ibm.com>
Acked-by: NMichael Neuling <mikey@neuling.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Commit 8f61aa32 "Add support for SIER" missed updates to siar_valid()
and perf_get_data_addr().

In both cases we need to check the SIER instead of mmcra.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This is a revert and then some of commit 860aad71 "Add regs_no_sipr()".
This workaround was only needed on early chip versions.

As before NO_SIPR becomes a static flag of the PMU struct.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The codes which ever used these two variables have gone. Throw away
them too.
Signed-off-by: NKevin Hao <haokexin@gmail.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

These comments already don't apply to the current code. So just remove
them.
Signed-off-by: NKevin Hao <haokexin@gmail.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Adam Lackorzynski reported the following build failure on
!CONFIG_HOTPLUG_CPU configuration:

  CC      arch/powerpc/kernel/rtas.o
arch/powerpc/kernel/rtas.c: In function ‘rtas_cpu_state_change_mask’:
arch/powerpc/kernel/rtas.c:843:4: error: implicit declaration of function ‘cpu_down’ [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
make[1]: *** [arch/powerpc/kernel/rtas.o] Error 1
make: *** [arch/powerpc/kernel] Error 2

The build fails because cpu_down() is defined only under CONFIG_HOTPLUG_CPU.

Looking further, the mobility code in pseries is one of the call-sites which
uses rtas_ibm_suspend_me(), which in turn calls rtas_cpu_state_change_mask().
And the mobility code is unconditionally compiled-in (it does not fall under
any Kconfig option). And commit 120496ac (powerpc: Bring all threads online
prior to migration/hibernation) which introduced this build regression is
critical for the proper functioning of the migration code. So it appears
that the only solution to this problem is to enable CONFIG_HOTPLUG_CPU if
SMP is enabled on PPC_PSERIES platforms. So make that change in the Kconfig.
Reported-by: NAdam Lackorzynski <adam@os.inf.tu-dresden.de>
Cc: stable@vger.kernel.org
Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This adds the remaining two hypercalls defined by PAPR for manipulating
the XICS interrupt controller, H_IPOLL and H_XIRR_X.  H_IPOLL returns
information about the priority and pending interrupts for a virtual
cpu, without changing any state.  H_XIRR_X is like H_XIRR in that it
reads and acknowledges the highest-priority pending interrupt, but it
also returns the timestamp (timebase register value) from when the
interrupt was first received by the hypervisor.  Currently we just
return the current time, since we don't do any software queueing of
virtual interrupts inside the XICS emulation code.

These hcalls are not currently used by Linux guests, but may be in
future.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Acked-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Commit a9c4e541
"powerpc/kprobe: Complete kprobe and migrate exception frame"
introduced a regression:

While returning from exception handling in case of PREEMPT enabled,
_TIF_NEED_RESCHED bit is checked in TI_FLAGS (thread_info flag) of current
task. Only if this bit is set, it should continue with the process of
calling preempt_schedule_irq() to schedule highest priority task if
available.

Current code assumes that r8 contains TI_FLAGS and check this for
_TIF_NEED_RESCHED, but as r8 is modified in the code which executes before
this check, r8 no longer contains the expected TI_FLAGS information.

As a result check for comparison with _TIF_NEED_RESCHED was failing even if
NEED_RESCHED bit is set in the current thread_info flag. Due to this,
preempt_schedule_irq() and in turn scheduler was not getting called even if
highest priority task is ready for execution.

So, store temporary results in r0 instead of r8 to prevent r8 from getting
modified as subsequent code is dependent on its value.
Signed-off-by: NPriyanka Jain <Priyanka.Jain@freescale.com>
CC: <stable@vger.kernel.org> [v3.7+]
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

If a hash bucket gets full, we "evict" a more/less random entry from it.
When we do that we don't invalidate the TLB (hpte_remove) because we assume
the old translation is still technically "valid". This implies that when
we are invalidating or updating pte, even if HPTE entry is not valid
we should do a tlb invalidate.

This was a regression introduced by b1022fbdSigned-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

No code changes, just documenting what's happening a little better.
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

On context switch, we should have no prefetch streams leak from one
userspace process to another.  This frees up prefetch resources for the
next process.

Based on patch from Milton Miller.
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Maynard informed me that neither the oprofile kernel module nor oprofile
userspace has been updated to support that "legacy" oprofile module
interface for power8, which is indicated by "ppc64/power8." This results
in no samples. The solution is to default to the "timer" type, instead.
The raw entry also should be updated, as "ppc64/ibm-compat-v1" indicates
to oprofile userspace to use "compatibility events" which are obsolete
in ISA 2.07.
Signed-off-by: NNishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

For the mpic with a flag MPIC_SINGLE_DEST_CPU, only one bit should be
set in interrupt destination registers.

The code is applicable to 64-bit platforms as well as 32-bit.
Signed-off-by: NZhao Chenhui <chenhui.zhao@freescale.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

When in an active transaction that takes a signal, we need to be careful with
the stack.  It's possible that the stack has moved back up after the tbegin.
The obvious case here is when the tbegin is called inside a function that
returns before a tend.  In this case, the stack is part of the checkpointed
transactional memory state.  If we write over this non transactionally or in
suspend, we are in trouble because if we get a tm abort, the program counter
and stack pointer will be back at the tbegin but our in memory stack won't be
valid anymore.

To avoid this, when taking a signal in an active transaction, we need to use
the stack pointer from the checkpointed state, rather than the speculated
state.  This ensures that the signal context (written tm suspended) will be
written below the stack required for the rollback.  The transaction is aborted
becuase of the treclaim, so any memory written between the tbegin and the
signal will be rolled back anyway.

For signals taken in non-TM or suspended mode, we use the
normal/non-checkpointed stack pointer.

Tested with 64 and 32 bit signals
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> # v3.9
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

These cause codes are usable by userspace, so let's export to uapi.
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> # v3.9
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

If we are emulating an instruction inside an active user transaction that
touches memory, the kernel can't emulate it as it operates in transactional
suspend context.  We need to abort these transactions and send them back to
userspace for the hardware to rollback.

We can service these if the user transaction is in suspend mode, since the
kernel will operate in the same suspend context.

This adds a check to all alignment faults and to specific instruction
emulations (only string instructions for now).  If the user process is in an
active (non-suspended) transaction, we abort the transaction go back to
userspace allowing the HW to roll back the transaction and tell the user of the
failure.  This also adds new tm abort cause codes to report the reason of the
persistent error to the user.

Crappy test case here http://neuling.org/devel/junkcode/aligntm.cSigned-off-by: NMichael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> # v3.9
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

PAPR carves out 0xff-0xe0 for hypervisor use of transactional memory software
abort cause codes.  Unfortunately we don't respect this currently.

Below fixes this to move our cause codes to below this region.
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org> # 3.9 only
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Rather than completely killing the kernel if we receive an esr value we
can't deal with in the el0 handlers, send the process a SIGILL and log
the esr value in the hope that we can debug it. If we receive a bad esr
from el1, we'll die() as before.
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: stable@vger.kernel.org

Currently, if a compat process reads or writes from/to a disabled
cp15/cp14 register, the trap is not handled by the el0_sync_compat
handler, and the kernel will head to bad_mode, where it will die(), and
oops(). For 64 bit processes, disabled system register accesses are
currently treated as unhandled instructions.

This patch modifies entry.S to treat these unhandled traps as undefined
instructions, sending a SIGILL to userspace. This gives processes a
chance to handle this and stop using inaccessible registers, and
prevents further issues in the kernel as a result of the die().
Reported-by: NJohannes Jensen <Johannes.Jensen@arm.com>
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

With the addition of eagerfpu the irq_fpu_usable() now returns false
negatives especially in the case of ksoftirqd and interrupted idle task,
two common cases for FPU use for example in networking/crypto.  With
eagerfpu=off FPU use is possible in those contexts.  This is because of
the eagerfpu check in interrupted_kernel_fpu_idle():

...
  * For now, with eagerfpu we will return interrupted kernel FPU
  * state as not-idle. TBD: Ideally we can change the return value
  * to something like __thread_has_fpu(current). But we need to
  * be careful of doing __thread_clear_has_fpu() before saving
  * the FPU etc for supporting nested uses etc. For now, take
  * the simple route!
...
 	if (use_eager_fpu())
 		return 0;

As eagerfpu is automatically "on" on those CPUs that also have the
features like AES-NI this patch changes the eagerfpu check to return 1 in
case the kernel_fpu_begin() has not been said yet.  Once it has been the
__thread_has_fpu() will start returning 0.

Notice that with eagerfpu the __thread_has_fpu is always true initially.
FPU use is thus always possible no matter what task is under us, unless
the state has already been saved with kernel_fpu_begin().

[ hpa: this is a performance regression, not a correctness regression,
  but since it can be quite serious on CPUs which need encryption at
  interrupt time I am marking this for urgent/stable. ]
Signed-off-by: NPekka Riikonen <priikone@iki.fi>
Link: http://lkml.kernel.org/r/alpine.GSO.2.00.1305131356320.18@git.silcnet.org
Cc: <stable@vger.kernel.org> v3.7+
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

binutils prior to 2.18 (e.g. the ones found on SLE10) don't support
assembling PEXTRD, so a macro based approach like the one for PCLMULQDQ
in the same file should be used.

This requires making the helper macros capable of recognizing 32-bit
general purpose register operands.

[ hpa: tagging for stable as it is a low risk build fix ]
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Link: http://lkml.kernel.org/r/51A6142A02000078000D99D8@nat28.tlf.novell.com
Cc: Alexander Boyko <alexander_boyko@xyratex.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Huang Ying <ying.huang@intel.com>
Cc: <stable@vger.kernel.org> v3.9
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists)
changed PM to not access IVA registers on omaps that don't have
them. Turns out we still need to idle iva2 as otherwise
iva2_pwrdm will stay on and block deeper idle states.

It seems that the only part of the reset that may not be needed
is the setting of the iva2 boot mode to idle. But as that register
seems to be there and is harmless if no iva2 is on the SoC, it's
probably safest to do the complete reset.
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Acked-by: NKevin Hilman <khilman@linaro.org>
Tested-by: NYegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Include the generic definitions of pci_iomap() and __pci_ioport_map()
otherwise we can get errors like:

  lib/pci_iomap.c: In function 'pci_iomap':
  lib/pci_iomap.c:37: error: implicit declaration of function '__pci_ioport_map'
  lib/pci_iomap.c:37: warning: return makes pointer from integer without a cast

and:

  drivers/pci/quirks.c: In function 'disable_igfx_irq':
  drivers/pci/quirks.c:2893: error: implicit declaration of function 'pci_iomap'
  drivers/pci/quirks.c:2893: warning: initialization makes pointer from integer without a cast
  drivers/pci/quirks.c: In function 'reset_ivb_igd':
  drivers/pci/quirks.c:3133: warning: assignment makes pointer from integer without a cast
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NKen Cox <jkc@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The code for PCI in the ASB2305 needs the definition of XIRQ1 from proc/irq.h
otherwise the following error appears:

  arch/mn10300/unit-asb2305/pci.c: In function 'unit_pci_init':
  arch/mn10300/unit-asb2305/pci.c:481: error: 'XIRQ1' undeclared (first use in this function)
  arch/mn10300/unit-asb2305/pci.c:481: error: (Each undeclared identifier is reported only once
  arch/mn10300/unit-asb2305/pci.c:481: error: for each function it appears in.)
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NKen Cox <jkc@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Enable IRQs when calling schedule() for TIF_NEED_RESCHED and
do_notify_resume().  If interrupts are enabled during do_notify_resume(), a
warning can be seen (see lower down).

Whilst we're at it, resume_userspace can be made local to entry.S as it is not
called outside of there and it can be merged with the part of work_resched that
occurs after schedule() is called.

  WARNING: at kernel/softirq.c:160 local_bh_enable+0x42/0xa0()
  Call Trace:
    local_bh_enable+0x42/0xa0
    unix_release_sock+0x86/0x23c
    unix_release+0x20/0x28
    sock_release+0x17/0x88
    sock_close+0x20/0x28
    __fput+0xc9/0x1fc
    ____fput+0xb/0x10
    task_work_run+0x64/0x78
    do_notify_resume+0x53d/0x544
    work_notifysig+0xa/0xc
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NKen Cox <jkc@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

ret_from_kernel_thread needs to set A2 to the thread_info pointer before
jumping to syscall_exit.

Without this, we never correctly start userspace.

This was caused by the rejuggling of the fork/exec paths in commit
ddf23e87 ("mn10300: switch to saner kernel_execve() semantics")
Reported-by: NKen Cox <jkc@redhat.com>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NKen Cox <jkc@redhat.com>
Acked-by: NAl Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>