linux-stable.git/drivers, branch v3.10.58

USB: cp210x: add support for Seluxit USB dongle

2014-10-15T06:31:58+00:00

commit dee80ad12d2b1b304286a707fde7ab05d1fc7bab upstream.

Added the Seluxit ApS USB Serial Dongle to cp210x driver.

Signed-off-by: Andreas Bomholtz 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: serial: cp210x: added Ketra N1 wireless interface support

2014-10-15T06:31:57+00:00

commit bfc2d7dfdd761ae3beccdb26abebe03cef042f46 upstream.

Added support for Ketra N1 wireless interface, which uses the
Silicon Labs' CP2104 USB to UART bridge with customized PID 8946.

Signed-off-by: Joe Savage 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

USB: Add device quirk for ASUS T100 Base Station keyboard

2014-10-15T06:31:57+00:00

commit ddbe1fca0bcb87ca8c199ea873a456ca8a948567 upstream.

This full-speed USB device generates spurious remote wakeup event
as soon as USB_DEVICE_REMOTE_WAKEUP feature is set. As the result,
Linux can't enter system suspend and S0ix power saving modes once
this keyboard is used.

This patch tries to introduce USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk.
With this quirk set, wakeup capability will be ignored during
device configure.

This patch could be back-ported to kernels as old as 2.6.39.

Signed-off-by: Lu Baolu 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

hyperv: Fix a bug in netvsc_start_xmit()

2014-10-15T06:31:57+00:00

[ Upstream commit dedb845ded56ded1c62f5398a94ffa8615d4592d ]

After the packet is successfully sent, we should not touch the skb
as it may have been freed. This patch is based on the work done by
Long Li .

In this version of the patch I have fixed issues pointed out by David.
David, please queue this up for stable.

Signed-off-by: K. Y. Srinivasan 
Tested-by: Long Li 
Tested-by: Sitsofe Wheeler 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tg3: Allow for recieve of full-size 8021AD frames

2014-10-15T06:31:57+00:00

[ Upstream commit 7d3083ee36b51e425b6abd76778a2046906b0fd3 ]

When receiving a vlan-tagged frame that still contains
a vlan header, the length of the packet will be greater
then MTU+ETH_HLEN since it will account of the extra
vlan header.  TG3 checks this for the case for 802.1Q,
but not for 802.1ad.  As a result, full sized 802.1ad
frames get dropped by the card.

Add a check for 802.1ad protocol when receving full
sized frames.

Suggested-by: Prashant Sreedharan 
CC: Prashant Sreedharan 
CC: Michael Chan 
Signed-off-by: Vladislav Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tg3: Work around HW/FW limitations with vlan encapsulated frames

2014-10-15T06:31:57+00:00

[ Upstream commit 476c18850c6cbaa3f2bb661ae9710645081563b9 ]

TG3 appears to have an issue performing TSO and checksum offloading
correclty when the frame has been vlan encapsulated (non-accelrated).
In these cases, tcp checksum is not correctly updated.

This patch attempts to work around this issue.  After the patch,
802.1ad vlans start working correctly over tg3 devices.

CC: Prashant Sreedharan 
CC: Michael Chan 
Signed-off-by: Vladislav Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

myri10ge: check for DMA mapping errors

2014-10-15T06:31:56+00:00

[ Upstream commit 10545937e866ccdbb7ab583031dbdcc6b14e4eb4 ]

On IOMMU systems DMA mapping can fail, we need to check for
that possibility.

Signed-off-by: Stanislaw Gruszka 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

cpufreq: ondemand: Change the calculation of target frequency

2014-10-09T19:18:43+00:00

commit dfa5bb622555d9da0df21b50f46ebdeef390041b upstream.

The ondemand governor calculates load in terms of frequency and
increases it only if load_freq is greater than up_threshold
multiplied by the current or average frequency.  This appears to
produce oscillations of frequency between min and max because,
for example, a relatively small load can easily saturate minimum
frequency and lead the CPU to the max.  Then, it will decrease
back to the min due to small load_freq.

Change the calculation method of load and target frequency on the
basis of the following two observations:

 - Load computation should not depend on the current or average
   measured frequency.  For example, absolute load of 80% at 100MHz
   is not necessarily equivalent to 8% at 1000MHz in the next
   sampling interval.

 - It should be possible to increase the target frequency to any
   value present in the frequency table proportional to the absolute
   load, rather than to the max only, so that:

   Target frequency = C * load

   where we take C = policy->cpuinfo.max_freq / 100.

Tested on Intel i7-3770 CPU @ 3.40GHz and on Quad core 1500MHz Krait.
Phoronix benchmark of Linux Kernel Compilation 3.1 test shows an
increase ~1.5% in performance. cpufreq_stats (time_in_state) shows
that middle frequencies are used more, with this patch.  Highest
and lowest frequencies were used less by ~9%.

[rjw: We have run multiple other tests on kernels with this
 change applied and in the vast majority of cases it turns out
 that the resulting performance improvement also leads to reduced
 consumption of energy.  The change is additionally justified by
 the overall simplification of the code in question.]

Signed-off-by: Stratos Karafotis 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Cc: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

cpufreq: Fix wrong time unit conversion

2014-10-09T19:18:43+00:00

commit a857c0b9e24e39fe5be82451b65377795f9538d8 upstream.

The time spent by a CPU under a given frequency is stored in jiffies unit
in the cpu var cpufreq_stats_table->time_in_state[i], i being the index of
the frequency.

This is what is displayed in the following file on the right column:

     cat /sys/devices/system/cpu/cpuX/cpufreq/stats/time_in_state
     2301000 19835820
     2300000 3172
     [...]

Now cpufreq converts this jiffies unit delta to clock_t before returning it
to the user as in the above file. And that conversion is achieved using the API
cputime64_to_clock_t().

Although it accidentally works on traditional tick based cputime accounting, where
cputime_t maps directly to jiffies, it doesn't work with other types of cputime
accounting such as CONFIG_VIRT_CPU_ACCOUNTING_* where cputime_t can map to nsecs
or any granularity preffered by the architecture.

For example we get a buggy zero delta on full dyntick configurations:

     cat /sys/devices/system/cpu/cpuX/cpufreq/stats/time_in_state
     2301000 0
     2300000 0
     [...]

Fix this with using the proper jiffies_64_t to clock_t conversion.

Reported-and-tested-by: Carsten Emde 
Signed-off-by: Andreas Schwab 
Signed-off-by: Frederic Weisbecker 
Acked-by: Paul E. McKenney 
Signed-off-by: Rafael J. Wysocki 
Cc: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

drbd: fix regression 'out of mem, failed to invoke fence-peer helper'

2014-10-09T19:18:43+00:00

commit bbc1c5e8ad6dfebf9d13b8a4ccdf66c92913eac9 upstream.

Since linux kernel 3.13, kthread_run() internally uses
wait_for_completion_killable().  We sometimes may use kthread_run()
while we still have a signal pending, which we used to kick our threads
out of potentially blocking network functions, causing kthread_run() to
mistake that as a new fatal signal and fail.

Fix: flush_signals() before kthread_run().

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman