Merge tag 'dt2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

Pull ARM SoC device-tree updates, take 2, from Olof Johansson:
 "This branch contains device-tree updates for the SPEAr platform.  They
  had dependencies on earlier branches from this merge window, which is
  why they were broken out in a separate branch."

* tag 'dt2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: SPEAr3xx: Shirq: Move shirq controller out of plat/
  ARM: SPEAr320: DT: Add SPEAr 320 HMI board support
  ARM: SPEAr3xx: DT: add shirq node for interrupt multiplexor
  ARM: SPEAr3xx: shirq: simplify and move the shared irq multiplexor to DT
  ARM: SPEAr1310: Fix AUXDATA for compact flash controller
  ARM: SPEAr13xx: Remove fields not required for ssp controller
  ARM: SPEAr1310: Move 1310 specific misc register into machine specific files
  ARM: SPEAr: DT: Update device nodes
  ARM: SPEAr: DT: add uart state to fix warning
  ARM: SPEAr: DT: Modify DT bindings for STMMAC
  ARM: SPEAr: DT: Fix existing DT support
  ARM: SPEAr: DT: Update partition info for MTD devices
  ARM: SPEAr: DT: Update pinctrl list
  ARM: SPEAr13xx: DT: Add spics gpio controller nodes
NFS: Fix calls to drop_nlink()

It is almost always wrong for NFS to call drop_nlink() after removing a
file. What we really want is to mark the inode's attributes for
revalidation, and we want to ensure that the VFS drops it if we're
reasonably sure that this is the final unlink().
Do the former using the usual cache validity flags, and the latter
by testing if inode->i_nlink == 1, and clearing it in that case.

This also fixes the following warning reported by Neil Brown and
Jeff Layton (among others).

[634155.004438] WARNING:
at /home/abuild/rpmbuild/BUILD/kernel-desktop-3.5.0/lin [634155.004442]
Hardware name: Latitude E6510 [634155.004577]  crc_itu_t crc32c_intel
snd_hwdep snd_pcm snd_timer snd soundcor [634155.004609] Pid: 13402, comm:
bash Tainted: G        W    3.5.0-36-desktop # [634155.004611] Call Trace:
[634155.004630]  [<ffffffff8100444a>] dump_trace+0xaa/0x2b0
[634155.004641]  [<ffffffff815a23dc>] dump_stack+0x69/0x6f
[634155.004653]  [<ffffffff81041a0b>] warn_slowpath_common+0x7b/0xc0
[634155.004662]  [<ffffffff811832e4>] drop_nlink+0x34/0x40
[634155.004687]  [<ffffffffa05bb6c3>] nfs_dentry_iput+0x33/0x70 [nfs]
[634155.004714]  [<ffffffff8118049e>] dput+0x12e/0x230
[634155.004726]  [<ffffffff8116b230>] __fput+0x170/0x230
[634155.004735]  [<ffffffff81167c0f>] filp_close+0x5f/0x90
[634155.004743]  [<ffffffff81167cd7>] sys_close+0x97/0x100
[634155.004754]  [<ffffffff815c3b39>] system_call_fastpath+0x16/0x1b
[634155.004767]  [<00007f2a73a0d110>] 0x7f2a73a0d10f

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: stable@vger.kernel.org [3.3+]
ARM: dts: OMAP2420: Correct H4 board memory size

The system memory node for the OMAP2420 H4 was incorrectly defined as
start address followed by end address, instead of start address and
size. No noticable side-effects were observed but fix this for
correctness.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: dts: Add build target for omap4-panda-a4

Commit 0d9250c (ARM: dts: omap4-panda: Add pinmux configuration for
HDMI) added a new device-tree source file for Rev A4 of the OMAP4430
Panda board but it did not add this version to the makefile. Hence,
add this file to the makefile.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP: Move plat/omap-serial.h to include/linux/platform_data/serial-omap.h

We need to move this file to allow ARM multiplatform configurations
to build for omap2+. This can now be done as this file now only
contains platform_data.

cc: Russell King <linux@arm.linux.org.uk>
cc: Alan Cox <alan@linux.intel.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Govindraj.R <govindraj.raja@ti.com>
cc: Kevin Hilman <khilman@ti.com>
cc: linux-serial@vger.kernel.org
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
NFS: nfs_lookup_revalidate should not trust an inode with i_nlink == 0

If the inode has no links, then we should force a new lookup.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Merge tag 'mvebu' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

Pull ARM SoC updates for Marvell mvebu/kirkwood from Olof Johansson:
 "This is a branch with updates for Marvell's mvebu/kirkwood platforms.
  They came in late-ish, and were heavily interdependent such that it
  didn't make sense to split them up across the cross-platform topic
  branches.  So here they are (for the second release in a row) in a
  branch on their own."

* tag 'mvebu' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (88 commits)
  arm: l2x0: add aurora related properties to OF binding
  arm: mvebu: add Aurora L2 Cache Controller to the DT
  arm: mvebu: add L2 cache support
  dma: mv_xor: fix error handling path
  dma: mv_xor: fix error checking of irq_of_parse_and_map()
  dma: mv_xor: use request_irq() instead of devm_request_irq()
  dma: mv_xor: clear the window override control registers
  arm: mvebu: fix address decoding armada_cfg_base() function
  ARM: mvebu: update defconfig with I2C and RTC support
  ARM: mvebu: Add SATA support for OpenBlocks AX3-4
  ARM: mvebu: Add support for the RTC in OpenBlocks AX3-4
  ARM: mvebu: Add support for I2C on OpenBlocks AX3-4
  ARM: mvebu: Add support for I2C controllers in Armada 370/XP
  arm: mvebu: Add hardware I/O Coherency support
  arm: plat-orion: Add coherency attribute when setup mbus target
  arm: dma mapping: Export a dma ops function arm_dma_set_mask
  arm: mvebu: Add SMP support for Armada XP
  arm: mm: Add support for PJ4B cpu and init routines
  arm: mvebu: Add IPI support via doorbells
  arm: mvebu: Add initial support for power managmement service unit
  ...
Merge tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux-2.6

Pull another devicetree update from Grant Likely:
 "Here's a couple more devicetree changes that I missed in the first
  pull by putting the tag in the wrong place.

  Two minor devicetree fixups for v3.8.  Addition of dummy inlines and
  constification of node argument to of_parse_phandle_with_args()."

* tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux-2.6:
  of: *node argument to of_parse_phandle_with_args should be const
  of/i2c: add dummy inline functions for when CONFIG_OF_I2C(_MODULE) isn't defined
Merge tag 'disintegrate-x86-20121214' of git://git.infradead.org/users/dhowells/linux-headers

Pull x86 UAPI disintegration from David Howells.

This is the scripted disintegration of the uapi headers for x86, now
that most of the x86 updates for 3.8 are hopefully merged.

* tag 'disintegrate-x86-20121214' of git://git.infradead.org/users/dhowells/linux-headers:
  UAPI: (Scripted) Disintegrate arch/x86/include/asm
userns: Require CAP_SYS_ADMIN for most uses of setns.

Andy Lutomirski <luto@amacapital.net> found a nasty little bug in
the permissions of setns.  With unprivileged user namespaces it
became possible to create new namespaces without privilege.

However the setns calls were relaxed to only require CAP_SYS_ADMIN in
the user nameapce of the targed namespace.

Which made the following nasty sequence possible.

pid = clone(CLONE_NEWUSER | CLONE_NEWNS);
if (pid == 0) { /* child */
	system("mount --bind /home/me/passwd /etc/passwd");
}
else if (pid != 0) { /* parent */
	char path[PATH_MAX];
	snprintf(path, sizeof(path), "/proc/%u/ns/mnt");
	fd = open(path, O_RDONLY);
	setns(fd, 0);
	system("su -");
}

Prevent this possibility by requiring CAP_SYS_ADMIN
in the current user namespace when joing all but the user namespace.

Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
spi: Keep chipselect assertion during one message

During all transfers in one message, the device will not be chagned.
So we don't need to deassert chipselect during one message.

Signed-off-by: Kyoungil Kim <ki0351.kim@samsung.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
spi: Change FIFO flush operation and spi channel off

Setting SW_RST does TX/RX FIFO flush.
After FIFO flush, SW_RST should be cleared.
The above setting and clearing SW_RST operation should be done after spi channel off.

Signed-off-by: Kyoungil Kim <ki0351.kim@samsung.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.

To get modprobe to automatically load the proper modules, we need to
prefix things with "spi:".  Partially based on Grant Likely's suggestions.

Signed-off-by: David Daney <david.daney@cavium.com>
[grant.likely: reworked because drivers/of/of_spi.c has been removed]
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
userns: Add a more complete capability subset test to commit_creds

When unsharing a user namespace we reduce our credentials to just what
can be done in that user namespace.  This is a subset of the credentials
we previously had.  Teach commit_creds to recognize this is a subset
of the credentials we have had before and don't clear the dumpability flag.

This allows an unprivileged  program to do:
unshare(CLONE_NEWUSER);
fd = open("/proc/self/uid_map", O_RDWR);

Where previously opening the uid_map writable would fail because
the the task had been made non-dumpable.

Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
userns: Fix typo in description of the limitation of userns_install

Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
ARM: OMAP4: Update timer clock aliases

Commit "ARM: dts: OMAP4: Update timer addresses" updated the device-tree
names of the OMAP4 timers 5-7 because the default address for the timers
was changed from the L3 address to the MPU private address. When booting
with device-tree, this introduces a regression when attempting to set
the parent clock of timers 5-7 to the sys_clk_div_ck. Therefore, update
the clock aliases for timer 5-7 to reflect the updated device-tree name
for the timers.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: updated to apply after the CCF conversion]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP4: Add function table for non-M4X dplls

Currently all OMAP4 non-core DPLLs use the same function table for
configuring DPLLs. For these DPLLs, the function
omap4_dpll_regm4xen_recalc() is used to recalculate the DPLL rate and
the function omap4_dpll_regm4xen_round_rate() is used to calculate the
closest rate to that requested. However, these omap4_dpll_regm4xen_xxx()
functions are only applicable to the ABE DPLL and not the other non-core
DPLLs. Therefore, add a new function table for non-core DPLLs that do
not include the 4X-multiplier (M4X).

Please note that using these omap4_dpll_regm4x_xxx() function works for
the non-M4X DPLLs today because we only check to see if the 4X
multiplier is enabled when calculating the rate. However, it is planned
that the dpll functions will be enhanced to enable the 4X multiplier as
necessary (in order to achieve the requested rate) and so calling these
functions for non-M4X dplls will no longer work.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP4: Enhance support for DPLLs with 4X multiplier

On OMAP4 devices, the ABE DPLL has an internal 4X multiplier that can
be enabled or disabled in addition to the standard configurable
multiplier (M) for OMAP DPLLs. When configuring the ABE DPLL the 4X
multiplier is accounted for by checking to see whether it is enabled or
not. However, when calculating a new rate we only check to see if the
rate can be achieved with the current setting for the 4X multiplier.
Enhance the round_rate() function for such DPLLs to see if the rate
can be achieved with the 4X multiplier if it cannot be achieved without
the 4X multiplier.

This change is necessary, because when using the 32kHz clock as the
source clock for the ABE DPLL, the default DPLL frequency for the ABE
DPLL cannot be achieved without enabling the 4X multiplier.

When using the 32kHz clock as the source clock for the ABE DPLL and
attempting to lock the DPLL to 98.304MHz (default frequency), it was
found that the DPLL would fail to lock if the low-power mode for the DPLL
was not enabled. From reviewing boot-loader settings that configure the
ABE DPLL it was found that the low-power mode is enabled when using the
32kHz clock source, however, the documentation for OMAP does not state
that this is a requirement. Therefore, introduce a new function for
OMAP4 devices to see if low-power mode can be enabled when calculating a
new rate to ensure the DPLL will lock.

New variables for the last calculated 4X multiplier and low-power
setting have been added to the dpll data structure as well as variables
defining the bit mask for enabling these features via the DPLL's
control_reg. It is possible that we could eliminate these bit masks from
the dpll data structure as these bit masks are not unique to OMAP4, if
it is preferred.

The function omap3_noncore_program_dpll() has been updated to avoid
passing the calculated values for the multiplier (M) and divider (N) as
these are stored in the clk structure.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP4460: Workaround ABE DPLL failing to turn-on

With the latest mainline u-boot bootloader (v2012.10), timers (5-8) in
the ABE power domain are failing to turn-on. The timers never come out
of the disabled state when setting the module-mode field to enable.

The problem was exposed when u-boot was updated to NOT configure and
lock the ABE DPLL on start-up. If the ABE DPLL is configured and locked
by u-boot the problem does not occur. However, if the ABE DPLL is in the
idle low-power bypass state and we attempt to enable a timer in the ABE
power domain, it remains stuck in the disabled state. It appears to be a
problem the timer interface clock as this comes from the ABE DPLL.

If we place the ABE DPLL in the MN-bypass state and not the idle
low-power state, then this problem is not seen.

This problem only appears to occur on OMAP4460 and not OMAP4430.

Workaround this problem by locking the ABE DPLL for OMAP4460 in the
kernel on boot. By locking the ABE DPLL, when clocks from the ABE DPLL
are not being requested the DPLL will transition into a low-power stop
mode.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP4: Fix EMU clock domain always on

Commit d043d87 (ARM: OMAP2+: clockdomain: bypass clockdomain handling
when disabling unused clks) skips the decrementing of a clock-domains
use count if the clocks use count is zero. However, for OMAP4 devices
this is causing the EMU clock-domain to be stuck ON as the use count is
not getting decremented correctly.

The scenario that leads to this problem is described below ...

omap_hwmod_setup_all
--> _setup
    --> clkdm_hwmod_enable
    	--> EMU clock domain usecount = 1
    --> _enable_clocks
        --> clk_enable
	    --> trace_clk_div_div usecount = 1
            --> clkdm_hwmod_enable
    	        --> EMU clock domain usecount = 2
--> _idle
    --> _disable_clocks
	--> clk_disable
            --> trace_clk_div_div usecount = 0
            --> clkdm_hwmod_disable
                --> skips decrement of EMU clock domain usecount
		    because trace_clk_div_div is 0!
    	        --> EMU clock domain usecount = 2
    --> clkdm_hwmod_disable
    	--> EMU clock domain usecount = 1

Hence, due to the order that a clocks use count is decremented and the
clock domain is disabled, it is possible that the clock domain can have
a non-zero use count when the actual clock has a use count of 0.
Therefore, we should only bypass the clock-domain handling when both the
clock-domain and clock in the clock-domain have a use count of 0 and
warn when the clock-domain has a zero use count and the clock has a
non-zero use count.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
[paul@pwsan.com: fixed checkpatch warning]
Signed-off-by: Paul Walmsley <paul@pwsan.com>