1. 21 Nov, 2018 40 commits
    • Hugues Fruchet's avatar
      media: ov5640: fix mode change regression · 7e0a5da5
      Hugues Fruchet authored
      [ Upstream commit fb98e29f ]
      
      fixes: 6949d864 ("media: ov5640: do not change mode if format or frame interval is unchanged").
      
      Symptom was fuzzy image because of JPEG default format
      not being changed according to new format selected, fix this.
      Init sequence initialises format to YUV422 UYVY but
      sensor->fmt initial value was set to JPEG, fix this.
      Signed-off-by: default avatarHugues Fruchet <hugues.fruchet@st.com>
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7e0a5da5
    • Sébastien Szymanski's avatar
      ARM: dts: imx6ull: keep IMX6UL_ prefix for signals on both i.MX6UL and i.MX6ULL · 2db36801
      Sébastien Szymanski authored
      [ Upstream commit 31edaa6e ]
      
      Signals available on both i.MX6UL and i.MX6ULL should have the same name
      because it is the case of all others common signals, it avoids to make
      mistakes (use the wrong ones) and it makes writing device tree files
      less complicated. For example:
      
      imx6ul-imx6ull-board.dtsi:
       ...
       pinctrl_uart5: uart5grp {
      	fsl,pins = <
      		MX6UL_PAD_UART5_TX_DATA__UART5_DCE_TX   0x1b0b1
      	 	MX6UL_PAD_UART5_RX_DATA__UART5_DCE_RX   0x1b0b1
       	 >;
       };
      
      imx6ul-board.dts:
       #include <imx6ul.dtsi>
       #include <imx6ul-imx6ull-board.dtsi>
       ...
      
      imx6ull-board.dts:
       #include <imx6ull.dtsi>
       #include <imx6ul-imx6ull-board.dtsi>
       ...
      
      Without this patch, the imx6ull-board.dtb will use
      MX6UL_PAD_UART5_RX_DATA__UART5_DCE_RX instead of
      MX6ULL_PAD_UART5_RX_DATA__UART5_DCE_RX and the uart5 will be
      misconfigured.
      Signed-off-by: default avatarSébastien Szymanski <sebastien.szymanski@armadeus.com>
      Reviewed-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2db36801
    • Jan Kara's avatar
      udf: Prevent write-unsupported filesystem to be remounted read-write · 8035d1a1
      Jan Kara authored
      [ Upstream commit a9ad01bc ]
      
      There are certain filesystem features which we support for reading but
      not for writing. We properly refuse to mount such filesystems read-write
      however for some features (such as read-only partitions), we don't check
      for these features when remounting the filesystem from read-only to
      read-write. Thus such filesystems could be remounted read-write leading
      to strange behavior (most likely crashes).
      
      Fix the problem by marking in superblock whether the filesystem has some
      features that are supported in read-only mode and check this flag during
      remount.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8035d1a1
    • Dominique Martinet's avatar
      9p locks: fix glock.client_id leak in do_lock · 949fd0ea
      Dominique Martinet authored
      [ Upstream commit b4dc44b3 ]
      
      the 9p client code overwrites our glock.client_id pointing to a static
      buffer by an allocated string holding the network provided value which
      we do not care about; free and reset the value as appropriate.
      
      This is almost identical to the leak in v9fs_file_getlock() fixed by
      Al Viro in commit ce85dd58 ("9p: we are leaking glock.client_id
      in v9fs_file_getlock()"), which was returned as an error by a coverity
      false positive -- while we are here attempt to make the code slightly
      more robust to future change of the net/9p/client code and hopefully
      more clear to coverity that there is no problem.
      
      Link: http://lkml.kernel.org/r/1536339057-21974-5-git-send-email-asmadeus@codewreck.orgSigned-off-by: default avatarDominique Martinet <dominique.martinet@cea.fr>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      949fd0ea
    • Colin Ian King's avatar
      staging: most: video: fix registration of an empty comp core_component · e55677b9
      Colin Ian King authored
      [ Upstream commit 1f447e51 ]
      
      Currently we have structrues comp (which is empty) and comp_info being
      used to register and deregister the component.  This mismatch in naming
      occurred from a previous commit that renamed aim_info to comp. Fix this
      to use consistent component naming in line with most/net, most/sound etc.
      
      This fixes the message two issues, one with a null empty name when
      loading the module:
      
      [ 1485.269515] most_core: registered new core component (null)
      
      and an Oops when removing the module:
      
      [ 1485.277971] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      [ 1485.278648] PGD 0 P4D 0
      [ 1485.279253] Oops: 0002 [#2] SMP PTI
      [ 1485.279847] CPU: 1 PID: 32629 Comm: modprobe Tainted: P      D WC OE     4.18.0-8-generic #9
      [ 1485.280442] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
      [ 1485.281040] RIP: 0010:most_deregister_component+0x3c/0x70 [most_core]
      .. etc
      
      Fixes: 1b10a031 ("staging: most: video: remove aim designators")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e55677b9
    • Andrey Grodzovsky's avatar
      drm/amdgpu: Fix SDMA TO after GPU reset v3 · 3b6ff8eb
      Andrey Grodzovsky authored
      [ Upstream commit d8de8260 ]
      
      After GPU reset amdgpu_vm_clear_bo triggers VM flush
      but job->vm_pd_addr is not set causing SDMA TO.
      
      v2:
      Per advise by Christian König avoid flushing VM for jobs where
      job->vm_pd_addr wasn't explicitly set.
      
      v3:
      Shortcut vm_flush_needed early.
      
      Fixes cbd52851 drm/amdgpu: move setting the GART addr into TTM.
      Signed-off-by: default avatarAndrey Grodzovsky <andrey.grodzovsky@amd.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3b6ff8eb
    • Kieran Bingham's avatar
      drm: rcar-du: Update Gen3 output limitations · d6a4baf4
      Kieran Bingham authored
      [ Upstream commit 2a3181d9 ]
      
      The R-Car Gen3 DU utilises the VSP1 hardware for memory access. The
      limits on the RPF and WPF in this pipeline are 8190x8190.
      
      Update the supported maximum sizes accordingly.
      Signed-off-by: default avatarKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
      Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d6a4baf4
    • Alexandru Ardelean's avatar
      staging:iio:ad7606: fix voltage scales · 73ad8868
      Alexandru Ardelean authored
      [ Upstream commit 4ee03330 ]
      
      Fixes commit 17be2a29 ("staging: iio:
      ad7606: replace range/range_available with corresponding scale").
      
      The AD7606 devices don't have a 2.5V voltage range, they have 5V & 10V
      voltage range, which is selectable via the `gpio_range` descriptor.
      
      The scales also seem to have been miscomputed, because when they were
      applied to the raw values, the results differ from the expected values.
      After checking the ADC transfer function in the datasheet, these were
      re-computed.
      Signed-off-by: default avatarAlexandru Ardelean <alexandru.ardelean@analog.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73ad8868
    • Breno Leitao's avatar
      powerpc/selftests: Wait all threads to join · 38672b57
      Breno Leitao authored
      [ Upstream commit 693b31b2 ]
      
      Test tm-tmspr might exit before all threads stop executing, because it just
      waits for the very last thread to join before proceeding/exiting.
      
      This patch makes sure that all threads that were created will join before
      proceeding/exiting.
      
      This patch also guarantees that the amount of threads being created is equal
      to thread_num.
      Signed-off-by: default avatarBreno Leitao <leitao@debian.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      38672b57
    • Marco Felsch's avatar
      media: tvp5150: fix width alignment during set_selection() · 733b1b42
      Marco Felsch authored
      [ Upstream commit bd24db04 ]
      
      The driver ignored the width alignment which exists due to the UYVY
      colorspace format. Fix the width alignment and make use of the the
      provided v4l2 helper function to set the width, height and all
      alignments in one.
      
      Fixes: 963ddc63 ("[media] media: tvp5150: Add cropping support")
      Signed-off-by: default avatarMarco Felsch <m.felsch@pengutronix.de>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      733b1b42
    • Phil Elwell's avatar
      sc16is7xx: Fix for multi-channel stall · c50363de
      Phil Elwell authored
      [ Upstream commit 83444987 ]
      
      The SC16IS752 is a dual-channel device. The two channels are largely
      independent, but the IRQ signals are wired together as an open-drain,
      active low signal which will be driven low while either of the
      channels requires attention, which can be for significant periods of
      time until operations complete and the interrupt can be acknowledged.
      In that respect it is should be treated as a true level-sensitive IRQ.
      
      The kernel, however, needs to be able to exit interrupt context in
      order to use I2C or SPI to access the device registers (which may
      involve sleeping).  Therefore the interrupt needs to be masked out or
      paused in some way.
      
      The usual way to manage sleeping from within an interrupt handler
      is to use a threaded interrupt handler - a regular interrupt routine
      does the minimum amount of work needed to triage the interrupt before
      waking the interrupt service thread. If the threaded IRQ is marked as
      IRQF_ONESHOT the kernel will automatically mask out the interrupt
      until the thread runs to completion. The sc16is7xx driver used to
      use a threaded IRQ, but a patch switched to using a kthread_worker
      in order to set realtime priorities on the handler thread and for
      other optimisations. The end result is non-threaded IRQ that
      schedules some work then returns IRQ_HANDLED, making the kernel
      think that all IRQ processing has completed.
      
      The work-around to prevent a constant stream of interrupts is to
      mark the interrupt as edge-sensitive rather than level-sensitive,
      but interpreting an active-low source as a falling-edge source
      requires care to prevent a total cessation of interrupts. Whereas
      an edge-triggering source will generate a new edge for every interrupt
      condition a level-triggering source will keep the signal at the
      interrupting level until it no longer requires attention; in other
      words, the host won't see another edge until all interrupt conditions
      are cleared. It is therefore vital that the interrupt handler does not
      exit with an outstanding interrupt condition, otherwise the kernel
      will not receive another interrupt unless some other operation causes
      the interrupt state on the device to be cleared.
      
      The existing sc16is7xx driver has a very simple interrupt "thread"
      (kthread_work job) that processes interrupts on each channel in turn
      until there are no more. If both channels are active and the first
      channel starts interrupting while the handler for the second channel
      is running then it will not be detected and an IRQ stall ensues. This
      could be handled easily if there was a shared IRQ status register, or
      a convenient way to determine if the IRQ had been deasserted for any
      length of time, but both appear to be lacking.
      
      Avoid this problem (or at least make it much less likely to happen)
      by reducing the granularity of per-channel interrupt processing
      to one condition per iteration, only exiting the overall loop when
      both channels are no longer interrupting.
      Signed-off-by: default avatarPhil Elwell <phil@raspberrypi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c50363de
    • John Garry's avatar
      serial: 8250_of: Fix for lack of interrupt support · ff8bf852
      John Garry authored
      [ Upstream commit a27d9382 ]
      
      In commit c58caaab ("serial: 8250: of: Defer probe on missing IRQ"), a
      check was added for the UART driver being probed prior to the parent IRQ
      controller.
      
      Unfortunately this breaks certain boards which have no interrupt support,
      like Huawei D03.
      
      Indeed, the 8250 DT bindings state that interrupts should be supported -
      not must.
      
      To fix, switch from irq_of_parse_and_map() to of_irq_get(), which
      does relay whether the IRQ host controller domain is not ready, i.e.
      defer probe, instead of assuming it.
      
      Fixes: c58caaab ("serial: 8250: of: Defer probe on missing IRQ")
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Reviewed-by: default avatarAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Tested-by: default avatarAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ff8bf852
    • Gao Xiang's avatar
      staging: erofs: fix a missing endian conversion · 19527c62
      Gao Xiang authored
      [ Upstream commit 37ec35a6 ]
      
      This patch fixes a missing endian conversion in
      vle_get_logical_extent_head.
      Reviewed-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarGao Xiang <gaoxiang25@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      19527c62
    • Huacai Chen's avatar
      MIPS/PCI: Call pcie_bus_configure_settings() to set MPS/MRRS · 92db94fa
      Huacai Chen authored
      [ Upstream commit 2794f688 ]
      
      Call pcie_bus_configure_settings() on MIPS, like for other platforms.
      The function pcie_bus_configure_settings() makes sure the MPS (Max
      Payload Size) across the bus is uniform and provides the ability to
      tune the MRSS (Max Read Request Size) and MPS (Max Payload Size) to
      higher performance values. Some devices will not operate properly if
      these aren't set correctly because the firmware doesn't always do it.
      Signed-off-by: default avatarHuacai Chen <chenhc@lemote.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20649/
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: Fuxin Zhang <zhangfx@lemote.com>
      Cc: Zhangjin Wu <wuzhangjin@gmail.com>
      Cc: Huacai Chen <chenhuacai@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      92db94fa
    • Rashmica Gupta's avatar
      powerpc/memtrace: Remove memory in chunks · 75837895
      Rashmica Gupta authored
      [ Upstream commit 3f7daf3d ]
      
      When hot-removing memory release_mem_region_adjustable() splits iomem
      resources if they are not the exact size of the memory being
      hot-deleted. Adding this memory back to the kernel adds a new resource.
      
      Eg a node has memory 0x0 - 0xfffffffff. Hot-removing 1GB from
      0xf40000000 results in the single resource 0x0-0xfffffffff being split
      into two resources: 0x0-0xf3fffffff and 0xf80000000-0xfffffffff.
      
      When we hot-add the memory back we now have three resources:
      0x0-0xf3fffffff, 0xf40000000-0xf7fffffff, and 0xf80000000-0xfffffffff.
      
      This is an issue if we try to remove some memory that overlaps
      resources. Eg when trying to remove 2GB at address 0xf40000000,
      release_mem_region_adjustable() fails as it expects the chunk of memory
      to be within the boundaries of a single resource. We then get the
      warning: "Unable to release resource" and attempting to use memtrace
      again gives us this error: "bash: echo: write error: Resource
      temporarily unavailable"
      
      This patch makes memtrace remove memory in chunks that are always the
      same size from an address that is always equal to end_of_memory -
      n*size, for some n. So hotremoving and hotadding memory of different
      sizes will now not attempt to remove memory that spans multiple
      resources.
      Signed-off-by: default avatarRashmica Gupta <rashmica.g@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      75837895
    • Joel Stanley's avatar
      powerpc/boot: Ensure _zimage_start is a weak symbol · ce62cb99
      Joel Stanley authored
      [ Upstream commit ee9d21b3 ]
      
      When building with clang crt0's _zimage_start is not marked weak, which
      breaks the build when linking the kernel image:
      
       $ objdump -t arch/powerpc/boot/crt0.o |grep _zimage_start$
       0000000000000058 g       .text  0000000000000000 _zimage_start
      
       ld: arch/powerpc/boot/wrapper.a(crt0.o): in function '_zimage_start':
       (.text+0x58): multiple definition of '_zimage_start';
       arch/powerpc/boot/pseries-head.o:(.text+0x0): first defined here
      
      Clang requires the .weak directive to appear after the symbol is
      declared. The binutils manual says:
      
       This directive sets the weak attribute on the comma separated list of
       symbol names. If the symbols do not already exist, they will be
       created.
      
      So it appears this is different with clang. The only reference I could
      see for this was an OpenBSD mailing list post[1].
      
      Changing it to be after the declaration fixes building with Clang, and
      still works with GCC.
      
       $ objdump -t arch/powerpc/boot/crt0.o |grep _zimage_start$
       0000000000000058  w      .text	0000000000000000 _zimage_start
      
      Reported to clang as https://bugs.llvm.org/show_bug.cgi?id=38921
      
      [1] https://groups.google.com/forum/#!topic/fa.openbsd.tech/PAgKKen2YCYSigned-off-by: default avatarJoel Stanley <joel@jms.id.au>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ce62cb99
    • Dengcheng Zhu's avatar
      MIPS: kexec: Mark CPU offline before disabling local IRQ · 754b404d
      Dengcheng Zhu authored
      [ Upstream commit dc57aaf9 ]
      
      After changing CPU online status, it will not be sent any IPIs such as in
      __flush_cache_all() on software coherency systems. Do this before disabling
      local IRQ.
      Signed-off-by: default avatarDengcheng Zhu <dzhu@wavecomp.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20571/
      Cc: pburton@wavecomp.com
      Cc: ralf@linux-mips.org
      Cc: linux-mips@linux-mips.org
      Cc: rachel.mozes@intel.com
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      754b404d
    • Lucas Stach's avatar
      media: coda: don't overwrite h.264 profile_idc on decoder instance · e066306b
      Lucas Stach authored
      [ Upstream commit 1f32061e ]
      
      On a decoder instance, after the profile has been parsed from the stream
      __v4l2_ctrl_s_ctrl() is called to notify userspace about changes in the
      read-only profile control. This ends up calling back into the CODA driver
      where a missing check on the s_ctrl caused the profile information that has
      just been parsed from the stream to be overwritten with the default
      baseline profile.
      
      Later on the driver fails to enable frame reordering, based on the wrong
      profile information.
      
      Fixes: 347de126d1da (media: coda: add read-only h.264 decoder
                           profile/level controls)
      Signed-off-by: default avatarLucas Stach <l.stach@pengutronix.de>
      Reviewed-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e066306b
    • Nicholas Mc Guire's avatar
      media: pci: cx23885: handle adding to list failure · b3ad2c52
      Nicholas Mc Guire authored
      [ Upstream commit c5d59528 ]
      
      altera_hw_filt_init() which calls append_internal() assumes
      that the node was successfully linked in while in fact it can
      silently fail. So the call-site needs to set return to -ENOMEM
      on append_internal() returning NULL and exit through the err path.
      
      Fixes: 349bcf02 ("[media] Altera FPGA based CI driver module")
      Signed-off-by: default avatarNicholas Mc Guire <hofrat@osadl.org>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b3ad2c52
    • John Garry's avatar
      drm/hisilicon: hibmc: Do not carry error code in HiBMC framebuffer pointer · 85c2f31a
      John Garry authored
      [ Upstream commit 331d880b ]
      
      In hibmc_drm_fb_create(), when the call to hibmc_framebuffer_init() fails
      with error, do not store the error code in the HiBMC device frame-buffer
      pointer, as this will be later checked for non-zero value in
      hibmc_fbdev_destroy() when our intention is to check for a valid function
      pointer.
      
      This fixes the following crash:
      [    9.699791] Unable to handle kernel NULL pointer dereference at virtual address 000000000000001a
      [    9.708672] Mem abort info:
      [    9.711489]   ESR = 0x96000004
      [    9.714570]   Exception class = DABT (current EL), IL = 32 bits
      [    9.720551]   SET = 0, FnV = 0
      [    9.723631]   EA = 0, S1PTW = 0
      [    9.726799] Data abort info:
      [    9.729702]   ISV = 0, ISS = 0x00000004
      [    9.733573]   CM = 0, WnR = 0
      [    9.736566] [000000000000001a] user address but active_mm is swapper
      [    9.742987] Internal error: Oops: 96000004 [#1] PREEMPT SMP
      [    9.748614] Modules linked in:
      [    9.751694] CPU: 16 PID: 293 Comm: kworker/16:1 Tainted: G        W         4.19.0-rc4-next-20180920-00001-g9b0012c #322
      [    9.762681] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018
      [    9.771915] Workqueue: events work_for_cpu_fn
      [    9.776312] pstate: 60000005 (nZCv daif -PAN -UAO)
      [    9.781150] pc : drm_mode_object_put+0x0/0x20
      [    9.785547] lr : hibmc_fbdev_fini+0x40/0x58
      [    9.789767] sp : ffff00000af1bcf0
      [    9.793108] x29: ffff00000af1bcf0 x28: 0000000000000000
      [    9.798473] x27: 0000000000000000 x26: ffff000008f66630
      [    9.803838] x25: 0000000000000000 x24: ffff0000095abb98
      [    9.809203] x23: ffff8017db92fe00 x22: ffff8017d2b13000
      [    9.814568] x21: ffffffffffffffea x20: ffff8017d2f80018
      [    9.819933] x19: ffff8017d28a0018 x18: ffffffffffffffff
      [    9.825297] x17: 0000000000000000 x16: 0000000000000000
      [    9.830662] x15: ffff0000092296c8 x14: ffff00008939970f
      [    9.836026] x13: ffff00000939971d x12: ffff000009229940
      [    9.841391] x11: ffff0000085f8fc0 x10: ffff00000af1b9a0
      [    9.846756] x9 : 000000000000000d x8 : 6620657a696c6169
      [    9.852121] x7 : ffff8017d3340580 x6 : ffff8017d4168000
      [    9.857486] x5 : 0000000000000000 x4 : ffff8017db92fb20
      [    9.862850] x3 : 0000000000002690 x2 : ffff8017d3340480
      [    9.868214] x1 : 0000000000000028 x0 : 0000000000000002
      [    9.873580] Process kworker/16:1 (pid: 293, stack limit = 0x(____ptrval____))
      [    9.880788] Call trace:
      [    9.883252]  drm_mode_object_put+0x0/0x20
      [    9.887297]  hibmc_unload+0x1c/0x80
      [    9.890815]  hibmc_pci_probe+0x170/0x3c8
      [    9.894773]  local_pci_probe+0x3c/0xb0
      [    9.898555]  work_for_cpu_fn+0x18/0x28
      [    9.902337]  process_one_work+0x1e0/0x318
      [    9.906382]  worker_thread+0x228/0x450
      [    9.910164]  kthread+0x128/0x130
      [    9.913418]  ret_from_fork+0x10/0x18
      [    9.917024] Code: a94153f3 a8c27bfd d65f03c0 d503201f (f9400c01)
      [    9.923180] ---[ end trace 2695ffa0af5be375 ]---
      
      Fixes: d1667b86 ("drm/hisilicon/hibmc: Add support for frame buffer")
      Signed-off-by: default avatarJohn Garry <john.garry@huawei.com>
      Reviewed-by: default avatarXinliang Liu <z.liuxinliang@hisilicon.com>
      Signed-off-by: default avatarXinliang Liu <z.liuxinliang@hisilicon.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      85c2f31a
    • SivapiriyanKumarasamy's avatar
      drm/amd/display: fix gamma not being applied · a1d0566c
      SivapiriyanKumarasamy authored
      [ Upstream commit 30049754 ]
      
      [WHY]
      Previously night light forced a full update by
      applying a  transfer function update regardless of if it was changed.
      This logic was removed,
      
      Now gamma surface updates are only applied when there is also a plane
      info update, this does not work in cases such as using the night light
      slider.
      
      [HOW]
      When moving the night light slider we will perform a full update if
      the gamma has changed and there is a surface, even when the surface
      has not changed. Also get stream updates in setgamma prior to
      update planes and stream.
      Signed-off-by: default avatarSivapiriyanKumarasamy <sivapiriyan.kumarasamy@amd.com>
      Reviewed-by: default avatarAnthony Koo <Anthony.Koo@amd.com>
      Acked-by: default avatarBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1d0566c
    • Nicholas Kazlauskas's avatar
      drm/amd/display: Raise dispclk value for dce120 by 15% · ce46da15
      Nicholas Kazlauskas authored
      [ Upstream commit 481f576c ]
      
      [Why]
      
      The DISPCLK value was previously requested to be 15% higher for all
      ASICs that went through the dce110 bandwidth code path. As part of a
      refactoring of dce_clocks and the dce110 set bandwidth codepath this
      was removed for power saving considerations.
      
      That change caused display corruption under certain hardware
      configurations with Vega10.
      
      [How]
      
      The 15% DISPCLK increase is brought back but only on dce110 for now.
      This is should be a temporary workaround until the root cause is sorted
      out for why this occurs on Vega (or other ASICs, if reported).
      Tested-by: default avatarNick Sarnie <sarnex@gentoo.org>
      Signed-off-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: default avatarHarry Wentland <Harry.Wentland@amd.com>
      Acked-by: default avatarBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ce46da15
    • Tomi Valkeinen's avatar
      drm/omap: fix memory barrier bug in DMM driver · 7423c288
      Tomi Valkeinen authored
      [ Upstream commit 538f66ba ]
      
      A DMM timeout "timed out waiting for done" has been observed on DRA7
      devices. The timeout happens rarely, and only when the system is under
      heavy load.
      
      Debugging showed that the timeout can be made to happen much more
      frequently by optimizing the DMM driver, so that there's almost no code
      between writing the last DMM descriptors to RAM, and writing to DMM
      register which starts the DMM transaction.
      
      The current theory is that a wmb() does not properly ensure that the
      data written to RAM is observable by all the components in the system.
      
      This DMM timeout has caused interesting (and rare) bugs as the error
      handling was not functioning properly (the error handling has been fixed
      in previous commits):
      
       * If a DMM timeout happened when a GEM buffer was being pinned for
         display on the screen, a timeout error would be shown, but the driver
         would continue programming DSS HW with broken buffer, leading to
         SYNCLOST floods and possible crashes.
      
       * If a DMM timeout happened when other user (say, video decoder) was
         pinning a GEM buffer, a timeout would be shown but if the user
         handled the error properly, no other issues followed.
      
       * If a DMM timeout happened when a GEM buffer was being released, the
         driver does not even notice the error, leading to crashes or hang
         later.
      
      This patch adds wmb() and readl() calls after the last bit is written to
      RAM, which should ensure that the execution proceeds only after the data
      is actually in RAM, and thus observable by DMM.
      
      The read-back should not be needed. Further study is required to understand
      if DMM is somehow special case and read-back is ok, or if DRA7's memory
      barriers do not work correctly.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7423c288
    • Christophe Leroy's avatar
      powerpc/mm: Don't report hugepage tables as memory leaks when using kmemleak · 5b248698
      Christophe Leroy authored
      [ Upstream commit 803d690e ]
      
      When a process allocates a hugepage, the following leak is
      reported by kmemleak. This is a false positive which is
      due to the pointer to the table being stored in the PGD
      as physical memory address and not virtual memory pointer.
      
      unreferenced object 0xc30f8200 (size 512):
        comm "mmap", pid 374, jiffies 4872494 (age 627.630s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<e32b68da>] huge_pte_alloc+0xdc/0x1f8
          [<9e0df1e1>] hugetlb_fault+0x560/0x8f8
          [<7938ec6c>] follow_hugetlb_page+0x14c/0x44c
          [<afbdb405>] __get_user_pages+0x1c4/0x3dc
          [<b8fd7cd9>] __mm_populate+0xac/0x140
          [<3215421e>] vm_mmap_pgoff+0xb4/0xb8
          [<c148db69>] ksys_mmap_pgoff+0xcc/0x1fc
          [<4fcd760f>] ret_from_syscall+0x0/0x38
      
      See commit a984506c ("powerpc/mm: Don't report PUDs as
      memory leaks when using kmemleak") for detailed explanation.
      
      To fix that, this patch tells kmemleak to ignore the allocated
      hugepage table.
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5b248698
    • Sean Paul's avatar
      drm/msm: dpu: Allow planes to extend past active display · fb4dd7a9
      Sean Paul authored
      [ Upstream commit 96fc56a7 ]
      
      The atomic_check is a bit too aggressive with respect to planes which
      leave the active area. This caused a bunch of log spew when the cursor
      got to the edge of the screen and stopped it from going all the way.
      
      This patch removes the conservative bounds checks from atomic and clips
      the dst rect such that we properly display planes which go off the
      screen.
      
      Changes in v2:
      - Apply the clip to src as well (taking into account scaling)
      Changes in v3:
      - Use drm_atomic_helper_check_plane_state() to clip src/dst
      
      Cc: Sravanthi Kollukuduru <skolluku@codeaurora.org>
      Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarJeykumar Sankaran <jsanka@codeaurora.org>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fb4dd7a9
    • Stephen Boyd's avatar
      drm/msm/disp/dpu: Use proper define for drm_encoder_init() 'encoder_type' · 721b54a6
      Stephen Boyd authored
      [ Upstream commit 2c043eef ]
      
      We got a bug report that this function oopses when trying to do a kasprintf().
      
      PC is at string+0x2c/0x60
      LR is at vsnprintf+0x28c/0x4ec
      pc : [<ffffff80088d35d8>] lr : [<ffffff80088d5fc4>] pstate: a0c00049
      sp : ffffff80095fb540
      x29: ffffff80095fb540 x28: ffffff8008ad42bc
      x27: 00000000ffffffd8 x26: 0000000000000000
      x25: ffffff8008c216c8 x24: 0000000000000000
      x23: 0000000000000000 x22: ffffff80095fb720
      x21: 0000000000000000 x20: ffffff80095fb720
      x19: ffffff80095fb6f0 x18: 000000000000000a
      x17: 00000000b42ba473 x16: ffffff800805bbe8
      x15: 00000000000a157d x14: 000000000000000c
      x13: 0000000000000000 x12: 0000ffff0000000f
      x11: 0000000000000003 x10: 0000000000000001
      x9 : 0000000000000040 x8 : 000000000000001c
      x7 : ffffffffffffffff x6 : 0000000000000000
      x5 : 0000000000000228 x4 : 0000000000000000
      x3 : ffff0a00ffffff04 x2 : 0000000000007961
      x1 : 0000000000000000 x0 : 0000000000000000
      Process kworker/3:1 (pid: 61, stack limit = 0xffffff80095f8000)
      Call trace:
      Exception stack(0xffffff80095fb400 to 0xffffff80095fb540)
      b400: 0000000000000000 0000000000000000 0000000000007961 ffff0a00ffffff04
      b420: 0000000000000000 0000000000000228 0000000000000000 ffffffffffffffff
      b440: 000000000000001c 0000000000000040 0000000000000001 0000000000000003
      b460: 0000ffff0000000f 0000000000000000 000000000000000c 00000000000a157d
      b480: ffffff800805bbe8 00000000b42ba473 000000000000000a ffffff80095fb6f0
      b4a0: ffffff80095fb720 0000000000000000 ffffff80095fb720 0000000000000000
      b4c0: 0000000000000000 ffffff8008c216c8 0000000000000000 00000000ffffffd8
      b4e0: ffffff8008ad42bc ffffff80095fb540 ffffff80088d5fc4 ffffff80095fb540
      b500: ffffff80088d35d8 00000000a0c00049 ffffff80095fb550 ffffff80080d06a4
      b520: ffffffffffffffff ffffff80088d5e0c ffffff80095fb540 ffffff80088d35d8
      [<ffffff80088d35d8>] string+0x2c/0x60
      [<ffffff80088d5fc4>] vsnprintf+0x28c/0x4ec
      [<ffffff80083973b8>] kvasprintf+0x68/0x100
      [<ffffff800839755c>] kasprintf+0x60/0x80
      [<ffffff800849cc24>] drm_encoder_init+0x134/0x164
      [<ffffff80084d9a7c>] dpu_encoder_init+0x60/0x94
      [<ffffff80084eced0>] _dpu_kms_drm_obj_init+0xa0/0x424
      [<ffffff80084ed870>] dpu_kms_hw_init+0x61c/0x6bc
      [<ffffff80084f7614>] msm_drm_bind+0x380/0x67c
      [<ffffff80085114e4>] try_to_bring_up_master+0x228/0x264
      [<ffffff80085116e8>] component_master_add_with_match+0x90/0xc0
      [<ffffff80084f722c>] msm_pdev_probe+0x260/0x2c8
      [<ffffff800851a910>] platform_drv_probe+0x58/0xa8
      [<ffffff80085185c8>] driver_probe_device+0x2d8/0x40c
      [<ffffff8008518928>] __device_attach_driver+0xd4/0x10c
      [<ffffff800851644c>] bus_for_each_drv+0xb4/0xd0
      [<ffffff8008518230>] __device_attach+0xd0/0x160
      [<ffffff8008518984>] device_initial_probe+0x24/0x30
      [<ffffff800851744c>] bus_probe_device+0x38/0x98
      [<ffffff8008517aac>] deferred_probe_work_func+0x144/0x148
      [<ffffff80080c8654>] process_one_work+0x218/0x3bc
      [<ffffff80080c883c>] process_scheduled_works+0x44/0x48
      [<ffffff80080c95bc>] worker_thread+0x288/0x32c
      [<ffffff80080cea30>] kthread+0x134/0x13c
      [<ffffff8008084750>] ret_from_fork+0x10/0x18
      Code: 910003fd 2a0403e6 eb0400ff 54000060 (38646845)
      
      Looking at the code I see that drm_encoder_init() is called from the DPU
      code with 'DRM_MODE_CONNECTOR_DSI' passed in as the 'encoder_type'
      argument (follow from _dpu_kms_initialize_dsi()). That corresponds to
      the integer 16. That is then indexed into drm_encoder_enum_list in
      drm_encoder_init() to look up the name of the encoder. If you're still
      following along, that's an encoder not a connector! We really want to
      use DRM_MODE_ENCODER_DSI (integer 6) instead of DRM_MODE_CONNECTOR_DSI
      here, or we'll go out of bounds of the encoder array. Pass the right
      thing and everything is fine.
      
      Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
      Cc: Jordan Crouse <jcrouse@codeaurora.org>
      Cc: Sean Paul <seanpaul@chromium.org>
      Fixes: 25fdd593 (drm/msm: Add SDM845 DPU support)
      Tested-by: default avatarSai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
      Reviewed-by: default avatarJeykumar Sankaran <jsanka@codeaurora.org>
      Signed-off-by: default avatarStephen Boyd <swboyd@chromium.org>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      721b54a6
    • Anders Roxell's avatar
      drm/msm/gpu: fix parameters in function msm_gpu_crashstate_capture · 9565e7c0
      Anders Roxell authored
      [ Upstream commit 6969019f ]
      
      When CONFIG_DEV_COREDUMP isn't defined msm_gpu_crashstate_capture
      doesn't pass the correct parameters.
      drivers/gpu/drm/msm/msm_gpu.c: In function ‘recover_worker’:
      drivers/gpu/drm/msm/msm_gpu.c:479:34: error: passing argument 2 of ‘msm_gpu_crashstate_capture’ from incompatible pointer type [-Werror=incompatible-pointer-types]
        msm_gpu_crashstate_capture(gpu, submit, comm, cmd);
                                        ^~~~~~
      drivers/gpu/drm/msm/msm_gpu.c:388:13: note: expected ‘char *’ but argument is of type ‘struct msm_gem_submit *’
       static void msm_gpu_crashstate_capture(struct msm_gpu *gpu, char *comm,
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/gpu/drm/msm/msm_gpu.c:479:2: error: too many arguments to function ‘msm_gpu_crashstate_capture’
        msm_gpu_crashstate_capture(gpu, submit, comm, cmd);
        ^~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/gpu/drm/msm/msm_gpu.c:388:13: note: declared here
       static void msm_gpu_crashstate_capture(struct msm_gpu *gpu, char *comm,
      
      In current code the function msm_gpu_crashstate_capture parameters.
      
      Fixes: cdb95931 ("drm/msm/gpu: Add the buffer objects from the submit to the crash dump")
      Signed-off-by: default avatarAnders Roxell <anders.roxell@linaro.org>
      Reviewed-By: default avatarJordan Crouse <jcrouse@codeaurora.org>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9565e7c0
    • Daniel Axtens's avatar
      powerpc/nohash: fix undefined behaviour when testing page size support · b0f85991
      Daniel Axtens authored
      [ Upstream commit f5e28480 ]
      
      When enumerating page size definitions to check hardware support,
      we construct a constant which is (1U << (def->shift - 10)).
      
      However, the array of page size definitions is only initalised for
      various MMU_PAGE_* constants, so it contains a number of 0-initialised
      elements with def->shift == 0. This means we end up shifting by a
      very large number, which gives the following UBSan splat:
      
      ================================================================================
      UBSAN: Undefined behaviour in /home/dja/dev/linux/linux/arch/powerpc/mm/tlb_nohash.c:506:21
      shift exponent 4294967286 is too large for 32-bit type 'unsigned int'
      CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc3-00045-ga604f927b012-dirty #6
      Call Trace:
      [c00000000101bc20] [c000000000a13d54] .dump_stack+0xa8/0xec (unreliable)
      [c00000000101bcb0] [c0000000004f20a8] .ubsan_epilogue+0x18/0x64
      [c00000000101bd30] [c0000000004f2b10] .__ubsan_handle_shift_out_of_bounds+0x110/0x1a4
      [c00000000101be20] [c000000000d21760] .early_init_mmu+0x1b4/0x5a0
      [c00000000101bf10] [c000000000d1ba28] .early_setup+0x100/0x130
      [c00000000101bf90] [c000000000000528] start_here_multiplatform+0x68/0x80
      ================================================================================
      
      Fix this by first checking if the element exists (shift != 0) before
      constructing the constant.
      Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b0f85991
    • Fabio Estevam's avatar
      ARM: imx_v6_v7_defconfig: Select CONFIG_TMPFS_POSIX_ACL · 270cbdee
      Fabio Estevam authored
      [ Upstream commit 35d3cbe8 ]
      
      Andreas Müller reports:
      
      "Fixes:
      
      | Sep 04 09:05:10 imx6qdl-variscite-som systemd-udevd[220]: Failed to apply ACL on /dev/v4l-subdev0: Operation not supported
      | Sep 04 09:05:10 imx6qdl-variscite-som systemd-udevd[224]: Failed to apply ACL on /dev/v4l-subdev1: Operation not supported
      | Sep 04 09:05:10 imx6qdl-variscite-som systemd-udevd[215]: Failed to apply ACL on /dev/v4l-subdev10: Operation not supported
      | Sep 04 09:05:10 imx6qdl-variscite-som systemd-udevd[228]: Failed to apply ACL on /dev/v4l-subdev2: Operation not supported
      | Sep 04 09:05:10 imx6qdl-variscite-som systemd-udevd[232]: Failed to apply ACL on /dev/v4l-subdev5: Operation not supported
      | Sep 04 09:05:10 imx6qdl-variscite-som systemd-udevd[217]: Failed to apply ACL on /dev/v4l-subdev11: Operation not supported
      | Sep 04 09:05:10 imx6qdl-variscite-som systemd-udevd[214]: Failed to apply ACL on /dev/dri/card1: Operation not supported
      | Sep 04 09:05:10 imx6qdl-variscite-som systemd-udevd[216]: Failed to apply ACL on /dev/v4l-subdev8: Operation not supported
      | Sep 04 09:05:10 imx6qdl-variscite-som systemd-udevd[226]: Failed to apply ACL on /dev/v4l-subdev9: Operation not supported
      
      and nasty follow-ups: Starting weston from sddm as unpriviledged user fails
      with some hints on missing access rights."
      
      Select the CONFIG_TMPFS_POSIX_ACL option to fix these issues.
      Reported-by: default avatarAndreas Müller <schnitzeltony@gmail.com>
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      Acked-by: default avatarOtavio Salvador <otavio@ossystems.com.br>
      Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      270cbdee
    • Colin Ian King's avatar
      drm/amdgpu/powerplay: fix missing break in switch statements · 17a5d018
      Colin Ian King authored
      [ Upstream commit 14b28483 ]
      
      There are several switch statements that are missing break statements.
      Add missing breaks to handle any fall-throughs corner cases.
      
      Detected by CoverityScan, CID#1457175 ("Missing break in switch")
      
      Fixes: 18aafc59 ("drm/amd/powerplay: implement fw related smu interface for iceland.")
      Acked-by: default avatarHuang Rui <ray.huang@amd.com>
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      17a5d018
    • Gustavo A. R. Silva's avatar
      drm/nouveau/secboot/acr: fix memory leak · 05dff1e2
      Gustavo A. R. Silva authored
      [ Upstream commit 74a07c0a ]
      
      In case memory resources for *bl_desc* were allocated, release
      them before return.
      
      Addresses-Coverity-ID: 1472021 ("Resource leak")
      Fixes: 0d466901 ("drm/nouveau/secboot/acr: Remove VLA usage")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Reviewed-by: default avatarJohn Hubbard <jhubbard@nvidia.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      05dff1e2
    • Masami Hiramatsu's avatar
      tracing/kprobes: Check the probe on unloaded module correctly · 784c2eb3
      Masami Hiramatsu authored
      [ Upstream commit 59158ec4 ]
      
      Current kprobe event doesn't checks correctly whether the
      given event is on unloaded module or not. It just checks
      the event has ":" in the name.
      
      That is not enough because if we define a probe on non-exist
      symbol on loaded module, it allows to define that (with
      warning message)
      
      To ensure it correctly, this searches the module name on
      loaded module list and only if there is not, it allows to
      define it. (this event will be available when the target
      module is loaded)
      
      Link: http://lkml.kernel.org/r/153547309528.26502.8300278470528281328.stgit@devboxSigned-off-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      784c2eb3
    • Miles Chen's avatar
      tty: check name length in tty_find_polling_driver() · 7ecd146b
      Miles Chen authored
      [ Upstream commit 33a1a7be ]
      
      The issue is found by a fuzzing test.
      If tty_find_polling_driver() recevies an incorrect input such as
      ',,' or '0b', the len becomes 0 and strncmp() always return 0.
      In this case, a null p->ops->poll_init() is called and it causes a kernel
      panic.
      
      Fix this by checking name length against zero in tty_find_polling_driver().
      
      $echo ,, > /sys/module/kgdboc/parameters/kgdboc
      [   20.804451] WARNING: CPU: 1 PID: 104 at drivers/tty/serial/serial_core.c:457
      uart_get_baud_rate+0xe8/0x190
      [   20.804917] Modules linked in:
      [   20.805317] CPU: 1 PID: 104 Comm: sh Not tainted 4.19.0-rc7ajb #8
      [   20.805469] Hardware name: linux,dummy-virt (DT)
      [   20.805732] pstate: 20000005 (nzCv daif -PAN -UAO)
      [   20.805895] pc : uart_get_baud_rate+0xe8/0x190
      [   20.806042] lr : uart_get_baud_rate+0xc0/0x190
      [   20.806476] sp : ffffffc06acff940
      [   20.806676] x29: ffffffc06acff940 x28: 0000000000002580
      [   20.806977] x27: 0000000000009600 x26: 0000000000009600
      [   20.807231] x25: ffffffc06acffad0 x24: 00000000ffffeff0
      [   20.807576] x23: 0000000000000001 x22: 0000000000000000
      [   20.807807] x21: 0000000000000001 x20: 0000000000000000
      [   20.808049] x19: ffffffc06acffac8 x18: 0000000000000000
      [   20.808277] x17: 0000000000000000 x16: 0000000000000000
      [   20.808520] x15: ffffffffffffffff x14: ffffffff00000000
      [   20.808757] x13: ffffffffffffffff x12: 0000000000000001
      [   20.809011] x11: 0101010101010101 x10: ffffff880d59ff5f
      [   20.809292] x9 : ffffff880d59ff5e x8 : ffffffc06acffaf3
      [   20.809549] x7 : 0000000000000000 x6 : ffffff880d59ff5f
      [   20.809803] x5 : 0000000080008001 x4 : 0000000000000003
      [   20.810056] x3 : ffffff900853e6b4 x2 : dfffff9000000000
      [   20.810693] x1 : ffffffc06acffad0 x0 : 0000000000000cb0
      [   20.811005] Call trace:
      [   20.811214]  uart_get_baud_rate+0xe8/0x190
      [   20.811479]  serial8250_do_set_termios+0xe0/0x6f4
      [   20.811719]  serial8250_set_termios+0x48/0x54
      [   20.811928]  uart_set_options+0x138/0x1bc
      [   20.812129]  uart_poll_init+0x114/0x16c
      [   20.812330]  tty_find_polling_driver+0x158/0x200
      [   20.812545]  configure_kgdboc+0xbc/0x1bc
      [   20.812745]  param_set_kgdboc_var+0xb8/0x150
      [   20.812960]  param_attr_store+0xbc/0x150
      [   20.813160]  module_attr_store+0x40/0x58
      [   20.813364]  sysfs_kf_write+0x8c/0xa8
      [   20.813563]  kernfs_fop_write+0x154/0x290
      [   20.813764]  vfs_write+0xf0/0x278
      [   20.813951]  __arm64_sys_write+0x84/0xf4
      [   20.814400]  el0_svc_common+0xf4/0x1dc
      [   20.814616]  el0_svc_handler+0x98/0xbc
      [   20.814804]  el0_svc+0x8/0xc
      [   20.822005] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
      [   20.826913] Mem abort info:
      [   20.827103]   ESR = 0x84000006
      [   20.827352]   Exception class = IABT (current EL), IL = 16 bits
      [   20.827655]   SET = 0, FnV = 0
      [   20.827855]   EA = 0, S1PTW = 0
      [   20.828135] user pgtable: 4k pages, 39-bit VAs, pgdp = (____ptrval____)
      [   20.828484] [0000000000000000] pgd=00000000aadee003, pud=00000000aadee003, pmd=0000000000000000
      [   20.829195] Internal error: Oops: 84000006 [#1] SMP
      [   20.829564] Modules linked in:
      [   20.829890] CPU: 1 PID: 104 Comm: sh Tainted: G        W         4.19.0-rc7ajb #8
      [   20.830545] Hardware name: linux,dummy-virt (DT)
      [   20.830829] pstate: 60000085 (nZCv daIf -PAN -UAO)
      [   20.831174] pc :           (null)
      [   20.831457] lr : serial8250_do_set_termios+0x358/0x6f4
      [   20.831727] sp : ffffffc06acff9b0
      [   20.831936] x29: ffffffc06acff9b0 x28: ffffff9008d7c000
      [   20.832267] x27: ffffff900969e16f x26: 0000000000000000
      [   20.832589] x25: ffffff900969dfb0 x24: 0000000000000000
      [   20.832906] x23: ffffffc06acffad0 x22: ffffff900969e160
      [   20.833232] x21: 0000000000000000 x20: ffffffc06acffac8
      [   20.833559] x19: ffffff900969df90 x18: 0000000000000000
      [   20.833878] x17: 0000000000000000 x16: 0000000000000000
      [   20.834491] x15: ffffffffffffffff x14: ffffffff00000000
      [   20.834821] x13: ffffffffffffffff x12: 0000000000000001
      [   20.835143] x11: 0101010101010101 x10: ffffff880d59ff5f
      [   20.835467] x9 : ffffff880d59ff5e x8 : ffffffc06acffaf3
      [   20.835790] x7 : 0000000000000000 x6 : ffffff880d59ff5f
      [   20.836111] x5 : c06419717c314100 x4 : 0000000000000007
      [   20.836419] x3 : 0000000000000000 x2 : 0000000000000000
      [   20.836732] x1 : 0000000000000001 x0 : ffffff900969df90
      [   20.837100] Process sh (pid: 104, stack limit = 0x(____ptrval____))
      [   20.837396] Call trace:
      [   20.837566]            (null)
      [   20.837816]  serial8250_set_termios+0x48/0x54
      [   20.838089]  uart_set_options+0x138/0x1bc
      [   20.838570]  uart_poll_init+0x114/0x16c
      [   20.838834]  tty_find_polling_driver+0x158/0x200
      [   20.839119]  configure_kgdboc+0xbc/0x1bc
      [   20.839380]  param_set_kgdboc_var+0xb8/0x150
      [   20.839658]  param_attr_store+0xbc/0x150
      [   20.839920]  module_attr_store+0x40/0x58
      [   20.840183]  sysfs_kf_write+0x8c/0xa8
      [   20.840183]  sysfs_kf_write+0x8c/0xa8
      [   20.840440]  kernfs_fop_write+0x154/0x290
      [   20.840702]  vfs_write+0xf0/0x278
      [   20.840942]  __arm64_sys_write+0x84/0xf4
      [   20.841209]  el0_svc_common+0xf4/0x1dc
      [   20.841471]  el0_svc_handler+0x98/0xbc
      [   20.841713]  el0_svc+0x8/0xc
      [   20.842057] Code: bad PC value
      [   20.842764] ---[ end trace a8835d7de79aaadf ]---
      [   20.843134] Kernel panic - not syncing: Fatal exception
      [   20.843515] SMP: stopping secondary CPUs
      [   20.844289] Kernel Offset: disabled
      [   20.844634] CPU features: 0x0,21806002
      [   20.844857] Memory Limit: none
      [   20.845172] ---[ end Kernel panic - not syncing: Fatal exception ]---
      Signed-off-by: default avatarMiles Chen <miles.chen@mediatek.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7ecd146b
    • Sam Bobroff's avatar
      powerpc/eeh: Fix possible null deref in eeh_dump_dev_log() · 234bee8b
      Sam Bobroff authored
      [ Upstream commit f9bc28ae ]
      
      If an error occurs during an unplug operation, it's possible for
      eeh_dump_dev_log() to be called when edev->pdn is null, which
      currently leads to dereferencing a null pointer.
      
      Handle this by skipping the error log for those devices.
      Signed-off-by: default avatarSam Bobroff <sbobroff@linux.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      234bee8b
    • Joel Stanley's avatar
      powerpc/Makefile: Fix PPC_BOOK3S_64 ASFLAGS · 32f2674c
      Joel Stanley authored
      [ Upstream commit 960e3002 ]
      
      Ever since commit 15a3204d ("powerpc/64s: Set assembler machine type
      to POWER4") we force -mpower4 to be passed to the assembler
      irrespective of the CFLAGS used (for Book3s 64).
      
      When building a powerpc64 kernel with clang, clang will not add -many
      to the assembler flags, so any instructions that the compiler has
      generated that are not available on power4 will cause an error:
      
        /usr/bin/as -a64 -mppc64 -mlittle-endian -mpower8 \
         -I ./arch/powerpc/include -I ./arch/powerpc/include/generated \
         -I ./include -I ./arch/powerpc/include/uapi \
         -I ./arch/powerpc/include/generated/uapi -I ./include/uapi \
         -I ./include/generated/uapi -I arch/powerpc -I arch/powerpc \
         -maltivec -mpower4 -o init/do_mounts.o /tmp/do_mounts-3b0a3d.s
        /tmp/do_mounts-51ce54.s:748: Error: unrecognized opcode: `isel'
      
      GCC does include -many, so the GCC driven gas call will succeed:
      
        as -v -I ./arch/powerpc/include -I ./arch/powerpc/include/generated -I
        ./include -I ./arch/powerpc/include/uapi
        -I ./arch/powerpc/include/generated/uapi -I ./include/uapi
        -I ./include/generated/uapi -I arch/powerpc -I arch/powerpc
         -a64 -mpower8 -many -mlittle -maltivec -mpower4 -o init/do_mounts.o
      
      Note that isel is power7 and above for IBM CPUs. GCC only generates it
      for Power9 and above, but the above test was run against the clang
      generated assembly.
      
      Peter Bergner explains:
      
        When using -many -mpower4, gas will first try and find a matching
        power4 mnemonic and failing that, it will then allow any valid
        mnemonic that gas knows about. GCC's use of -many predates me
        though.
      
        IIRC, Alan looked at trying to remove it, but I forget why he
        didn't. Could be either a gcc or gas issue at the time. I'm not sure
        whether issue still exists or not. He and I have modified how gas
        works internally a fair amount since he tried removing gcc use of
        -many.
      
        I will also note that when using -many, gas will choose the first
        mnemonic that matches in the mnemonic table and we have (mostly)
        sorted the table so that server mnemonics show up earlier in the
        table than other mnemonics, so they'll be seen/chosen first.
      
      By explicitly setting -many we can build with Clang and GCC while
      retaining the -mpower4 option.
      Signed-off-by: default avatarJoel Stanley <joel@jms.id.au>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      32f2674c
    • Randy Dunlap's avatar
      Input: wm97xx-ts - fix exit path · d7dba42c
      Randy Dunlap authored
      [ Upstream commit a3f7c3fc ]
      
      Loading then unloading wm97xx-ts.ko when CONFIG_AC97_BUS=m
      causes a WARNING: from drivers/base/driver.c:
      
      Unexpected driver unregister!
      WARNING: CPU: 0 PID: 1709 at ../drivers/base/driver.c:193 driver_unregister+0x30/0x40
      
      Fix this by only calling driver_unregister() with the same
      condition that driver_register() is called.
      
      Fixes: ae9d1b5f ("Input: wm97xx: add new AC97 bus support")
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d7dba42c
    • Su Sung Chung's avatar
      drm/amd/display: fix bug of accessing invalid memory · 139dde1e
      Su Sung Chung authored
      [ Upstream commit 43c3ff27 ]
      
      [Why]
      A loop inside of build_evenly_distributed_points function that traverse through
      the array of points become an infinite loop when m_GammaUpdates does not
      get assigned to any value.
      
      [How]
      In DMColor, clear m_gammaIsValid bit just before writting all Zeromem for
      m_GammaUpdates, to prevent calling build_evenly_distributed_points
      before m_GammaUpdates gets assigned to some value.
      Signed-off-by: default avatarSu Sung Chung <Su.Chung@amd.com>
      Reviewed-by: default avatarAric Cyr <Aric.Cyr@amd.com>
      Acked-by: default avatarBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      139dde1e
    • Christophe Leroy's avatar
      powerpc/mm: fix always true/false warning in slice.c · 56e4367f
      Christophe Leroy authored
      [ Upstream commit 37e9c674 ]
      
      This patch fixes the following warnings (obtained with make W=1).
      
      arch/powerpc/mm/slice.c: In function 'slice_range_to_mask':
      arch/powerpc/mm/slice.c:73:12: error: comparison is always true due to limited range of data type [-Werror=type-limits]
        if (start < SLICE_LOW_TOP) {
                  ^
      arch/powerpc/mm/slice.c:81:20: error: comparison is always false due to limited range of data type [-Werror=type-limits]
        if ((start + len) > SLICE_LOW_TOP) {
                          ^
      arch/powerpc/mm/slice.c: In function 'slice_mask_for_free':
      arch/powerpc/mm/slice.c:136:17: error: comparison is always true due to limited range of data type [-Werror=type-limits]
        if (high_limit <= SLICE_LOW_TOP)
                       ^
      arch/powerpc/mm/slice.c: In function 'slice_check_range_fits':
      arch/powerpc/mm/slice.c:185:12: error: comparison is always true due to limited range of data type [-Werror=type-limits]
        if (start < SLICE_LOW_TOP) {
                  ^
      arch/powerpc/mm/slice.c:195:39: error: comparison is always false due to limited range of data type [-Werror=type-limits]
        if (SLICE_NUM_HIGH && ((start + len) > SLICE_LOW_TOP)) {
                                             ^
      arch/powerpc/mm/slice.c: In function 'slice_scan_available':
      arch/powerpc/mm/slice.c:306:11: error: comparison is always true due to limited range of data type [-Werror=type-limits]
        if (addr < SLICE_LOW_TOP) {
                 ^
      arch/powerpc/mm/slice.c: In function 'get_slice_psize':
      arch/powerpc/mm/slice.c:709:11: error: comparison is always true due to limited range of data type [-Werror=type-limits]
        if (addr < SLICE_LOW_TOP) {
                 ^
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      56e4367f
    • Michael Ellerman's avatar
      powerpc/mm: Fix page table dump to work on Radix · 287deb22
      Michael Ellerman authored
      [ Upstream commit 0d923962 ]
      
      When we're running on Book3S with the Radix MMU enabled the page table
      dump currently prints the wrong addresses because it uses the wrong
      start address.
      
      Fix it to use PAGE_OFFSET rather than KERN_VIRT_START.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      287deb22
    • Nicholas Piggin's avatar
      powerpc/64/module: REL32 relocation range check · 63880b2f
      Nicholas Piggin authored
      [ Upstream commit b851ba02 ]
      
      The recent module relocation overflow crash demonstrated that we
      have no range checking on REL32 relative relocations. This patch
      implements a basic check, the same kernel that previously oopsed
      and rebooted now continues with some of these errors when loading
      the module:
      
        module_64: x_tables: REL32 527703503449812 out of range!
      
      Possibly other relocations (ADDR32, REL16, TOC16, etc.) should also have
      overflow checks.
      Signed-off-by: default avatarNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      63880b2f