linux-stable.git/include, branch v3.12.3

mfd: rtsx: Modify rts5249_optimize_phy

2013-12-04T19:06:13+00:00

commit 26b818511c6562ce372566c219a2ef1afea35fe6 upstream.

In some platforms, specially Thinkpad series, rts5249 won't be
initialized properly. So we need adjust some phy parameters to
improve the compatibility issue.

It is a little different between simulation and real chip. We have
no idea about which configuration is better before tape-out. We set
default settings according to simulation, but need to tune these
parameters after getting the real chip.

I can't explain every change in detail here. The below information is
just a rough description:

PHY_REG_REV: Disable internal clkreq_tx, enable rx_pwst
PHY_BPCR: No change, just turn the magic number to macro definitions
PHY_PCR: Change OOBS sensitivity, from 60mV to 90mV
PHY_RCR2: Control charge-pump current automatically
PHY_FLD4: Use TX cmu reference clock
PHY_RDR: Change RXDSEL from 30nF to 1.9nF
PHY_RCR1: Change the duration between adp_st and asserting cp_en from
0.32 us to 0.64us
PHY_FLD3: Adjust internal timers
PHY_TUNE: Fine tune the regulator12 output voltage

Signed-off-by: Wei WANG 
Signed-off-by: Lee Jones 
Cc: Chris Ball 
Signed-off-by: Greg Kroah-Hartman

tracing: Allow events to have NULL strings

2013-12-04T19:05:56+00:00

commit 4e58e54754dc1fec21c3a9e824bc108b05fdf46e upstream.

If an TRACE_EVENT() uses __assign_str() or __get_str on a NULL pointer
then the following oops will happen:

BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [] strlen+0x10/0x1a
*pde = 00000000 ^M
Oops: 0000 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.13.0-rc1-test+ #2
Hardware name:                  /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006^M
task: f5cde9f0 ti: f5e5e000 task.ti: f5e5e000
EIP: 0060:[] EFLAGS: 00210046 CPU: 1
EIP is at strlen+0x10/0x1a
EAX: 00000000 EBX: c2472da8 ECX: ffffffff EDX: c2472da8
ESI: c1c5e5fc EDI: 00000000 EBP: f5e5fe84 ESP: f5e5fe80
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 8005003b CR2: 00000000 CR3: 01f32000 CR4: 000007d0
Stack:
 f5f18b90 f5e5feb8 c10687a8 0759004f 00000005 00000005 00000005 00200046
 00000002 00000000 c1082a93 f56c7e28 c2472da8 c1082a93 f5e5fee4 c106bc61^M
 00000000 c1082a93 00000000 00000000 00000001 00200046 00200082 00000000
Call Trace:
 [] ftrace_raw_event_lock+0x39/0xc0
 [] ? ktime_get+0x29/0x69
 [] ? ktime_get+0x29/0x69
 [] lock_release+0x57/0x1a5
 [] ? ktime_get+0x29/0x69
 [] read_seqcount_begin.constprop.7+0x4d/0x75
 [] ? ktime_get+0x29/0x69^M
 [] ktime_get+0x29/0x69
 [] __tick_nohz_idle_enter+0x1e/0x426
 [] ? lock_release_holdtime.part.19+0x48/0x4d
 [] ? time_hardirqs_off+0xe/0x28
 [] ? trace_hardirqs_off_caller+0x3f/0xaf
 [] tick_nohz_idle_enter+0x59/0x62
 [] cpu_startup_entry+0x64/0x192
 [] start_secondary+0x277/0x27c
Code: 90 89 c6 89 d0 88 c4 ac 38 e0 74 09 84 c0 75 f7 be 01 00 00 00 89 f0 48 5e 5d c3 55 89 e5 57 66 66 66 66 90 83 c9 ff 89 c7 31 c0  ae f7 d1 8d 41 ff 5f 5d c3 55 89 e5 57 66 66 66 66 90 31 ff
EIP: [] strlen+0x10/0x1a SS:ESP 0068:f5e5fe80
CR2: 0000000000000000
---[ end trace 01bc47bf519ec1b2 ]---

New tracepoints have been added that have allowed for NULL pointers
being assigned to strings. To fix this, change the TRACE_EVENT() code
to check for NULL and if it is, it will assign "(null)" to it instead
(similar to what glibc printf does).

Reported-by: Shuah Khan 
Reported-by: Jovi Zhangwei 
Link: http://lkml.kernel.org/r/CAGdX0WFeEuy+DtpsJzyzn0343qEEjLX97+o1VREFkUEhndC+5Q@mail.gmail.com
Link: http://lkml.kernel.org/r/528D6972.9010702@samsung.com
Fixes: 9cbf117662e2 ("tracing/events: provide string with undefined size support")
Signed-off-by: Steven Rostedt 
Signed-off-by: Greg Kroah-Hartman

ACPI / hotplug: Fix conflicted PCI bridge notify handlers

2013-12-04T19:05:40+00:00

commit ca499fc87ed945094d952da0eb7eea7dbeb1feec upstream.

The PCI host bridge scan handler installs its own notify handler,
handle_hotplug_event_root(), by itself.  Nevertheless, the ACPI
hotplug framework also installs the common notify handler,
acpi_hotplug_notify_cb(), for PCI root bridges.  This causes
acpi_hotplug_notify_cb() to call _OST method with unsupported
error as hotplug.enabled is not set.

To address this issue, introduce hotplug.ignore flag, which
indicates that the scan handler installs its own notify handler by
itself.  The ACPI hotplug framework does not install the common
notify handler when this flag is set.

Signed-off-by: Toshi Kani 
[rjw: Changed the name of the new flag]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

mtd: map: fixed bug in 64-bit systems

2013-12-04T19:05:25+00:00

commit a4d62babf988fe5dfde24437fa135ef147bc7aa0 upstream.

Hardware:
	CPU: XLP832,the 64-bit OS
	NOR Flash:S29GL128S 128M
Software:
	Kernel:2.6.32.41
	Filesystem:JFFS2
When writing files, errors appear:
	Write len 182  but return retlen 180
	Write of 182 bytes at 0x072c815c failed. returned -5, retlen 180
	Write len 186  but return retlen 184
	Write of 186 bytes at 0x072caff4 failed. returned -5, retlen 184
These errors exist only in 64-bit systems,not in 32-bit systems. After analysis, we
found that the left shift operation is wrong in map_word_load_partial. For instance:
	unsigned char buf[3] ={0x9e,0x3a,0xea};
	map_bankwidth(map) is 4;
	for (i=0; i < 3; i++) {
		int bitpos;
		bitpos = (map_bankwidth(map)-1-i)*8;
		orig.x[0] &= ~(0xff << bitpos);
		orig.x[0] |= buf[i] << bitpos;
	}

The value of orig.x[0] is expected to be 0x9e3aeaff, but in this situation(64-bit
System) we'll get the wrong value of 0xffffffff9e3aeaff due to the 64-bit sign
extension:
buf[i] is defined as "unsigned char" and the left-shift operation will convert it
to the type of "signed int", so when left-shift buf[i] by 24 bits, the final result
will get the wrong value: 0xffffffff9e3aeaff.

If the left-shift bits are less than 24, then sign extension will not occur. Whereas
the bankwidth of the nor flash we used is 4, therefore this BUG emerges.

Signed-off-by: Pang Xunlei 
Signed-off-by: Zhang Yi 
Signed-off-by: Lu Zhongjun 
Signed-off-by: Brian Norris 
Signed-off-by: Greg Kroah-Hartman

ipc, msg: fix message length check for negative values

2013-12-04T19:05:22+00:00

commit 4e9b45a19241354daec281d7a785739829b52359 upstream.

On 64 bit systems the test for negative message sizes is bogus as the
size, which may be positive when evaluated as a long, will get truncated
to an int when passed to load_msg().  So a long might very well contain a
positive value but when truncated to an int it would become negative.

That in combination with a small negative value of msg_ctlmax (which will
be promoted to an unsigned type for the comparison against msgsz, making
it a big positive value and therefore make it pass the check) will lead to
two problems: 1/ The kmalloc() call in alloc_msg() will allocate a too
small buffer as the addition of alen is effectively a subtraction.  2/ The
copy_from_user() call in load_msg() will first overflow the buffer with
userland data and then, when the userland access generates an access
violation, the fixup handler copy_user_handle_tail() will try to fill the
remainder with zeros -- roughly 4GB.  That almost instantly results in a
system crash or reset.

  ,-[ Reproducer (needs to be run as root) ]--
  | #include 
  | #include 
  | #include 
  | #include 
  |
  | int main(void) {
  |     long msg = 1;
  |     int fd;
  |
  |     fd = open("/proc/sys/kernel/msgmax", O_WRONLY);
  |     write(fd, "-1", 2);
  |     close(fd);
  |
  |     msgsnd(0, &msg, 0xfffffff0, IPC_NOWAIT);
  |
  |     return 0;
  | }
  '---

Fix the issue by preventing msgsz from getting truncated by consistently
using size_t for the message length.  This way the size checks in
do_msgsnd() could still be passed with a negative value for msg_ctlmax but
we would fail on the buffer allocation in that case and error out.

Also change the type of m_ts from int to size_t to avoid similar nastiness
in other code paths -- it is used in similar constructs, i.e.  signed vs.
unsigned checks.  It should never become negative under normal
circumstances, though.

Setting msg_ctlmax to a negative value is an odd configuration and should
be prevented.  As that might break existing userland, it will be handled
in a separate commit so it could easily be reverted and reworked without
reintroducing the above described bug.

Hardening mechanisms for user copy operations would have catched that bug
early -- e.g.  checking slab object sizes on user copy operations as the
usercopy feature of the PaX patch does.  Or, for that matter, detect the
long vs.  int sign change due to truncation, as the size overflow plugin
of the very same patch does.

[akpm@linux-foundation.org: fix i386 min() warnings]
Signed-off-by: Mathias Krause 
Cc: Pax Team 
Cc: Davidlohr Bueso 
Cc: Brad Spengler 
Cc: Manfred Spraul 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

rbtree: fix rbtree_postorder_for_each_entry_safe() iterator

2013-12-04T19:05:10+00:00

commit 1310a5a99d900ee30b9f171146406bde0c6c2bd4 upstream.

The iterator rbtree_postorder_for_each_entry_safe() relies on pointer
underflow behavior when testing for loop termination.  In particular it
expects that

  &rb_entry(NULL, type, field)->field

is NULL.  But the result of this expression is not defined by a C standard
and some gcc versions (e.g.  4.3.4) assume the above expression can never
be equal to NULL.  The net result is an oops because the iteration is not
properly terminated.

Fix the problem by modifying the iterator to avoid pointer underflows.

Signed-off-by: Jan Kara 
Signed-off-by: Cody P Schafer 
Cc: Michel Lespinasse 
Cc: "David S. Miller" 
Cc: Adrian Hunter 
Cc: Artem Bityutskiy 
Cc: David Woodhouse 
Cc: Jozsef Kadlecsik 
Cc: Pablo Neira Ayuso 
Cc: Patrick McHardy 
Cc: Paul Mundt 
Cc: Theodore Ts'o 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

usb: Don't enable USB 2.0 Link PM by default.

2013-11-29T19:28:09+00:00

commit de68bab4fa96014cfaa6fcbcdb9750e32969fb86 upstream.

How it's supposed to work:
--------------------------

USB 2.0 Link PM is a lower power state that some newer USB 2.0 devices
support.  USB 3.0 devices certified by the USB-IF are required to
support it if they are plugged into a USB 2.0 only port, or a USB 2.0
cable is used.  USB 2.0 Link PM requires both a USB device and a host
controller that supports USB 2.0 hardware-enabled LPM.

USB 2.0 Link PM is designed to be enabled once by software, and the host
hardware handles transitions to the L1 state automatically.  The premise
of USB 2.0 Link PM is to be able to put the device into a lower power
link state when the bus is idle or the device NAKs USB IN transfers for
a specified amount of time.

...but hardware is broken:
--------------------------

It turns out many USB 3.0 devices claim to support USB 2.0 Link PM (by
setting the LPM bit in their USB 2.0 BOS descriptor), but they don't
actually implement it correctly.  This manifests as the USB device
refusing to respond to transfers when it is plugged into a USB 2.0 only
port under the Haswell-ULT/Lynx Point LP xHCI host.

These devices pass the xHCI driver's simple test to enable USB 2.0 Link
PM, wait for the port to enter L1, and then bring it back into L0.  They
only start to break when L1 entry is interleaved with transfers.

Some devices then fail to respond to the next control transfer (usually
a Set Configuration).  This results in devices never enumerating.

Other mass storage devices (such as a later model Western Digital My
Passport USB 3.0 hard drive) respond fine to going into L1 between
control transfers.  They ACK the entry, come out of L1 when the host
needs to send a control transfer, and respond properly to those control
transfers.  However, when the first READ10 SCSI command is sent, the
device NAKs the data phase while it's reading from the spinning disk.
Eventually, the host requests to put the link into L1, and the device
ACKs that request.  Then it never responds to the data phase of the
READ10 command.  This results in not being able to read from the drive.

Some mass storage devices (like the Corsair Survivor USB 3.0 flash
drive) are well behaved.  They ACK the entry into L1 during control
transfers, and when SCSI commands start coming in, they NAK the requests
to go into L1, because they need to be at full power.

Not all USB 3.0 devices advertise USB 2.0 link PM support.  My Point
Grey USB 3.0 webcam advertises itself as a USB 2.1 device, but doesn't
have a USB 2.0 BOS descriptor, so we don't enable USB 2.0 Link PM.  I
suspect that means the device isn't certified.

What do we do about it?
-----------------------

There's really no good way for the kernel to test these devices.
Therefore, the kernel needs to disable USB 2.0 Link PM by default, and
distros will have to enable it by writing 1 to the sysfs file
/sys/bus/usb/devices/../power/usb2_hardware_lpm.  Rip out the xHCI Link
PM test, since it's not sufficient to detect these buggy devices, and
don't automatically enable LPM after the device is addressed.

This patch should be backported to kernels as old as 3.11, that
contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci:
add USB2 Link power management BESL support".  Without this fix, some
USB 3.0 devices will not enumerate or work properly under USB 2.0 ports
on Haswell-ULT systems.

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

NFSv4.2: Fix a mismatch between Linux labeled NFS and the NFSv4.2 spec

2013-11-29T19:28:02+00:00

commit f3f5a0f8cc40b942f4c0ae117df82eeb65f07d4d upstream.

In the spec, the security label attribute id is '80', which means that
it should be bit number 80-64 == 16 in the 3rd word of the bitmap.

Fixes: 4488cc96c581: NFS: Add NFSv4.2 protocol constants
Cc: J. Bruce Fields 
Cc: Steve Dickson 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

ALSA: compress: fix drain calls blocking other compress functions (v6)

2013-11-29T19:27:58+00:00

commit f44f2a5417b2968a8724b352cc0b2545a6bcb1f4 upstream.

The drain and drain_notify callback were blocked by low level driver
until the draining was complete. Due to this being invoked with big
fat mutex held, others ops like reading timestamp, calling pause, drop
were blocked.

So to fix this we add a new snd_compr_drain_notify() API. This would
be required to be invoked by low level driver when drain or partial
drain has been completed by the DSP. Thus we make the drain and
partial_drain callback as non blocking and driver returns immediately
after notifying DSP.  The waiting is done while releasing the lock so
that other ops can go ahead.

[ The commit 917f4b5cba78 was wrongly applied from the preliminary
  patch.  This commit corrects to the final version.
  Sorry for inconvenience!  -- tiwai ]

Signed-off-by: Vinod Koul 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: compress: fix drain calls blocking other compress functions

2013-11-29T19:27:58+00:00

commit 917f4b5cba78980a527098a910d94139d3e82c8d upstream.

The drain and drain_notify callback were blocked by low level driver untill the
draining was complete. Due to this being invoked with big fat mutex held, others
ops like reading timestamp, calling pause, drop were blocked.

So to fix this we add a new snd_compr_drain_notify() API. This would be required
to be invoked by low level driver when drain or partial drain has been completed
by the DSP. Thus we make the drain and partial_drain callback as non blocking
and driver returns immediately after notifying DSP.
The waiting is done while relasing the lock so that other ops can go ahead.

Signed-off-by: Vinod Koul 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman