linux.git, branch v3.11.8

Linux 3.11.8

2013-11-13T03:08:24+00:00

NTB: Correct debugfs to work with more than 1 NTB Device

2013-11-13T03:08:12+00:00

commit 1517a3f21a1dd321f16bcf44204bddff9d21abd0 upstream.

Debugfs was setup in NTB to only have a single debugfs directory.  This
resulted in the leaking of debugfs directories and files when multiple
NTB devices were present, due to each device stomping on the variables
containing the previous device's values (thus preventing them from being
freed on cleanup).  Correct this by creating a secondary directory of
the PCI BDF for each device present, and nesting the previously existing
information in those directories.

Signed-off-by: Jon Mason 
Signed-off-by: Greg Kroah-Hartman

NTB: Correct USD/DSD Identification

2013-11-13T03:08:12+00:00

commit b6750cfe0710a14fd147ba27fddbecae8ba88c77 upstream.

Due to ambiguous documentation, the USD/DSD identification is backward
when compared to the setting in BIOS.  Correct the bits to match the
BIOS setting.

Signed-off-by: Jon Mason 
Signed-off-by: Greg Kroah-Hartman

NTB: Correct Number of Scratch Pad Registers

2013-11-13T03:08:12+00:00

commit 87034511519815259e37336f52edf06d114d43b6 upstream.

The NTB Xeon hardware has 16 scratch pad registers and 16 back-to-back
scratch pad registers.  Correct the #define to represent this and update
the variable names to reflect their usage.

Signed-off-by: Jon Mason 
Signed-off-by: Greg Kroah-Hartman

NTB: Add Error Handling in ntb_device_setup

2013-11-13T03:08:12+00:00

commit 3b12a0d15bd1559e72ad21d9d807fd2a6706f0ab upstream.

If an error is encountered in ntb_device_setup, it is possible that the
spci_cmd isn't populated.  Writes to the offset can result in a NULL
pointer dereference.  This issue is easily encountered by running in
NTB-RP mode, as it currently is not supported and will generate an
error.  To get around this issue, return if an error is encountered
prior to attempting to write to the spci_cmd offset.

Signed-off-by: Jon Mason 
Signed-off-by: Greg Kroah-Hartman

seq_file: always update file->f_pos in seq_lseek()

2013-11-13T03:08:12+00:00

commit 05e16745c0c471bba313961b605b6da3b21a853d upstream.

This issue was first pointed out by Jiaxing Wang several months ago, but no
further comments:
https://lkml.org/lkml/2013/6/29/41

As we know pread() does not change f_pos, so after pread(), file->f_pos
and m->read_pos become different. And seq_lseek() does not update file->f_pos
if offset equals to m->read_pos, so after pread() and seq_lseek()(lseek to
m->read_pos), then a subsequent read may read from a wrong position, the
following program produces the problem:

    char str1[32] = { 0 };
    char str2[32] = { 0 };
    int poffset = 10;
    int count = 20;

    /*open any seq file*/
    int fd = open("/proc/modules", O_RDONLY);

    pread(fd, str1, count, poffset);
    printf("pread:%s\n", str1);

    /*seek to where m->read_pos is*/
    lseek(fd, poffset+count, SEEK_SET);

    /*supposed to read from poffset+count, but this read from position 0*/
    read(fd, str2, count);
    printf("read:%s\n", str2);

out put:
pread:
 ck_netbios_ns 12665
read:
 nf_conntrack_netbios

/proc/modules:
nf_conntrack_netbios_ns 12665 0 - Live 0xffffffffa038b000
nf_conntrack_broadcast 12589 1 nf_conntrack_netbios_ns, Live 0xffffffffa0386000

So we always update file->f_pos to offset in seq_lseek() to fix this issue.

Signed-off-by: Jiaxing Wang 
Signed-off-by: Gu Zheng 
Signed-off-by: Al Viro 
Cc: Jonghwan Choi 
Signed-off-by: Greg Kroah-Hartman

mutex: Avoid gcc version dependent __builtin_constant_p() usage

2013-11-13T03:08:12+00:00

commit b0267507dfd0187fb7840a0ec461a510a7f041c5 upstream.

Commit 040a0a37 ("mutex: Add support for wound/wait style locks")
used "!__builtin_constant_p(p == NULL)" but gcc 3.x cannot
handle such expression correctly, leading to boot failure when
built with CONFIG_DEBUG_MUTEXES=y.

Fix it by explicitly passing a bool which tells whether p != NULL
or not.

[ PeterZ: This is a sad patch, but provided it actually generates
          similar code I suppose its the best we can do bar whole
	  sale deprecating gcc-3. ]

Signed-off-by: Tetsuo Handa 
Acked-by: Peter Zijlstra 
Acked-by: Maarten Lankhorst 
Cc: peterz@infradead.org
Cc: imirkin@alum.mit.edu
Cc: daniel.vetter@ffwll.ch
Cc: robdclark@gmail.com
Cc: Linus Torvalds 
Cc: Andrew Morton 
Link: http://lkml.kernel.org/r/201310171945.AGB17114.FSQVtHOJFOOFML@I-love.SAKURA.ne.jp
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb

2013-11-13T03:08:12+00:00

commit 1fbc0d789d12fec313c91912fc11733fdfbab863 upstream.

Originally I've thought that this is leftover hw state dirt from the
BIOS. But after way too much helpless flailing around on my part I've
noticed that the actual bug is when we change the state of an already
active pipe.

For example when we change the fdi lines from 2 to 3 without switching
off outputs in-between we'll never see the crucial on->off transition
in the ->modeset_global_resources hook the current logic relies on.

Patch version 2 got this right by instead also checking whether the
pipe is indeed active. But that in turn broke things when pipes have
been turned off through dpms since the bifurcate enabling is done in
the ->crtc_mode_set callback.

To address this issues discussed with Ville in the patch review move
the setting of the bifurcate bit into the ->crtc_enable hook. That way
we won't wreak havoc with this state when userspace puts all other
outputs into dpms off state. This also moves us forward with our
overall goal to unify the modeset and dpms on paths (which we need to
have to allow runtime pm in the dpms off state).

Unfortunately this requires us to move the bifurcate helpers around a
bit.

Also update the commit message, I've misanalyzed the bug rather badly.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70507
Tested-by: Jan-Michael Brummer 
Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: No LVDS hardware on Intel D410PT and D425KT

2013-11-13T03:08:11+00:00

commit 645378d85ee524e429aa4cf52806047b56cdc596 upstream.

The Intel D410PT(LW) and D425KT Mini-ITX desktop boards both show up as
having LVDS but the hardware is not populated. This patch adds them to
the list of such systems. Patch is against 3.11.4

v2: Patch revised to match the D425KT exactly as the D425KTW does have
LVDS.  According to Intel's documentation, the D410PTL and D410PLTW
don't.

Signed-off-by: Rob Pearce 
[danvet: Pimp commit message to my liking and add cc: stable.]
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Add support for pipe_bpp readout

2013-11-13T03:08:11+00:00

commit 4f56d12ebb28fceac4c6e60c8993fbfc122e1399 upstream.

On CTG+ read out the pipe bpp setting from hardware and fill it into
pipe config. Also check it appropriately.

v2: Don't do the pipe_bpp extraction inside the PCH only code block on
    ILK+.
    Avoid the PIPECONF read as we already have read it for the
    PIPECONF_EANBLE check.

Note: This is already in drm-intel-next-queued as
commit 42571aefafb1d330ef84eb29418832f72e7dfb4c
Author: Ville Syrjälä 
Date:   Fri Sep 6 23:29:00 2013 +0300

    drm/i915: Add support for pipe_bpp readout

but is needed for the following bugfix.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Jani Nikula 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman