A NULL pointer is seen if two concurrent "vgchange -ay -K <vg name>"
processes race to load the dm-thin-pool module:

 PID: 25992 TASK: ffff883cd7d23500 CPU: 4 COMMAND: "vgchange"
  #0 [ffff883cd743d600] machine_kexec at ffffffff81038fa9
  0000001 [ffff883cd743d660] crash_kexec at ffffffff810c5992
  0000002 [ffff883cd743d730] oops_end at ffffffff81515c90
  0000003 [ffff883cd743d760] no_context at ffffffff81049f1b
  0000004 [ffff883cd743d7b0] __bad_area_nosemaphore at ffffffff8104a1a5
  0000005 [ffff883cd743d800] bad_area at ffffffff8104a2ce
  0000006 [ffff883cd743d830] __do_page_fault at ffffffff8104aa6f
  0000007 [ffff883cd743d950] do_page_fault at ffffffff81517bae
  0000008 [ffff883cd743d980] page_fault at ffffffff81514f95
     [exception RIP: kmem_cache_alloc+108]
     RIP: ffffffff8116ef3c RSP: ffff883cd743da38 RFLAGS: 00010046
     RAX: 0000000000000004 RBX: ffffffff81121b90 RCX: ffff881bf1e78cc0
     RDX: 0000000000000000 RSI: 00000000000000d0 RDI: 0000000000000000
     RBP: ffff883cd743da68 R8: ffff881bf1a4eb00 R9: 0000000080042000
     R10: 0000000000002000 R11: 0000000000000000 R12: 00000000000000d0
     R13: 0000000000000000 R14: 00000000000000d0 R15: 0000000000000246
     ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
  0000009 [ffff883cd743da70] mempool_alloc_slab at ffffffff81121ba5
 0000010 [ffff883cd743da80] mempool_create_node at ffffffff81122083
 0000011 [ffff883cd743dad0] mempool_create at ffffffff811220f4
 0000012 [ffff883cd743dae0] pool_ctr at ffffffffa08de049 [dm_thin_pool]
 0000013 [ffff883cd743dbd0] dm_table_add_target at ffffffffa0005f2f [dm_mod]
 0000014 [ffff883cd743dc30] table_load at ffffffffa0008ba9 [dm_mod]
 0000015 [ffff883cd743dc90] ctl_ioctl at ffffffffa0009dc4 [dm_mod]

The race results in a NULL pointer because:

Process A (vgchange -ay -K):
 	a. send DM_LIST_VERSIONS_CMD ioctl;
 	b. pool_target not registered;
 	c. modprobe dm_thin_pool and wait until end.

Process B (vgchange -ay -K):
 	a. send DM_LIST_VERSIONS_CMD ioctl;
 	b. pool_target registered;
 	c. table_load->dm_table_add_target->pool_ctr;
 	d. _new_mapping_cache is NULL and panic.
Note:
 	1. process A and process B are two concurrent processes.
 	2. pool_target can be detected by process B but
 	_new_mapping_cache initialization has not ended.

To fix dm-thin-pool, and other targets (cache, multipath, and snapshot)
with the same problem, simply dm_register_target() after all resources
created during module init (as labelled with __init) are finished.

Cc: stable@vger.kernel.org
Signed-off-by: Nmonty <monty_pavel@sina.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>

Multiple refcounts are needed if the device was already added.  The
micro-optimization of setting the refcount to 1 on first added (rather
than fall thru to a common refcount_inc) lost sight of the fact that the
refcount_inc is also needed for the case when the device already exists
and the mode need not be upgraded.

Fixes: 2a0b4682 ("dm: convert dm_dev_internal.count from atomic_t to refcount_t")
Reported-by: NZdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>

With a nxp,se97 chip on an atmel sama5d31 board, the I2C adapter driver
is not always capable of avoiding the 25-35 ms timeout as specified by
the SMBUS protocol. This may cause silent corruption of the last bit of
any transfer, e.g. a one is read instead of a zero if the sensor chip
times out. This also affects the eeprom half of the nxp-se97 chip, where
this silent corruption was originally noticed. Other I2C adapters probably
suffer similar issues, e.g. bit-banging comes to mind as risky...

The SMBUS register in the nxp chip is not a standard Jedec register, but
it is not special to the nxp chips either, at least the atmel chips
have the same mechanism. Therefore, do not special case this on the
manufacturer, it is opt-in via the device property anyway.

Cc: stable@vger.kernel.org # 4.9+
Signed-off-by: NPeter Rosin <peda@axentia.se>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>

drm_atomic_helper_wait_for_vblanks will go away in the future.

The new drm_atomic_helper_setup_commit in 4.15 expects that blocking commits
have completed flipping before the commit_tail returns. This must be ensured
by calling wait_for_vblanks or wait_for_flip_done, where flip_done might do
a less agressive wait, which is fine for imx-drm.

Fixes: 080de2e5 (drm/atomic: Check for busy planes/connectors before
                     setting the commit)
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>

"ret" needs to be signed for the error handling to work.

Fixes: 8d7f934d ("omapdrm: hdmi4_cec: add OMAP4 HDMI CEC support")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Commit d178e034 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature
to dpi code") replaced usage of platform data version with SoC matching
to configure DPI VDDS. The SoC match entries were incorrect, they should
have matched on the machine name instead of the SoC family. Fix it.

The result was observed on OpenPandora with OMAP3530 where the panel only
had the Blue channel and Red&Green were missing. It was not observed on
GTA04 with DM3730.

Fixes: d178e034 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code")
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reported-by: NH. Nikolaus Schaller <hns@goldelico.com>
Tested-by: NH. Nikolaus Schaller <hns@goldelico.com>
Cc: stable@vger.kernel.org # 4.14
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

I believe the intention of the commit 2c9fc9bf
("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver")
was to identify omap4430 ES1.x, omap4430 ES2.x and other OMAP4 revisions,
like omap4460.

By using family=OMAP4 in the match the code will treat omap4460 ES1.x in a
same way as it would treat omap4430 ES1.x

This breaks HDMI audio on OMAP4460 devices (PandaES for example).

Correct the match rule so we are not going to get false positive match.

Fixes: 2c9fc9bf ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver")

Cc: stable@vger.kernel.org # 4.14
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The new backlight code causes a link failure when backlight
support itself is disabled:

drivers/gpu/drm/omapdrm/displays/panel-dpi.o: In function `panel_dpi_probe_of':
panel-dpi.c:(.text+0x35c): undefined reference to `of_find_backlight_by_node'

This adds a Kconfig dependency like we have for the other OMAP
display targets.

Fixes: 39135a30 ("drm/omap: displays: panel-dpi: Support for handling backlight devices")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

If we don't find a matching device node, we must free the memory allocated
in 'omap_dmm' a few lines above.

Fixes: 7cb0d6c1 ("drm/omap: fix TILER on OMAP5")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We seem to be missing some W/A for 2M pages and are getting
a hit on raw GPU read bandwidths (even 30%) even though the
GPU write bandwidths improve (even 10%).

For now, disable THP, which is our only practical source of
2M pages until we have a W/A for the issue.

v2:
- Be explicit that we talk about GPU bandwidths (Eero)
- s/deny/never/ because that's why (Chris)
Reported-by: NValtteri Rantala <valtteri.rantala@intel.com>
Fixes: b901bb89 ("drm/i915/gemfs: enable THP")
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Valtteri Rantala <valtteri.rantala@intel.com>
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Tested-by: NValtteri Rantala <valtteri.rantala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171127091233.7001-1-joonas.lahtinen@linux.intel.com
(cherry picked from commit 9987da4b)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Use drm_dp_channel_eq_ok helper
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NAndrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-7-git-send-email-andrey.gusakov@cogentembedded.com

First four bytes should go to DP0_AUXWDATA0. Due to bug if
len > 4 first four bytes was writen to DP0_AUXWDATA1 and all
data get shifted by 4 bytes. Fix it.
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NAndrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-6-git-send-email-andrey.gusakov@cogentembedded.com

Fields in HTIM01 and HTIM02 regs should be even.
Recomended thresh_dly value is max_tu_symbol.
Remove set of VPCTRL0.VSDELAY as it is related to DSI input
interface. Currently driver supports only DPI.
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NAndrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-5-git-send-email-andrey.gusakov@cogentembedded.com

Remove shift from TU_SIZE_RECOMMENDED define as it used to
calculate max_tu_symbols.
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NAndrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-4-git-send-email-andrey.gusakov@cogentembedded.com

Pixel clock limitation for DPI is 154 MHz. Do not accept modes
with higher pixel clock rate.
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NAndrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-3-git-send-email-andrey.gusakov@cogentembedded.com

Do not fail data rates higher than 2.7 and more than 2 lanes.
Try to fall back to 2.7Gbps and 2 lanes.
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NAndrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-2-git-send-email-andrey.gusakov@cogentembedded.com

The panel_bridge bridge attaches to the panel's OF node, not the
lvds-encoder's node.  Put in a little no-op bridge of our own so that
our consumers can still find a bridge where they expect.

This also fixes an unintended unregistration and leak of the
panel-bridge on module remove.
Signed-off-by: NEric Anholt <eric@anholt.net>
Fixes: 13dfc054 ("drm/bridge: Refactor out the panel wrapper from the lvds-encoder bri
dge.")
Tested-by: NLothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114191647.22207-1-eric@anholt.net

Support the "cec" optional clock. The documentation already mentions "cec"
optional clock and it is used by several boards, but currently the driver
doesn't enable it, thus preventing cec from working on those boards.

And even worse: a /dev/cecX device will appear for those boards, but it
won't be functioning without configuring this clock.

Changes:
v4:
- Change commit message to stress the importance of this patch

v3:
- Drop useless braces

v2:
- Separate ENOENT errors from others
- Propagate other errors (especially -EPROBE_DEFER)
Signed-off-by: NPierre-Hugues Husson <phh@phh.me>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171125201844.11353-1-phh@phh.me

If the device tree for a board did not specify a cec clock, then
adv7511_cec_init would return an error, which would cause adv7511_probe()
to fail and thus there is no HDMI output.

There is no need to have adv7511_probe() fail if the CEC initialization
fails, so just change adv7511_cec_init() to a void function. In addition,
adv7511_cec_init() should just return silently if the cec clock isn't
found and show a message for any other errors.

An otherwise correct cleanup patch from Dan Carpenter turned this broken
failure handling into a kernel Oops, so bisection points to commit
7af35b0a ("drm/kirin: Checking for IS_ERR() instead of NULL") rather
than 3b1b9750 ("drm: adv7511/33: add HDMI CEC support").

Based on earlier patches from Arnd and John.
Reported-by: NNaresh Kamboju <naresh.kamboju@linaro.org>
Cc: Xinliang Liu <xinliang.liu@linaro.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: John Stultz <john.stultz@linaro.org>
Link: https://bugs.linaro.org/show_bug.cgi?id=3345
Link: https://lkft.validation.linaro.org/scheduler/job/48017#L3551
Fixes: 7af35b0a ("drm/kirin: Checking for IS_ERR() instead of NULL")
Fixes: 3b1b9750 ("drm: adv7511/33: add HDMI CEC support")
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Tested-by: NHans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/9097b2a4-b6b9-5fca-e039-0a17694b1143@xs4all.nl

Until there is a solution to the dma-to-dax vs truncate problem it is
not safe to allow RDMA to create long standing memory registrations
against filesytem-dax vmas.

Link: http://lkml.kernel.org/r/151068941011.7446.7766030590347262502.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: 3565fce3 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Reported-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NJason Gunthorpe <jgg@mellanox.com>
Acked-by: NDoug Ledford <dledford@redhat.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

V4L2 memory registrations are incompatible with filesystem-dax that
needs the ability to revoke dma access to a mapping at will, or
otherwise allow the kernel to wait for completion of DMA.  The
filesystem-dax implementation breaks the traditional solution of
truncate of active file backed mappings since there is no page-cache
page we can orphan to sustain ongoing DMA.

If v4l2 wants to support long lived DMA mappings it needs to arrange to
hold a file lease or use some other mechanism so that the kernel can
coordinate revoking DMA access when the filesystem needs to truncate
mappings.

Link: http://lkml.kernel.org/r/151068940499.7446.12846708245365671207.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: 3565fce3 ("mm, x86: get_user_pages() for dax mappings")
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Reported-by: NJan Kara <jack@suse.cz>
Reviewed-by: NJan Kara <jack@suse.cz>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Doug Ledford <dledford@redhat.com>
Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Jason Gunthorpe <jgg@mellanox.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Similar to how device-dax enforces that the 'address', 'offset', and
'len' parameters to mmap() be aligned to the device's fundamental
alignment, the same constraints apply to munmap().  Implement ->split()
to fail munmap calls that violate the alignment constraint.

Otherwise, we later fail VM_BUG_ON checks in the unmap_page_range() path
with crash signatures of the form:

    vma ffff8800b60c8a88 start 00007f88c0000000 end 00007f88c0e00000
    next           (null) prev           (null) mm ffff8800b61150c0
    prot 8000000000000027 anon_vma           (null) vm_ops ffffffffa0091240
    pgoff 0 file ffff8800b638ef80 private_data           (null)
    flags: 0x380000fb(read|write|shared|mayread|maywrite|mayexec|mayshare|softdirty|mixedmap|hugepage)
    ------------[ cut here ]------------
    kernel BUG at mm/huge_memory.c:2014!
    [..]
    RIP: 0010:__split_huge_pud+0x12a/0x180
    [..]
    Call Trace:
     unmap_page_range+0x245/0xa40
     ? __vma_adjust+0x301/0x990
     unmap_vmas+0x4c/0xa0
     unmap_region+0xae/0x120
     ? __vma_rb_erase+0x11a/0x230
     do_munmap+0x276/0x410
     vm_munmap+0x6a/0xa0
     SyS_munmap+0x1d/0x30

Link: http://lkml.kernel.org/r/151130418681.4029.7118245855057952010.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: dee41079 ("/dev/dax, core: file operations and dax-mmap")
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Reported-by: NJeff Moyer <jmoyer@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

VMIDs 8-16 in Kaveri were reserved for use by the amdkfd driver.
Because we removed amdkfd support from radeon, those VMIDs are now
used by radeon and are initialized by radeon.

This patch removes the function that initialized those VMIDs for amdkfd
use.
This initialization overridden the radeon initialization and caused GPU
faults and GUI crashed.

Fixes: f4fa88ab ("drm/radeon: deprecate and remove KFD interface")
Rported-by: NMichel Dänzer <michel.daenzer@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-and-Tested-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This reverts "drm/ttm: Fix configuration error around populate_and_map()
functions".

This fix has gone into the wrong direction. Those helpers should be
available even when neither CONFIG_INTEL_IOMMU nor CONFIG_SWIOTLB are
set.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Uniformize STMicroelectronics copyrights header
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@st.com>
CC: Alexandre Torgue <alexandre.torgue@st.com>
Acked-by: NAlexandre TORGUE <alexandre.torgue@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

So far we completely rely on the caller to provide valid arguments.
To be on the safe side perform an own sanity check.

Cc: stable@vger.kernel.org
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

Chip datasheet mentions that word addresses other than the actual
start position of the MAC delivers undefined results. So fix this.
Current implementation doesn't work due to this wrong offset.

Cc: stable@vger.kernel.org
Fixes: 0b813658 ("eeprom: at24: add support for at24mac series")
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>

Don't use %x and casting to print out an address, instead use %p
and remove the casting.  Cleans up smatch warnings:

drivers/net/ethernet/via/via-rhine.c:998 rhine_init_one_common()
warn: argument 4 to %lx specifier is cast from pointer
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

On 64-bit (e.g. powerpc64/allmodconfig):

    drivers/net/ethernet/xilinx/ll_temac_main.c: In function 'temac_start_xmit_done':
    drivers/net/ethernet/xilinx/ll_temac_main.c:633:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
	dev_kfree_skb_irq((struct sk_buff *)cur_p->app4);
			  ^

cdmac_bd.app4 is u32, so it is too small to hold a kernel pointer.

Note that several other fields in struct cdmac_bd are also too small to
hold physical addresses on 64-bit platforms.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Some drivers like i915 start with crtc's enabled, but with deferred
fbcon setup they were no longer disabled as part of fbdev setup.
Headless units could no longer enter pc3 state because the crtc was
still enabled.

Fix this by calling restore_fbdev_mode when we would have called
it otherwise once during initial fbdev setup.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: ca91a275 ("drm/fb-helper: Support deferred setup")
Cc: <stable@vger.kernel.org> # v4.14+
Reported-by: NThomas Voegtle <tv@lio96.de>
Tested-by: NThomas Voegtle <tv@lio96.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171128111603.62757-1-maarten.lankhorst@linux.intel.com

There's an ilog2() expansion in AT24_DEVICE_MAGIC() which rounds down
the actual size of EUI-48 byte array in at24mac402 eeproms to 4 from 6,
making it impossible to read it all.

Fix it by manually adjusting the value in probe().

This patch contains a temporary fix that is suitable for stable
branches. Eventually we'll probably remove the call to ilog2() while
converting the magic values to actual structs.

Cc: stable@vger.kernel.org
Fixes: 0b813658 ("eeprom: at24: add support for at24mac series")
Signed-off-by: NBartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>

drm_atomic_helper_setup_commit expects that flipping of previous commits
has happened when it is called to set up a new commit. This can be violated
by commits where userspace doesn't get a flip completion event to
synchronize against i.e. legacy modesets and property changes.

The expectation is that those are done by blocking commits, which wait for
completion. Most drivers call drm_atomic_helper_wait_for_vblanks in the
commit_tail to ensure completion, but the wait for next vblank might not
actually happen if the commit didn't change any planes.

Make the wait more agressive by also waiting if no planes changed. This
is the minimal regression fix for the 4.15 kernel series. Long term
drivers should switch away from drm_atomic_helper_wait_for_vblanks and
use drm_atomic_helper_wait_for_flip_done instead.

Fixes: de39bec1 ("drm/atomic: Remove waits in drm_atomic_helper_commit_cleanup_done, v2.")
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171129110431.6300-1-l.stach@pengutronix.de

The sysfs entry "ocr" was missing the 0x prefix to identify it as hex
formatted.

Fixes: 5fb06af7 ("mmc: core: Extend sysfs with OCR register")
Signed-off-by: NBastian Stender <bst@pengutronix.de>
Cc: <stable@vger.kernel.org> # v4.8+
[Ulf: Amended change to also cover SD-cards]
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The sysfs entry "pre_eol_info" was missing the 0x prefix to identify it
as hex formatted.

Fixes: 46bc5c40 ("mmc: core: Export device lifetime information through sysfs")
Signed-off-by: NBastian Stender <bst@pengutronix.de>
Cc: <stable@vger.kernel.org> # v4.11+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

reading dpcd 0x600 cause link loss for a particular USB-C dock with
thurderbolt.  workaround by avoiding dcpd 0x600 read unless it's
necessary.
Signed-off-by: NHersen Wu <hersenxs.wu@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This new helper function is advised to be used for drviers that
use the nonblocking commit tracking support instead of
drm_atomic_helper_wait_for_vblanks.
Signed-off-by: NAndrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
Reviewed-and-Tested-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Adding gamma changed check as condition for affected plane.
We ignored adding plane as affected if modeset was not required.
But for color management change we still need it.
Signed-off-by: NRoman Li <Roman.Li@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

drm_atomic_helper_resume now puts it for us. See relevant patch here:
https://lists.freedesktop.org/archives/dri-devel/2017-October/154268.htmlSigned-off-by: NLeo (Sunpeng) Li <sunpeng.li@amd.com>
Reviewed-by: NHarry Wentland <Harry.Wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Found by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1001
acquire_free_pipe_for_stream() error: we previously assumed 'head_pipe'
could be null (see line 998)
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1808
dc_validate_global_state() error: we previously assumed 'new_ctx' could
be null (see line 1778)
Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Found by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:148 create_links()
error: potential null dereference 'link->link_enc'.  (kzalloc returns
null)
Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>