linux.git, branch v4.4.54

Linux 4.4.54

2017-03-15T01:57:56+00:00

drivers: hv: Turn off write permission on the hypercall page

2017-03-15T01:57:15+00:00

commit 372b1e91343e657a7cc5e2e2bcecd5140ac28119 upstream.

The hypercall page only needs to be executable but currently it is setup to
be writable as well. Fix the issue.

Signed-off-by: K. Y. Srinivasan 
Acked-by: Kees Cook 
Reported-by: Stephen Hemminger 
Tested-by: Stephen Hemminger 
Signed-off-by: Greg Kroah-Hartman

fat: fix using uninitialized fields of fat_inode/fsinfo_inode

2017-03-15T01:57:15+00:00

commit c0d0e351285161a515396b7b1ee53ec9ffd97e3c upstream.

Recently fallocate patch was merged and it uses
MSDOS_I(inode)->mmu_private at fat_evict_inode().  However,
fat_inode/fsinfo_inode that was introduced in past didn't initialize
MSDOS_I(inode) properly.

With those combinations, it became the cause of accessing random entry
in FAT area.

Link: http://lkml.kernel.org/r/87pohrj4i8.fsf@mail.parknet.co.jp
Signed-off-by: OGAWA Hirofumi 
Reported-by: Moreno Bartalucci 
Tested-by: Moreno Bartalucci 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

libceph: use BUG() instead of BUG_ON(1)

2017-03-15T01:57:15+00:00

commit d24cdcd3e40a6825135498e11c20c7976b9bf545 upstream.

I ran into this compile warning, which is the result of BUG_ON(1)
not always leading to the compiler treating the code path as
unreachable:

    include/linux/ceph/osdmap.h: In function 'ceph_can_shift_osds':
    include/linux/ceph/osdmap.h:62:1: error: control reaches end of non-void function [-Werror=return-type]

Using BUG() here avoids the warning.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Ilya Dryomov 
Cc: Heinrich Schuchardt 
Signed-off-by: Greg Kroah-Hartman

drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating

2017-03-15T01:57:15+00:00

commit bb98e72adaf9d19719aba35f802d4836f5d5176c upstream.

On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
Once the i915 driver has successfully loaded, the panel can be disabled /
enabled without hitting this issue.

The getting stuck is caused by vlv_init_display_clock_gating() clearing
the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from
chv_pipe_power_well_ops.enable() on driver load, while a pipe is enabled
driving the DSI LCD by the BIOS.

Clearing this bit while DSI is in use is a known issue and
intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it
as appropriate.

This commit modifies vlv_init_display_clock_gating() to leave the
DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing the pipe getting stuck.

Changes in v2:
-Replace PIPE-A with "a pipe" or "the pipe" in the commit msg and
comment

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97330
Signed-off-by: Hans de Goede 
Reviewed-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/20161202142904.25613-1-hdegoede@redhat.com
Signed-off-by: Ville Syrjälä 
(cherry picked from commit 721d484563e1a51ada760089c490cbc47e909756)
Signed-off-by: Jani Nikula 
Signed-off-by: River Zhou 
Signed-off-by: Greg Kroah-Hartman

fakelb: fix schedule while atomic

2017-03-15T01:57:15+00:00

commit bdca1fd9a6df745857e23c6056494b7fe062b4e6 upstream.

This patch changes the spinlock to mutex for the available fakelb phy
list. When holding the spinlock the ieee802154_unregister_hw is called
which holding the rtnl_mutex, in that case we get a "BUG: sleeping function
called from invalid context" error. We simple change the spinlock to
mutex which allows to hold the rtnl lock there.

Signed-off-by: Alexander Aring 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

drm/atomic: fix an error code in mode_fixup()

2017-03-15T01:57:15+00:00

commit f9ad86e42d0303eeb8e0d41bb208153022ebd9d2 upstream.

Having "ret" be a bool type works for everything except
ret = funcs->atomic_check().  The other functions all return zero on
error but ->atomic_check() returns negative error codes.  We want to
propagate the error code but instead we return 1.

I found this bug with static analysis and I don't know if it affects
run time.

Fixes: 4cd4df8080a3 ("drm/atomic: Add ->atomic_check() to encoder helpers")
Signed-off-by: Dan Carpenter 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20170207234601.GA23981@mwanda
Signed-off-by: Greg Kroah-Hartman

drm/ttm: Make sure BOs being swapped out are cacheable

2017-03-15T01:57:15+00:00

commit 239ac65fa5ffab71adf66e642750f940e7241d99 upstream.

The current caching state may not be tt_cached, even though the
placement contains TTM_PL_FLAG_CACHED, because placement can contain
multiple caching flags. Trying to swap out such a BO would trip up the

	BUG_ON(ttm->caching_state != tt_cached);

in ttm_tt_swapout.

Signed-off-by: Michel Dänzer 
Reviewed-by: Thomas Hellstrom 
Reviewed-by: Christian König .
Reviewed-by: Sinclair Yeh 
Signed-off-by: Christian König 
Signed-off-by: Greg Kroah-Hartman

drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058

2017-03-15T01:57:15+00:00

commit 36fc579761b50784b63dafd0f2e796b659e0f5ee upstream.

Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all
1.1.

When a sink that supports deep color is connected to the output, the
receiver will send EDIDs that advertise this capability, even if it
isn't possible with HDMI versions earlier than 1.3.

Currently the kernel is assuming that deep color is possible and the
sink displays an error.

This quirk will make sure that deep color isn't used with this
particular receiver.

Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
Signed-off-by: Tomeu Vizoso 
Link: http://patchwork.freedesktop.org/patch/msgid/20170220152545.13153-1-tomeu.vizoso@collabora.com
Cc: Matt Horan 
Tested-by: Matt Horan 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99869
Reviewed-by: Ville Syrjälä 
Signed-off-by: Ville Syrjälä 
Signed-off-by: Greg Kroah-Hartman

drm/ast: Fix AST2400 POST failure without BMC FW or VBIOS

2017-03-15T01:57:14+00:00

commit 3856081eede297b617560b85e948cfb00bb395ec upstream.

The current POST code for the AST2300/2400 family doesn't work properly
if the chip hasn't been initialized previously by either the BMC own FW
or the VBIOS. This fixes it.

Signed-off-by: Y.C. Chen 
Signed-off-by: Benjamin Herrenschmidt 
Tested-by: Y.C. Chen 
Acked-by: Joel Stanley 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman