Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
No functional changes since pipe_src_w/h are already filled via
drm_mode_get_hv_timing().

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-3-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NThierry Reding <treding@nvidia.com>

In order to guarantee that pipe_src_w/h matches the user mode h/vdisplay
we must not adjust pipe_src_w to accommodate double wide/dual link.
Instead just reject the mode outright.

This will allows us to rely on crtc_state->mode for plane clipping.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-2-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NThierry Reding <treding@nvidia.com>

Fixes the following build warnings:
In file included from ../drivers/gpu/drm/sun4i/sun8i_mixer.h:18:0,
                 from ../drivers/gpu/drm/sun4i/sun8i_vi_scaler.h:13,
                 from ../drivers/gpu/drm/sun4i/sun8i_vi_scaler.c:12:
../drivers/gpu/drm/sun4i/sunxi_engine.h:36:16: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration
         struct drm_crtc_state *old_state);
                ^~~~~~~~~~~~~~
../drivers/gpu/drm/sun4i/sunxi_engine.h:53:15: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration
        struct drm_crtc_state *state);
               ^~~~~~~~~~~~~~
In file included from ../drivers/gpu/drm/sun4i/sun8i_mixer.h:18:0,
                 from ../drivers/gpu/drm/sun4i/sun8i_ui_scaler.h:12,
                 from ../drivers/gpu/drm/sun4i/sun8i_ui_scaler.c:12:
../drivers/gpu/drm/sun4i/sunxi_engine.h:36:16: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration
         struct drm_crtc_state *old_state);
                ^~~~~~~~~~~~~~
../drivers/gpu/drm/sun4i/sunxi_engine.h:53:15: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration
        struct drm_crtc_state *state);
               ^~~~~~~~~~~~~~

Fixes: 6b8562c8 ("drm/sun4i: engine: Create an atomic_begin
callback")
Fixes: 656e5f65 ("drm/sun4i: engine: Add a custom crtc
atomic_check")
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180122174306.231609-1-seanpaul@chromium.org

A couple more return value fixes which Philippe brought up during our
previous review.
Suggested-by: NPhilippe CORNU <philippe.cornu@st.com>
Reviewed-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180117213751.54668-1-seanpaul@chromium.org

If we try to read the backend registers while it fetches the new values, we
end up with the value of some random register instead of the one we asked
for.

In order to prevent that, let's make sure that the very first thing we do
during our atomic modesetting is to let the commit bit come to a rest.

We don't have to worry about anything else since the only time we will
trigger a new transaction is during the atomic_commit which comes much
later.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/35604307e5bde2b85c674de79fa7c4d55700f085.1516613040.git-series.maxime.ripard@free-electrons.com

During a hardware commit, the commit bit in the backend will only be
cleared if the TCON is enabled. Use the runtime_pm variant of the
atomic_commit_tail hook that makes sure that the CRTC, our TCON, is enabled
when we perform an atomic_commit.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bde95faff2078f63e9af99c3abee5360b9050fd1.1516613040.git-series.maxime.ripard@free-electrons.com

Now that we have everything in place, we can start enabling the frontend.
This is more difficult than one would assume since there can only be one
plane using the frontend per-backend.

We therefore need to make sure that the userspace will not try to setup
multiple planes using it, since that would be impossible. In order to
prevent that, we can create an atomic_check callback that will check that
only one plane will effectively make use of the frontend in a given
configuration, and will toggle the switch in that plane state so that the
proper setup function can do their role.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/278e6c514a8311750fe627c7f28d58b3e2cbd825.1516613040.git-series.maxime.ripard@free-electrons.com

Now that we have a driver, we can make use of it. This is done by
adding a flag to our custom plane state that will trigger whether we should
use the frontend on that particular plane or not.

The rest is just plumbing to set up the backend to not perform the DMA but
receive its data from the frontend.

Note that we're still not making any use of the frontend itself, as no one
is setting the flag yet.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/cdffc25eab2d817820cc78cbd24f1f4b99902014.1516613040.git-series.maxime.ripard@free-electrons.com

The display frontend is an hardware block that can be used to implement
some more advanced features like hardware scaling or colorspace
conversions. It can also be used to implement the output format of the VPU.

Let's create a minimal driver for it that will only enable the hardware
scaling features.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/029cdc3478bf89d422f5e8d9e600baf5e48ce4db.1516613040.git-series.maxime.ripard@free-electrons.com

We have to implement some display engine specific behaviours in
atomic_begin. Let's add a function for that.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/44110951ae0cc13767fefc7fc1d9e2ec782d0a40.1516613040.git-series.maxime.ripard@free-electrons.com

In some cases, the display engine needs to apply some quirks during the
VBLANK event. In the Display Engine 1.0 case for example, we can only
disable the frontend once the backend has been, which is at VBLANK.

Let's introduce a callback that can be implemented by the various engines.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7c298d43aa1500196aa5d15d7a7c0f228c7a6f3c.1516613040.git-series.maxime.ripard@free-electrons.com

We have some restrictions on what the planes and CRTC can provide that are
tied to only one generation of display engines.

For example, on the first generation, we can only have one YUV plane or one
plane that uses the frontend output.

Let's allow our engines to provide an atomic_check callback to validate the
current configuration.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e5f5f144e5c20d348cdb29933ae876c105bec017.1516613040.git-series.maxime.ripard@free-electrons.com

We will need to store some additional data in the future to the state.
Create a custom plane state that will embed those data, in order to store
the pipe or whether or not that plane should use the frontend.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/88dd9c2b0caa550595e7b2ff37dc9d0af2c78609.1516613040.git-series.maxime.ripard@free-electrons.com

The function converting the DRM format to its equivalent in the backend
registers was assuming that we were having a plane.

However, we might want to use that function when setting up a plane using
the frontend, in which case we will not have a plane associated to the
backend's layer. Yet, we still need to setup the format to the one output
by the frontend.

Test for NULL plane pointers before referencing them, so that we can work
around it.
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bfbe4c2e8525a7542526b648d59a8f3546e905f1.1516613040.git-series.maxime.ripard@free-electrons.com

Our operations were missing some documentation to explain what was expected
from them.

Let's make that clearer.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/fdcd8ec3ae9ecd73ef089ede5218d3a41b49be05.1516613040.git-series.maxime.ripard@free-electrons.com

Setup the line stride in the buffer setup function, since it's tied to the
buffer itself, and is not needed when we do not set the buffer in the
backend.

This is for example the case when using the frontend and then routing its
output to the backend.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/cbec84125bc0d5a6cf1d856b8291fbf77b138881.1516613040.git-series.maxime.ripard@free-electrons.com

It's been a while since we've backmerged drm-next. Dave just brought
back 4.15-rc8, so now's a good time to freshen things up around here.
Signed-off-by: NSean Paul <seanpaul@chromium.org>

Signed-off-by: NSamuel Li <Samuel.Li@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1516311860-24949-1-git-send-email-Samuel.Li@amd.com

Since i2c_unregister_device() became NULL-aware we may remove duplicate
NULL check.

Cc: Russell King <linux@armlinux.org.uk>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031142149.32512-8-andriy.shevchenko@linux.intel.comAcked-by: NRussell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Since i2c_unregister_device() became NULL-aware we may remove duplicate
NULL check.

Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031142149.32512-7-andriy.shevchenko@linux.intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Since i2c_unregister_device() became NULL-aware we may remove duplicate
NULL check.

Cc: Archit Taneja <architt@codeaurora.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031142149.32512-6-andriy.shevchenko@linux.intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Linux 4.15-rc8

Daniel requested this for so the intel CI won't fall over on drm-next
so often.

Return value for mipi_dsi_shutdown_peripheral() is unchecked.
Check it and return any errors if they come up. Even if
mipi_dsi_shutdown_peripheral() fails, continue attempting to
disable.

Cc: Philippe Cornu <philippe.cornu@st.com>
Reviewed-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180116222217.240939-1-seanpaul@chromium.org

The function mipi_dsi_device_transfer() returns the number of transmitted
or received bytes on success or a negative error code on failure.

The functions mipi_dsi_shutdown_peripheral(), mipi_dsi_turn_on_peripheral() &
mipi_dsi_set_maximum_return_packet_size() use improperly this returned
value in case of success: 0 should be returned instead of the number of
transmitted bytes.
Signed-off-by: NPhilippe Cornu <philippe.cornu@st.com>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180112144847.18810-1-philippe.cornu@st.com

We're filling the "remainder" word with little-endian data, then writing
it out to IO registers with endian-correcting writel(). That probably
won't work on big-endian systems.

Let's mark the "remainder" variable as LE32 (since we fill it with
memcpy()) and do the swapping explicitly.

Some of this function could be done more easily without memcpy(), but
the unaligned "remainder" case is a little hard to do without
potentially overrunning 'tx_buf', so I just applied the same solution in
all cases (memcpy() + le32_to_cpu()).

Tested only on a little-endian system.
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180109203248.139249-2-briannorris@chromium.org

This takes care of 2 TODOs in this driver, by using the common DSI
packet-marshalling code instead of our custom short/long write code.
This both saves us some duplicated code and gets us free support for
command types that weren't already part of our switch block (e.g.,
MIPI_DSI_GENERIC_LONG_WRITE).

The code logic stays mostly intact, except that it becomes unnecessary
to split the short/long write functions, and we have to copy data a bit
more.

Along the way, I noticed that loop bounds were a little odd:

	while (DIV_ROUND_UP(len, pld_data_bytes))

This really was just supposed to be 'len != 0', so I made that more
clear.

Tested on RK3399 with some pending refactoring patches by Nickey Yang,
to make the Rockchip DSI driver wrap this common driver.
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Reviewed-by: NPhilippe Cornu <philippe.cornu@st.com>
Tested-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180109203248.139249-1-briannorris@chromium.org

sparse complains:

drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:703:6: warning: symbol
'dw_mipi_dsi_bridge_mode_set' was not declared. Should it be static?
Reviewed-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180109203319.139520-1-briannorris@chromium.org

The MIPI DBI spec states that reset active/low time should be more
than 9us. Change from 20ms to 20us.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDavid Lechner <david@lechnology.com>
Tested-by: NDavid Lechner <david@lechnology.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180110185940.53841-8-noralf@tronnes.org

Embed the mode in tinydrm_connector instead of doing an devm_ allocation.
Remove unnecessary use of ret variable at the end of
tinydrm_display_pipe_init().
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDavid Lechner <david@lechnology.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180110185940.53841-7-noralf@tronnes.org

It's better to leave power handling and controller init to the
modesetting machinery using the simple pipe .enable and .disable
callbacks. Remove unused mipi_dbi_pipe_enable().
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDavid Lechner <david@lechnology.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180110185940.53841-6-noralf@tronnes.org

Split out common poweron-reset functionality.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDavid Lechner <david@lechnology.com>
Tested-by: NDavid Lechner <david@lechnology.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180110185940.53841-5-noralf@tronnes.org

Add and use a function for enabling, flushing and turning on backlight.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDavid Lechner <david@lechnology.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180110185940.53841-4-noralf@tronnes.org

No need for a public header file for the command macros.
Just include the necessary ones in the driver.

Also use the MIPI_DCS_PIXEL_FMT_16BIT macro.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDavid Lechner <david@lechnology.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180110185940.53841-3-noralf@tronnes.org

Include linux headers before drm headers as it's commonly done.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDavid Lechner <david@lechnology.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180110185940.53841-2-noralf@tronnes.org

Pull x86 fixlet from Thomas Gleixner.

Remove a warning about lack of compiler support for retpoline that most
people can't do anything about, so it just annoys them needlessly.

* 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/retpoline: Remove compile time warning

Pull powerpc fixes from Michael Ellerman:
 "One fix for an oops at boot if we take a hotplug interrupt before we
  are ready to handle it.

  The bulk is patches to implement mitigation for Meltdown, see the
  change logs for more details.

  Thanks to: Nicholas Piggin, Michael Neuling, Oliver O'Halloran, Jon
  Masters, Jose Ricardo Ziviani, David Gibson"

* tag 'powerpc-4.15-7' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/powernv: Check device-tree for RFI flush settings
  powerpc/pseries: Query hypervisor for RFI flush settings
  powerpc/64s: Support disabling RFI flush with no_rfi_flush and nopti
  powerpc/64s: Add support for RFI flush of L1-D cache
  powerpc/64s: Convert slb_miss_common to use RFI_TO_USER/KERNEL
  powerpc/64: Convert fast_exception_return to use RFI_TO_USER/KERNEL
  powerpc/64: Convert the syscall exit path to use RFI_TO_USER/KERNEL
  powerpc/64s: Simple RFI macro conversions
  powerpc/64: Add macros for annotating the destination of rfid/hrfid
  powerpc/pseries: Add H_GET_CPU_CHARACTERISTICS flags & wrapper
  powerpc/pseries: Make RAS IRQ explicitly dependent on DLPAR WQ

Remove the compile time warning when CONFIG_RETPOLINE=y and the compiler
does not have retpoline support. Linus rationale for this is:

  It's wrong because it will just make people turn off RETPOLINE, and the
  asm updates - and return stack clearing - that are independent of the
  compiler are likely the most important parts because they are likely the
  ones easiest to target.

  And it's annoying because most people won't be able to do anything about
  it. The number of people building their own compiler? Very small. So if
  their distro hasn't got a compiler yet (and pretty much nobody does), the
  warning is just annoying crap.

  It is already properly reported as part of the sysfs interface. The
  compile-time warning only encourages bad things.

Fixes: 76b04384 ("x86/retpoline: Add initial retpoline support")
Requested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: gnomes@lxorguk.ukuu.org.uk
Cc: Rik van Riel <riel@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: thomas.lendacky@amd.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Kees Cook <keescook@google.com>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org>
Link: https://lkml.kernel.org/r/CA+55aFzWgquv4i6Mab6bASqYXg3ErV3XDFEYf=GEcCDQg5uAtw@mail.gmail.com

Pull NVMe fix from Jens Axboe:
 "Just a single fix for nvme over fabrics that should go into 4.15"

* 'for-linus' of git://git.kernel.dk/linux-block:
  nvme-fabrics: initialize default host->id in nvmf_host_default()

Pull x86 pti updates from Thomas Gleixner:
 "This contains:

   - a PTI bugfix to avoid setting reserved CR3 bits when PCID is
     disabled. This seems to cause issues on a virtual machine at least
     and is incorrect according to the AMD manual.

   - a PTI bugfix which disables the perf BTS facility if PTI is
     enabled. The BTS AUX buffer is not globally visible and causes the
     CPU to fault when the mapping disappears on switching CR3 to user
     space. A full fix which restores BTS on PTI is non trivial and will
     be worked on.

   - PTI bugfixes for EFI and trusted boot which make sure that the user
     space visible page table entries have the NX bit cleared

   - removal of dead code in the PTI pagetable setup functions

   - add PTI documentation

   - add a selftest for vsyscall to verify that the kernel actually
     implements what it advertises.

   - a sysfs interface to expose vulnerability and mitigation
     information so there is a coherent way for users to retrieve the
     status.

   - the initial spectre_v2 mitigations, aka retpoline:

      + The necessary ASM thunk and compiler support

      + The ASM variants of retpoline and the conversion of affected ASM
        code

      + Make LFENCE serializing on AMD so it can be used as speculation
        trap

      + The RSB fill after vmexit

   - initial objtool support for retpoline

  As I said in the status mail this is the most of the set of patches
  which should go into 4.15 except two straight forward patches still on
  hold:

   - the retpoline add on of LFENCE which waits for ACKs

   - the RSB fill after context switch

  Both should be ready to go early next week and with that we'll have
  covered the major holes of spectre_v2 and go back to normality"

* 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (28 commits)
  x86,perf: Disable intel_bts when PTI
  security/Kconfig: Correct the Documentation reference for PTI
  x86/pti: Fix !PCID and sanitize defines
  selftests/x86: Add test_vsyscall
  x86/retpoline: Fill return stack buffer on vmexit
  x86/retpoline/irq32: Convert assembler indirect jumps
  x86/retpoline/checksum32: Convert assembler indirect jumps
  x86/retpoline/xen: Convert Xen hypercall indirect jumps
  x86/retpoline/hyperv: Convert assembler indirect jumps
  x86/retpoline/ftrace: Convert ftrace assembler indirect jumps
  x86/retpoline/entry: Convert entry assembler indirect jumps
  x86/retpoline/crypto: Convert crypto assembler indirect jumps
  x86/spectre: Add boot time option to select Spectre v2 mitigation
  x86/retpoline: Add initial retpoline support
  objtool: Allow alternatives to be ignored
  objtool: Detect jumps to retpoline thunks
  x86/pti: Make unpoison of pgd for trusted boot work for real
  x86/alternatives: Fix optimize_nops() checking
  sysfs/cpu: Fix typos in vulnerability documentation
  x86/cpu/AMD: Use LFENCE_RDTSC in preference to MFENCE_RDTSC
  ...