Permalink
Commits on Oct 5, 2018
  1. Makefile: linux4sam_6.0

    cristibirsan committed Oct 5, 2018
    Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
Commits on Oct 4, 2018
  1. Makefile: linux4sam_6.0-rc5

    cristibirsan committed Oct 4, 2018
    Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
  2. drm/kms: use drm_atomic_helper_framebuffer_changed when waiting for v…

    ehristev committed Oct 4, 2018
    …blanks
    
    Waiting for vblanks takes too long on our boards. Reverting to the old API
    which was calling drm_atomic_helper_framebuffer_changed.
    
    With this, we can achieve the framerate in kernel 4.9.
    
    Tested-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Tested-by: Razvan Stefanescu <razvan.stefanescu@microchip.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Commits on Oct 2, 2018
  1. Makefile: linux4sam_6.0-rc4

    cristibirsan committed Oct 2, 2018
    Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
  2. nohz: Fix missing tick reprogram when interrupting an inline softirq

    Frederic Weisbecker authored and cristibirsan committed Aug 3, 2018
    commit 0a0e082 upstream.
    
    The full nohz tick is reprogrammed in irq_exit() only if the exit is not in
    a nesting interrupt. This stands as an optimization: whether a hardirq or a
    softirq is interrupted, the tick is going to be reprogrammed when necessary
    at the end of the inner interrupt, with even potential new updates on the
    timer queue.
    
    When soft interrupts are interrupted, it's assumed that they are executing
    on the tail of an interrupt return. In that case tick_nohz_irq_exit() is
    called after softirq processing to take care of the tick reprogramming.
    
    But the assumption is wrong: softirqs can be processed inline as well, ie:
    outside of an interrupt, like in a call to local_bh_enable() or from
    ksoftirqd.
    
    Inline softirqs don't reprogram the tick once they are done, as opposed to
    interrupt tail softirq processing. So if a tick interrupts an inline
    softirq processing, the next timer will neither be reprogrammed from the
    interrupting tick's irq_exit() nor after the interrupted softirq
    processing. This situation may leave the tick unprogrammed while timers are
    armed.
    
    To fix this, simply keep reprogramming the tick even if a softirq has been
    interrupted. That can be optimized further, but for now correctness is more
    important.
    
    Note that new timers enqueued in nohz_full mode after a softirq gets
    interrupted will still be handled just fine through self-IPIs triggered by
    the timer code.
    
    Reported-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
    Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
    Cc: stable@vger.kernel.org # 4.14+
    Link: https://lkml.kernel.org/r/1533303094-15855-1-git-send-email-frederic@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. ARM: dts: at91: sama5d4_xplained: even nand memory partitions

    ambarus committed Oct 1, 2018
    sama5d4_xplained, ssam9x5cm, sama5d2_ptc_ek and sama5d3_xplained nand
    flashes have a common memory map. Even the nand memory partitions to
    match our nand flash map available at:
    
    http://www.at91.com/linux4sam/pub/Linux4SAM/SambaSubsections//demo_nandflash_map_lnx4sam5x.png
    
    Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
  4. ARM: dts: at91: sama5d3_xplained: even nand memory partitions

    ambarus committed Oct 1, 2018
    sama5d3_xplained, sam9x5cm, sama5d2_ptc_ek and sama5d4_xplained nand
    flashes have a common memory map. Even the nand memory partitions to
    match our nand flash map available at:
    
    http://www.at91.com/linux4sam/pub/Linux4SAM/SambaSubsections//demo_nandflash_map_lnx4sam5x.png
    
    Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
  5. ARM: dts: at91: at91sam9x5cm: even nand memory partitions

    ambarus committed Oct 1, 2018
    sam9x5cm, sama5d2_ptc_ek, sama5d3_xplained and sama5d4_xplained nand
    flashes have a common memory map. Even the nand memory partitions to
    match our nand flash map available at:
    
    http://www.at91.com/linux4sam/pub/Linux4SAM/SambaSubsections//demo_nandflash_map_lnx4sam5x.png
    
    Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
  6. ARM: dts: at91: sama5d2_ptc_ek: fix bootloader env offsets

    ambarus committed Oct 1, 2018
    The offsets for the bootloader environment and its redundant partition
    were inverted. Fix the addresses to match our NAND flash map available at:
    
    http://www.at91.com/linux4sam/pub/Linux4SAM/SambaSubsections//demo_nandflash_map_lnx4sam5x.png
    
    Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
  7. ARM: dts: at91: at91sam9x5cm: fix addressable nand flash size

    ambarus committed Oct 1, 2018
    at91sam9x5cm comes with a 2Gb NAND flash. Fix the rootfs size to
    match this limit.
    
    Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
  8. ARM: dts: at91: sama5d4_xplained: fix addressable nand flash size

    ambarus committed Oct 1, 2018
    sama5d4_xplained comes with a 4Gb NAND flash. Increase the rootfs
    size to match this limit.
    
    Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Commits on Sep 29, 2018
  1. Linux 4.14.73

    gregkh committed Sep 29, 2018
  2. spi: Fix double IDR allocation with DT aliases

    Geert Uytterhoeven authored and gregkh committed Aug 21, 2018
    commit 04b2d03 upstream.
    
    If the SPI bus number is provided by a DT alias, idr_alloc() is called
    twice, leading to:
    
        WARNING: CPU: 1 PID: 1 at drivers/spi/spi.c:2179 spi_register_controller+0x11c/0x5d8
        couldn't get idr
    
    Fix this by moving the handling of fixed SPI bus numbers up, before the
    DT handling code fills in ctlr->bus_num.
    
    Fixes: 1a4327f ("spi: fix IDR collision on systems with both fixed and dynamic SPI bus numbers")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Cc: Kirill Kapranov <kirill.kapranov@compulab.co.il>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. tick/nohz: Prevent bogus softirq pending warning

    Thomas Gleixner authored and gregkh committed Aug 30, 2018
    Commit 0a0e082 ("nohz: Fix missing tick reprogram when interrupting an
    inline softirq") got backported to stable trees and now causes the NOHZ
    softirq pending warning to trigger. It's not an upstream issue as the NOHZ
    update logic has been changed there.
    
    The problem is when a softirq disabled section gets interrupted and on
    return from interrupt the tick/nohz state is evaluated, which then can
    observe pending soft interrupts. These soft interrupts are legitimately
    pending because they cannot be processed as long as soft interrupts are
    disabled and the interrupted code will correctly process them when soft
    interrupts are reenabled.
    
    Add a check for softirqs disabled to the pending check to prevent the
    warning.
    
    Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
    Reported-by: John Crispin <john@phrozen.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Grygorii Strashko <grygorii.strashko@ti.com>
    Tested-by: John Crispin <john@phrozen.org>
    Cc: Frederic Weisbecker <frederic@kernel.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Anna-Maria Gleixner <anna-maria@linutronix.de>
    Cc: stable@vger.kernel.org
    Fixes: 2d89891 ("nohz: Fix missing tick reprogram when interrupting an inline softirq")
    Acked-by: Frederic Weisbecker <frederic@kernel.org>
    Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
  4. iw_cxgb4: only allow 1 flush on user qps

    larrystevenwise authored and gregkh committed Aug 31, 2018
    commit 308aa2b upstream.
    
    Once the qp has been flushed, it cannot be flushed again.  The user qp
    flush logic wasn't enforcing it however.  The bug can cause
    touch-after-free crashes like:
    
    Unable to handle kernel paging request for data at address 0x000001ec
    Faulting instruction address: 0xc008000016069100
    Oops: Kernel access of bad area, sig: 11 [#1]
    ...
    NIP [c008000016069100] flush_qp+0x80/0x480 [iw_cxgb4]
    LR [c00800001606cd6c] c4iw_modify_qp+0x71c/0x11d0 [iw_cxgb4]
    Call Trace:
    [c00800001606cd6c] c4iw_modify_qp+0x71c/0x11d0 [iw_cxgb4]
    [c00800001606e868] c4iw_ib_modify_qp+0x118/0x200 [iw_cxgb4]
    [c0080000119eae80] ib_security_modify_qp+0xd0/0x3d0 [ib_core]
    [c0080000119c4e24] ib_modify_qp+0xc4/0x2c0 [ib_core]
    [c008000011df0284] iwcm_modify_qp_err+0x44/0x70 [iw_cm]
    [c008000011df0fec] destroy_cm_id+0xcc/0x370 [iw_cm]
    [c008000011ed4358] rdma_destroy_id+0x3c8/0x520 [rdma_cm]
    [c0080000134b0540] ucma_close+0x90/0x1b0 [rdma_ucm]
    [c000000000444da4] __fput+0xe4/0x2f0
    
    So fix flush_qp() to only flush the wq once.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Steve Wise <swise@opengridcomputing.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. vmw_balloon: include asm/io.h

    Nadav Amit authored and gregkh committed Sep 13, 2018
    commit a3b92ee6fc171d7c9d9b6b829b7fef169210440c upstream.
    
    Fix a build error due to missing virt_to_phys()
    
    Reported-by: kbuild test robot <lkp@intel.com>
    Fixes: f0a1bf29d821b ("vmw_balloon: fix inflation with batching")
    Cc: stable@vger.kernel.org
    Cc: Xavier Deguillard <xdeguillard@vmware.com>
    Signed-off-by: Nadav Amit <namit@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. PCI: aardvark: Size bridges before resources allocation

    Zachary Zhang authored and gregkh committed Jun 29, 2018
    commit 91a2968 upstream.
    
    The PCIE I/O and MEM resource allocation mechanism is that root bus
    goes through the following steps:
    
    1. Check PCI bridges' range and computes I/O and Mem base/limits.
    
    2. Sort all subordinate devices I/O and MEM resource requirements and
       allocate the resources and writes/updates subordinate devices'
       requirements to PCI bridges I/O and Mem MEM/limits registers.
    
    Currently, PCI Aardvark driver only handles the second step and lacks
    the first step, so there is an I/O and MEM resource allocation failure
    when using a PCI switch. This commit fixes that by sizing bridges
    before doing the resource allocation.
    
    Fixes: 8c39d71 ("PCI: aardvark: Add Aardvark PCI host controller
    driver")
    Signed-off-by: Zachary Zhang <zhangzg@marvell.com>
    [Thomas: edit commit log.]
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  7. sched/fair: Fix vruntime_normalized() for remote non-migration wakeup

    smuckle authored and gregkh committed Aug 31, 2018
    commit d0cdb3c upstream.
    
    When a task which previously ran on a given CPU is remotely queued to
    wake up on that same CPU, there is a period where the task's state is
    TASK_WAKING and its vruntime is not normalized. This is not accounted
    for in vruntime_normalized() which will cause an error in the task's
    vruntime if it is switched from the fair class during this time.
    
    For example if it is boosted to RT priority via rt_mutex_setprio(),
    rq->min_vruntime will not be subtracted from the task's vruntime but
    it will be added again when the task returns to the fair class. The
    task's vruntime will have been erroneously doubled and the effective
    priority of the task will be reduced.
    
    Note this will also lead to inflation of all vruntimes since the doubled
    vruntime value will become the rq's min_vruntime when other tasks leave
    the rq. This leads to repeated doubling of the vruntime and priority
    penalty.
    
    Fix this by recognizing a WAKING task's vruntime as normalized only if
    sched_remote_wakeup is true. This indicates a migration, in which case
    the vruntime would have been normalized in migrate_task_rq_fair().
    
    Based on a similar patch from John Dias <joaodias@google.com>.
    
    Suggested-by: Peter Zijlstra <peterz@infradead.org>
    Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Signed-off-by: Steve Muckle <smuckle@google.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Chris Redpath <Chris.Redpath@arm.com>
    Cc: John Dias <joaodias@google.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Miguel de Dios <migueldedios@google.com>
    Cc: Morten Rasmussen <Morten.Rasmussen@arm.com>
    Cc: Patrick Bellasi <Patrick.Bellasi@arm.com>
    Cc: Paul Turner <pjt@google.com>
    Cc: Quentin Perret <quentin.perret@arm.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Todd Kjos <tkjos@google.com>
    Cc: kernel-team@android.com
    Fixes: b5179ac ("sched/fair: Prepare to fix fairness problems on migration")
    Link: http://lkml.kernel.org/r/20180831224217.169476-1-smuckle@google.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  8. ext4: show test_dummy_encryption mount option in /proc/mounts

    ebiggers authored and gregkh committed Sep 15, 2018
    commit 338affb upstream.
    
    When in effect, add "test_dummy_encryption" to _ext4_show_options() so
    that it is shown in /proc/mounts and other relevant procfs files.
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. ext4: don't mark mmp buffer head dirty

    Li Dongyang authored and gregkh committed Sep 15, 2018
    commit fe18d64 upstream.
    
    Marking mmp bh dirty before writing it will make writeback
    pick up mmp block later and submit a write, we don't want the
    duplicate write as kmmpd thread should have full control of
    reading and writing the mmp block.
    Another reason is we will also have random I/O error on
    the writeback request when blk integrity is enabled, because
    kmmpd could modify the content of the mmp block(e.g. setting
    new seq and time) while the mmp block is under I/O requested
    by writeback.
    
    Signed-off-by: Li Dongyang <dongyangli@ddn.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  10. ext4: fix online resizing for bigalloc file systems with a 1k block size

    tytso authored and gregkh committed Sep 4, 2018
    commit 5f8c109 upstream.
    
    An online resize of a file system with the bigalloc feature enabled
    and a 1k block size would be refused since ext4_resize_begin() did not
    understand s_first_data_block is 0 for all bigalloc file systems, even
    when the block size is 1k.
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  11. ext4: fix online resize's handling of a too-small final block group

    tytso authored and gregkh committed Sep 4, 2018
    commit f0a459d upstream.
    
    Avoid growing the file system to an extent so that the last block
    group is too small to hold all of the metadata that must be stored in
    the block group.
    
    This problem can be triggered with the following reproducer:
    
    umount /mnt
    mke2fs -F -m0 -b 4096 -t ext4 -O resize_inode,^has_journal \
    	-E resize=1073741824 /tmp/foo.img 128M
    mount /tmp/foo.img /mnt
    truncate --size 1708M /tmp/foo.img
    resize2fs /dev/loop0 295400
    umount /mnt
    e2fsck -fy /tmp/foo.img
    
    Reported-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  12. ext4: recalucate superblock checksum after updating free blocks/inodes

    tytso authored and gregkh committed Sep 1, 2018
    commit 4274f51 upstream.
    
    When mounting the superblock, ext4_fill_super() calculates the free
    blocks and free inodes and stores them in the superblock.  It's not
    strictly necessary, since we don't use them any more, but it's nice to
    keep them roughly aligned to reality.
    
    Since it's not critical for file system correctness, the code doesn't
    call ext4_commit_super().  The problem is that it's in
    ext4_commit_super() that we recalculate the superblock checksum.  So
    if we're not going to call ext4_commit_super(), we need to call
    ext4_superblock_csum_set() to make sure the superblock checksum is
    consistent.
    
    Most of the time, this doesn't matter, since we end up calling
    ext4_commit_super() very soon thereafter, and definitely by the time
    the file system is unmounted.  However, it doesn't work in this
    sequence:
    
    mke2fs -Fq -t ext4 /dev/vdc 128M
    mount /dev/vdc /vdc
    cp xfstests/git-versions /vdc
    godown /vdc
    umount /vdc
    mount /dev/vdc
    tune2fs -l /dev/vdc
    
    With this commit, the "tune2fs -l" no longer fails.
    
    Reported-by: Chengguang Xu <cgxu519@gmx.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  13. ext4: avoid arithemetic overflow that can trigger a BUG

    tytso authored and gregkh committed Sep 1, 2018
    commit bcd8e91 upstream.
    
    A maliciously crafted file system can cause an overflow when the
    results of a 64-bit calculation is stored into a 32-bit length
    parameter.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=200623
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reported-by: Wen Xu <wen.xu@gatech.edu>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  14. ext4: avoid divide by zero fault when deleting corrupted inline direc…

    tytso authored and gregkh committed Aug 27, 2018
    …tories
    
    commit 4d982e2 upstream.
    
    A specially crafted file system can trick empty_inline_dir() into
    reading past the last valid entry in a inline directory, and then run
    into the end of xattr marker. This will trigger a divide by zero
    fault.  Fix this by using the size of the inline directory instead of
    dir->i_size.
    
    Also clean up error reporting in __ext4_check_dir_entry so that the
    message is clearer and more understandable --- and avoids the division
    by zero trap if the size passed in is zero.  (I'm not sure why we
    coded it that way in the first place; printing offset % size is
    actually more confusing and less useful.)
    
    https://bugzilla.kernel.org/show_bug.cgi?id=200933
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reported-by: Wen Xu <wen.xu@gatech.edu>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  15. ext4: check to make sure the rename(2)'s destination is not freed

    tytso authored and gregkh committed Aug 27, 2018
    commit b50282f upstream.
    
    If the destination of the rename(2) system call exists, the inode's
    link count (i_nlinks) must be non-zero.  If it is, the inode can end
    up on the orphan list prematurely, leading to all sorts of hilarity,
    including a use-after-free.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=200931
    
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reported-by: Wen Xu <wen.xu@gatech.edu>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  16. tty: vt_ioctl: fix potential Spectre v1

    GustavoARSilva authored and gregkh committed Aug 16, 2018
    commit e97267c upstream.
    
    vsa.console is indirectly controlled by user-space, hence leading to
    a potential exploitation of the Spectre variant 1 vulnerability.
    
    This issue was detected with the help of Smatch:
    
    drivers/tty/vt/vt_ioctl.c:711 vt_ioctl() warn: potential spectre issue
    'vc_cons' [r]
    
    Fix this by sanitizing vsa.console before using it to index vc_cons
    
    Notice that given that speculation windows are large, the policy is
    to kill the speculation on the first load and not worry if it can be
    completed with a dependent load/store [1].
    
    [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Reviewed-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  17. drm/amdgpu: add new polaris pci id

    Alex Deucher authored and gregkh committed Sep 18, 2018
    commit 30f3984 upstream.
    
    Add new pci id.
    
    Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  18. drm: udl: Destroy framebuffer only if it was initialized

    lndmrk authored and gregkh committed May 28, 2018
    commit fcb74da upstream.
    
    This fixes a NULL pointer dereference that can happen if the UDL
    driver is unloaded before the framebuffer is initialized. This can
    happen e.g. if the USB device is unplugged right after it was plugged
    in.
    
    As explained by Stéphane Marchesin:
    
    It happens when fbdev is disabled (which is the case for Chrome OS).
    Even though intialization of the fbdev part is optional (it's done in
    udlfb_create which is the callback for fb_probe()), the teardown isn't
    optional (udl_driver_unload -> udl_fbdev_cleanup ->
    udl_fbdev_destroy).
    
    Note that udl_fbdev_cleanup *tries* to be conditional (you can see it
    does if (!udl->fbdev)) but that doesn't work, because udl->fbdev is
    always set during udl_fbdev_init.
    
    Cc: stable@vger.kernel.org
    Suggested-by: Sean Paul <seanpaul@chromium.org>
    Reviewed-by: Sean Paul <seanpaul@chromium.org>
    Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Emil Lundmark <lndmrk@chromium.org>
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20180528142711.142466-1-lndmrk@chromium.org
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  19. drm/vc4: Fix the "no scaling" case on multi-planar YUV formats

    Boris Brezillon authored and gregkh committed Jul 25, 2018
    commit 658d8cb upstream.
    
    When there's no scaling requested ->is_unity should be true no matter
    the format.
    
    Also, when no scaling is requested and we have a multi-planar YUV
    format, we should leave ->y_scaling[0] to VC4_SCALING_NONE and only
    set ->x_scaling[0] to VC4_SCALING_PPF.
    
    Doing this fixes an hardly visible artifact (seen when using modetest
    and a rather big overlay plane in YUV420).
    
    Fixes: fc04023 ("drm/vc4: Add support for YUV planes.")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
    Reviewed-by: Eric Anholt <eric@anholt.net>
    Link: https://patchwork.freedesktop.org/patch/msgid/20180725122907.13702-1-boris.brezillon@bootlin.com
    Signed-off-by: Sean Paul <seanpaul@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>