linux-stable.git/include, branch linux-3.7.y

ALSA: usb: Fix Processing Unit Descriptor parsers

2013-02-27T17:21:10+00:00

commit b531f81b0d70ffbe8d70500512483227cc532608 upstream.

Commit 99fc86450c439039d2ef88d06b222fd51a779176 "ALSA: usb-mixer:
parse descriptors with structs" introduced a set of useful parsers
for descriptors. Unfortunately the parses for the Processing Unit
Descriptor came with a very subtle bug...

Functions uac_processing_unit_iProcessing() and
uac_processing_unit_specific() were indexing the baSourceID array
forgetting the fields before the iProcessing and process-specific
descriptors.

The problem was observed with Sound Blaster Extigy mixer,
where nNrModes in Up/Down-mix Processing Unit Descriptor
was accessed at offset 10 of the descriptor (value 0)
instead of offset 15 (value 7). In result the resulting
control had interesting limit values:

Simple mixer control 'Channel Routing Mode Select',0
  Capabilities: volume volume-joined penum
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - -1
  Mono: -1 [100%]

Fixed by starting from the bmControls, which was calculated
correctly, instead of baSourceID.

Now the mentioned control is fine:

Simple mixer control 'Channel Routing Mode Select',0
  Capabilities: volume volume-joined penum
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 6
  Mono: 0 [0%]

Signed-off-by: Pawel Moll 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

serial_core: Fix type definition for PORT_BRCM_TRUMANAGE.

2013-02-27T17:21:07+00:00

commit 85f024401bf80746ae08b7fd5809a9b16accf0b1 upstream.

It was mistakenly defined to be 24 instead of the next higher number 25.

Reported-by: Alexander Shishkin 
Cc: Stephen Hurd 
Signed-off-by: Michael Chan 
Signed-off-by: Greg Kroah-Hartman

ipv4: Add a socket release callback for datagram sockets

2013-02-14T18:48:32+00:00

[ Upstream commit 8141ed9fcedb278f4a3a78680591bef1e55f75fb ]

This implements a socket release callback function to check
if the socket cached route got invalid during the time
we owned the socket. The function is used from udp, raw
and ping sockets.

Signed-off-by: Steffen Klassert 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net, wireless: overwrite default_ethtool_ops

2013-02-14T18:48:02+00:00

[ Upstream commit d07d7507bfb4e23735c9b83e397c43e1e8a173e8 ]

Since:

commit 2c60db037034d27f8c636403355d52872da92f81
Author: Eric Dumazet 
Date:   Sun Sep 16 09:17:26 2012 +0000

    net: provide a default dev->ethtool_ops

wireless core does not correctly assign ethtool_ops.

After alloc_netdev*() call, some cfg80211 drivers provide they own
ethtool_ops, but some do not. For them, wireless core provide generic
cfg80211_ethtool_ops, which is assigned in NETDEV_REGISTER notify call:

        if (!dev->ethtool_ops)
                dev->ethtool_ops = &cfg80211_ethtool_ops;

But after Eric's commit, dev->ethtool_ops is no longer NULL (on cfg80211
drivers without custom ethtool_ops), but points to &default_ethtool_ops.

In order to fix the problem, provide function which will overwrite
default_ethtool_ops and use it by wireless core.

Signed-off-by: Stanislaw Gruszka 
Acked-by: Johannes Berg 
Acked-by: Ben Hutchings 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

usb: Using correct way to clear usb3.0 device's remote wakeup feature.

2013-02-11T17:04:45+00:00

commit 54a3ac0c9e5b7213daa358ce74d154352657353a upstream.

Usb3.0 device defines function remote wakeup which is only for interface
recipient rather than device recipient. This is different with usb2.0 device's
remote wakeup feature which is defined for device recipient. According usb3.0
spec 9.4.5, the function remote wakeup can be modified by the SetFeature()
requests using the FUNCTION_SUSPEND feature selector. This patch is to use
correct way to disable usb3.0 device's function remote wakeup after suspend
error and resuming.

This should be backported to kernels as old as 3.4, that contain the
commit 623bef9e03a60adc623b09673297ca7a1cdfb367 "USB/xhci: Enable remote
wakeup for USB3 devices."

Signed-off-by: Lan Tianyu 
Signed-off-by: Sarah Sharp 
Signed-off-by: Greg Kroah-Hartman

netfilter: nf_conntrack: fix BUG_ON while removing nf_conntrack with netns

2013-02-04T00:27:08+00:00

commit 1e47ee8367babe6a5e8adf44a714c7086657b87e upstream.

canqun zhang reported that we're hitting BUG_ON in the
nf_conntrack_destroy path when calling kfree_skb while
rmmod'ing the nf_conntrack module.

Currently, the nf_ct_destroy hook is being set to NULL in the
destroy path of conntrack.init_net. However, this is a problem
since init_net may be destroyed before any other existing netns
(we cannot assume any specific ordering while releasing existing
netns according to what I read in recent emails).

Thanks to Gao feng for initial patch to address this issue.

Reported-by: canqun zhang 
Acked-by: Gao feng 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

netfilter: xt_CT: recover NOTRACK target support

2013-02-04T00:27:07+00:00

commit 10db9069eb5c60195170a4119bdbcbce69a4945f upstream.

Florian Westphal reported that the removal of the NOTRACK target
(9655050 netfilter: remove xt_NOTRACK) is breaking some existing
setups.

That removal was scheduled for removal since long time ago as
described in Documentation/feature-removal-schedule.txt

What:  xt_NOTRACK
Files: net/netfilter/xt_NOTRACK.c
When:  April 2011
Why:   Superseded by xt_CT

Still, people may have not notice / may have decided to stick to an
old iptables version. I agree with him in that some more conservative
approach by spotting some printk to warn users for some time is less
agressive.

Current iptables 1.4.16.3 already contains the aliasing support
that makes it point to the CT target, so upgrading would fix it.
Still, the policy so far has been to avoid pushing our users to
upgrade.

As a solution, this patch recovers the NOTRACK target inside the CT
target and it now spots a warning.

Reported-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

efi: Make 'efi_enabled' a function to query EFI facilities

2013-02-04T00:27:05+00:00

commit 83e68189745ad931c2afd45d8ee3303929233e7f upstream.

Originally 'efi_enabled' indicated whether a kernel was booted from
EFI firmware. Over time its semantics have changed, and it now
indicates whether or not we are booted on an EFI machine with
bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.

The immediate motivation for this patch is the bug report at,

    https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557

which details how running a platform driver on an EFI machine that is
designed to run under BIOS can cause the machine to become
bricked. Also, the following report,

    https://bugzilla.kernel.org/show_bug.cgi?id=47121

details how running said driver can also cause Machine Check
Exceptions. Drivers need a new means of detecting whether they're
running on an EFI machine, as sadly the expression,

    if (!efi_enabled)

hasn't been a sufficient condition for quite some time.

Users actually want to query 'efi_enabled' for different reasons -
what they really want access to is the list of available EFI
facilities.

For instance, the x86 reboot code needs to know whether it can invoke
the ResetSystem() function provided by the EFI runtime services, while
the ACPI OSL code wants to know whether the EFI config tables were
mapped successfully. There are also checks in some of the platform
driver code to simply see if they're running on an EFI machine (which
would make it a bad idea to do BIOS-y things).

This patch is a prereq for the samsung-laptop fix patch.

Signed-off-by: Matt Fleming 
Cc: David Airlie 
Cc: Corentin Chary 
Cc: Matthew Garrett 
Cc: Dave Jiang 
Cc: Olof Johansson 
Cc: Peter Jones 
Cc: Colin Ian King 
Cc: Steve Langasek 
Cc: Tony Luck 
Cc: Konrad Rzeszutek Wilk 
Cc: Rafael J. Wysocki 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

module: add new state MODULE_STATE_UNFORMED.

2013-01-28T04:49:02+00:00

commit 0d21b0e3477395e7ff2acc269f15df6e6a8d356d upstream.

You should never look at such a module, so it's excised from all paths
which traverse the modules list.

We add the state at the end, to avoid gratuitous ABI break (ksplice).

Signed-off-by: Rusty Russell 
Signed-off-by: Greg Kroah-Hartman

ptrace: introduce signal_wake_up_state() and ptrace_signal_wake_up()

2013-01-28T04:49:00+00:00

commit 910ffdb18a6408e14febbb6e4b6840fd2c928c82 upstream.

Cleanup and preparation for the next change.

signal_wake_up(resume => true) is overused. None of ptrace/jctl callers
actually want to wakeup a TASK_WAKEKILL task, but they can't specify the
necessary mask.

Turn signal_wake_up() into signal_wake_up_state(state), reintroduce
signal_wake_up() as a trivial helper, and add ptrace_signal_wake_up()
which adds __TASK_TRACED.

This way ptrace_signal_wake_up() can work "inside" ptrace_request()
even if the tracee doesn't have the TASK_WAKEKILL bit set.

Signed-off-by: Oleg Nesterov 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman