1. 05 Apr, 2019 40 commits
    • Rafael Ávila de Espíndola's avatar
      x86/build: Mark per-CPU symbols as absolute explicitly for LLD · c8a8dd1d
      Rafael Ávila de Espíndola authored
      [ Upstream commit d071ae09 ]
      
      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: Dmitry Golovin's avatarDmitry Golovin <dima@golovin.in>
      Signed-off-by: Rafael Ávila de Espíndola'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: Dmitry Golovin'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>
      c8a8dd1d
    • Zumeng Chen's avatar
      wlcore: Fix memory leak in case wl12xx_fetch_firmware failure · 38af5462
      Zumeng Chen authored
      [ Upstream commit ba2ffc96 ]
      
      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>
      38af5462
    • Hans de Goede's avatar
      brcmfmac: Use firmware_request_nowarn for the clm_blob · ab79dc3e
      Hans de Goede authored
      [ Upstream commit 4ad0be16 ]
      
      The linux-firmware brcmfmac firmware files contain an embedded table with
      per country allowed channels and strength info.
      
      For recent hardware these versions of the firmware are specially build for
      linux-firmware, the firmware files directly available from Cypress rely on
      a separate clm_blob file for this info.
      
      For some unknown reason Cypress refuses to provide the standard firmware
      files + clm_blob files it uses elsewhere for inclusion into linux-firmware,
      instead relying on these special builds with the clm_blob info embedded.
      This means that the linux-firmware firmware versions often lag behind,
      but I digress.
      
      The brcmfmac driver does support the separate clm_blob file and always
      tries to load this. Currently we use request_firmware for this. This means
      that on any standard install, using the standard combo of linux-kernel +
      linux-firmware, we will get a warning:
      "Direct firmware load for ... failed with error -2"
      
      On top of this, brcmfmac itself prints: "no clm_blob available (err=-2),
      device may have limited channels available".
      
      This commit switches to firmware_request_nowarn, fixing almost any brcmfmac
      device logging the warning (it leaves the brcmfmac info message in place).
      Signed-off-by: 's avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: 's avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      ab79dc3e
    • Ondrej Mosnáček's avatar
      selinux: do not override context on context mounts · f836093a
      Ondrej Mosnáček authored
      [ Upstream commit 53e0c2aa ]
      
      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: Ondrej Mosnáček's avatarOndrej Mosnacek <omosnace@redhat.com>
      Reviewed-by: Stephen Smalley'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>
      f836093a
    • George Rimar's avatar
      x86/build: Specify elf_i386 linker emulation explicitly for i386 objects · 993f9641
      George Rimar authored
      [ Upstream commit 927185c1 ]
      
      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: Dmitry Golovin'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>
      993f9641
    • Daniel Vetter's avatar
      drm/nouveau: Stop using drm_crtc_force_disable · 16d4d75d
      Daniel Vetter authored
      [ Upstream commit 934c5b32 ]
      
      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>
      16d4d75d
    • Paul Kocialkowski's avatar
      drm: Auto-set allow_fb_modifiers when given modifiers at plane init · bfb59eab
      Paul Kocialkowski authored
      [ Upstream commit 890880dd ]
      
      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: Daniel Vetter's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: 's avatarPaul Kocialkowski <paul.kocialkowski@bootlin.com>
      Signed-off-by: '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>
      bfb59eab
    • Martin Blumenstingl's avatar
      pinctrl: meson: meson8b: add the eth_rxd2 and eth_rxd3 pins · 778c82db
      Martin Blumenstingl authored
      [ Upstream commit 6daae002 ]
      
      Gigabit Ethernet requires the Ethernet TXD0..3 and RXD0..3 data lines.
      Add the missing eth_rxd2 and eth_rxd3 definitions so we don't have to
      rely on the bootloader to set them up correctly.
      
      The vendor u-boot sources for Odroid-C1 use the following Ethernet
      pinmux configuration:
        SET_CBUS_REG_MASK(PERIPHS_PIN_MUX_6, 0x3f4f);
        SET_CBUS_REG_MASK(PERIPHS_PIN_MUX_7, 0xf00000);
      This translates to the following pin groups in the mainline kernel:
      - register 6 bit  0: eth_rxd1 (DIF_0_P)
      - register 6 bit  1: eth_rxd0 (DIF_0_N)
      - register 6 bit  2: eth_rx_dv (DIF_1_P)
      - register 6 bit  3: eth_rx_clk (DIF_1_N)
      - register 6 bit  6: eth_tx_en (DIF_3_P)
      - register 6 bit  8: eth_ref_clk (DIF_3_N)
      - register 6 bit  9: eth_mdc (DIF_4_P)
      - register 6 bit 10: eth_mdio_en (DIF_4_N)
      - register 6 bit 11: eth_tx_clk (GPIOH_9)
      - register 6 bit 12: eth_txd2 (GPIOH_8)
      - register 6 bit 13: eth_txd3 (GPIOH_7)
      - register 7 bit 20: eth_txd0_0 (GPIOH_6)
      - register 7 bit 21: eth_txd1_0 (GPIOH_5)
      - register 7 bit 22: eth_rxd3 (DIF_2_P)
      - register 7 bit 23: eth_rxd2 (DIF_2_N)
      
      All functions except eth_rxd2 and eth_rxd3 are already supported by the
      pinctrl-meson8b driver.
      Suggested-by: 's avatarJianxin Pan <jianxin.pan@amlogic.com>
      Signed-off-by: 's avatarMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Reviewed-by: Kevin Hilman's avatarKevin Hilman <khilman@baylibre.com>
      Tested-by: 's avatarEmiliano Ingrassia <ingrassia@epigenesys.com>
      Reviewed-by: 's avatarEmiliano Ingrassia <ingrassia@epigenesys.com>
      Signed-off-by: 's avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      778c82db
    • Axel Lin's avatar
      regulator: act8865: Fix act8600_sudcdc_voltage_ranges setting · 1048bfd8
      Axel Lin authored
      [ Upstream commit f01a7beb ]
      
      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>
      1048bfd8
    • Richard Guy Briggs's avatar
      audit: hand taken context to audit_kill_trees for syscall logging · e78d5e16
      Richard Guy Briggs authored
      [ Upstream commit 9e36a5d4 ]
      
      Since the context is derived from the task parameter handed to
      __audit_free(), hand the context to audit_kill_trees() so it can be used
      to associate with a syscall record.  This requires adding the context
      parameter to kill_rules() rather than using the current audit_context.
      
      The callers of trim_marked() and evict_chunk() still have their context.
      
      The EOE record was being issued prior to the pruning of the killed_tree
      list.
      
      Move the kill_trees call before the audit_log_exit call in
      __audit_free() and __audit_syscall_exit() so that any pruned trees
      CONFIG_CHANGE records are included with the associated syscall event by
      the user library due to the EOE record flagging the end of the event.
      
      See: https://github.com/linux-audit/audit-kernel/issues/50
      See: https://github.com/linux-audit/audit-kernel/issues/59Signed-off-by: 's avatarRichard Guy Briggs <rgb@redhat.com>
      [PM: fixed merge fuzz in kernel/audit_tree.c]
      Signed-off-by: 's avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      e78d5e16
    • Mika Westerberg's avatar
      PCI: pciehp: Assign ctrl->slot_ctrl before writing it to hardware · a43ea8ca
      Mika Westerberg authored
      [ Upstream commit 25bd879e ]
      
      Shameerali reported that running v4.20-rc1 as QEMU guest, the PCIe hotplug
      port times out during boot:
      
        pciehp 0000:00:01.0:pcie004: Timeout on hotplug command 0x03f1 (issued 1016 msec ago)
        pciehp 0000:00:01.0:pcie004: Timeout on hotplug command 0x03f1 (issued 1024 msec ago)
        pciehp 0000:00:01.0:pcie004: Failed to check link status
        pciehp 0000:00:01.0:pcie004: Timeout on hotplug command 0x02f1 (issued 2520 msec ago)
      
      The issue was bisected down to commit 720d6a67 ("PCI: pciehp: Do not
      handle events if interrupts are masked") and was further analyzed by the
      reporter to be caused by the fact that pciehp first updates the hardware
      and only then cache the ctrl->slot_ctrl in pcie_do_write_cmd().  If the
      interrupt happens before we cache the value, pciehp_isr() reads value 0 and
      decides that the interrupt was not meant for it causing the above timeout
      to trigger.
      
      Fix by moving ctrl->slot_ctrl assignment to happen before it is written to
      the hardware.
      
      Fixes: 720d6a67 ("PCI: pciehp: Do not handle events if interrupts are masked")
      Link: https://lore.kernel.org/linux-pci/5FC3163CFD30C246ABAA99954A238FA8387DD344@FRAEML521-MBX.china.huawei.comReported-by: 's avatarShameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
      Signed-off-by: 's avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: 's avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      a43ea8ca
    • PabloPL's avatar
      media: s5p-jpeg: Check for fmt_ver_flag when doing fmt enumeration · e5d1f1c0
      PabloPL authored
      [ Upstream commit 49710c32 ]
      
      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: PabloPL'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>
      e5d1f1c0
    • Steve Longerbeam's avatar
      media: rcar-vin: Allow independent VIN link enablement · 68ec6a13
      Steve Longerbeam authored
      [ Upstream commit c5ff0edb ]
      
      There is a block of code in rvin_group_link_notify() that prevents
      enabling a link to a VIN node if any entity in the media graph is
      in use. This prevents enabling a VIN link even if there is an in-use
      entity somewhere in the graph that is independent of the link's
      pipeline.
      
      For example, the code block will prevent enabling a link from
      the first rcar-csi2 receiver to a VIN node even if there is an
      enabled link somewhere far upstream on the second independent
      rcar-csi2 receiver pipeline.
      
      If this code block is meant to prevent modifying a link if any entity
      in the graph is actively involved in streaming (because modifying
      the CHSEL register fields can disrupt any/all running streams), then
      the entities stream counts should be checked rather than the use counts.
      
      (There is already such a check in __media_entity_setup_link() that verifies
      the stream_count of the link's source and sink entities are both zero,
      but that is insufficient, since there should be no running streams in
      the entire graph).
      
      Modify the code block to check the entity stream_count instead of the
      use_count (and elaborate on the comment). VIN node links can now be
      enabled even if there are other independent in-use entities that are
      not streaming.
      
      Fixes: c0cc5aef ("media: rcar-vin: add link notify for Gen3")
      Signed-off-by: 's avatarSteve Longerbeam <slongerbeam@gmail.com>
      Reviewed-by: 's avatarNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
      Signed-off-by: 's avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: 's avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      68ec6a13
    • Florian Westphal's avatar
      netfilter: physdev: relax br_netfilter dependency · ebd0f306
      Florian Westphal authored
      [ Upstream commit 8e2f311a ]
      
      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>
      ebd0f306
    • Shunyong Yang's avatar
      dmaengine: qcom_hidma: initialize tx flags in hidma_prep_dma_* · d7e6e93b
      Shunyong Yang authored
      [ Upstream commit 875aac8a ]
      
      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: Vinod Koul's avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      d7e6e93b
    • Shunyong Yang's avatar
      dmaengine: qcom_hidma: assign channel cookie correctly · 1bac8b82
      Shunyong Yang authored
      [ Upstream commit 546c0547 ]
      
      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: Vinod Koul's avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      1bac8b82
    • Anders Roxell's avatar
      dmaengine: imx-dma: fix warning comparison of distinct pointer types · 56d276b5
      Anders Roxell authored
      [ Upstream commit 9227ab56 ]
      
      The warning got introduced by commit 930507c1 ("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: Olof Johansson's avatarOlof Johansson <olof@lixom.net>
      Reviewed-by: Fabio Estevam's avatarFabio Estevam <festevam@gmail.com>
      Signed-off-by: Vinod Koul's avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      56d276b5
    • Valentin Schneider's avatar
      cpu/hotplug: Mute hotplug lockdep during init · 964065d2
      Valentin Schneider authored
      [ Upstream commit ce48c457 ]
      
      Since we've had:
      
        commit cb538267 ("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 40fa3780 ("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>
      964065d2
    • Takeshi Kihara's avatar
      pinctrl: sh-pfc: r8a77995: Fix MOD_SEL bit numbering · 8376acca
      Takeshi Kihara authored
      [ Upstream commit 5219aa33 ]
      
      MOD_SEL register bit numbering was different from R-Car D3 SoC and
      R-Car H3/M3-[WN] SoCs.
      
      MOD_SEL 1-bit      H3/M3-[WN]  D3
      ===============    ==========  =====
      Set Value = H'0    b'0         b'0
      Set Value = H'1    b'1         b'1
      
      MOD_SEL 2-bits     H3/M3-[WN]  D3
      ===============    ==========  =====
      Set Value = H'0    b'00        b'00
      Set Value = H'1    b'01        b'10
      Set Value = H'2    b'10        b'01
      Set Value = H'3    b'11        b'11
      
      MOD_SEL 3-bits     H3/M3-[WN]  D3
      ===============    ==========  =====
      Set Value = H'0    b'000       b'000
      Set Value = H'1    b'001       b'100
      Set Value = H'2    b'010       b'010
      Set Value = H'3    b'011       b'110
      Set Value = H'4    b'100       b'001
      Set Value = H'5    b'101       b'101
      Set Value = H'6    b'110       b'011
      Set Value = H'7    b'111       b'111
      
      This patch replaces the #define name and value of MOD_SEL.
      Signed-off-by: 's avatarTakeshi Kihara <takeshi.kihara.df@renesas.com>
      Fixes: 794a6711 ("pinctrl: sh-pfc: Initial R8A77995 PFC support")
      [shimoda: split a patch per SoC and revise the commit log]
      Signed-off-by: Yoshihiro Shimoda's avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      [geert: Use a macro to do the actual reordering]
      Signed-off-by: 's avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: 's avatarSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      8376acca
    • Takeshi Kihara's avatar
      pinctrl: sh-pfc: r8a77990: Fix MOD_SEL bit numbering · e848354f
      Takeshi Kihara authored
      [ Upstream commit 3e3eebea ]
      
      MOD_SEL register bit numbering was different from R-Car E3 SoC and
      R-Car H3/M3-[WN] SoCs.
      
      MOD_SEL 1-bit      H3/M3-[WN]  E3
      ===============    ==========  =====
      Set Value = H'0    b'0         b'0
      Set Value = H'1    b'1         b'1
      
      MOD_SEL 2-bits     H3/M3-[WN]  E3
      ===============    ==========  =====
      Set Value = H'0    b'00        b'00
      Set Value = H'1    b'01        b'10
      Set Value = H'2    b'10        b'01
      Set Value = H'3    b'11        b'11
      
      MOD_SEL 3-bits     H3/M3-[WN]  E3
      ===============    ==========  =====
      Set Value = H'0    b'000       b'000
      Set Value = H'1    b'001       b'100
      Set Value = H'2    b'010       b'010
      Set Value = H'3    b'011       b'110
      Set Value = H'4    b'100       b'001
      Set Value = H'5    b'101       b'101
      Set Value = H'6    b'110       b'011
      Set Value = H'7    b'111       b'111
      
      This patch replaces the #define name and value of MOD_SEL.
      Signed-off-by: 's avatarTakeshi Kihara <takeshi.kihara.df@renesas.com>
      Fixes: 6d4036a1 ("pinctrl: sh-pfc: Initial R8A77990 PFC support")
      [shimoda: Split a patch per SoC and revise the commit log]
      Signed-off-by: Yoshihiro Shimoda's avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      [geert: Use macros to do the actual reordering]
      Signed-off-by: 's avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: Yoshihiro Shimoda's avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      e848354f
    • Xingyu Chen's avatar
      pinctrl: meson: fix G12A ao pull registers base address · 9d7ff2ae
      Xingyu Chen authored
      [ Upstream commit e66dd48e ]
      
      Since Meson G12A SoC, Introduce new ao registers AO_RTI_PULL_UP_EN_REG
      and AO_GPIO_O.
      
      These bits of controlling output level are remapped to the new register
      AO_GPIO_O, and the AO_GPIO_O_EN_N support only controlling output enable.
      
      These bits of controlling pull enable are remapped to the new register
      AO_RTI_PULL_UP_EN_REG, and the AO_RTI_PULL_UP_REG support only controlling
      pull type(up/down).
      
      The new layout of ao gpio/pull registers is as follows:
      - AO_GPIO_O_EN_N        [offset: 0x9 << 2]
      - AO_GPIO_I             [offset: 0xa << 2]
      - AO_RTI_PULL_UP_REG    [offset: 0xb << 2]
      - AO_RTI_PULL_UP_EN_REG [offset: 0xc << 2]
      - AO_GPIO_O             [offset: 0xd << 2]
      
      From above, we can see ao GPIO registers region has been separated by the
      ao pull registers. In order to ensure the continuity of the region on
      software, the ao GPIO and ao pull registers use the same base address, but
      can be identified by the offset.
      
      Fixes: 29ae0952 ("pinctrl: meson-g12a: add pinctrl driver support")
      Signed-off-by: 's avatarXingyu Chen <xingyu.chen@amlogic.com>
      Signed-off-by: 's avatarJianxin Pan <jianxin.pan@amlogic.com>
      Signed-off-by: Jerome Brunet's avatarJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: 's avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      9d7ff2ae
    • Buland Singh's avatar
      hpet: Fix missing '=' character in the __setup() code of hpet_mmap_enable · e17a340f
      Buland Singh authored
      [ Upstream commit 24d48a61 ]
      
      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>
      e17a340f
    • Chao Yu's avatar
      f2fs: fix to initialize variable to avoid UBSAN/smatch warning · 283a29de
      Chao Yu authored
      [ Upstream commit f9aa52a8 ]
      
      As Dan Carpenter as below:
      
      The patch df634f444ee9: "f2fs: use rb_*_cached friends" from Oct 4,
      2018, leads to the following static checker warning:
      
      	fs/f2fs/extent_cache.c:606 f2fs_update_extent_tree_range()
      	error: uninitialized symbol 'leftmost'.
      
      And also Eric Biggers, and Kyungtae Kim reported, there is an UBSAN
      warning described as below:
      
      We report a bug in linux-4.20.2: "UBSAN: Undefined behaviour in
      fs/f2fs/extent_cache.c"
      
      kernel config: https://kt0755.github.io/etc/config_v4.20_stable
      repro: https://kt0755.github.io/etc/repro.4a3e7.c (f2fs is mounted on
      /mnt/f2fs/)
      
      This arose in f2fs_update_extent_tree_range (fs/f2fs/extent_cache.c:605).
      It seems that, for some reason, its last argument became "24"
      although that was supposed to be bool type.
      
      =========================================
      UBSAN: Undefined behaviour in fs/f2fs/extent_cache.c:605:4
      load of value 24 is not a valid value for type '_Bool'
      CPU: 0 PID: 6774 Comm: syz-executor5 Not tainted 4.20.2 #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0xb1/0x118 lib/dump_stack.c:113
       ubsan_epilogue+0x12/0x94 lib/ubsan.c:159
       __ubsan_handle_load_invalid_value+0x17a/0x1be lib/ubsan.c:457
       f2fs_update_extent_tree_range+0x1d4a/0x1d50 fs/f2fs/extent_cache.c:605
       f2fs_update_extent_cache+0x2b6/0x350 fs/f2fs/extent_cache.c:804
       f2fs_update_data_blkaddr+0x61/0x70 fs/f2fs/data.c:656
       f2fs_outplace_write_data+0x1d6/0x4b0 fs/f2fs/segment.c:3140
       f2fs_convert_inline_page+0x86d/0x2060 fs/f2fs/inline.c:163
       f2fs_convert_inline_inode+0x6b5/0xad0 fs/f2fs/inline.c:208
       f2fs_preallocate_blocks+0x78b/0xb00 fs/f2fs/data.c:982
       f2fs_file_write_iter+0x31b/0xf40 fs/f2fs/file.c:3062
       call_write_iter include/linux/fs.h:1857 [inline]
       new_sync_write fs/read_write.c:474 [inline]
       __vfs_write+0x538/0x6e0 fs/read_write.c:487
       vfs_write+0x1b3/0x520 fs/read_write.c:549
       ksys_write+0xde/0x1c0 fs/read_write.c:598
       __do_sys_write fs/read_write.c:610 [inline]
       __se_sys_write fs/read_write.c:607 [inline]
       __x64_sys_write+0x7e/0xc0 fs/read_write.c:607
       do_syscall_64+0xbe/0x4f0 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x4497b9
      Code: e8 8c 9f 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48
      89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
      01 f0 ff ff 0f 83 9b 6b fc ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f1ea15edc68 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 00007f1ea15ee6cc RCX: 00000000004497b9
      RDX: 0000000000001000 RSI: 0000000020000140 RDI: 0000000000000013
      RBP: 000000000071bea0 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 000000000000bb50 R14: 00000000006f4bf0 R15: 00007f1ea15ee700
      =========================================
      
      As I checked, this uninitialized variable won't cause extent cache
      corruption, but in order to avoid such kind of warning of both UBSAN
      and smatch, fix to initialize related variable.
      Reported-by: 's avatarDan Carpenter <dan.carpenter@oracle.com>
      Reported-by: 's avatarEric Biggers <ebiggers@google.com>
      Reported-by: 's avatarKyungtae Kim <kt0755@gmail.com>
      Signed-off-by: 's avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: 's avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      283a29de
    • Sheng Yong's avatar
      f2fs: UBSAN: set boolean value iostat_enable correctly · 3d1a731b
      Sheng Yong authored
      [ Upstream commit ac929858 ]
      
      When setting /sys/fs/f2fs/<DEV>/iostat_enable with non-bool value, UBSAN
      reports the following warning.
      
      [ 7562.295484] ================================================================================
      [ 7562.296531] UBSAN: Undefined behaviour in fs/f2fs/f2fs.h:2776:10
      [ 7562.297651] load of value 64 is not a valid value for type '_Bool'
      [ 7562.298642] CPU: 1 PID: 7487 Comm: dd Not tainted 4.20.0-rc4+ #79
      [ 7562.298653] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [ 7562.298662] Call Trace:
      [ 7562.298760]  dump_stack+0x46/0x5b
      [ 7562.298811]  ubsan_epilogue+0x9/0x40
      [ 7562.298830]  __ubsan_handle_load_invalid_value+0x72/0x90
      [ 7562.298863]  f2fs_file_write_iter+0x29f/0x3f0
      [ 7562.298905]  __vfs_write+0x115/0x160
      [ 7562.298922]  vfs_write+0xa7/0x190
      [ 7562.298934]  ksys_write+0x50/0xc0
      [ 7562.298973]  do_syscall_64+0x4a/0xe0
      [ 7562.298992]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [ 7562.299001] RIP: 0033:0x7fa45ec19c00
      [ 7562.299004] Code: 73 01 c3 48 8b 0d 88 92 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d dd eb 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ce 8f 01 00 48 89 04 24
      [ 7562.299044] RSP: 002b:00007ffca52b49e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      [ 7562.299052] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa45ec19c00
      [ 7562.299059] RDX: 0000000000000400 RSI: 000000000093f000 RDI: 0000000000000001
      [ 7562.299065] RBP: 000000000093f000 R08: 0000000000000004 R09: 0000000000000000
      [ 7562.299071] R10: 00007ffca52b47b0 R11: 0000000000000246 R12: 0000000000000400
      [ 7562.299077] R13: 000000000093f000 R14: 000000000093f400 R15: 0000000000000000
      [ 7562.299091] ================================================================================
      
      So, if iostat_enable is enabled, set its value as true.
      Signed-off-by: 's avatarSheng Yong <shengyong1@huawei.com>
      Reviewed-by: 's avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: 's avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      3d1a731b
    • Song Hongyan's avatar
      HID: intel-ish: ipc: handle PIMR before ish_wakeup also clear PISR busy_clear bit · d9f59ff2
      Song Hongyan authored
      [ Upstream commit 2edefc05 ]
      
      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>
      d9f59ff2
    • Stanislav Fomichev's avatar
      selftests/bpf: suppress readelf stderr when probing for BTF support · 93148045
      Stanislav Fomichev authored
      [ Upstream commit 2f092126 ]
      
      Before:
      $ make -s -C tools/testing/selftests/bpf
      readelf: Error: Missing knowledge of 32-bit reloc types used in DWARF
      sections of machine number 247
      readelf: Warning: unable to apply unsupported reloc type 10 to section
      .debug_info
      readelf: Warning: unable to apply unsupported reloc type 1 to section
      .debug_info
      readelf: Warning: unable to apply unsupported reloc type 10 to section
      .debug_info
      
      After:
      $ make -s -C tools/testing/selftests/bpf
      
      v2:
      * use llvm-readelf instead of redirecting binutils' readelf stderr to
        /dev/null
      Signed-off-by: 's avatarStanislav Fomichev <sdf@google.com>
      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>
      93148045
    • Timo Alho's avatar
      soc/tegra: fuse: Fix illegal free of IO base address · e01bc8ba
      Timo Alho authored
      [ Upstream commit 51294bf6 ]
      
      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>
      e01bc8ba
    • David Tolnay's avatar
      hwrng: virtio - Avoid repeated init of completion · bf381e06
      David Tolnay authored
      [ Upstream commit aef027db ]
      
      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: David Tolnay's avatarDavid Tolnay <dtolnay@gmail.com>
      Tested-by: David Tolnay'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>
      bf381e06
    • Akinobu Mita's avatar
      media: mt9m111: set initial frame size other than 0x0 · 64ef5941
      Akinobu Mita authored
      [ Upstream commit 29856308 ]
      
      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>
      64ef5941
    • Tony Jones's avatar
      perf script python: Add trace_context extension module to sys.modules · 9acd16ab
      Tony Jones authored
      [ Upstream commit cc437642 ]
      
      In Python3, the result of PyModule_Create (called from
      scripts/python/Perf-Trace-Util/Context.c) is not automatically added to
      sys.modules.  See: https://bugs.python.org/issue4592
      
      Below is the observed behavior without the fix:
      
        # ldd /usr/bin/perf | grep -i python
      	libpython3.6m.so.1.0 => /usr/lib64/libpython3.6m.so.1.0 (0x00007f8e1dfb2000)
      
        # perf record /bin/false
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.015 MB perf.data (17 samples) ]
      
        # perf script -g python | cat
        generated Python script: perf-script.py
      
        # perf script -s ./perf-script.py
        Traceback (most recent call last):
          File "./perf-script.py", line 18, in <module>
            from perf_trace_context import *
        ModuleNotFoundError: No module named 'perf_trace_context'
        Error running python script ./perf-script.py
        #
      
      Committer notes:
      
      To build with python3 use:
      
        $ make -C tools/perf PYTHON=python3
      
      Use a non-const variable to pass the 'name' arg to
      PyImport_AppendInittab(), as python2.6 has that as 'char *', which ends
      up trowing this in some environments:
      
         CC       /tmp/build/perf/util/parse-branch-options.o
        util/scripting-engines/trace-event-python.c: In function 'python_start_script':
        util/scripting-engines/trace-event-python.c:1520:2: error: passing argument 1 of 'PyImport_AppendInittab' discards 'const' qualifier from pointer target type [-Werror]
          PyImport_AppendInittab("perf_trace_context", initfunc);
          ^
        In file included from /usr/include/python2.6/Python.h:130:0,
                         from util/scripting-engines/trace-event-python.c:22:
        /usr/include/python2.6/import.h:54:17: note: expected 'char *' but argument is of type 'const char *'
         PyAPI_FUNC(int) PyImport_AppendInittab(char *name, void (*initfunc)(void));
                         ^
        cc1: all warnings being treated as errors
      Signed-off-by: 's avatarTony Jones <tonyj@suse.de>
      Acked-by: 's avatarJiri Olsa <jolsa@kernel.org>
      Tested-by: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jaroslav Škarvada <jskarvad@redhat.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
      Fixes: 66dfdff0 ("perf tools: Add Python 3 support")
      Link: http://lkml.kernel.org/r/20190124005229.16146-2-tonyj@suse.deSigned-off-by: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      9acd16ab
    • Tony Jones's avatar
      perf script python: Use PyBytes for attr in trace-event-python · 8febc5d3
      Tony Jones authored
      [ Upstream commit 72e0b15c ]
      
      With Python3.  PyUnicode_FromStringAndSize is unsafe to call on attr and will
      return NULL.  Use _PyBytes_FromStringAndSize (as with raw_buf).
      
      Below is the observed behavior without the fix.  Note it is first necessary
      to apply the prior fix (Add trace_context extension module to sys,modules):
      
        # ldd /usr/bin/perf | grep -i python
                libpython3.6m.so.1.0 => /usr/lib64/libpython3.6m.so.1.0 (0x00007f8e1dfb2000)
      
        # perf record -e raw_syscalls:sys_enter /bin/false
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.018 MB perf.data (21 samples) ]
      
        # perf script -g python | cat
        generated Python script: perf-script.py
      
        # perf script -s ./perf-script.py
        in trace_begin
        Segmentation fault (core dumped)
      Signed-off-by: 's avatarTony Jones <tonyj@suse.de>
      Acked-by: 's avatarJiri Olsa <jolsa@kernel.org>
      Tested-by: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jaroslav Škarvada <jskarvad@redhat.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Seeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
      Fixes: 66dfdff0 ("perf tools: Add Python 3 support")
      Link: http://lkml.kernel.org/r/20190124005229.16146-3-tonyj@suse.deSigned-off-by: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      8febc5d3
    • Arnaldo Carvalho de Melo's avatar
      perf trace: Fixup etcsnoop example · 8f4264f5
      Arnaldo Carvalho de Melo authored
      [ Upstream commit 1d59cb1b ]
      
      Where we don't have "raw_syscalls:sys_enter", so we need to look for a
      "*syscalls:sys_enter*" to initialize the offsets for the
      __augmented_syscalls__ evsel, which is the case with etcsnoop, that was
      segfaulting, fixed:
      
        # trace -e /home/acme/git/perf/tools/perf/examples/bpf/etcsnoop.c
           0.000 (         ): gnome-shell/2105 openat(dfd: CWD, filename: "/etc/localtime")                       ...
         631.834 (         ): cat/6521 openat(dfd: CWD, filename: "/etc/ld.so.cache", flags: RDONLY|CLOEXEC) ...
         632.637 (         ): bash/6521 openat(dfd: CWD, filename: "/etc/passwd")                          ...
        ^C#
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Luis Cláudio Gonçalves <lclaudio@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Fixes: b9b6a2ea ("perf trace: Do not hardcode the size of the tracepoint common_ fields")
      Link: https://lkml.kernel.org/n/tip-0tjwcit8qitsmh4nyvf2b0jo@git.kernel.orgSigned-off-by: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      8f4264f5
    • Jérôme de Bretagne's avatar
      platform/x86: intel-hid: Missing power button release on some Dell models · 631e6859
      Jérôme de Bretagne authored
      [ Upstream commit e97a3456 ]
      
      Power button suspend for some Dell models was added in:
      
      commit 821b8536 ("platform/x86: intel-hid: Power button suspend on Dell Latitude 7275")
      
      by checking against the power button press notification (0xCE) to report
      the power button press event. The corresponding power button release
      notification (0xCF) was caught and ignored to stop it from being reported
      as an "unknown event" in the logs.
      
      The missing button release event is creating issues on Android-x86, as
      reported on the project mailing list for a Dell Latitude 5175 model, since
      the events are expected in down/up pairs.
      
      Report the power button release event to fix this issue.
      
      Link: https://groups.google.com/forum/#!topic/android-x86/aSwZK9Nf9RoTested-by: 's avatarTristian Celestin <tristian.celestin@outlook.com>
      Tested-by: 's avatarJérôme de Bretagne <jerome.debretagne@gmail.com>
      Signed-off-by: 's avatarJérôme de Bretagne <jerome.debretagne@gmail.com>
      Reviewed-by: 's avatarMario Limonciello <mario.limonciello@dell.com>
      [dvhart: corrected commit reference format per checkpatch]
      Signed-off-by: Darren Hart's avatarDarren Hart (VMware) <dvhart@infradead.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      631e6859
    • Roger Quadros's avatar
      usb: dwc3: gadget: Fix OTG events when gadget driver isn't loaded · 3ea0a48a
      Roger Quadros authored
      [ Upstream commit 169e3b68 ]
      
      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>
      3ea0a48a
    • Axel Lin's avatar
      regulator: mcp16502: Include linux/gpio/consumer.h to fix build error · bce56838
      Axel Lin authored
      [ Upstream commit f3c6a1a1 ]
      
      Fix below build error:
      drivers/regulator/mcp16502.c: In function ‘mcp16502_gpio_set_mode’:
      drivers/regulator/mcp16502.c:135:3: error: implicit declaration of function ‘gpiod_set_value’; did you mean ‘gpio_set_value’? [-Werror=implicit-function-declaration]
         gpiod_set_value(mcp->lpm, 0);
         ^~~~~~~~~~~~~~~
         gpio_set_value
      drivers/regulator/mcp16502.c: In function ‘mcp16502_probe’:
      drivers/regulator/mcp16502.c:486:13: error: implicit declaration of function ‘devm_gpiod_get’; did you mean ‘devm_gpio_free’? [-Werror=implicit-function-declaration]
        mcp->lpm = devm_gpiod_get(dev, "lpm", GPIOD_OUT_LOW);
                   ^~~~~~~~~~~~~~
                   devm_gpio_free
      drivers/regulator/mcp16502.c:486:40: error: ‘GPIOD_OUT_LOW’ undeclared (first use in this function); did you mean ‘GPIOF_INIT_LOW’?
        mcp->lpm = devm_gpiod_get(dev, "lpm", GPIOD_OUT_LOW);
                                              ^~~~~~~~~~~~~
                                              GPIOF_INIT_LOW
      Signed-off-by: 's avatarAxel Lin <axel.lin@ingics.com>
      Acked-by: 's avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: 's avatarMark Brown <broonie@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      bce56838
    • 坂本 貴史's avatar
      ALSA: dice: add support for Solid State Logic Duende Classic/Mini · f8d78138
      坂本 貴史 authored
      [ Upstream commit b2e9e1c8 ]
      
      Duende Classic was produced by Solid State Logic in 2006, as a
      first model of Duende DSP series. The following model, Duende Mini
      was produced in 2008. They are designed to receive isochronous
      packets for PCM frames via IEEE 1394 bus, perform signal processing by
      downloaded program, then transfer isochronous packets for converted
      PCM frames.
      
      These two models includes the same embedded board, consists of several
      ICs below:
       - Texus Instruments Inc, TSB41AB3 for physical layer of IEEE 1394 bus
       - WaveFront semiconductor, DICE II STD ASIC for link/protocol layer
       - Altera MAX 3000A CPLD for programs
       - Analog devices, SHARC ADSP-21363 for signal processing (4 chips)
      
      This commit adds support for the two models to ALSA dice driver. Like
      support for the other devices, packet streaming is just available.
      Userspace applications should be developed if full features became
      available; e.g. program uploader and parameter controller.
      
      $ ./hinawa-config-rom-printer /dev/fw1
      { 'bus-info': { 'adj': False,
                      'bmc': False,
                      'chip_ID': 349771402425,
                      'cmc': True,
                      'cyc_clk_acc': 255,
                      'generation': 1,
                      'imc': True,
                      'isc': True,
                      'link_spd': 2,
                      'max_ROM': 1,
                      'max_rec': 512,
                      'name': '1394',
                      'node_vendor_ID': 20674,
                      'pmc': False},
        'root-directory': [ ['VENDOR', 20674],
                            ['DESCRIPTOR', 'Solid State Logic'],
                            ['MODEL', 112],
                            ['DESCRIPTOR', 'Duende board'],
                            [ 'NODE_CAPABILITIES',
                              { 'addressing': {'64': True, 'fix': True, 'prv': True},
                                'misc': {'int': False, 'ms': False, 'spt': True},
                                'state': { 'atn': False,
                                           'ded': False,
                                           'drq': True,
                                           'elo': False,
                                           'init': False,
                                           'lst': True,
                                           'off': False},
                                'testing': {'bas': False, 'ext': False}}],
                            [ 'UNIT',
                              [ ['SPECIFIER_ID', 20674],
                                ['VERSION', 1],
                                ['MODEL', 112],
                                ['DESCRIPTOR', 'Duende board']]]]}
      Signed-off-by: 坂本 貴史's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      f8d78138
    • Nicholas Kazlauskas's avatar
      drm/amd/display: Enable vblank interrupt during CRC capture · 504dfdea
      Nicholas Kazlauskas authored
      [ Upstream commit 428da2bd ]
      
      [Why]
      In order to read CRC events when CRC capture is enabled the vblank
      interrput handler needs to be running for the CRTC. The handler is
      enabled while there is an active vblank reference.
      
      When running IGT tests there will often be no active vblank reference
      but the test expects to read a CRC value. This is valid usage (and
      works on i915 since they have a CRC interrupt handler) so the reference
      to the vblank should be grabbed while capture is active.
      
      This issue was found running:
      
      igt@kms_plane_multiple@atomic-pipe-b-tiling-none
      
      The pipe-b is the only one in the initial commit and was not previously
      active so no vblank reference is grabbed. The vblank interrupt is
      not enabled and the test times out.
      
      [How]
      Keep a reference to the vblank as long as CRC capture is enabled.
      If userspace never explicitly disables it then the reference is
      also dropped when removing the CRTC from the context (stream = NULL).
      Signed-off-by: 's avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: 's avatarHarry Wentland <Harry.Wentland@amd.com>
      Reviewed-by: 's avatarSun peng Li <Sunpeng.Li@amd.com>
      Acked-by: 's avatarLeo Li <sunpeng.li@amd.com>
      Signed-off-by: 's avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      504dfdea
    • Nathan Fontenot's avatar
      powerpc/pseries: Perform full re-add of CPU for topology update post-migration · b32cff3d
      Nathan Fontenot authored
      [ Upstream commit 81b61324 ]
      
      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: Michael Ellerman's avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      b32cff3d
    • Manfred Schlaegl's avatar
      tty: increase the default flip buffer limit to 2*640K · 9ee0088f
      Manfred Schlaegl authored
      [ Upstream commit 7ab57b76 ]
      
      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>
      9ee0088f
    • Chen-Yu Tsai's avatar
      backlight: pwm_bl: Use gpiod_get_value_cansleep() to get initial state · d9c61474
      Chen-Yu Tsai authored
      [ Upstream commit cec2b188 ]
      
      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: '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>
      d9c61474