ima: fix filename hint to reflect script interpreter name

When IMA was first upstreamed, the bprm filename and interp were
always the same.  Currently, the bprm->filename and bprm->interp
are the same, except for when only bprm->interp contains the
interpreter name.  So instead of using the bprm->filename as
the IMA filename hint in the measurement list, we could replace
it with bprm->interp, but this feels too fragil.

The following patch is not much better, but at least there is some
indication that sometimes we're passing the filename and other times
the interpreter name.

Reported-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>

Merge branch 'for-1205' of git.gitorious.org/smack-next/kernel into next

Pull request from Casey.

KEYS: Don't check for NULL key pointer in key_validate()

Don't bother checking for NULL key pointer in key_validate() as all of the
places that call it will crash anyway if the relevant key pointer is NULL by
the time they call key_validate().  Therefore, the checking must be done prior
to calling here.

Whilst we're at it, simplify the key_validate() function a bit and mark its
argument const.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>

Smack: allow for significantly longer Smack labels v4

V4 updated to current linux-security#next
Targeted for git://gitorious.org/smack-next/kernel.git

Modern application runtime environments like to use
naming schemes that are structured and generated without
human intervention. Even though the Smack limit of 23
characters for a label name is perfectly rational for
human use there have been complaints that the limit is
a problem in environments where names are composed from
a set or sources, including vendor, author, distribution
channel and application name. Names like

softwarehouse-pgwodehouse-coolappstore-mellowmuskrats

are becoming harder to avoid. This patch introduces long
label support in Smack. Labels are now limited to 255
characters instead of the old 23.

The primary reason for limiting the labels to 23 characters
was so they could be directly contained in CIPSO category sets.
This is still done were possible, but for labels that are too
large a mapping is required. This is perfectly safe for communication
that stays "on the box" and doesn't require much coordination
between boxes beyond what would have been required to keep label
names consistent.

The bulk of this patch is in smackfs, adding and updating
administrative interfaces. Because existing APIs can't be
changed new ones that do much the same things as old ones
have been introduced.

The Smack specific CIPSO data representation has been removed
and replaced with the data format used by netlabel. The CIPSO
header is now computed when a label is imported rather than
on use. This results in improved IP performance. The smack
label is now allocated separately from the containing structure,
allowing for larger strings.

Four new /smack interfaces have been introduced as four
of the old interfaces strictly required labels be specified
in fixed length arrays.

The access interface is supplemented with the check interface:
access  "Subject                 Object                  rwxat"
access2 "Subject Object rwaxt"

The load interface is supplemented with the rules interface:
load   "Subject                 Object                  rwxat"
load2  "Subject Object rwaxt"

The load-self interface is supplemented with the self-rules interface:
load-self   "Subject                 Object                  rwxat"
load-self2  "Subject Object rwaxt"

The cipso interface is supplemented with the wire interface:
cipso  "Subject                  lvl cnt  c1  c2 ..."
cipso2 "Subject lvl cnt  c1  c2 ..."

The old interfaces are maintained for compatibility.

Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>

gfp flags for security_inode_alloc()?

Dave Chinner wrote:
> Yes, because you have no idea what the calling context is except
> for the fact that is from somewhere inside filesystem code and the
> filesystem could be holding locks. Therefore, GFP_NOFS is really the
> only really safe way to allocate memory here.

I see. Thank you.

I'm not sure, but can call trace happen where somewhere inside network
filesystem or stackable filesystem code with locks held invokes operations that
involves GFP_KENREL memory allocation outside that filesystem?
----------
[PATCH] SMACK: Fix incorrect GFP_KERNEL usage.

new_inode_smack() which can be called from smack_inode_alloc_security() needs
to use GFP_NOFS like SELinux's inode_alloc_security() does, for
security_inode_alloc() is called from inode_init_always() and
inode_init_always() is called from xfs_inode_alloc() which is using GFP_NOFS.

smack_inode_init_security() needs to use GFP_NOFS like
selinux_inode_init_security() does, for initxattrs() callback function (e.g.
btrfs_initxattrs()) which is called from security_inode_init_security() is
using GFP_NOFS.

smack_audit_rule_match() needs to use GFP_ATOMIC, for
security_audit_rule_match() can be called from audit_filter_user_rules() and
audit_filter_user_rules() is called from audit_filter_user() with RCU read lock
held.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Casey Schaufler <cschaufler@cschaufler-intel.(none)>

Smack: recursive tramsmute

The transmuting directory feature of Smack requires that
the transmuting attribute be explicitly set in all cases.
It seems the users of this facility would expect that the
transmuting attribute be inherited by subdirectories that
are created in a transmuting directory. This does not seem
to add any additional complexity to the understanding of
how the system works.

Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>

Yama: replace capable() with ns_capable()

When checking capabilities, the question we want to be asking is "does
current() have the capability in the child's namespace?"

Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: James Morris <james.l.morris@oracle.com>

TOMOYO: Accept manager programs which do not start with / .

The pathname of /usr/sbin/tomoyo-editpolicy seen from Ubuntu 12.04 Live CD is
squashfs:/usr/sbin/tomoyo-editpolicy rather than /usr/sbin/tomoyo-editpolicy .
Therefore, we need to accept manager programs which do not start with / .

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: James Morris <james.l.morris@oracle.com>

KEYS: Add invalidation support

Add support for invalidating a key - which renders it immediately invisible to
further searches and causes the garbage collector to immediately wake up,
remove it from keyrings and then destroy it when it's no longer referenced.

It's better not to do this with keyctl_revoke() as that marks the key to start
returning -EKEYREVOKED to searches when what is actually desired is to have the
key refetched.

To invalidate a key the caller must be granted SEARCH permission by the key.
This may be too strict.  It may be better to also permit invalidation if the
caller has any of READ, WRITE or SETATTR permission.

The primary use for this is to evict keys that are cached in special keyrings,
such as the DNS resolver or an ID mapper.

Signed-off-by: David Howells <dhowells@redhat.com>

KEYS: Do LRU discard in full keyrings

Do an LRU discard in keyrings that are full rather than returning ENFILE.  To
perform this, a time_t is added to the key struct and updated by the creation
of a link to a key and by a key being found as the result of a search.  At the
completion of a successful search, the keyrings in the path between the root of
the search and the first found link to it also have their last-used times
updated.

Note that discarding a link to a key from a keyring does not necessarily
destroy the key as there may be references held by other places.

An alternate discard method that might suffice is to perform FIFO discard from
the keyring, using the spare 2-byte hole in the keylist header as the index of
the next link to be discarded.

This is useful when using a keyring as a cache for DNS results or foreign
filesystem IDs.

This can be tested by the following.  As root do:

echo 1000 >/proc/sys/kernel/keys/root_maxkeys

kr=`keyctl newring foo @s`
for ((i=0; i<2000; i++)); do keyctl add user a$i a $kr; done

Without this patch ENFILE should be reported when the keyring fills up.  With
this patch, the keyring discards keys in an LRU fashion.  Note that the stored
LRU time has a granularity of 1s.

After doing this, /proc/key-users can be observed and should show that most of
the 2000 keys have been discarded:

[root@andromeda ~]# cat /proc/key-users
    0:   517 516/516 513/1000 5249/20000

The "513/1000" here is the number of quota-accounted keys present for this user
out of the maximum permitted.

In /proc/keys, the keyring shows the number of keys it has and the number of
slots it has allocated:

[root@andromeda ~]# grep foo /proc/keys
200c64c4 I--Q--     1 perm 3b3f0000     0     0 keyring   foo: 509/509

The maximum is (PAGE_SIZE - header) / key pointer size.  That's typically 509
on a 64-bit system and 1020 on a 32-bit system.

Signed-off-by: David Howells <dhowells@redhat.com>

KEYS: Permit in-place link replacement in keyring list

Make use of the previous patch that makes the garbage collector perform RCU
synchronisation before destroying defunct keys.  Key pointers can now be
replaced in-place without creating a new keyring payload and replacing the
whole thing as the discarded keys will not be destroyed until all currently
held RCU read locks are released.

If the keyring payload space needs to be expanded or contracted, then a
replacement will still need allocating, and the original will still have to be
freed by RCU.

Signed-off-by: David Howells <dhowells@redhat.com>

KEYS: Perform RCU synchronisation on keys prior to key destruction

Make the keys garbage collector invoke synchronize_rcu() prior to destroying
keys with a zero usage count.  This means that a key can be examined under the
RCU read lock in the safe knowledge that it won't get deallocated until after
the lock is released - even if its usage count becomes zero whilst we're
looking at it.

This is useful in keyring search vs key link.  Consider a keyring containing a
link to a key.  That link can be replaced in-place in the keyring without
requiring an RCU copy-and-replace on the keyring contents without breaking a
search underway on that keyring when the displaced key is released, provided
the key is actually destroyed only after the RCU read lock held by the search
algorithm is released.

This permits __key_link() to replace a key without having to reallocate the key
payload.  A key gets replaced if a new key being linked into a keyring has the
same type and description.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Jeff Layton <jlayton@redhat.com>

KEYS: Announce key type (un)registration

Announce the (un)registration of a key type in the core key code rather than
in the callers.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Mimi Zohar <zohar@us.ibm.com>

KEYS: Reorganise keys Makefile

Reorganise the keys directory Makefile to put all the core bits together and
the type-specific bits after.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Mimi Zohar <zohar@us.ibm.com>

KEYS: Move the key config into security/keys/Kconfig

Move the key config into security/keys/Kconfig as there are going to be a lot
of key-related options.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Mimi Zohar <zohar@us.ibm.com>

KEYS: Use the compat keyctl() syscall wrapper on Sparc64 for Sparc32 compat

Use the 32-bit compat keyctl() syscall wrapper on Sparc64 for Sparc32 binary
compatibility.

Without this, keyctl(KEYCTL_INSTANTIATE_IOV) is liable to malfunction as it
uses an iovec array read from userspace - though the kernel should survive this
as it checks pointers and sizes anyway.

I think all the other keyctl() function should just work, provided (a) the top
32-bits of each 64-bit argument register are cleared prior to invoking the
syscall routine, and the 32-bit address space is right at the 0-end of the
64-bit address space.  Most of the arguments are 32-bit anyway, and so for
those clearing is not required.

Signed-off-by: David Howells <dhowells@redhat.com
cc: "David S. Miller" <davem@davemloft.net>
cc: sparclinux@vger.kernel.org
cc: stable@vger.kernel.org

Merge tag 'v3.4-rc5' into next

Linux 3.4-rc5

Merge to pull in prerequisite change for Smack:
86812bb0de1a3758dc6c7aa01a763158a7c0638a

Requested by Casey.

Linux 3.4-rc5

Merge tag 'pm-for-3.4-rc5' of git://git./linux/kernel/git/rafael/linux-pm

Pull power management fixes from Rafael J. Wysocki:
 "Fix for an issue causing hibernation to hang on systems with highmem
  (that practically means i386) due to broken memory management (bug
  introduced in 3.2, so -stable material) and PM documentation update
  making the freezer documentation follow the code again after some
  recent updates."

* tag 'pm-for-3.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  PM / Freezer / Docs: Update documentation about freezing of tasks
  PM / Hibernate: fix the number of pages used for hibernate/thaw buffering

autofs: make the autofsv5 packet file descriptor use a packetized pipe

The autofs packet size has had a very unfortunate size problem on x86:
because the alignment of 'u64' differs in 32-bit and 64-bit modes, and
because the packet data was not 8-byte aligned, the size of the autofsv5
packet structure differed between 32-bit and 64-bit modes despite
looking otherwise identical (300 vs 304 bytes respectively).

We first fixed that up by making the 64-bit compat mode know about this
problem in commit a32744d4abae ("autofs: work around unhappy compat
problem on x86-64"), and that made a 32-bit 'systemd' work happily on a
64-bit kernel because everything then worked the same way as on a 32-bit
kernel.

But it turned out that 'automount' had actually known and worked around
this problem in user space, so fixing the kernel to do the proper 32-bit
compatibility handling actually *broke* 32-bit automount on a 64-bit
kernel, because it knew that the packet sizes were wrong and expected
those incorrect sizes.

As a result, we ended up reverting that compatibility mode fix, and
thus breaking systemd again, in commit fcbf94b9dedd.

With both automount and systemd doing a single read() system call, and
verifying that they get *exactly* the size they expect but using
different sizes, it seemed that fixing one of them inevitably seemed to
break the other.  At one point, a patch I seriously considered applying
from Michael Tokarev did a "strcmp()" to see if it was automount that
was doing the operation.  Ugly, ugly.

However, a prettier solution exists now thanks to the packetized pipe
mode.  By marking the communication pipe as being packetized (by simply
setting the O_DIRECT flag), we can always just write the bigger packet
size, and if user-space does a smaller read, it will just get that
partial end result and the extra alignment padding will simply be thrown
away.

This makes both automount and systemd happy, since they now get the size
they asked for, and the kernel side of autofs simply no longer needs to
care - it could pad out the packet arbitrarily.

Of course, if there is some *other* user of autofs (please, please,
please tell me it ain't so - and we haven't heard of any) that tries to
read the packets with multiple writes, that other user will now be
broken - the whole point of the packetized mode is that one system call
gets exactly one packet, and you cannot read a packet in pieces.

Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David Miller <davem@davemloft.net>
Cc: Ian Kent <raven@themaw.net>
Cc: Thomas Meyer <thomas@m3y3r.de>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

PM / Freezer / Docs: Update documentation about freezing of tasks

The file Documentation/power/freezing-of-tasks.txt was still referencing
the TIF_FREEZE flag, that was removed by the commit
d88e4cb67197d007fb778d62fe17360e970d5bfa(freezer: remove now unused
TIF_FREEZE).

This patch removes all the references of TIF_FREEZE that were left
behind.

Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

pipes: add a "packetized pipe" mode for writing

The actual internal pipe implementation is already really about
individual packets (called "pipe buffers"), and this simply exposes that
as a special packetized mode.

When we are in the packetized mode (marked by O_DIRECT as suggested by
Alan Cox), a write() on a pipe will not merge the new data with previous
writes, so each write will get a pipe buffer of its own.  The pipe
buffer is then marked with the PIPE_BUF_FLAG_PACKET flag, which in turn
will tell the reader side to break the read at that boundary (and throw
away any partial packet contents that do not fit in the read buffer).

End result: as long as you do writes less than PIPE_BUF in size (so that
the pipe doesn't have to split them up), you can now treat the pipe as a
packet interface, where each read() system call will read one packet at
a time.  You can just use a sufficiently big read buffer (PIPE_BUF is
sufficient, since bigger than that doesn't guarantee atomicity anyway),
and the return value of the read() will naturally give you the size of
the packet.

NOTE! We do not support zero-sized packets, and zero-sized reads and
writes to a pipe continue to be no-ops.  Also note that big packets will
currently be split at write time, but that the size at which that
happens is not really specified (except that it's bigger than PIPE_BUF).
Currently that limit is the system page size, but we might want to
explicitly support bigger packets some day.

The main user for this is going to be the autofs packet interface,
allowing us to stop having to care so deeply about exact packet sizes
(which have had bugs with 32/64-bit compatibility modes).  But user
space can create packetized pipes with "pipe2(fd, O_DIRECT)", which will
fail with an EINVAL on kernels that do not support this interface.

Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David Miller <davem@davemloft.net>
Cc: Ian Kent <raven@themaw.net>
Cc: Thomas Meyer <thomas@m3y3r.de>
Cc: stable@kernel.org # needed for systemd/autofs interaction fix
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'staging-3.4-rc4' of git://git./linux/kernel/git/gregkh/staging

Pull staging tree fixes from Greg Kroah-Hartman:
 "Here are some tiny drivers/staging/ bugfixes.  Some build fixes that
  were recently reported, as well as one kfree bug that is hitting a
  number of users."

* tag 'staging-3.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  staging: ozwpan: Fix bug where kfree is called twice.
  staging: octeon-ethernet: fix build errors by including interrupt.h
  staging: zcache: fix Kconfig crypto dependency
  staging: tidspbridge: remove usage of OMAP2_L4_IO_ADDRESS

Merge tag 'usb-3.4-rc5' of git://git./linux/kernel/git/gregkh/usb

Pull USB fixes from Greg Kroah-Hartman:
 "Here are a number of small USB fixes for 3.4-rc5.

  Nothing major, as before, some USB gadget fixes.  There's a crash fix
  for a number of ASUS laptops on resume that had been reported by a
  number of different people.  We think the fix might also pertain to
  other machines, as this was a BIOS bug, and they seem to travel to
  different models and manufacturers quite easily.  Other than that,
  some other reported problems fixed as well."

* tag 'usb-3.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  usb: gadget: udc-core: fix incompatibility with dummy-hcd
  usb: gadget: udc-core: fix wrong call order
  USB: cdc-wdm: fix race leading leading to memory corruption
  USB: EHCI: fix crash during suspend on ASUS computers
  usb gadget: uvc: uvc_request_data::length field must be signed
  usb: gadget: dummy: do not call pullup() on udc_stop()
  usb: musb: davinci.c: add missing unregister
  usb: musb: drop __deprecated flag
  USB: gadget: storage gadgets send wrong error code for unknown commands
  usb: otg: gpio_vbus: Add otg transceiver events and notifiers

Merge branch 'for-linus' of git://git./linux/kernel/git/mason/linux-btrfs

Pull btrfs fixes from Chris Mason:
 "This has our collection of bug fixes.  I missed the last rc because I
  thought our patches were making NFS crash during my xfs test runs.
  Turns out it was an NFS client bug fixed by someone else while I tried
  to bisect it.

  All of these fixes are small, but some are fairly high impact.  The
  biggest are fixes for our mount -o remount handling, a deadlock due to
  GFP_KERNEL allocations in readdir, and a RAID10 error handling bug.

  This was tested against both 3.3 and Linus' master as of this morning."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: (26 commits)
  Btrfs: reduce lock contention during extent insertion
  Btrfs: avoid deadlocks from GFP_KERNEL allocations during btrfs_real_readdir
  Btrfs: Fix space checking during fs resize
  Btrfs: fix block_rsv and space_info lock ordering
  Btrfs: Prevent root_list corruption
  Btrfs: fix repair code for RAID10
  Btrfs: do not start delalloc inodes during sync
  Btrfs: fix that check_int_data mount option was ignored
  Btrfs: don't count CRC or header errors twice while scrubbing
  Btrfs: fix btrfs_ioctl_dev_info() crash on missing device
  btrfs: don't return EINTR
  Btrfs: double unlock bug in error handling
  Btrfs: always store the mirror we read the eb from
  fs/btrfs/volumes.c: add missing free_fs_devices
  btrfs: fix early abort in 'remount'
  Btrfs: fix max chunk size check in chunk allocator
  Btrfs: add missing read locks in backref.c
  Btrfs: don't call free_extent_buffer twice in iterate_irefs
  Btrfs: Make free_ipath() deal gracefully with NULL pointers
  Btrfs: avoid possible use-after-free in clear_extent_bit()
  ...

Merge tag 'fixes-for-linus' of git://git./linux/kernel/git/arm/arm-soc

Pull ARM SoC fixes from Olof Johansson:
 "Nothing controversial, just another batch of fixes:

   - Samsung/exynos fixes for more merge window fallout: build errors
     and warnings mostly, but also some clock/device setup issues on
     exynos4/5
   - PXA bug and warning fixes related to gpio and pinmux
   - IRQ domain conversion bugfixes for U300 and MSM
   - A regulator setup fix for U300"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: PXA2xx: MFP: fix potential direction bug
  ARM: PXA2xx: MFP: fix bug with MFP_LPM_KEEP_OUTPUT
  arm/sa1100: fix sa1100-rtc memory resource
  ARM: pxa: fix gpio wakeup setting
  ARM: SAMSUNG: add missing MMC_CAP2_BROKEN_VOLTAGE capability
  ARM: EXYNOS: Fix compilation error when CONFIG_OF is not defined
  ARM: EXYNOS: Fix resource on dev-dwmci.c
  ARM: S3C24XX: Fix build warning for S3C2410_PM
  ARM: mini2440_defconfig: Fix build error
  ARM: msm: Fix gic irqdomain support
  ARM: EXYNOS: Fix incorrect initialization of GIC
  ARM: EXYNOS: use 'exynos4-sdhci' as device name for sdhci controllers
  ARM: u300: bump all IRQ numbers by one
  ARM: ux300: Fix unimplementable regulation constraints

Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

Pull drm fixes from Dave Airlie:
 "As soon as I sent the non-urgent stack, two important fixes come in:

   - i915: fixes SNB GPU hangs in a number of 3D apps

   - radeon: initial fix for VGA on LLano system, 3 or 4 of us have
     spent time debugging this, and Jerome finally figured out the magic
     bit the BIOS/fglrx set that we didn't.  This at least should get
     things working, there may be future reliability fixes."

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/i915: Set the Stencil Cache eviction policy to non-LRA mode.
  drm/radeon/kms: need to set up ss on DP bridges as well

Revert "autofs: work around unhappy compat problem on x86-64"

This reverts commit a32744d4abae24572eff7269bc17895c41bd0085.

While that commit was technically the right thing to do, and made the
x86-64 compat mode work identically to native 32-bit mode (and thus
fixing the problem with a 32-bit systemd install on a 64-bit kernel), it
turns out that the automount binaries had workarounds for this compat
problem.

Now, the workarounds are disgusting: doing an "uname()" to find out the
architecture of the kernel, and then comparing it for the 64-bit cases
and fixing up the size of the read() in automount for those.  And they
were confused: it's not actually a generic 64-bit issue at all, it's
very much tied to just x86-64, which has different alignment for an
'u64' in 64-bit mode than in 32-bit mode.

But the end result is that fixing the compat layer actually breaks the
case of a 32-bit automount on a x86-64 kernel.

There are various approaches to fix this (including just doing a
"strcmp()" on current->comm and comparing it to "automount"), but I
think that I will do the one that teaches pipes about a special "packet
mode", which will allow user space to not have to care too deeply about
the padding at the end of the autofs packet.

That change will make the compat workaround unnecessary, so let's revert
it first, and get automount working again in compat mode.  The
packetized pipes will then fix autofs for systemd.

Reported-and-requested-by: Michael Tokarev <mjt@tls.msk.ru>
Cc: Ian Kent <raven@themaw.net>
Cc: stable@kernel.org # for 3.3
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

drm/i915: Set the Stencil Cache eviction policy to non-LRA mode.

Clearing bit 5 of CACHE_MODE_0 is necessary to prevent GPU hangs in
OpenGL programs such as Google MapsGL, Google Earth, and gzdoom when
using separate stencil buffers.  Without it, the GPU tries to use the
LRA eviction policy, which isn't supported.  This was supposed to be off
by default, but seems to be on for many machines.

This cannot be done in gen6_init_clock_gating with most of the other
workaround bits; the render ring needs to exist.  Otherwise, the
register write gets dropped on the floor (one printk will show it
changed, but a second printk immediately following shows the value
reverts to the old one).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47535
Cc: stable@vger.kernel.org
Cc: Rob Castle <futuredub@gmail.com>
Cc: Eric Appleman <erappleman@gmail.com>
Cc: aaron667@gmx.net
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/radeon/kms: need to set up ss on DP bridges as well

Makes Nutmeg DP to VGA bridges work for me.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=42490

Noticed by Jerome Glisse (after weeks of debugging).

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge git://git.samba.org/sfrench/cifs-2.6

Pull CIFS fixes from Steve French.

* git://git.samba.org/sfrench/cifs-2.6:
  Use correct conversion specifiers in cifs_show_options
  CIFS: Show backupuid/gid in /proc/mounts
  cifs: fix offset handling in cifs_iovec_write

Merge tag 'stable/for-linus-3.4-rc4-tag' of git://git./linux/kernel/git/konrad/xen

Pull Xen fixes from Konrad Rzeszutek Wilk:
 "Some of these had been in existence since the 2.6.27 days, some since
  3.0 - and some due to new features added in v3.4.

  The one that is most interesting is David's one - in the low-level
  assembler code we had be checking events needlessly.  With his patch
  now we do it when the appropriate flag is set - with the added benefit
  that we can process events faster.  Stefano's is fixing a mistake
  where the Linux IRQ numbers were ACK-ed instead of the Xen IRQ,
  resulting in missing interrupts.  The other ones are bootup related
  that can show up on various hardware."

 - In the low-level assembler code we would jump to check events even if
   none were present.  This incorrect behavior had been there since
   2.6.27 days!
 - When using the fast-path for ACK-ing interrupts we were using the
   Linux IRQ numbers instead of the Xen ones (and they can differ) and
   missing interrupts in process.
 - Fix bootup crashes when ACPI hotplug CPUs were present and they would
   expand past the set number of CPUs we were allocated.
 - Deal with broken BIOSes when uploading C-states to the hypervisor.
 - Disable the cpuid check for MWAIT_LEAF if the ACPI PAD driver is
   loaded.  If the ACPI PAD driver is used it will crash, so lets not
   export the functionality so the ACPI PAD driver won't load.

* tag 'stable/for-linus-3.4-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
  xen: correctly check for pending events when restoring irq flags
  xen/acpi: Workaround broken BIOSes exporting non-existing C-states.
  xen/smp: Fix crash when booting with ACPI hotplug CPUs.
  xen: use the pirq number to check the pirq_eoi_map
  xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded.

Merge tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6

Pull misc SPI device driver bug fixes from Grant Likely.

* tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6:
  spi/spi-bfin5xx: Fix flush of last bit after each spi transfer
  spi/spi-bfin5xx: fix reversed if condition in interrupt mode
  spi/spi_bfin_sport: drop bits_per_word from client data
  spi/bfin_spi: drop bits_per_word from client data
  spi/spi-bfin-sport: move word length setup to transfer handler
  spi/bfin5xx: rename config macro name for bfin5xx spi controller driver
  spi/pl022: Allow request for higher frequency than maximum possible
  spi/bcm63xx: set master driver mode_bits.
  spi/bcm63xx: don't use the stopping state
  spi/bcm63xx: convert to the pump message infrastructure
  spi/spi-ep93xx.c: use dma_transfer_direction instead of dma_data_direction
  spi: fix spi.h kernel-doc warning
  spi/pl022: Fix calculate_effective_freq()
  spi/pl022: Fix range checking for bits per word

Merge tag 'hwmon-for-linus' of git://git./linux/kernel/git/groeck/linux-staging

Pull hwmon patches from Guenter Roeck:
 - Fix build warning in ad7314 driver
 - Fix pci_device_id array access in fam15h_power driver, introduced by
   commit 00250ec90963 ("hwmon: fam15h_power: fix bogus values with
   current BIOSes")

* tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  hwmon: (fam15h_power) Fix pci_device_id array
  hwmon: (ad7314) Fix build warning

Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

Pull drm fixes from Dave Airlie:
 "For your Friday pull request stack, nothing astounding or shattering
  this week some exynos, some intel, some radeon fixes.  One intel fix
  for a regression somwehere back in 2.6.35 land."

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/radeon/kms: use frac fb div on APUs
  drm/radeon: add a missing entry to encoder_names
  drm/i915: handle input/output sdvo timings separately in mode_set
  drm/i915: fix integer overflow in i915_gem_do_execbuffer()
  drm/i915: fix integer overflow in i915_gem_execbuffer2()
  drm/exynos: added missed vm area region mapping type.
  drm/exynos: fixed exynos_drm_gem_map_pages bug.
  drm/exynos: fixed duplicatd memory allocation bug.
  drm/i915: fixup load-detect on enabled, but not active pipe

Merge branch 'core-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull RCU fix from Ingo Molnar.

* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  rcu: Permit call_rcu() from CPU_DYING notifiers

Merge branch 'x86-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull x86 fixes from Ingo Molnar.

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/apic: Use x2apic physical mode based on FADT setting
  x86/mrst: Quiet sparse noise about plain integer as NULL pointer
  x86, intel_cacheinfo: Fix error return code in amd_set_l3_disable_slot()

Merge branch 'sched-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull scheduler fixes from Ingo Molnar.

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched: Fix OOPS when build_sched_domains() percpu allocation fails
  sched: Fix more load-balancing fallout

Merge branch 'perf-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull perf fixes from Ingo Molnar.

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf: Fix perf_event_for_each() to use sibling
  perf symbols: Read plt symbols from proper symtab_type binary
  tracing: Fix stacktrace of latency tracers (irqsoff and friends)
  perf tools: Add 'G' and 'H' modifiers to event parsing
  tracing: Fix regression with tracing_on
  perf tools: Drop CROSS_COMPILE from flex and bison calls
  perf report: Fix crash showing warning related to kernel maps
  tracing: Fix build breakage without CONFIG_PERF_EVENTS (again)

Merge branch 'for-v3.4-rc5' of git://git./linux/kernel/git/paulg/linux

Pull build fixes for less mainstream architectures from Paul Gortmaker:
 "These are fixes for frv(1), blackfin(2), powerpc(1) and xtensa(4).

  Fortunately the touches are nearly all specific to files just used by
  the arch in question.  The two touches to shared/common files
  [kernel/irq/debug.h and drivers/pci/Makefile] are trivial to assess as
  no risk to anyone.

  Half of them relate to xtensa directly.  It was only when I fixed the
  last xtensa issue that I realized that the arch has been broken for a
  significant time, and isn't a specific v3.4 regression.  So if you
  wanted, we could leave xtensa lying bleeding in the street for a
  couple more weeks and queue those for 3.5.  But given they are no risk
  to anyone outside of xtensa, I figured to just leave them in.

  If you are OK with taking the xtensa fixes, then please pull to get:

   - one last implicit include uncovered by system.h that is in a file
     specific to just one powerpc defconfig.  (I'd sync'd with BenH).

   - fix an oversight in the PCI makefile where shared code wasn't being
     compiled for ARCH=frv

   - fix a missing include for GPIO in blackfin framebuffer.

   - audit and tag endif in blackfin ezkit board file, in order to find
     and fix the misplaced endif masking a block of code.

   - fix irq/debug.h choice of temporary macro names to be more internal
     so they don't conflict with names used by xtensa.

   - fix a reference to an undeclared local var in xtensa's signal.c

   - fix an implicit bug.h usage in xtensa's asm/io.h uncovered by my
     removing bug.h from kernel.h

   - fix xtensa to properly indicate it is using asm-generic/hardirq.h
     in order to resolve the link error - undefined ack_bad_irq

  The xtensa still fails final link as my latest binutils does something
  evil when ld forward-relocates unlikely() blocks, but in theory people
  who have older/valid toolchains could now use the thing."

* 'for-v3.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
  xtensa: fix build fail on undefined ack_bad_irq
  blackfin: fix ifdef fustercluck in mach-bf538/boards/ezkit.c
  blackfin: fix compile error in bfin-lq035q1-fb.c
  pci: frv architecture needs generic setup-bus infrastructure
  irq: hide debug macros so they don't collide with others.
  xtensa: fix build error in xtensa/include/asm/io.h
  xtensa: fix build failure in xtensa/kernel/signal.c
  powerpc: fix system.h fallout in sysdev/scom.c [chroma_defconfig]

Merge tag 'sh-for-linus' of git://github.com/pmundt/linux-sh

Pull SuperH fixes from Paul Mundt.

* tag 'sh-for-linus' of git://github.com/pmundt/linux-sh:
  sh: Fix up tracepoint build fallout from static key introduction.
  sh: Fix error synchronising kernel page tables

Merge branch 'docs-3.4' of git://git.samba.org/jlayton/linux

Pull security key doc update from Jeff Layton:
 "Ordinarily, I send my patches through others' trees, but David
  suggested I just send this one to you directly since it's just a
  Documentation/ update"

* 'docs-3.4' of git://git.samba.org/jlayton/linux:
  keys: update the documentation with info about "logon" keys

xen: correctly check for pending events when restoring irq flags

In xen_restore_fl_direct(), xen_force_evtchn_callback() was being
called even if no events were pending.  This resulted in (depending on
workload) about a 100 times as many xen_version hypercalls as
necessary.

Fix this by correcting the sense of the conditional jump.

This seems to give a significant performance benefit for some
workloads.

There is some subtle tricksy "..since the check here is trying to
check both pending and masked in a single cmpw, but I think this is
correct. It will call check_events now only when the combined
mask+pending word is 0x0001 (aka unmasked, pending)." (Ian)

CC: stable@kernel.org
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Btrfs: reduce lock contention during extent insertion

We're spending huge amounts of time on lock contention during
end_io processing because we unconditionally assume we are overwriting
an existing extent in the file for each IO.

This checks to see if we are outside i_size, and if so, it uses a
less expensive readonly search of the btree to look for existing
extents.

Signed-off-by: Chris Mason <chris.mason@oracle.com>

Btrfs: avoid deadlocks from GFP_KERNEL allocations during btrfs_real_readdir

Btrfs has an optimization where it will preallocate dentries during
readdir to fill in enough information to open the inode without an extra
lookup.

But, we're calling d_alloc, which is doing GFP_KERNEL allocations, and
that leads to deadlocks because our readdir code has tree locks held.

For now, disable this optimization.  We'll fix the gfp mask in the next
merge window.

Signed-off-by: Chris Mason <chris.mason@oracle.com>

spi/spi-bfin5xx: Fix flush of last bit after each spi transfer

This patch ensures that the last bit of a transfer gets correctly
flushed out of the register.

Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

spi/spi-bfin5xx: fix reversed if condition in interrupt mode

This condition is used to determine 8 bits or 16 and 32 bits transfer.
Obviously it is reversed.

Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

spi/spi_bfin_sport: drop bits_per_word from client data

Since the member was dropped from the common Blackfin header, we need
to stop using it in the SPORT driver too.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

spi/bfin_spi: drop bits_per_word from client data

No other SPI controller has this field, and SPI clients should be setting
this up in their own drivers.  So drop it from the Blackfin controller to
keep people from using it.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

spi/spi-bfin-sport: move word length setup to transfer handler

Each transfer may have its own bits per word.

Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

spi/bfin5xx: rename config macro name for bfin5xx spi controller driver

This controller is only for blackfin 5xx soc, so rename it to BFIN5XX

Signed-off-by: Scott Jiang <scott.jiang.linux@gmail.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

spi/pl022: Allow request for higher frequency than maximum possible

Currently, if we request for frequency greater than maximum possible, spi driver
returns error.

For example, if the spi block src frequency is 333/4 MHz, i.e. 83.33.. MHz,
maximum frequency programmable would be src/2. Which would come around 41.6...

It is difficult to pass frequency in these figures. We normally try to program
in round figures, like 42 MHz and it should get programmed to <=
requested_frequency, i.e. 41.6...

For this to happen, we must not return error even if requested freq is higher
than max possible. But should program it to max possible.

Reported-by: Vinit Kamalaksha Shenoy <vinit.shenoy@st.com>
Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

Btrfs: Fix space checking during fs resize

Fix out-of-space checking, addressing a warning and potential resource
leak when resizing the filesystem down while allocating blocks.

Signed-off-by: Daniel J Blueman <daniel@quora.org>
Reviewed-by: Josef Bacik <josef@redhat.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>

Btrfs: fix block_rsv and space_info lock ordering

may_commit_transaction() calls
        spin_lock(&space_info->lock);
        spin_lock(&delayed_rsv->lock);
and update_global_block_rsv() calls
        spin_lock(&block_rsv->lock);
        spin_lock(&sinfo->lock);

Lockdep complains about this at run time.
Everywhere except in update_global_block_rsv(), the space_info lock is
the outer lock, therefore the locking order in update_global_block_rsv()
is changed.

Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: Chris Mason <chris.mason@oracle.com>

Btrfs: Prevent root_list corruption

I was seeing root_list corruption on unmount during fs resize in 3.4-rc4; add
correct locking to address this.

Signed-off-by: Daniel J Blueman <daniel@quora.org>
Signed-off-by: Chris Mason <chris.mason@oracle.com>

Btrfs: fix repair code for RAID10

btrfs_map_block sets mirror_num, so that the repair code knows eventually
which device gave us the read error. For RAID10, mirror_num must be 1 or 2.
Before this fix mirror_num was incorrectly related to our stripe index.

Signed-off-by: Jan Schmidt <list.btrfs@jan-o-sch.net>
Signed-off-by: Chris Mason <chris.mason@oracle.com>

Btrfs: do not start delalloc inodes during sync

btrfs_start_delalloc_inodes will just walk the list of delalloc inodes and
start writing them out, but it doesn't splice the list or anything so as
long as somebody is doing work on the box you could end up in this section
_forever_.  So just remove it, it's not needed anyway since sync will start
writeback on all inodes anyway, all we need to do is wait for ordered
extents and then we can commit the transaction.  In my horrible torture test
sync goes from taking 4 minutes to about 1.5 minutes.  Thanks,

Signed-off-by: Josef Bacik <josef@redhat.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>

spi/bcm63xx: set master driver mode_bits.

We were not properly advertising the MODE bits supported by this driver, fix
that.

Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

spi/bcm63xx: don't use the stopping state

We do not need to use a flag to indicate if the master driver is stopping
it is sufficient to perform spi master unregistering in the platform
driver's remove function.

Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

spi/bcm63xx: convert to the pump message infrastructure

This patch converts the bcm63xx SPI driver to use the SPI infrastructure
pump message queue. Since we were previously sleeping in the SPI
driver's transfer() function (which is not allowed) this is now fixed as well.

To complete that conversion a certain number of changes have been made:
- the transfer len is split into multiple hardware transfers in case its
  size is bigger than the hardware FIFO size
- the FIFO refill is no longer done in the interrupt context, which was a
  bad idea leading to quick interrupt handler re-entrancy

Tested-by: Tanguy Bouzeloc <tanguy.bouzeloc@efixo.com>
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

spi/spi-ep93xx.c: use dma_transfer_direction instead of dma_data_direction

A new enum indicating the dma channel direction was introduced by:

commit 49920bc66984a512f4bcc7735a61642cd0e4d6f2
    dmaengine: add new enum dma_transfer_direction

The following commit changed spi-ep93xx to use the new enum:

commit a485df4b4404379786c4bdd258bc528b2617449d
    spi, serial: move to dma_transfer_direction

In doing so a sparse warning was introduced:

warning: mixing different enum types
   int enum dma_data_direction  versus
   int enum dma_transfer_direction

This is produced because the 'dir' passed in ep93xx_spi_dma_prepare
is an enum dma_data_direction and is being used to set the
dma_slave_config 'direction' which is now an enum dma_transfer_direction.

Fix this by converting spi-ep93xx to use the new enum type in all
places.

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

spi: fix spi.h kernel-doc warning

Fix kernel-doc warning in spi.h (copy/paste):

Warning(include/linux/spi/spi.h:365): No description found for parameter 'unprepare_transfer_hardware'

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

spi/pl022: Fix calculate_effective_freq()

calculate_effective_freq() was still not optimized and there were cases when it
returned without error and with values of cpsr and scr as zero.

Also, the variable named found is not used well.

This patch targets to optimize and correct this routine. Tested for SPEAr.

Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
Tested-by: Vinit Kamalaksha Shenoy <vinit.shenoy@st.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

Merge branch 'v3.4-samsung-fixes-3' of git://git./linux/kernel/git/kgene/linux-samsung into fixes

* 'v3.4-samsung-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
  ARM: SAMSUNG: add missing MMC_CAP2_BROKEN_VOLTAGE capability
  ARM: EXYNOS: Fix compilation error when CONFIG_OF is not defined
  ARM: EXYNOS: Fix resource on dev-dwmci.c
  ARM: S3C24XX: Fix build warning for S3C2410_PM
  ARM: mini2440_defconfig: Fix build error
  ARM: EXYNOS: Fix incorrect initialization of GIC
  ARM: EXYNOS: use 'exynos4-sdhci' as device name for sdhci controllers

Merge branch 'fixes' of git://github.com/hzhuang1/linux into fixes

* 'fixes' of git://github.com/hzhuang1/linux:
  ARM: PXA2xx: MFP: fix potential direction bug
  ARM: PXA2xx: MFP: fix bug with MFP_LPM_KEEP_OUTPUT
  arm/sa1100: fix sa1100-rtc memory resource
  ARM: pxa: fix gpio wakeup setting

Merge tag 'fixes-for-v3.4-rc5' of git://git./linux/kernel/git/balbi/usb into usb-linus

usb: fixes for v3.4-rc cycle

A few more fixes for v3.4-rc cycle.

It includes a couple of fixes to the ordering of the methods in udc-core.c.
Without these two patches, we will have issues when either unregistering a
gadget driver (triggered with dummy_hcd only) or issuing a device-initiated
disconnect through sysfs.

There's also a fix on dummy_hcd to not call ->pullup() from udc_stop() because
udc-core.c already handles that.

A fix to MUSB as promised, to kill the compile warnings regarding deprecated
interfaces. We are essentially dropping the __deprecated flag because it
doesn't look like we will ever be able to live without it when we consider the
amount of silicon issues we find on different MUSB instantiations.

A couple of other fixes are also available, one adding the missing transceiver
events to gpio_vbus and another adding a missing unregister call to MUSB's
davinci glue layer.

usb: gadget: udc-core: fix incompatibility with dummy-hcd

This patch (as1548) fixes a recently-introduced incompatibility
between the UDC core and the dummy-hcd driver.  Commit
8ae8090c82eb407267001f75b3d256b3bd4ae691 (usb: gadget: udc-core: fix
asymmetric calls in remove_driver) moved the usb_gadget_udc_stop()
call in usb_gadget_remove_driver() below the usb_gadget_disconnect()
call.

As a result, usb_gadget_disconnect() gets called at a time when the
gadget driver believes it has been unbound but dummy-hcd believes
it has not.  A nasty error ensues when dummy-hcd calls the gadget
driver's disconnect method a second time.

To fix the problem, this patch moves the gadget driver's unbind
notification after the usb_gadget_disconnect() call.  Now nothing
happens between the two unbind notifications, so nothing goes wrong.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

usb: gadget: udc-core: fix wrong call order

commit 6d258a4 (usb: gadget: udc-core: stop UDC on device-initiated
disconnect) introduced another case of asymmetric calls when issuing
a device-initiated disconnect. Fix it.

Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Felipe Balbi <balbi@ti.com>

drm/radeon/kms: use frac fb div on APUs

Seems to be more stable on certain monitors.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=48880

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/radeon: add a missing entry to encoder_names

An entry for INTERNAL_VCE encoder was missing. Add it.

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes

From Daniel Vetter

- VGA load-detect fix. This bug seems to be as old as the load-detect code
  (2.6.30), but needs stupid userspace (upowerd trying to detect
  connectors on dpms-off outputs) to actually kill the machine. And
  obviously a machine without VGA-hotplug, otherwise we don't do load
  detect.
- 2 interger overflow fixes for unpriviledged ioctls from Xi Wang.
- Fix SDVO regression for low-res (pixelclock < 100MHz) digital outputs,
 introduce in 2.6.36.

* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: handle input/output sdvo timings separately in mode_set
  drm/i915: fix integer overflow in i915_gem_do_execbuffer()
  drm/i915: fix integer overflow in i915_gem_execbuffer2()
  drm/i915: fixup load-detect on enabled, but not active pipe

Merge branch 'exynos-drm-fixes' of git://git.infradead.org/users/kmpark/linux-2.6-samsung into drm-fixes

From Inki Dae:

this patch set fixes gem allocation and mapping issue between user space and
physical memory region.

* 'exynos-drm-fixes' of git://git.infradead.org/users/kmpark/linux-2.6-samsung:
  drm/exynos: added missed vm area region mapping type.
  drm/exynos: fixed exynos_drm_gem_map_pages bug.
  drm/exynos: fixed duplicatd memory allocation bug.

ARM: PXA2xx: MFP: fix potential direction bug

Pins configured as input and have MFP_LPM_DRIVE_* flag set, can have a
wrong output value for some period of time (spike) during the suspend
sequence.
This can happen because the direction of the pins (GPDR) is set by
software and the output level is set by hardware (PGSR) at a later
stage.

Fix the above potential bug by setting the output levels first.
Also save the actual levels of the pins before the suspend and restore
them after the resume, but before the direction settings take place, so
the same bug as described above will not happen in the resume sequence.

Reported-by: Paul Parsons <lost.distance@yahoo.com>
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Tested-by: Paul Parsons <lost.distance@yahoo.com>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>

ARM: PXA2xx: MFP: fix bug with MFP_LPM_KEEP_OUTPUT

Pins that have MFP_LPM_KEEP_OUTPUT set and are configured for output
must retain the output state in low power mode.
Currently, the pin direction configuration is overrided with values
in gpdr_lpm[] array and do not obey the MFP_LPM_KEEP_OUTPUT setting.

Fix the above bug and add some documentation to clarify the
MFP_LPM_KEEP_OUTPUT setting purpose.

Reported-by: Paul Parsons <lost.distance@yahoo.com>
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Tested-by: Paul Parsons <lost.distance@yahoo.com>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>

arm/sa1100: fix sa1100-rtc memory resource

DEFINE_RES_MEM() takes the size of resource as a second argument,
not the end address. Passing end address leads to following error
in runtime during device registration:
sa1100-rtc: failed to claim resource 0

Fix it.

Signed-off-by: Dmitry Artamonow <mad_soft@inbox.ru>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>

ARM: pxa: fix gpio wakeup setting

In 3.3, gpio wakeup setting was broken. The call
enable_irq_wake() didn't set up the PXA gpio registers
(PWER, ...) anymore.

Fix it at least for pxa27x. The driver doesn't seem to be
used in pxa25x (weird ...), and the fix doesn't extend to
pxa3xx and pxa95x (which don't have a gpio_set_wake()
available).

Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>

xen/acpi: Workaround broken BIOSes exporting non-existing C-states.

We did a similar check for the P-states but did not do it for
the C-states. What we want to do is ignore cases where the DSDT
has definition for sixteen CPUs, but the machine only has eight
CPUs and we get:
xen-acpi-processor: (CX): Hypervisor error (-22) for ACPI CPU14

Reported-by: Tobias Geiger <tobias.geiger@vido.info>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

xen/smp: Fix crash when booting with ACPI hotplug CPUs.

When we boot on a machine that can hotplug CPUs and we
are using 'dom0_max_vcpus=X' on the Xen hypervisor line
to clip the amount of CPUs available to the initial domain,
we get this:

(XEN) Command line: com1=115200,8n1 dom0_mem=8G noreboot dom0_max_vcpus=8 sync_console mce_verbosity=verbose console=com1,vga loglvl=all guest_loglvl=all
.. snip..
DMI: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x032.072520111118 07/25/2011
.. snip.
SMP: Allowing 64 CPUs, 32 hotplug CPUs
installing Xen timer for CPU 7
cpu 7 spinlock event irq 361
NMI watchdog: disabled (cpu7): hardware events not enabled
Brought up 8 CPUs
.. snip..
[acpi processor finds the CPUs are not initialized and starts calling
arch_register_cpu, which creates /sys/devices/system/cpu/cpu8/online]
CPU 8 got hotplugged
CPU 9 got hotplugged
CPU 10 got hotplugged
.. snip..
initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 406 usecs
calling  erst_init+0x0/0x2bb @ 1

[and the scheduler sticks newly started tasks on the new CPUs, but
said CPUs cannot be initialized b/c the hypervisor has limited the
amount of vCPUS to 8 - as per the dom0_max_vcpus=8 flag.
The spinlock tries to kick the other CPU, but the structure for that
is not initialized and we crash.]
BUG: unable to handle kernel paging request at fffffffffffffed8
IP: [<ffffffff81035289>] xen_spin_lock+0x29/0x60
PGD 180d067 PUD 180e067 PMD 0
Oops: 0002 [#1] SMP
CPU 7
Modules linked in:

Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc2upstream-00001-gf5154e8 #1 Intel Corporation S2600CP/S2600CP
RIP: e030:[<ffffffff81035289>]  [<ffffffff81035289>] xen_spin_lock+0x29/0x60
RSP: e02b:ffff8801fb9b3a70  EFLAGS: 00010282

With this patch, we cap the amount of vCPUS that the initial domain
can run, to exactly what dom0_max_vcpus=X has specified.

In the future, if there is a hypercall that will allow a running
domain to expand past its initial set of vCPUS, this patch should
be re-evaluated.

CC: stable@kernel.org
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Merge branch 'sh/urgent' into sh-fixes-for-linus

sh: Fix up tracepoint build fallout from static key introduction.

With the introduction of static keys, anything using tracepoints blows up
in the following manner:

include/trace/events/oom.h:8:13: error: initializer element is not constant
include/trace/events/oom.h:8:13: error: (near initialization for '__tracepoint_oom_score_adj_update')
include/trace/events/oom.h:8:13: error: initializer element is not constant
include/trace/events/oom.h:8:13: error: (near initialization for '__tracepoint_oom_score_adj_update.key')

This is a result of the STATIC_KEY_INIT_xxx defs wrapping ATOMIC_INIT()
which on sh includes an atomic_t typecast. Given that we don't really
need the typecast for anything anymore, the simplest solution is simply
to kill off the cast.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>

USB: cdc-wdm: fix race leading leading to memory corruption

This patch fixes a race whereby a pointer to a buffer
would be overwritten while the buffer was in use leading
to a double free and a memory leak. This causes crashes.
This bug was introduced in 2.6.34

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Tested-by: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge branch 'stable' of git://git./linux/kernel/git/cmetcalf/linux-tile

Pull arch/tile fixes from Chris Metcalf:
 "One change fixes a platform-independent bug about environment var
  handling in the boot command line.  The other is a trivial
  tile-specific bug fix to avoid a link-time warning."

* 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
  arch/tile: fix a couple of functions that should be __init
  init: fix bug where environment vars can't be passed via boot args

Merge tag 'ib-fixes' of git://git./linux/kernel/git/roland/infiniband

Pull infiniband fixes from Roland Dreier:
 "A few fixes for regressions introduced in 3.4-rc1:
   - fix memory leak in mlx4
   - fix two problems with new MAD response generation code"

* tag 'ib-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband:
  IB/mlx4: Fix memory leaks in ib_link_query_port()
  IB/mad: Don't send response for failed MADs
  IB/mad: Set 'D' bit in response for unhandled MADs

xtensa: fix build fail on undefined ack_bad_irq

Commit e520c410854bab763be24e0fce7ba89dc252efee

    "xtensa: convert to asm-generic/hardirq.h"

converted over to using the asm-generic parts, but it also
added the sentinel

#define ack_bad_irq ack_bad_irq

which tells asm-generic to _not_ use the common ack_bad_irq.

Since e520c41 deleted the duplicated code from the arch specific
file, we _do_ want the asm-generic one in scope.  So delete
the trigger define above which hides it.  In doing so we'll
realize that we've got to delete the almost-duplicate prototype
as well to avoid "static declaration ... follows non-static".

Cc: Christoph Hellwig <hch@lst.de>
Cc: Chris Zankel <chris@zankel.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

Merge branch 'fixes' of git://git.infradead.org/users/vkoul/slave-dma

Pull [GIT PULL] slave-dmaengine fixes from Vinod Koul.

* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
  dmaengine/amba-pl08x : reset phychan_hold on terminate all
  dma: pl330: fix a couple of compilation warnings
  dma/ste_dma40: fix erroneous comparison
  dma/ste_dma40: explicitly include regulator consumer header
  dma40: Improve the logic of stopping logical chan
  dmaengine: at_hdmac: remove clear-on-read in atc_dostart()
  dma: mxs-dma: enable channel in device_issue_pending call
  dmaengine: imx-dma: dont complete descriptor for cyclic dma

Merge tag 'sound-3.4' of git://git./linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "A workaround for an ASUS laptop and a few ASoC changes; most of the
  commits are tagged for stable, too."

* tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ASoC: wm8994: Improve sequencing of AIF channel enables
  ALSA: HDA: Add external mic quirk for Asus Zenbook UX31E
  ASoC: fsi: update for dmaengine prep_slave_sg fallout.
  ASoC: core: Fix card RTD count for deferred probe.
  ASoC: cs42l73: don't use negative array index
  ASoC: dapm: Ensure power gets managed for line widgets

Merge git://www.linux-watchdog.org/linux-watchdog

Pull a watchdog fix from Wim Van Sebroeck:
 "It will fix the size when reading or writing to WD Timer port 0x72 in
  the hpwdt driver."

* git://www.linux-watchdog.org/linux-watchdog:
  hpwdt: Only BYTE reads/writes to WD Timer port 0x72

Merge branch 'timers-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull timer fixes from Thomas Gleixner.

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  tick: Fix the spurious broadcast timer ticks after resume
  tick: Ensure that the broadcast device is initialized
  tick: Fix oneshot broadcast setup really

Merge branch 'akpm' (Andrew's patch-bomb)

Merge fixes from Andrew Morton:
 "13 fixes.  The acerhdf patches aren't (really) fixes.  But they've
  been stuck in my tree for up to two years, sent to Matthew multiple
  times and the developers are unhappy."

* emailed from Andrew Morton <akpm@linux-foundation.org>: (13 patches)
  mm: fix NULL ptr dereference in move_pages
  mm: fix NULL ptr dereference in migrate_pages
  revert "proc: clear_refs: do not clear reserved pages"
  drivers/rtc/rtc-ds1307.c: fix BUG shown with lock debugging enabled
  arch/arm/mach-ux500/mbox-db5500.c: world-writable sysfs fifo file
  hugetlbfs: lockdep annotate root inode properly
  acerhdf: lowered default temp fanon/fanoff values
  acerhdf: add support for new hardware
  acerhdf: add support for Aspire 1410 BIOS v1.3314
  fs/buffer.c: remove BUG() in possible but rare condition
  mm: fix up the vmscan stat in vmstat
  epoll: clear the tfile_check_list on -ELOOP
  mm/hugetlb: fix warning in alloc_huge_page/dequeue_huge_page_vma

xen: use the pirq number to check the pirq_eoi_map

In pirq_check_eoi_map use the pirq number rather than the Linux irq
number to check whether an eoi is needed in the pirq_eoi_map.

The reason is that the irq number is not always identical to the
pirq number so if we wrongly use the irq number to check the
pirq_eoi_map we are going to check for the wrong pirq to EOI.

As a consequence some interrupts might not be EOI'ed by the
guest correctly.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Tobias Geiger <tobias.geiger@vido.info>
[v1: Added some extra wording to git commit]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded.

There are exactly four users of __monitor and __mwait:

 - cstate.c (which allows acpi_processor_ffh_cstate_enter to be called
   when the cpuidle API drivers are used. However patch
   "cpuidle: replace xen access to x86 pm_idle and default_idle"
   provides a mechanism to disable the cpuidle and use safe_halt.
 - smpboot (which allows mwait_play_dead to be called). However
   safe_halt is always used so we skip that.
 - intel_idle (same deal as above).
 - acpi_pad.c. This the one that we do not want to run as we
   will hit the below crash.

Why do we want to expose MWAIT_LEAF in the first place?
We want it for the xen-acpi-processor driver - which uploads
C-states to the hypervisor. If MWAIT_LEAF is set, the cstate.c
sets the proper address in the C-states so that the hypervisor
can benefit from using the MWAIT functionality. And that is
the sole reason for using it.

Without this patch, if a module performs mwait or monitor we
get this:

invalid opcode: 0000 [#1] SMP
CPU 2
.. snip..
Pid: 5036, comm: insmod Tainted: G           O 3.4.0-rc2upstream-dirty #2 Intel Corporation S2600CP/S2600CP
RIP: e030:[<ffffffffa000a017>]  [<ffffffffa000a017>] mwait_check_init+0x17/0x1000 [mwait_check]
RSP: e02b:ffff8801c298bf18  EFLAGS: 00010282
RAX: ffff8801c298a010 RBX: ffffffffa03b2000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff8801c29800d8 RDI: ffff8801ff097200
RBP: ffff8801c298bf18 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: ffffffffa000a000 R14: 0000005148db7294 R15: 0000000000000003
FS:  00007fbb364f2700(0000) GS:ffff8801ff08c000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000179f038 CR3: 00000001c9469000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process insmod (pid: 5036, threadinfo ffff8801c298a000, task ffff8801c29cd7e0)
Stack:
 ffff8801c298bf48 ffffffff81002124 ffffffffa03b2000 00000000000081fd
 000000000178f010 000000000178f030 ffff8801c298bf78 ffffffff810c41e6
 00007fff3fb30db9 00007fff3fb30db9 00000000000081fd 0000000000010000
Call Trace:
 [<ffffffff81002124>] do_one_initcall+0x124/0x170
 [<ffffffff810c41e6>] sys_init_module+0xc6/0x220
 [<ffffffff815b15b9>] system_call_fastpath+0x16/0x1b
Code: <0f> 01 c8 31 c0 0f 01 c9 c9 c3 00 00 00 00 00 00 00 00 00 00 00 00
RIP  [<ffffffffa000a017>] mwait_check_init+0x17/0x1000 [mwait_check]
 RSP <ffff8801c298bf18>
---[ end trace 16582fc8a3d1e29a ]---
Kernel panic - not syncing: Fatal exception

With this module (which is what acpi_pad.c would hit):

MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>");
MODULE_DESCRIPTION("mwait_check_and_back");
MODULE_LICENSE("GPL");
MODULE_VERSION();

static int __init mwait_check_init(void)
{
__monitor((void *)&current_thread_info()->flags, 0, 0);
__mwait(0, 0);
return 0;
}
static void __exit mwait_check_exit(void)
{
}
module_init(mwait_check_init);
module_exit(mwait_check_exit);

Reported-by: Liu, Jinsong <jinsong.liu@intel.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

staging: ozwpan: Fix bug where kfree is called twice.

Signed-off-by: Rupesh Gujare <rgujare@ozmodevices.com>
Signed-off-by: Chris Kelly <ckelly@ozmodevices.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

blackfin: fix ifdef fustercluck in mach-bf538/boards/ezkit.c

This file has lots and lots of ifdef, around structure decls
and structure usages.  The failure issue was that we would
build the BF538-EZKIT_defconfig and get:

 arch/blackfin/mach-bf538/boards/ezkit.c:924:3: error: 'bfin_lq035q1_device'
 undeclared here (not in a function)

even though the same ifdef _appeared_ to enable both the struct
declaration and the code that used it.  Yet cpp was telling us we
didn't have the struct, but we still had the usage of it.

However, _appeared_ is the operative word.  After marking all the
anonymous #endif with their parent #ifdef config options, it was
_then_ clear that there was a misplaced #endif that was hiding
the struct declaration.

The real guts of the patch boils down to this:

-#endif
+#endif /* CONFIG_MTD_M25P80 */
+#endif /* CONFIG_SPI_BFIN5XX */
 [...]
-#endif  /* spi master and devices */

but since I had to tag the #endif with their respective #ifdef
options to find this misplaced SPI endif, it would be silly to
then go and delete them all.  So they stay.

Cc: Sonic Zhang <sonic.zhang@analog.com>
Cc: Bob Liu <lliubbo@gmail.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

blackfin: fix compile error in bfin-lq035q1-fb.c

This file has an implicit dependency on GPIO stuff, showing
up as the following build failure:

drivers/video/bfin-lq035q1-fb.c:369:6: error: 'GPIOF_OUT_INIT_LOW' undeclared

Other more global bfin build issues prevent an automated bisect, but
it really doesn't matter - simply add in the appropriate header.

Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

pci: frv architecture needs generic setup-bus infrastructure

Otherwise we get this link failure for frv's defconfig:

   LD      .tmp_vmlinux1
 drivers/built-in.o: In function `pci_assign_resource':
 (.text+0xbf0c): undefined reference to `pci_cardbus_resource_alignment'
 drivers/built-in.o: In function `pci_setup':
 pci.c:(.init.text+0x174): undefined reference to `pci_realloc_get_opt'
 pci.c:(.init.text+0x1a0): undefined reference to `pci_realloc_get_opt'
 make[1]: *** [.tmp_vmlinux1] Error 1

Cc: David Howells <dhowells@redhat.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

drm/i915: handle input/output sdvo timings separately in mode_set

We seem to have a decent confusion between the output timings and the
input timings of the sdvo encoder. If I understand the code correctly,
we use the original mode unchanged for the output timings, safe for
the lvds case. And we should use the adjusted mode for input timings.

Clarify the situation by adding an explicit output_dtd to the sdvo
mode_set function and streamline the code-flow by moving the input and
output mode setting in the sdvo encode together.

Furthermore testing showed that the sdvo input timing needs the
unadjusted dotclock, the sdvo chip will automatically compute the
required pixel multiplier to get a dotclock above 100 MHz.

Fix this up when converting a drm mode to an sdvo dtd.

This regression was introduced in

commit c74696b9c890074c1e1ee3d7496fc71eb3680ced
Author: Pavel Roskin <proski@gnu.org>
Date:   Thu Sep 2 14:46:34 2010 -0400

    i915: revert some checks added by commit 32aad86f

particularly the following hunk:

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 093e914..62d22ae 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1122,11 +1123,9 @@ static void intel_sdvo_mode_set(struct drm_encoder *encoder,

     /* We have tried to get input timing in mode_fixup, and filled into
        adjusted_mode */
-    if (intel_sdvo->is_tv || intel_sdvo->is_lvds) {
-        intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode);
+    intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode);
+    if (intel_sdvo->is_tv || intel_sdvo->is_lvds)
         input_dtd.part2.sdvo_flags = intel_sdvo->sdvo_flags;
-    } else
-        intel_sdvo_get_dtd_from_mode(&input_dtd, mode);

     /* If it's a TV, we already set the output timing in mode_fixup.
      * Otherwise, the output timing is equal to the input timing.

Due to questions raised in review, below a more elaborate analysis of
the bug at hand:

Sdvo seems to have two timings, one is the output timing which will be
sent over whatever is connected on the other side of the sdvo chip (panel,
hdmi screen, tv), the other is the input timing which will be generated by
the gmch pipe. It looks like sdvo is expected to scale between the two.

To make things slightly more complicated, we have a bunch of special
cases:
- For lvds panel we always use a fixed output timing, namely
  intel_sdvo->sdvo_lvds_fixed_mode, hence that special case.
- Sdvo has an interface to generate a preferred input timing for a given
  output timing. This is the confusing thing that I've tried to clear up
  with the follow-on patches.
- A special requirement is that the input pixel clock needs to be between
  100MHz and 200MHz (likely to keep it within the electromechanical design
  range of PCIe), 270MHz on later gen4+. Lower pixel clocks are
  doubled/quadrupled.

The thing this patch tries to fix is that the pipe needs to be
explicitly instructed to double/quadruple the pixels and needs the
correspondingly higher pixel clock, whereas the sdvo adaptor seems to
do that itself and needs the unadjusted pixel clock. For the sdvo
encode side we already set the pixel mutliplier with a different
command (0x21).

This patch tries to fix this mess by:
- Keeping the output mode timing in the unadjusted plain mode, safe
  for the lvds case.
- Storing the input timing in the adjusted_mode with the adjusted
  pixel clock. This way we don't need to frob around with the core
  crtc mode set code.
- Fixing up the pixelclock when constructing the sdvo dtd timing
  struct. This is why the first hunk of the patch is an integral part
  of the series.
- Dropping the is_tv special case because input_dtd is equivalent to
  adjusted_mode after these changes. Follow-up patches clear this up
  further (by simply ripping out intel_sdvo->input_dtd because it's
  not needed).

v2: Extend commit message with an in-depth bug analysis.

Reported-and-Tested-by: Bernard Blackham <b-linuxgit@largestprime.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48157
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

hwmon: (fam15h_power) Fix pci_device_id array

pci_match_id() takes an *array* of IDs which must be properly zero-
terminated.

Reported-by: Ben Hutchings <ben@decadent.org.uk>
Cc: stable@vger.kernel.org # 3.0+: 00250ec hwmon: fam15h_power: fix bogus values
Cc: stable@vger.kernel.org # 3.0+
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Jean Delvare <khali@linux-fr.org>

hpwdt: Only BYTE reads/writes to WD Timer port 0x72

This patch is to correct the use of the iLO port 0x72 usage.
The port 0x72 is a byte size write/read and hpwdt is currently
writing a WORD.

Signed-off by: Thomas Mingarelli <thomas.mingarelli@hp.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>

perf: Fix perf_event_for_each() to use sibling

In perf_event_for_each() we call a function on an event, and then
iterate over the siblings of the event.

However we don't call the function on the siblings, we call it
repeatedly on the original event - it seems "obvious" that we should
be calling it with sibling as the argument.

It looks like this broke in commit 75f937f24bd9 ("Fix ctx->mutex
vs counter->mutex inversion").

The only effect of the bug is that the PERF_IOC_FLAG_GROUP parameter
to the ioctls doesn't work.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1334109253-31329-1-git-send-email-michael@ellerman.id.au
Signed-off-by: Ingo Molnar <mingo@kernel.org>

sched: Fix OOPS when build_sched_domains() percpu allocation fails

Under extreme memory used up situations, percpu allocation
might fail. We hit it when system goes to suspend-to-ram,
causing a kworker panic:

 EIP: [<c124411a>] build_sched_domains+0x23a/0xad0
 Kernel panic - not syncing: Fatal exception
 Pid: 3026, comm: kworker/u:3
 3.0.8-137473-gf42fbef #1

 Call Trace:
  [<c18cc4f2>] panic+0x66/0x16c
  [...]
  [<c1244c37>] partition_sched_domains+0x287/0x4b0
  [<c12a77be>] cpuset_update_active_cpus+0x1fe/0x210
  [<c123712d>] cpuset_cpu_inactive+0x1d/0x30
  [...]

With this fix applied build_sched_domains() will return -ENOMEM and
the suspend attempt fails.

Signed-off-by: he, bo <bo.he@intel.com>
Reviewed-by: Zhang, Yanmin <yanmin.zhang@intel.com>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <stable@kernel.org>
Link: http://lkml.kernel.org/r/1335355161.5892.17.camel@hebo
[ So, we fail to deallocate a CPU because we cannot allocate RAM :-/
  I don't like that kind of sad behavior but nevertheless it should
  not crash under high memory load. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>