1. 11 Apr, 2019 2 commits
  2. 09 Apr, 2019 2 commits
  3. 05 Apr, 2019 36 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.14.111 · 1ec8f1f0
      Greg Kroah-Hartman authored
      1ec8f1f0
    • Hans de Goede's avatar
      ACPI / video: Extend chassis-type detection with a "Lunch Box" check · 30d7823d
      Hans de Goede authored
      [ Upstream commit d693c008e3ca04db5916ff72e68ce661888a913b ]
      
      Commit 53fa1f6e ("ACPI / video: Only default only_lcd to true on
      Win8-ready _desktops_") introduced chassis type detection, limiting the
      lcd_only check for the backlight to devices where the chassis-type
      indicates their is no builtin LCD panel.
      
      The purpose of the lcd_only check is to avoid advertising a backlight
      interface on desktops, since skylake and newer machines seem to always
      have a backlight interface even if there is no LCD panel. The limiting
      of this check to desktops only was done to avoid breaking backlight
      support on some laptops which do not have the lcd flag set.
      
      The Fujitsu ESPRIMO Q910 which is a compact (NUC like) desktop machine
      has a chassis type of 0x10 aka "Lunch Box". Without the lcd_only check
      we end up falsely advertising backlight/brightness control on this
      device. This commit extend the dmi_is_desktop check to return true
      for type 0x10 to fix this.
      
      Fixes: 53fa1f6e ("ACPI / video: Only default only_lcd to true ...")
      Signed-off-by: 's avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: 's avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      30d7823d
    • Ville Syrjälä's avatar
      drm/dp/mst: Configure no_stop_bit correctly for remote i2c xfers · 5cf6953f
      Ville Syrjälä authored
      [ Upstream commit c978ae9bde582e82a04c63a4071701691dd8b35c ]
      
      We aren't supposed to force a stop+start between every i2c msg
      when performing multi message transfers. This should eg. cause
      the DDC segment address to be reset back to 0 between writing
      the segment address and reading the actual EDID extension block.
      
      To quote the E-DDC spec:
      "... this standard requires that the segment pointer be
       reset to 00h when a NO ACK or a STOP condition is received."
      
      Since we're going to touch this might as well consult the
      I2C_M_STOP flag to determine whether we want to force the stop
      or not.
      
      Cc: Brian Vincent <brainn@gmail.com>
      References: https://bugs.freedesktop.org/show_bug.cgi?id=108081Signed-off-by: 's avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180928180403.22499-1-ville.syrjala@linux.intel.comReviewed-by: 's avatarDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      5cf6953f
    • Ben Dooks's avatar
      dmaengine: tegra: avoid overflow of byte tracking · cf44af74
      Ben Dooks authored
      [ Upstream commit e486df39305864604b7e25f2a95d51039517ac57 ]
      
      The dma_desc->bytes_transferred counter tracks the number of bytes
      moved by the DMA channel. This is then used to calculate the information
      passed back in the in the tegra_dma_tx_status callback, which is usually
      fine.
      
      When the DMA channel is configured as continous, then the bytes_transferred
      counter will increase over time and eventually overflow to become negative
      so the residue count will become invalid and the ALSA sound-dma code will
      report invalid hardware pointer values to the application. This results in
      some users becoming confused about the playout position and putting audio
      data in the wrong place.
      
      To fix this issue, always ensure the bytes_transferred field is modulo the
      size of the request. We only do this for the case of the cyclic transfer
      done ISR as anyone attempting to move 2GiB of DMA data in one transfer
      is unlikely.
      
      Note, we don't fix the issue that we should /never/ transfer a negative
      number of bytes so we could make those fields unsigned.
      Reviewed-by: 's avatarDmitry Osipenko <digetx@gmail.com>
      Signed-off-by: 's avatarBen Dooks <ben.dooks@codethink.co.uk>
      Acked-by: 's avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: 's avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      cf44af74
    • Katsuhiro Suzuki's avatar
      clk: rockchip: fix frac settings of GPLL clock for rk3328 · 80433260
      Katsuhiro Suzuki authored
      [ Upstream commit a0e447b0c50240a90ab84b7126b3c06b0bab4adc ]
      
      This patch fixes settings of GPLL frequency in fractional mode for
      rk3328. In this mode, FOUTVCO is calcurated by following formula:
        FOUTVCO = FREF * FBDIV / REFDIV + ((FREF * FRAC / REFDIV) >> 24)
      
      The problem is in FREF * FRAC >> 24 term. This result always lacks
      one from target value is specified by rate member. For example first
      itme of rk3328_pll_frac_rate originally has
        - rate  : 1016064000
        - refdiv: 3
        - fbdiv : 127
        - frac  : 134217
        - FREF * FBDIV / REFDIV        = 1016000000
        - (FREF * FRAC / REFDIV) >> 24 = 63999
      Thus calculated rate is 1016063999. It seems wrong.
      
      If frac has 134218 (it is increased 1 from original value), second
      term is 64000. All other items have same situation. So this patch
      adds 1 to frac member in all items of rk3328_pll_frac_rate.
      Signed-off-by: 's avatarKatsuhiro Suzuki <katsuhiro@katsuster.net>
      Acked-by: 's avatarElaine Zhang <zhangqing@rock-chips.com>
      Signed-off-by: 's avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      80433260
    • Rafael Ávila de Espíndola's avatar
      x86/build: Mark per-CPU symbols as absolute explicitly for LLD · 1d0961c1
      Rafael Ávila de Espíndola authored
      [ Upstream commit d071ae09a4a1414c1433d5ae9908959a7325b0ad ]
      
      Accessing per-CPU variables is done by finding the offset of the
      variable in the per-CPU block and adding it to the address of the
      respective CPU's block.
      
      Section 3.10.8 of ld.bfd's documentation states:
      
        For expressions involving numbers, relative addresses and absolute
        addresses, ld follows these rules to evaluate terms:
      
        Other binary operations, that is, between two relative addresses
        not in the same section, or between a relative address and an
        absolute address, first convert any non-absolute term to an
        absolute address before applying the operator."
      
      Note that LLVM's linker does not adhere to the GNU ld's implementation
      and as such requires implicitly-absolute terms to be explicitly marked
      as absolute in the linker script. If not, it fails currently with:
      
        ld.lld: error: ./arch/x86/kernel/vmlinux.lds:153: at least one side of the expression must be absolute
        ld.lld: error: ./arch/x86/kernel/vmlinux.lds:154: at least one side of the expression must be absolute
        Makefile:1040: recipe for target 'vmlinux' failed
      
      This is not a functional change for ld.bfd which converts the term to an
      absolute symbol anyways as specified above.
      
      Based on a previous submission by Tri Vo <trong@android.com>.
      Reported-by: 's avatarDmitry Golovin <dima@golovin.in>
      Signed-off-by: 's avatarRafael Ávila de Espíndola <rafael@espindo.la>
      [ Update commit message per Boris' and Michael's suggestions. ]
      Signed-off-by: 's avatarNick Desaulniers <ndesaulniers@google.com>
      [ Massage commit message more, fix typos. ]
      Signed-off-by: 's avatarBorislav Petkov <bp@suse.de>
      Tested-by: 's avatarDmitry Golovin <dima@golovin.in>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Brijesh Singh <brijesh.singh@amd.com>
      Cc: Cao Jin <caoj.fnst@cn.fujitsu.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tri Vo <trong@android.com>
      Cc: dima@golovin.in
      Cc: morbo@google.com
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20181219190145.252035-1-ndesaulniers@google.comSigned-off-by: 's avatarSasha Levin <sashal@kernel.org>
      1d0961c1
    • Zumeng Chen's avatar
      wlcore: Fix memory leak in case wl12xx_fetch_firmware failure · d2a1b60a
      Zumeng Chen authored
      [ Upstream commit ba2ffc96321c8433606ceeb85c9e722b8113e5a7 ]
      
      Release fw_status, raw_fw_status, and tx_res_if when wl12xx_fetch_firmware
      failed instead of meaningless goto out to avoid the following memory leak
      reports(Only the last one listed):
      
      unreferenced object 0xc28a9a00 (size 512):
        comm "kworker/0:4", pid 31298, jiffies 2783204 (age 203.290s)
        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:
          [<6624adab>] kmemleak_alloc+0x40/0x74
          [<500ddb31>] kmem_cache_alloc_trace+0x1ac/0x270
          [<db4d731d>] wl12xx_chip_wakeup+0xc4/0x1fc [wlcore]
          [<76c5db53>] wl1271_op_add_interface+0x4a4/0x8f4 [wlcore]
          [<cbf30777>] drv_add_interface+0xa4/0x1a0 [mac80211]
          [<65bac325>] ieee80211_reconfig+0x9c0/0x1644 [mac80211]
          [<2817c80e>] ieee80211_restart_work+0x90/0xc8 [mac80211]
          [<7e1d425a>] process_one_work+0x284/0x42c
          [<55f9432e>] worker_thread+0x2fc/0x48c
          [<abb582c6>] kthread+0x148/0x160
          [<63144b13>] ret_from_fork+0x14/0x2c
          [< (null)>] (null)
          [<1f6e7715>] 0xffffffff
      Signed-off-by: 's avatarZumeng Chen <zumeng.chen@gmail.com>
      Signed-off-by: 's avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      d2a1b60a
    • Ondrej Mosnacek's avatar
      selinux: do not override context on context mounts · 0ce68e86
      Ondrej Mosnacek authored
      [ Upstream commit 53e0c2aa9a59a48e3798ef193d573ade85aa80f5 ]
      
      Ignore all selinux_inode_notifysecctx() calls on mounts with SBLABEL_MNT
      flag unset. This is achived by returning -EOPNOTSUPP for this case in
      selinux_inode_setsecurtity() (because that function should not be called
      in such case anyway) and translating this error to 0 in
      selinux_inode_notifysecctx().
      
      This fixes behavior of kernfs-based filesystems when mounted with the
      'context=' option. Before this patch, if a node's context had been
      explicitly set to a non-default value and later the filesystem has been
      remounted with the 'context=' option, then this node would show up as
      having the manually-set context and not the mount-specified one.
      
      Steps to reproduce:
          # mount -t cgroup2 cgroup2 /sys/fs/cgroup/unified
          # chcon unconfined_u:object_r:user_home_t:s0 /sys/fs/cgroup/unified/cgroup.stat
          # ls -lZ /sys/fs/cgroup/unified
          total 0
          -r--r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.controllers
          -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.max.depth
          -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.max.descendants
          -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.procs
          -r--r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Dec 13 10:41 cgroup.stat
          -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.subtree_control
          -rw-r--r--. 1 root root system_u:object_r:cgroup_t:s0        0 Dec 13 10:41 cgroup.threads
          # umount /sys/fs/cgroup/unified
          # mount -o context=system_u:object_r:tmpfs_t:s0 -t cgroup2 cgroup2 /sys/fs/cgroup/unified
      
      Result before:
          # ls -lZ /sys/fs/cgroup/unified
          total 0
          -r--r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.controllers
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.max.depth
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.max.descendants
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.procs
          -r--r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 0 Dec 13 10:41 cgroup.stat
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.subtree_control
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0         0 Dec 13 10:41 cgroup.threads
      
      Result after:
          # ls -lZ /sys/fs/cgroup/unified
          total 0
          -r--r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.controllers
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.max.depth
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.max.descendants
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.procs
          -r--r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.stat
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.subtree_control
          -rw-r--r--. 1 root root system_u:object_r:tmpfs_t:s0 0 Dec 13 10:41 cgroup.threads
      Signed-off-by: 's avatarOndrej Mosnacek <omosnace@redhat.com>
      Reviewed-by: 's avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: 's avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      0ce68e86
    • George Rimar's avatar
      x86/build: Specify elf_i386 linker emulation explicitly for i386 objects · 621f35e5
      George Rimar authored
      [ Upstream commit 927185c124d62a9a4d35878d7f6d432a166b74e3 ]
      
      The kernel uses the OUTPUT_FORMAT linker script command in it's linker
      scripts. Most of the time, the -m option is passed to the linker with
      correct architecture, but sometimes (at least for x86_64) the -m option
      contradicts the OUTPUT_FORMAT directive.
      
      Specifically, arch/x86/boot and arch/x86/realmode/rm produce i386 object
      files, but are linked with the -m elf_x86_64 linker flag when building
      for x86_64.
      
      The GNU linker manpage doesn't explicitly state any tie-breakers between
      -m and OUTPUT_FORMAT. But with BFD and Gold linkers, OUTPUT_FORMAT
      overrides the emulation value specified with the -m option.
      
      LLVM lld has a different behavior, however. When supplied with
      contradicting -m and OUTPUT_FORMAT values it fails with the following
      error message:
      
        ld.lld: error: arch/x86/realmode/rm/header.o is incompatible with elf_x86_64
      
      Therefore, just add the correct -m after the incorrect one (it overrides
      it), so the linker invocation looks like this:
      
        ld -m elf_x86_64 -z max-page-size=0x200000 -m elf_i386 --emit-relocs -T \
          realmode.lds header.o trampoline_64.o stack.o reboot.o -o realmode.elf
      
      This is not a functional change for GNU ld, because (although not
      explicitly documented) OUTPUT_FORMAT overrides -m EMULATION.
      
      Tested by building x86_64 kernel with GNU gcc/ld toolchain and booting
      it in QEMU.
      
       [ bp: massage and clarify text. ]
      Suggested-by: 's avatarDmitry Golovin <dima@golovin.in>
      Signed-off-by: 's avatarGeorge Rimar <grimar@accesssoftek.com>
      Signed-off-by: 's avatarTri Vo <trong@android.com>
      Signed-off-by: 's avatarBorislav Petkov <bp@suse.de>
      Tested-by: 's avatarTri Vo <trong@android.com>
      Tested-by: 's avatarNick Desaulniers <ndesaulniers@google.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Michael Matz <matz@suse.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: morbo@google.com
      Cc: ndesaulniers@google.com
      Cc: ruiu@google.com
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20190111201012.71210-1-trong@android.comSigned-off-by: 's avatarSasha Levin <sashal@kernel.org>
      621f35e5
    • Daniel Vetter's avatar
      drm/nouveau: Stop using drm_crtc_force_disable · 3025691e
      Daniel Vetter authored
      [ Upstream commit 934c5b32a5e43d8de2ab4f1566f91d7c3bf8cb64 ]
      
      The correct way for legacy drivers to update properties that need to
      do a full modeset, is to do a full modeset.
      
      Note that we don't need to call the drm_mode_config_internal helper
      because we're not changing any of the refcounted paramters.
      
      v2: Fixup error handling (Ville). Since the old code didn't bother
      I decided to just delete it instead of adding even more code for just
      error handling.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
      Cc: Sean Paul <seanpaul@chromium.org>
      Signed-off-by: 's avatarDaniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181217194303.14397-2-daniel.vetter@ffwll.chSigned-off-by: 's avatarSasha Levin <sashal@kernel.org>
      3025691e
    • Paul Kocialkowski's avatar
      drm: Auto-set allow_fb_modifiers when given modifiers at plane init · 0cab1159
      Paul Kocialkowski authored
      [ Upstream commit 890880ddfdbe256083170866e49c87618b706ac7 ]
      
      When drivers pass non-empty lists of modifiers for initializing their
      planes, we can infer that they allow framebuffer modifiers and set the
      driver's allow_fb_modifiers mode config element.
      
      In case the allow_fb_modifiers element was not set (some drivers tend
      to set them after registering planes), the modifiers will still be
      registered but won't be available to userspace unless the flag is set
      later. However in that case, the IN_FORMATS blob won't be created.
      
      In order to avoid this case and generally reduce the trouble associated
      with the flag, always set allow_fb_modifiers when a non-empty list of
      format modifiers is passed at plane init.
      Reviewed-by: 's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: 's avatarPaul Kocialkowski <paul.kocialkowski@bootlin.com>
      Signed-off-by: Maxime Ripard's avatarMaxime Ripard <maxime.ripard@bootlin.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190104085610.5829-1-paul.kocialkowski@bootlin.comSigned-off-by: 's avatarSasha Levin <sashal@kernel.org>
      0cab1159
    • Axel Lin's avatar
      regulator: act8865: Fix act8600_sudcdc_voltage_ranges setting · 8fbaad2c
      Axel Lin authored
      [ Upstream commit f01a7beb6791f1c419424c1a6958b7d0a289c974 ]
      
      The act8600_sudcdc_voltage_ranges setting does not match the datasheet.
      
      The problems in below entry:
        REGULATOR_LINEAR_RANGE(19000000, 191, 255, 400000),
      
      1. The off-by-one min_sel causes wrong volatage calculation.
         The min_sel should be 192.
      2. According to the datasheet[1] Table 7. (on page 43):
         The selector 248 (0b11111000) ~ 255 (0b11111111) are 41.400V.
      
      Also fix off-by-one for ACT8600_SUDCDC_VOLTAGE_NUM.
      
      [1] https://active-semi.com/wp-content/uploads/ACT8600_Datasheet.pdf
      
      Fixes: df3a950e ("regulator: act8865: Add act8600 support")
      Signed-off-by: 's avatarAxel Lin <axel.lin@ingics.com>
      Signed-off-by: 's avatarMark Brown <broonie@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      8fbaad2c
    • Pawe? Chmiel's avatar
      media: s5p-jpeg: Check for fmt_ver_flag when doing fmt enumeration · 644bdba7
      Pawe? Chmiel authored
      [ Upstream commit 49710c32cd9d6626a77c9f5f978a5f58cb536b35 ]
      
      Previously when doing format enumeration, it was returning all
       formats supported by driver, even if they're not supported by hw.
      Add missing check for fmt_ver_flag, so it'll be fixed and only those
       supported by hw will be returned. Similar thing is already done
       in s5p_jpeg_find_format.
      
      It was found by using v4l2-compliance tool and checking result
       of VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS test
      and using v4l2-ctl to get list of all supported formats.
      
      Tested on s5pv210-galaxys (Samsung i9000 phone).
      
      Fixes: bb677f3a ("[media] Exynos4 JPEG codec v4l2 driver")
      Signed-off-by: 's avatarPawe? Chmiel <pawel.mikolaj.chmiel@gmail.com>
      Reviewed-by: 's avatarJacek Anaszewski <jacek.anaszewski@gmail.com>
      [hverkuil-cisco@xs4all.nl: fix a few alignment issues]
      Signed-off-by: 's avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      644bdba7
    • Florian Westphal's avatar
      netfilter: physdev: relax br_netfilter dependency · 2230f5e2
      Florian Westphal authored
      [ Upstream commit 8e2f311a68494a6677c1724bdcb10bada21af37c ]
      
      Following command:
        iptables -D FORWARD -m physdev ...
      causes connectivity loss in some setups.
      
      Reason is that iptables userspace will probe kernel for the module revision
      of the physdev patch, and physdev has an artificial dependency on
      br_netfilter (xt_physdev use makes no sense unless a br_netfilter module
      is loaded).
      
      This causes the "phydev" module to be loaded, which in turn enables the
      "call-iptables" infrastructure.
      
      bridged packets might then get dropped by the iptables ruleset.
      
      The better fix would be to change the "call-iptables" defaults to 0 and
      enforce explicit setting to 1, but that breaks backwards compatibility.
      
      This does the next best thing: add a request_module call to checkentry.
      This was a stray '-D ... -m physdev' won't activate br_netfilter
      anymore.
      Signed-off-by: 's avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: 's avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      2230f5e2
    • Shunyong Yang's avatar
      dmaengine: qcom_hidma: initialize tx flags in hidma_prep_dma_* · 0999f638
      Shunyong Yang authored
      [ Upstream commit 875aac8a46424e5b73a9ff7f40b83311b609e407 ]
      
      In async_tx_test_ack(), it uses flags in struct dma_async_tx_descriptor
      to check the ACK status. As hidma reuses the descriptor in a free list
      when hidma_prep_dma_*(memcpy/memset) is called, the flag will keep ACKed
      if the descriptor has been used before. This will cause a BUG_ON in
      async_tx_quiesce().
      
        kernel BUG at crypto/async_tx/async_tx.c:282!
        Internal error: Oops - BUG: 0 1 SMP
        ...
        task: ffff8017dd3ec000 task.stack: ffff8017dd3e8000
        PC is at async_tx_quiesce+0x54/0x78 [async_tx]
        LR is at async_trigger_callback+0x98/0x110 [async_tx]
      
      This patch initializes flags in dma_async_tx_descriptor by the flags
      passed from the caller when hidma_prep_dma_*(memcpy/memset) is called.
      
      Cc: Joey Zheng <yu.zheng@hxt-semitech.com>
      Reviewed-by: 's avatarSinan Kaya <okaya@kernel.org>
      Signed-off-by: 's avatarShunyong Yang <shunyong.yang@hxt-semitech.com>
      Signed-off-by: 's avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      0999f638
    • Shunyong Yang's avatar
      dmaengine: qcom_hidma: assign channel cookie correctly · c67ed493
      Shunyong Yang authored
      [ Upstream commit 546c0547555efca8ba8c120716c325435e29df1b ]
      
      When dma_cookie_complete() is called in hidma_process_completed(),
      dma_cookie_status() will return DMA_COMPLETE in hidma_tx_status(). Then,
      hidma_txn_is_success() will be called to use channel cookie
      mchan->last_success to do additional DMA status check. Current code
      assigns mchan->last_success after dma_cookie_complete(). This causes
      a race condition of dma_cookie_status() returns DMA_COMPLETE before
      mchan->last_success is assigned correctly. The race will cause
      hidma_tx_status() return DMA_ERROR but the transaction is actually a
      success. Moreover, in async_tx case, it will cause a timeout panic
      in async_tx_quiesce().
      
       Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for
       transaction
       ...
       Call trace:
       [<ffff000008089994>] dump_backtrace+0x0/0x1f4
       [<ffff000008089bac>] show_stack+0x24/0x2c
       [<ffff00000891e198>] dump_stack+0x84/0xa8
       [<ffff0000080da544>] panic+0x12c/0x29c
       [<ffff0000045d0334>] async_tx_quiesce+0xa4/0xc8 [async_tx]
       [<ffff0000045d03c8>] async_trigger_callback+0x70/0x1c0 [async_tx]
       [<ffff0000048b7d74>] raid_run_ops+0x86c/0x1540 [raid456]
       [<ffff0000048bd084>] handle_stripe+0x5e8/0x1c7c [raid456]
       [<ffff0000048be9ec>] handle_active_stripes.isra.45+0x2d4/0x550 [raid456]
       [<ffff0000048beff4>] raid5d+0x38c/0x5d0 [raid456]
       [<ffff000008736538>] md_thread+0x108/0x168
       [<ffff0000080fb1cc>] kthread+0x10c/0x138
       [<ffff000008084d34>] ret_from_fork+0x10/0x18
      
      Cc: Joey Zheng <yu.zheng@hxt-semitech.com>
      Reviewed-by: 's avatarSinan Kaya <okaya@kernel.org>
      Signed-off-by: 's avatarShunyong Yang <shunyong.yang@hxt-semitech.com>
      Signed-off-by: 's avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      c67ed493
    • Anders Roxell's avatar
      dmaengine: imx-dma: fix warning comparison of distinct pointer types · d66f368b
      Anders Roxell authored
      [ Upstream commit 9227ab5643cb8350449502dd9e3168a873ab0e3b ]
      
      The warning got introduced by commit 930507c18304 ("arm64: add basic
      Kconfig symbols for i.MX8"). Since it got enabled for arm64. The warning
      haven't been seen before since size_t was 'unsigned int' when built on
      arm32.
      
      ../drivers/dma/imx-dma.c: In function ‘imxdma_sg_next’:
      ../include/linux/kernel.h:846:29: warning: comparison of distinct pointer types lacks a cast
         (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
                                   ^~
      ../include/linux/kernel.h:860:4: note: in expansion of macro ‘__typecheck’
         (__typecheck(x, y) && __no_side_effects(x, y))
          ^~~~~~~~~~~
      ../include/linux/kernel.h:870:24: note: in expansion of macro ‘__safe_cmp’
        __builtin_choose_expr(__safe_cmp(x, y), \
                              ^~~~~~~~~~
      ../include/linux/kernel.h:879:19: note: in expansion of macro ‘__careful_cmp’
       #define min(x, y) __careful_cmp(x, y, <)
                         ^~~~~~~~~~~~~
      ../drivers/dma/imx-dma.c:288:8: note: in expansion of macro ‘min’
        now = min(d->len, sg_dma_len(sg));
              ^~~
      
      Rework so that we use min_t and pass in the size_t that returns the
      minimum of two values, using the specified type.
      Signed-off-by: 's avatarAnders Roxell <anders.roxell@linaro.org>
      Acked-by: 's avatarOlof Johansson <olof@lixom.net>
      Reviewed-by: 's avatarFabio Estevam <festevam@gmail.com>
      Signed-off-by: 's avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      d66f368b
    • Valentin Schneider's avatar
      cpu/hotplug: Mute hotplug lockdep during init · 2ae0dd16
      Valentin Schneider authored
      [ Upstream commit ce48c457b95316b9a01b5aa9d4456ce820df94b4 ]
      
      Since we've had:
      
        commit cb538267ea1e ("jump_label/lockdep: Assert we hold the hotplug lock for _cpuslocked() operations")
      
      we've been getting some lockdep warnings during init, such as on HiKey960:
      
      [    0.820495] WARNING: CPU: 4 PID: 0 at kernel/cpu.c:316 lockdep_assert_cpus_held+0x3c/0x48
      [    0.820498] Modules linked in:
      [    0.820509] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G S                4.20.0-rc5-00051-g4cae42a #34
      [    0.820511] Hardware name: HiKey960 (DT)
      [    0.820516] pstate: 600001c5 (nZCv dAIF -PAN -UAO)
      [    0.820520] pc : lockdep_assert_cpus_held+0x3c/0x48
      [    0.820523] lr : lockdep_assert_cpus_held+0x38/0x48
      [    0.820526] sp : ffff00000a9cbe50
      [    0.820528] x29: ffff00000a9cbe50 x28: 0000000000000000
      [    0.820533] x27: 00008000b69e5000 x26: ffff8000bff4cfe0
      [    0.820537] x25: ffff000008ba69e0 x24: 0000000000000001
      [    0.820541] x23: ffff000008fce000 x22: ffff000008ba70c8
      [    0.820545] x21: 0000000000000001 x20: 0000000000000003
      [    0.820548] x19: ffff00000a35d628 x18: ffffffffffffffff
      [    0.820552] x17: 0000000000000000 x16: 0000000000000000
      [    0.820556] x15: ffff00000958f848 x14: 455f3052464d4d34
      [    0.820559] x13: 00000000769dde98 x12: ffff8000bf3f65a8
      [    0.820564] x11: 0000000000000000 x10: ffff00000958f848
      [    0.820567] x9 : ffff000009592000 x8 : ffff00000958f848
      [    0.820571] x7 : ffff00000818ffa0 x6 : 0000000000000000
      [    0.820574] x5 : 0000000000000000 x4 : 0000000000000001
      [    0.820578] x3 : 0000000000000000 x2 : 0000000000000001
      [    0.820582] x1 : 00000000ffffffff x0 : 0000000000000000
      [    0.820587] Call trace:
      [    0.820591]  lockdep_assert_cpus_held+0x3c/0x48
      [    0.820598]  static_key_enable_cpuslocked+0x28/0xd0
      [    0.820606]  arch_timer_check_ool_workaround+0xe8/0x228
      [    0.820610]  arch_timer_starting_cpu+0xe4/0x2d8
      [    0.820615]  cpuhp_invoke_callback+0xe8/0xd08
      [    0.820619]  notify_cpu_starting+0x80/0xb8
      [    0.820625]  secondary_start_kernel+0x118/0x1d0
      
      We've also had a similar warning in sched_init_smp() for every
      asymmetric system that would enable the sched_asym_cpucapacity static
      key, although that was singled out in:
      
        commit 40fa3780bac2 ("sched/core: Take the hotplug lock in sched_init_smp()")
      
      Those warnings are actually harmless, since we cannot have hotplug
      operations at the time they appear. Instead of starting to sprinkle
      useless hotplug lock operations in the init codepaths, mute the
      warnings until they start warning about real problems.
      Suggested-by: 's avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: 's avatarValentin Schneider <valentin.schneider@arm.com>
      Signed-off-by: 's avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: cai@gmx.us
      Cc: daniel.lezcano@linaro.org
      Cc: dietmar.eggemann@arm.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: longman@redhat.com
      Cc: marc.zyngier@arm.com
      Cc: mark.rutland@arm.com
      Link: https://lkml.kernel.org/r/1545243796-23224-2-git-send-email-valentin.schneider@arm.comSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      2ae0dd16
    • Buland Singh's avatar
      hpet: Fix missing '=' character in the __setup() code of hpet_mmap_enable · 96fc367d
      Buland Singh authored
      [ Upstream commit 24d48a61f2666630da130cc2ec2e526eacf229e3 ]
      
      Commit '3d035f58 ("drivers/char/hpet.c: allow user controlled mmap for
      user processes")' introduced a new kernel command line parameter hpet_mmap,
      that is required to expose the memory map of the HPET registers to
      user-space. Unfortunately the kernel command line parameter 'hpet_mmap' is
      broken and never takes effect due to missing '=' character in the __setup()
      code of hpet_mmap_enable.
      
      Before this patch:
      
      dmesg output with the kernel command line parameter hpet_mmap=1
      
      [    0.204152] HPET mmap disabled
      
      dmesg output with the kernel command line parameter hpet_mmap=0
      
      [    0.204192] HPET mmap disabled
      
      After this patch:
      
      dmesg output with the kernel command line parameter hpet_mmap=1
      
      [    0.203945] HPET mmap enabled
      
      dmesg output with the kernel command line parameter hpet_mmap=0
      
      [    0.204652] HPET mmap disabled
      
      Fixes: 3d035f58 ("drivers/char/hpet.c: allow user controlled mmap for user processes")
      Signed-off-by: 's avatarBuland Singh <bsingh@redhat.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      96fc367d
    • Song Hongyan's avatar
      HID: intel-ish: ipc: handle PIMR before ish_wakeup also clear PISR busy_clear bit · bce54df8
      Song Hongyan authored
      [ Upstream commit 2edefc056e4f0e6ec9508dd1aca2c18fa320efef ]
      
      Host driver should handle interrupt mask register earlier than wake up ish FW
      else there will be conditions when FW interrupt comes, host PIMR register still
      not set ready, so move the interrupt mask setting before ish_wakeup.
      
      Clear PISR busy_clear bit in ish_irq_handler. If not clear, there will be
      conditions host driver received a busy_clear interrupt (before the busy_clear
      mask bit is ready), it will return IRQ_NONE after check_generated_interrupt,
      the interrupt will never be cleared, causing the DEVICE not sending following
      IRQ.
      
      Since PISR clear should not be called for the CHV device we do this change.
      After the change, both ISH2HOST interrupt and busy_clear interrupt will be
      considered as interrupt from ISH, busy_clear interrupt will return IRQ_HANDLED
      from IPC_IS_BUSY check.
      Signed-off-by: 's avatarSong Hongyan <hongyan.song@intel.com>
      Acked-by: 's avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: 's avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      bce54df8
    • Timo Alho's avatar
      soc/tegra: fuse: Fix illegal free of IO base address · dd4e3eaf
      Timo Alho authored
      [ Upstream commit 51294bf6b9e897d595466dcda5a3f2751906a200 ]
      
      On cases where device tree entries for fuse and clock provider are in
      different order, fuse driver needs to defer probing. This leads to
      freeing incorrect IO base address as the fuse->base variable gets
      overwritten once during first probe invocation. This leads to the
      following spew during boot:
      
      [    3.082285] Trying to vfree() nonexistent vm area (00000000cfe8fd94)
      [    3.082308] WARNING: CPU: 5 PID: 126 at /hdd/l4t/kernel/stable/mm/vmalloc.c:1511 __vunmap+0xcc/0xd8
      [    3.082318] Modules linked in:
      [    3.082330] CPU: 5 PID: 126 Comm: kworker/5:1 Tainted: G S                4.19.7-tegra-gce119d3 #1
      [    3.082340] Hardware name: quill (DT)
      [    3.082353] Workqueue: events deferred_probe_work_func
      [    3.082364] pstate: 40000005 (nZcv daif -PAN -UAO)
      [    3.082372] pc : __vunmap+0xcc/0xd8
      [    3.082379] lr : __vunmap+0xcc/0xd8
      [    3.082385] sp : ffff00000a1d3b60
      [    3.082391] x29: ffff00000a1d3b60 x28: 0000000000000000
      [    3.082402] x27: 0000000000000000 x26: ffff000008e8b610
      [    3.082413] x25: 0000000000000000 x24: 0000000000000009
      [    3.082423] x23: ffff000009221a90 x22: ffff000009f6d000
      [    3.082432] x21: 0000000000000000 x20: 0000000000000000
      [    3.082442] x19: ffff000009f6d000 x18: ffffffffffffffff
      [    3.082452] x17: 0000000000000000 x16: 0000000000000000
      [    3.082462] x15: ffff0000091396c8 x14: 0720072007200720
      [    3.082471] x13: 0720072007200720 x12: 0720072907340739
      [    3.082481] x11: 0764076607380765 x10: 0766076307300730
      [    3.082491] x9 : 0730073007300730 x8 : 0730073007280720
      [    3.082501] x7 : 0761076507720761 x6 : 0000000000000102
      [    3.082510] x5 : 0000000000000000 x4 : 0000000000000000
      [    3.082519] x3 : ffffffffffffffff x2 : ffff000009150ff8
      [    3.082528] x1 : 3d95b1429fff5200 x0 : 0000000000000000
      [    3.082538] Call trace:
      [    3.082545]  __vunmap+0xcc/0xd8
      [    3.082552]  vunmap+0x24/0x30
      [    3.082561]  __iounmap+0x2c/0x38
      [    3.082569]  tegra_fuse_probe+0xc8/0x118
      [    3.082577]  platform_drv_probe+0x50/0xa0
      [    3.082585]  really_probe+0x1b0/0x288
      [    3.082593]  driver_probe_device+0x58/0x100
      [    3.082601]  __device_attach_driver+0x98/0xf0
      [    3.082609]  bus_for_each_drv+0x64/0xc8
      [    3.082616]  __device_attach+0xd8/0x130
      [    3.082624]  device_initial_probe+0x10/0x18
      [    3.082631]  bus_probe_device+0x90/0x98
      [    3.082638]  deferred_probe_work_func+0x74/0xb0
      [    3.082649]  process_one_work+0x1e0/0x318
      [    3.082656]  worker_thread+0x228/0x450
      [    3.082664]  kthread+0x128/0x130
      [    3.082672]  ret_from_fork+0x10/0x18
      [    3.082678] ---[ end trace 0810fe6ba772c1c7 ]---
      
      Fix this by retaining the value of fuse->base until driver has
      successfully probed.
      Signed-off-by: 's avatarTimo Alho <talho@nvidia.com>
      Acked-by: 's avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: 's avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      dd4e3eaf
    • David Tolnay's avatar
      hwrng: virtio - Avoid repeated init of completion · 7f14d931
      David Tolnay authored
      [ Upstream commit aef027db48da56b6f25d0e54c07c8401ada6ce21 ]
      
      The virtio-rng driver uses a completion called have_data to wait for a
      virtio read to be fulfilled by the hypervisor. The completion is reset
      before placing a buffer on the virtio queue and completed by the virtio
      callback once data has been written into the buffer.
      
      Prior to this commit, the driver called init_completion on this
      completion both during probe as well as when registering virtio buffers
      as part of a hwrng read operation. The second of these init_completion
      calls should instead be reinit_completion because the have_data
      completion has already been inited by probe. As described in
      Documentation/scheduler/completion.txt, "Calling init_completion() twice
      on the same completion object is most likely a bug".
      
      This bug was present in the initial implementation of virtio-rng in
      f7f510ec ("virtio: An entropy device, as suggested by hpa"). Back
      then the have_data completion was a single static completion rather than
      a member of one of potentially multiple virtrng_info structs as
      implemented later by 08e53fbd ("virtio-rng: support multiple
      virtio-rng devices"). The original driver incorrectly used
      init_completion rather than INIT_COMPLETION to reset have_data during
      read.
      
      Tested by running `head -c48 /dev/random | hexdump` within crosvm, the
      Chrome OS virtual machine monitor, and confirming that the virtio-rng
      driver successfully produces random bytes from the host.
      Signed-off-by: 's avatarDavid Tolnay <dtolnay@gmail.com>
      Tested-by: 's avatarDavid Tolnay <dtolnay@gmail.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      7f14d931
    • Akinobu Mita's avatar
      media: mt9m111: set initial frame size other than 0x0 · 0bf1f184
      Akinobu Mita authored
      [ Upstream commit 29856308137de1c21eda89411695f4fc6e9780ff ]
      
      This driver sets initial frame width and height to 0x0, which is invalid.
      So set it to selection rectangle bounds instead.
      
      This is detected by v4l2-compliance detected.
      
      Cc: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
      Cc: Michael Grzeschik <m.grzeschik@pengutronix.de>
      Cc: Marco Felsch <m.felsch@pengutronix.de>
      Signed-off-by: 's avatarAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: 's avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: 's avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      0bf1f184
    • Roger Quadros's avatar
      usb: dwc3: gadget: Fix OTG events when gadget driver isn't loaded · df4a6a26
      Roger Quadros authored
      [ Upstream commit 169e3b68cadb5775daca009ced4faf01ffd97dcf ]
      
      On v3.10a in dual-role mode, if port is in device mode
      and gadget driver isn't loaded, the OTG event interrupts don't
      come through.
      
      It seems that if the core is configured to be OTG2.0 only,
      then we can't leave the DCFG.DEVSPD at Super-speed (default)
      if we expect OTG to work properly. It must be set to High-speed.
      
      Fix this issue by configuring DCFG.DEVSPD to the supported
      maximum speed at gadget init. Device tree still needs to provide
      correct supported maximum speed for this to work.
      
      This issue wasn't present on v2.40a but is seen on v3.10a.
      It doesn't cause any side effects on v2.40a.
      Signed-off-by: 's avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: 's avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: 's avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      df4a6a26
    • Nathan Fontenot's avatar
      powerpc/pseries: Perform full re-add of CPU for topology update post-migration · 1b4283ff
      Nathan Fontenot authored
      [ Upstream commit 81b61324922c67f73813d8a9c175f3c153f6a1c6 ]
      
      On pseries systems, performing a partition migration can result in
      altering the nodes a CPU is assigned to on the destination system. For
      exampl, pre-migration on the source system CPUs are in node 1 and 3,
      post-migration on the destination system CPUs are in nodes 2 and 3.
      
      Handling the node change for a CPU can cause corruption in the slab
      cache if we hit a timing where a CPUs node is changed while cache_reap()
      is invoked. The corruption occurs because the slab cache code appears
      to rely on the CPU and slab cache pages being on the same node.
      
      The current dynamic updating of a CPUs node done in arch/powerpc/mm/numa.c
      does not prevent us from hitting this scenario.
      
      Changing the device tree property update notification handler that
      recognizes an affinity change for a CPU to do a full DLPAR remove and
      add of the CPU instead of dynamically changing its node resolves this
      issue.
      Signed-off-by: 's avatarNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: 's avatarMichael W. Bringmann <mwb@linux.vnet.ibm.com>
      Tested-by: 's avatarMichael W. Bringmann <mwb@linux.vnet.ibm.com>
      Signed-off-by: 's avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      1b4283ff
    • Manfred Schlaegl's avatar
      tty: increase the default flip buffer limit to 2*640K · 405edea4
      Manfred Schlaegl authored
      [ Upstream commit 7ab57b76ebf632bf2231ccabe26bea33868118c6 ]
      
      We increase the default limit for buffer memory allocation by a factor of
      10 to 640K to prevent data loss when using fast serial interfaces.
      
      For example when using RS485 without flow-control at speeds of 1Mbit/s
      an upwards we've run into problems such as applications being too slow
      to read out this buffer (on embedded devices based on imx53 or imx6).
      
      If you want to write transmitted data to a slow SD card and thus have
      realtime requirements, this limit can become a problem.
      
      That shouldn't be the case and 640K buffers fix such problems for us.
      
      This value is a maximum limit for allocation only. It has no effect
      on systems that currently run fine. When transmission is slow enough
      applications and hardware can keep up and increasing this limit
      doesn't change anything.
      
      It only _allows_ to allocate more than 2*64K in cases we currently fail to
      allocate memory despite having some.
      Signed-off-by: 's avatarManfred Schlaegl <manfred.schlaegl@ginzinger.com>
      Signed-off-by: 's avatarMartin Kepplinger <martin.kepplinger@ginzinger.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      405edea4
    • Chen-Yu Tsai's avatar
      backlight: pwm_bl: Use gpiod_get_value_cansleep() to get initial state · f325ee43
      Chen-Yu Tsai authored
      [ Upstream commit cec2b18832e26bc866bef2be22eff4e25bbc4034 ]
      
      gpiod_get_value() gives out a warning if access to the underlying gpiochip
      requires sleeping, which is common for I2C based chips:
      
          WARNING: CPU: 0 PID: 77 at drivers/gpio/gpiolib.c:2500 gpiod_get_value+0xd0/0x100
          Modules linked in:
          CPU: 0 PID: 77 Comm: kworker/0:2 Not tainted 4.14.0-rc3-00589-gf32897915d48-dirty #90
          Hardware name: Allwinner sun4i/sun5i Families
          Workqueue: events deferred_probe_work_func
          [<c010ec50>] (unwind_backtrace) from [<c010b784>] (show_stack+0x10/0x14)
          [<c010b784>] (show_stack) from [<c0797224>] (dump_stack+0x88/0x9c)
          [<c0797224>] (dump_stack) from [<c0125b08>] (__warn+0xe8/0x100)
          [<c0125b08>] (__warn) from [<c0125bd0>] (warn_slowpath_null+0x20/0x28)
          [<c0125bd0>] (warn_slowpath_null) from [<c037069c>] (gpiod_get_value+0xd0/0x100)
          [<c037069c>] (gpiod_get_value) from [<c03778d0>] (pwm_backlight_probe+0x238/0x508)
          [<c03778d0>] (pwm_backlight_probe) from [<c0411a2c>] (platform_drv_probe+0x50/0xac)
          [<c0411a2c>] (platform_drv_probe) from [<c0410224>] (driver_probe_device+0x238/0x2e8)
          [<c0410224>] (driver_probe_device) from [<c040e820>] (bus_for_each_drv+0x44/0x94)
          [<c040e820>] (bus_for_each_drv) from [<c040ff0c>] (__device_attach+0xb0/0x114)
          [<c040ff0c>] (__device_attach) from [<c040f4f8>] (bus_probe_device+0x84/0x8c)
          [<c040f4f8>] (bus_probe_device) from [<c040f944>] (deferred_probe_work_func+0x50/0x14c)
          [<c040f944>] (deferred_probe_work_func) from [<c013be84>] (process_one_work+0x1ec/0x414)
          [<c013be84>] (process_one_work) from [<c013ce5c>] (worker_thread+0x2b0/0x5a0)
          [<c013ce5c>] (worker_thread) from [<c0141908>] (kthread+0x14c/0x154)
          [<c0141908>] (kthread) from [<c0107ab0>] (ret_from_fork+0x14/0x24)
      
      This was missed in commit 0c9501f8 ("backlight: pwm_bl: Handle gpio
      that can sleep"). The code was then moved to a separate function in
      commit 7613c922 ("backlight: pwm_bl: Move the checks for initial power
      state to a separate function").
      
      The only usage of gpiod_get_value() is during the probe stage, which is
      safe to sleep in. Switch to gpiod_get_value_cansleep().
      
      Fixes: 0c9501f8 ("backlight: pwm_bl: Handle gpio that can sleep")
      Signed-off-by: 's avatarChen-Yu Tsai <wens@csie.org>
      Acked-by: Maxime Ripard's avatarMaxime Ripard <maxime.ripard@bootlin.com>
      Acked-by: 's avatarDaniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: 's avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      f325ee43
    • Oleg Nesterov's avatar
      cgroup/pids: turn cgroup_subsys->free() into cgroup_subsys->release() to fix the accounting · f3b3b543
      Oleg Nesterov authored
      [ Upstream commit 51bee5abeab2058ea5813c5615d6197a23dbf041 ]
      
      The only user of cgroup_subsys->free() callback is pids_cgrp_subsys which
      needs pids_free() to uncharge the pid.
      
      However, ->free() is called from __put_task_struct()->cgroup_free() and this
      is too late. Even the trivial program which does
      
      	for (;;) {
      		int pid = fork();
      		assert(pid >= 0);
      		if (pid)
      			wait(NULL);
      		else
      			exit(0);
      	}
      
      can run out of limits because release_task()->call_rcu(delayed_put_task_struct)
      implies an RCU gp after the task/pid goes away and before the final put().
      
      Test-case:
      
      	mkdir -p /tmp/CG
      	mount -t cgroup2 none /tmp/CG
      	echo '+pids' > /tmp/CG/cgroup.subtree_control
      
      	mkdir /tmp/CG/PID
      	echo 2 > /tmp/CG/PID/pids.max
      
      	perl -e 'while ($p = fork) { wait; } $p // die "fork failed: $!\n"' &
      	echo $! > /tmp/CG/PID/cgroup.procs
      
      Without this patch the forking process fails soon after migration.
      
      Rename cgroup_subsys->free() to cgroup_subsys->release() and move the callsite
      into the new helper, cgroup_release(), called by release_task() which actually
      frees the pid(s).
      Reported-by: 's avatarHerton R. Krzesinski <hkrzesin@redhat.com>
      Reported-by: 's avatarJan Stancek <jstancek@redhat.com>
      Signed-off-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: 's avatarTejun Heo <tj@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      f3b3b543
    • Valdis Kletnieks's avatar
      bpf: fix missing prototype warnings · 46b2c037
      Valdis Kletnieks authored
      [ Upstream commit 116bfa96a255123ed209da6544f74a4f2eaca5da ]
      
      Compiling with W=1 generates warnings:
      
        CC      kernel/bpf/core.o
      kernel/bpf/core.c:721:12: warning: no previous prototype for ?bpf_jit_alloc_exec_limit? [-Wmissing-prototypes]
        721 | u64 __weak bpf_jit_alloc_exec_limit(void)
            |            ^~~~~~~~~~~~~~~~~~~~~~~~
      kernel/bpf/core.c:757:14: warning: no previous prototype for ?bpf_jit_alloc_exec? [-Wmissing-prototypes]
        757 | void *__weak bpf_jit_alloc_exec(unsigned long size)
            |              ^~~~~~~~~~~~~~~~~~
      kernel/bpf/core.c:762:13: warning: no previous prototype for ?bpf_jit_free_exec? [-Wmissing-prototypes]
        762 | void __weak bpf_jit_free_exec(void *addr)
            |             ^~~~~~~~~~~~~~~~~
      
      All three are weak functions that archs can override, provide
      proper prototypes for when a new arch provides their own.
      Signed-off-by: 's avatarValdis Kletnieks <valdis.kletnieks@vt.edu>
      Acked-by: 's avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      46b2c037
    • Russell King's avatar
      ARM: avoid Cortex-A9 livelock on tight dmb loops · e2cadf02
      Russell King authored
      [ Upstream commit 5388a5b82199facacd3d7ac0d05aca6e8f902fed ]
      
      machine_crash_nonpanic_core() does this:
      
      	while (1)
      		cpu_relax();
      
      because the kernel has crashed, and we have no known safe way to deal
      with the CPU.  So, we place the CPU into an infinite loop which we
      expect it to never exit - at least not until the system as a whole is
      reset by some method.
      
      In the absence of erratum 754327, this code assembles to:
      
      	b	.
      
      In other words, an infinite loop.  When erratum 754327 is enabled,
      this becomes:
      
      1:	dmb
      	b	1b
      
      It has been observed that on some systems (eg, OMAP4) where, if a
      crash is triggered, the system tries to kexec into the panic kernel,
      but fails after taking the secondary CPU down - placing it into one
      of these loops.  This causes the system to livelock, and the most
      noticable effect is the system stops after issuing:
      
      	Loading crashdump kernel...
      
      to the system console.
      
      The tested as working solution I came up with was to add wfe() to
      these infinite loops thusly:
      
      	while (1) {
      		cpu_relax();
      		wfe();
      	}
      
      which, without 754327 builds to:
      
      1:	wfe
      	b	1b
      
      or with 754327 is enabled:
      
      1:	dmb
      	wfe
      	b	1b
      
      Adding "wfe" does two things depending on the environment we're running
      under:
      - where we're running on bare metal, and the processor implements
        "wfe", it stops us spinning endlessly in a loop where we're never
        going to do any useful work.
      - if we're running in a VM, it allows the CPU to be given back to the
        hypervisor and rescheduled for other purposes (maybe a different VM)
        rather than wasting CPU cycles inside a crashed VM.
      
      However, in light of erratum 794072, Will Deacon wanted to see 10 nops
      as well - which is reasonable to cover the case where we have erratum
      754327 enabled _and_ we have a processor that doesn't implement the
      wfe hint.
      
      So, we now end up with:
      
      1:      wfe
              b       1b
      
      when erratum 754327 is disabled, or:
      
      1:      dmb
              nop
              nop
              nop
              nop
              nop
              nop
              nop
              nop
              nop
              nop
              wfe
              b       1b
      
      when erratum 754327 is enabled.  We also get the dmb + 10 nop
      sequence elsewhere in the kernel, in terminating loops.
      
      This is reasonable - it means we get the workaround for erratum
      794072 when erratum 754327 is enabled, but still relinquish the dead
      processor - either by placing it in a lower power mode when wfe is
      implemented as such or by returning it to the hypervisior, or in the
      case where wfe is a no-op, we use the workaround specified in erratum
      794072 to avoid the problem.
      
      These as two entirely orthogonal problems - the 10 nops addresses
      erratum 794072, and the wfe is an optimisation that makes the system
      more efficient when crashed either in terms of power consumption or
      by allowing the host/other VMs to make use of the CPU.
      
      I don't see any reason not to use kexec() inside a VM - it has the
      potential to provide automated recovery from a failure of the VMs
      kernel with the opportunity for saving a crashdump of the failure.
      A panic() with a reboot timeout won't do that, and reading the
      libvirt documentation, setting on_reboot to "preserve" won't either
      (the documentation states "The preserve action for an on_reboot event
      is treated as a destroy".)  Surely it has to be a good thing to
      avoiding having CPUs spinning inside a VM that is doing no useful
      work.
      Acked-by: 's avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: 's avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      e2cadf02
    • Vladimir Murzin's avatar
      ARM: 8830/1: NOMMU: Toggle only bits in EXC_RETURN we are really care of · cbe71d95
      Vladimir Murzin authored
      [ Upstream commit 72cd4064fccaae15ab84d40d4be23667402df4ed ]
      
      ARMv8M introduces support for Security extension to M class, among
      other things it affects exception handling, especially, encoding of
      EXC_RETURN.
      
      The new bits have been added:
      
      Bit [6]	Secure or Non-secure stack
      Bit [5]	Default callee register stacking
      Bit [0]	Exception Secure
      
      which conflicts with hard-coded value of EXC_RETURN:
      
      In fact, we only care of few bits:
      
      Bit [3]	 Mode (0 - Handler, 1 - Thread)
      Bit [2]	 Stack pointer selection (0 - Main, 1 - Process)
      
      We can toggle only those bits and left other bits as they were on
      exception entry.
      
      It is basically, what patch does - saves EXC_RETURN when we do
      transition form Thread to Handler mode (it is first svc), so later
      saved value is used instead of EXC_RET_THREADMODE_PROCESSSTACK.
      Signed-off-by: 's avatarVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: 's avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      cbe71d95
    • Stanislaw Gruszka's avatar
      mt7601u: bump supported EEPROM version · e7bde590
      Stanislaw Gruszka authored
      [ Upstream commit 3bd1505fed71d834f45e87b32ff07157fdda47e0 ]
      
      As reported by Michael eeprom 0d is supported and work with the driver.
      
      Dump of /sys/kernel/debug/ieee80211/phy1/mt7601u/eeprom_param
      with 0d EEPORM looks like this:
      
      RSSI offset: 0 0
      Reference temp: f9
      LNA gain: 8
      Reg channels: 1-14
      Per rate power:
      	 raw:05 bw20:05 bw40:05
      	 raw:05 bw20:05 bw40:05
      	 raw:03 bw20:03 bw40:03
      	 raw:03 bw20:03 bw40:03
      	 raw:04 bw20:04 bw40:04
      	 raw:00 bw20:00 bw40:00
      	 raw:00 bw20:00 bw40:00
      	 raw:00 bw20:00 bw40:00
      	 raw:02 bw20:02 bw40:02
      	 raw:00 bw20:00 bw40:00
      Per channel power:
      	 tx_power  ch1:09 ch2:09
      	 tx_power  ch3:0a ch4:0a
      	 tx_power  ch5:0a ch6:0a
      	 tx_power  ch7:0b ch8:0b
      	 tx_power  ch9:0b ch10:0b
      	 tx_power  ch11:0b ch12:0b
      	 tx_power  ch13:0b ch14:0b
      Reported-and-tested-by: 's avatarMichael <ZeroBeat@gmx.de>
      Signed-off-by: 's avatarStanislaw Gruszka <sgruszka@redhat.com>
      Acked-by: 's avatarJakub Kicinski <kubakici@wp.pl>
      Signed-off-by: 's avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      e7bde590
    • Alexey Khoroshilov's avatar
      soc: qcom: gsbi: Fix error handling in gsbi_probe() · 8d7504c5
      Alexey Khoroshilov authored
      [ Upstream commit 8cd09a3dd3e176c62da67efcd477a44a8d87185e ]
      
      If of_platform_populate() fails in gsbi_probe(),
      gsbi->hclk is left undisabled.
      
      Found by Linux Driver Verification project (linuxtesting.org).
      Signed-off-by: 's avatarAlexey Khoroshilov <khoroshilov@ispras.ru>
      Signed-off-by: 's avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Signed-off-by: 's avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      8d7504c5
    • Ard Biesheuvel's avatar
      efi/arm/arm64: Allow SetVirtualAddressMap() to be omitted · eb262db3
      Ard Biesheuvel authored
      [ Upstream commit 4e46c2a956215482418d7b315749fb1b6c6bc224 ]
      
      The UEFI spec revision 2.7 errata A section 8.4 has the following to
      say about the virtual memory runtime services:
      
        "This section contains function definitions for the virtual memory
        support that may be optionally used by an operating system at runtime.
        If an operating system chooses to make EFI runtime service calls in a
        virtual addressing mode instead of the flat physical mode, then the
        operating system must use the services in this section to switch the
        EFI runtime services from flat physical addressing to virtual
        addressing."
      
      So it is pretty clear that calling SetVirtualAddressMap() is entirely
      optional, and so there is no point in doing so unless it achieves
      anything useful for us.
      
      This is not the case for 64-bit ARM. The identity mapping used by the
      firmware is arbitrarily converted into another permutation of userland
      addresses (i.e., bits [63:48] cleared), and the runtime code could easily
      deal with the original layout in exactly the same way as it deals with
      the converted layout. However, due to constraints related to page size
      differences if the OS is not running with 4k pages, and related to
      systems that may expose the individual sections of PE/COFF runtime
      modules as different memory regions, creating the virtual layout is a
      bit fiddly, and requires us to sort the memory map and reason about
      adjacent regions with identical memory types etc etc.
      
      So the obvious fix is to stop calling SetVirtualAddressMap() altogether
      on arm64 systems. However, to avoid surprises, which are notoriously
      hard to diagnose when it comes to OS<->firmware interactions, let's
      start by making it an opt-out feature, and implement support for the
      'efi=novamap' kernel command line parameter on ARM and arm64 systems.
      
      ( Note that 32-bit ARM generally does require SetVirtualAddressMap() to be
        used, given that the physical memory map and the kernel virtual address
        map are not guaranteed to be non-overlapping like on arm64. However,
        having support for efi=novamap,noruntime on 32-bit ARM, combined with
        the recently proposed support for earlycon=efifb, is likely to be useful
        to diagnose boot issues on such systems if they have no accessible serial
        port. )
      Tested-by: 's avatarJeffrey Hugo <jhugo@codeaurora.org>
      Tested-by: 's avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Tested-by: 's avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: 's avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Cc: Alexander Graf <agraf@suse.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20190202094119.13230-8-ard.biesheuvel@linaro.orgSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      eb262db3
    • Mathieu Malaterre's avatar
      ARM: dts: lpc32xx: Remove leading 0x and 0s from bindings notation · 80a4813b
      Mathieu Malaterre authored
      [ Upstream commit 3e3380d0675d5e20b0af067d60cb947a4348bf9b ]
      
      Improve the DTS files by removing all the leading "0x" and zeros to fix
      the following dtc warnings:
      
      Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
      
      and
      
      Warning (unit_address_format): Node /XXX unit name should not have leading 0s
      
      Converted using the following command:
      
      find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +
      
      For simplicity, two sed expressions were used to solve each warnings
      separately.
      
      To make the regex expression more robust a few other issues were resolved,
      namely setting unit-address to lower case, and adding a whitespace before
      the opening curly brace:
      
      https://elinux.org/Device_Tree_Linux#Linux_conventions
      
      This will solve as a side effect warning:
      
      Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
      
      This is a follow up to commit 4c9847b7 ("dt-bindings: Remove leading 0x from bindings notation")
      Reported-by: 's avatarDavid Daney <ddaney@caviumnetworks.com>
      Suggested-by: 's avatarRob Herring <robh@kernel.org>
      Signed-off-by: 's avatarMathieu Malaterre <malat@debian.org>
      [vzapolskiy: fixed commit message to pass checkpatch.pl test]
      Signed-off-by: 's avatarVladimir Zapolskiy <vz@mleia.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      80a4813b
    • Ard Biesheuvel's avatar
      efi/memattr: Don't bail on zero VA if it equals the region's PA · 7d84e045
      Ard Biesheuvel authored
      [ Upstream commit 5de0fef0230f3c8d75cff450a71740a7bf2db866 ]
      
      The EFI memory attributes code cross-references the EFI memory map with
      the more granular EFI memory attributes table to ensure that they are in
      sync before applying the strict permissions to the regions it describes.
      
      Since we always install virtual mappings for the EFI runtime regions to
      which these strict permissions apply, we currently perform a sanity check
      on the EFI memory descriptor, and ensure that the EFI_MEMORY_RUNTIME bit
      is set, and that the virtual address has been assigned.
      
      However, in cases where a runtime region exists at physical address 0x0,
      and the virtual mapping equals the physical mapping, e.g., when running
      in mixed mode on x86, we encounter a memory descriptor with the runtime
      attribute and virtual address 0x0, and incorrectly draw the conclusion
      that a runtime region exists for which no virtual mapping was installed,
      and give up altogether. The consequence of this is that firmware mappings
      retain their read-write-execute permissions, making the system more
      vulnerable to attacks.
      
      So let's only bail if the virtual address of 0x0 has been assigned to a
      physical region that does not reside at address 0x0.
      Signed-off-by: 's avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: 's avatarSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Cc: Alexander Graf <agraf@suse.de>
      Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
      Cc: Jeffrey Hugo <jhugo@codeaurora.org>
      Cc: Lee Jones <lee.jones@linaro.org>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Fixes: 10f0d2f5 ("efi: Implement generic support for the Memory ...")
      Link: http://lkml.kernel.org/r/20190202094119.13230-4-ard.biesheuvel@linaro.orgSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      7d84e045