1. 16 Sep, 2019 40 commits
    • Niklas Cassel's avatar
      ARM: dts: qcom: ipq4019: Fix MSI IRQ type · 445a78ea
      Niklas Cassel authored
      [ Upstream commit 97131f85 ]
      
      The databook clearly states that the MSI IRQ (msi_ctrl_int) is a level
      triggered interrupt.
      
      The msi_ctrl_int will be high for as long as any MSI status bit is set,
      thus the IRQ type should be set to IRQ_TYPE_LEVEL_HIGH, causing the
      IRQ handler to keep getting called, as long as any MSI status bit is set.
      
      A git grep shows that ipq4019 is the only SoC using snps,dw-pcie that has
      configured this IRQ incorrectly.
      
      Not having the correct IRQ type defined will cause us to lose interrupts,
      which in turn causes timeouts in the PCIe endpoint drivers.
      Signed-off-by: default avatarNiklas Cassel <niklas.cassel@linaro.org>
      Reviewed-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Signed-off-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      445a78ea
    • Mathias Kresin's avatar
      ARM: dts: qcom: ipq4019: fix PCI range · df1216d8
      Mathias Kresin authored
      [ Upstream commit da89f500 ]
      
      The PCI range is invalid and PCI attached devices doen't work.
      Signed-off-by: default avatarMathias Kresin <dev@kresin.me>
      Signed-off-by: default avatarJohn Crispin <john@phrozen.org>
      Signed-off-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      df1216d8
    • Theodore Ts'o's avatar
      ext4: protect journal inode's blocks using block_validity · 2fd4629d
      Theodore Ts'o authored
      [ Upstream commit 345c0dbf ]
      
      Add the blocks which belong to the journal inode to block_validity's
      system zone so attempts to deallocate or overwrite the journal due a
      corrupted file system where the journal blocks are also claimed by
      another inode.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202879Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2fd4629d
    • Koen Vandeputte's avatar
      media: i2c: tda1997x: select V4L2_FWNODE · f10a9230
      Koen Vandeputte authored
      [ Upstream commit 5f2efda7 ]
      
      Building tda1997x fails now unless V4L2_FWNODE is selected:
      
      drivers/media/i2c/tda1997x.o: in function `tda1997x_parse_dt'
      undefined reference to `v4l2_fwnode_endpoint_parse'
      
      While at it, also sort the selections alphabetically
      
      Fixes: 9ac0038d ("media: i2c: Add TDA1997x HDMI receiver driver")
      Signed-off-by: default avatarKoen Vandeputte <koen.vandeputte@ncentric.com>
      Cc: stable@vger.kernel.org # v4.17+
      Acked-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f10a9230
    • ZhangXiaoxu's avatar
      cifs: Fix lease buffer length error · 4061e662
      ZhangXiaoxu authored
      [ Upstream commit b57a55e2 ]
      
      There is a KASAN slab-out-of-bounds:
      BUG: KASAN: slab-out-of-bounds in _copy_from_iter_full+0x783/0xaa0
      Read of size 80 at addr ffff88810c35e180 by task mount.cifs/539
      
      CPU: 1 PID: 539 Comm: mount.cifs Not tainted 4.19 #10
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
                  rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
      Call Trace:
       dump_stack+0xdd/0x12a
       print_address_description+0xa7/0x540
       kasan_report+0x1ff/0x550
       check_memory_region+0x2f1/0x310
       memcpy+0x2f/0x80
       _copy_from_iter_full+0x783/0xaa0
       tcp_sendmsg_locked+0x1840/0x4140
       tcp_sendmsg+0x37/0x60
       inet_sendmsg+0x18c/0x490
       sock_sendmsg+0xae/0x130
       smb_send_kvec+0x29c/0x520
       __smb_send_rqst+0x3ef/0xc60
       smb_send_rqst+0x25a/0x2e0
       compound_send_recv+0x9e8/0x2af0
       cifs_send_recv+0x24/0x30
       SMB2_open+0x35e/0x1620
       open_shroot+0x27b/0x490
       smb2_open_op_close+0x4e1/0x590
       smb2_query_path_info+0x2ac/0x650
       cifs_get_inode_info+0x1058/0x28f0
       cifs_root_iget+0x3bb/0xf80
       cifs_smb3_do_mount+0xe00/0x14c0
       cifs_do_mount+0x15/0x20
       mount_fs+0x5e/0x290
       vfs_kern_mount+0x88/0x460
       do_mount+0x398/0x31e0
       ksys_mount+0xc6/0x150
       __x64_sys_mount+0xea/0x190
       do_syscall_64+0x122/0x590
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      It can be reproduced by the following step:
        1. samba configured with: server max protocol = SMB2_10
        2. mount -o vers=default
      
      When parse the mount version parameter, the 'ops' and 'vals'
      was setted to smb30,  if negotiate result is smb21, just
      update the 'ops' to smb21, but the 'vals' is still smb30.
      When add lease context, the iov_base is allocated with smb21
      ops, but the iov_len is initiallited with the smb30. Because
      the iov_len is longer than iov_base, when send the message,
      copy array out of bounds.
      
      we need to keep the 'ops' and 'vals' consistent.
      
      Fixes: 9764c02f ("SMB3: Add support for multidialect negotiate (SMB2.1 and later)")
      Fixes: d5c7076b ("smb3: add smb3.1.1 to default dialect list")
      Signed-off-by: default avatarZhangXiaoxu <zhangxiaoxu5@huawei.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Reviewed-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4061e662
    • Sean Christopherson's avatar
      KVM: x86: Always use 32-bit SMRAM save state for 32-bit kernels · df5d4ea2
      Sean Christopherson authored
      [ Upstream commit b68f3cc7 ]
      
      Invoking the 64-bit variation on a 32-bit kenrel will crash the guest,
      trigger a WARN, and/or lead to a buffer overrun in the host, e.g.
      rsm_load_state_64() writes r8-r15 unconditionally, but enum kvm_reg and
      thus x86_emulate_ctxt._regs only define r8-r15 for CONFIG_X86_64.
      
      KVM allows userspace to report long mode support via CPUID, even though
      the guest is all but guaranteed to crash if it actually tries to enable
      long mode.  But, a pure 32-bit guest that is ignorant of long mode will
      happily plod along.
      
      SMM complicates things as 64-bit CPUs use a different SMRAM save state
      area.  KVM handles this correctly for 64-bit kernels, e.g. uses the
      legacy save state map if userspace has hid long mode from the guest,
      but doesn't fare well when userspace reports long mode support on a
      32-bit host kernel (32-bit KVM doesn't support 64-bit guests).
      
      Since the alternative is to crash the guest, e.g. by not loading state
      or explicitly requesting shutdown, unconditionally use the legacy SMRAM
      save state map for 32-bit KVM.  If a guest has managed to get far enough
      to handle SMIs when running under a weird/buggy userspace hypervisor,
      then don't deliberately crash the guest since there are no downsides
      (from KVM's perspective) to allow it to continue running.
      
      Fixes: 660a5d51 ("KVM: x86: save/load state on SMM switch")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      df5d4ea2
    • WANG Chao's avatar
      x86/kvm: move kvm_load/put_guest_xcr0 into atomic context · 7a74d806
      WANG Chao authored
      [ Upstream commit 1811d979 ]
      
      guest xcr0 could leak into host when MCE happens in guest mode. Because
      do_machine_check() could schedule out at a few places.
      
      For example:
      
      kvm_load_guest_xcr0
      ...
      kvm_x86_ops->run(vcpu) {
        vmx_vcpu_run
          vmx_complete_atomic_exit
            kvm_machine_check
              do_machine_check
                do_memory_failure
                  memory_failure
                    lock_page
      
      In this case, host_xcr0 is 0x2ff, guest vcpu xcr0 is 0xff. After schedule
      out, host cpu has guest xcr0 loaded (0xff).
      
      In __switch_to {
           switch_fpu_finish
             copy_kernel_to_fpregs
               XRSTORS
      
      If any bit i in XSTATE_BV[i] == 1 and xcr0[i] == 0, XRSTORS will
      generate #GP (In this case, bit 9). Then ex_handler_fprestore kicks in
      and tries to reinitialize fpu by restoring init fpu state. Same story as
      last #GP, except we get DOUBLE FAULT this time.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarWANG Chao <chao.wang@ucloud.cn>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7a74d806
    • Ben Gardon's avatar
      kvm: mmu: Fix overflow on kvm mmu page limit calculation · 163b24b1
      Ben Gardon authored
      [ Upstream commit bc8a3d89 ]
      
      KVM bases its memory usage limits on the total number of guest pages
      across all memslots. However, those limits, and the calculations to
      produce them, use 32 bit unsigned integers. This can result in overflow
      if a VM has more guest pages that can be represented by a u32. As a
      result of this overflow, KVM can use a low limit on the number of MMU
      pages it will allocate. This makes KVM unable to map all of guest memory
      at once, prompting spurious faults.
      
      Tested: Ran all kvm-unit-tests on an Intel Haswell machine. This patch
      	introduced no new failures.
      Signed-off-by: default avatarBen Gardon <bgardon@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      163b24b1
    • Moni Shoua's avatar
      IB/mlx5: Reset access mask when looping inside page fault handler · feced628
      Moni Shoua authored
      [ Upstream commit 1abe186e ]
      
      If page-fault handler spans multiple MRs then the access mask needs to
      be reset before each MR handling or otherwise write access will be
      granted to mapped pages instead of read-only.
      
      Cc: <stable@vger.kernel.org> # 3.19
      Fixes: 7bdf65d4 ("IB/mlx5: Handle page faults")
      Reported-by: default avatarJerome Glisse <jglisse@redhat.com>
      Signed-off-by: default avatarMoni Shoua <monis@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      feced628
    • Dinh Nguyen's avatar
      arm64: dts: stratix10: add the sysmgr-syscon property from the gmac's · 37222eaf
      Dinh Nguyen authored
      [ Upstream commit 8efd6365 ]
      
      The gmac ethernet driver uses the "altr,sysmgr-syscon" property to
      configure phy settings for the gmac controller.
      
      Add the "altr,sysmgr-syscon" property to all gmac nodes.
      
      This patch fixes:
      
      [    0.917530] socfpga-dwmac ff800000.ethernet: No sysmgr-syscon node found
      [    0.924209] socfpga-dwmac ff800000.ethernet: Unable to parse OF data
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarLey Foon Tan <ley.foon.tan@intel.com>
      Signed-off-by: default avatarDinh Nguyen <dinguyen@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      37222eaf
    • Hans de Goede's avatar
      usb: typec: tcpm: Try PD-2.0 if sink does not respond to 3.0 source-caps · 3cfce8b7
      Hans de Goede authored
      [ Upstream commit 976daf9d ]
      
      PD 2.0 sinks are supposed to accept src-capabilities with a 3.0 header and
      simply ignore any src PDOs which the sink does not understand such as PPS
      but some 2.0 sinks instead ignore the entire PD_DATA_SOURCE_CAP message,
      causing contract negotiation to fail.
      
      This commit fixes such sinks not working by re-trying the contract
      negotiation with PD-2.0 source-caps messages if we don't have a contract
      after PD_N_HARD_RESET_COUNT hard-reset attempts.
      
      The problem fixed by this commit was noticed with a Type-C to VGA dongle.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3cfce8b7
    • Chris Wilson's avatar
      drm/i915: Sanity check mmap length against object size · fba4f7c1
      Chris Wilson authored
      [ Upstream commit 000c4f90 ]
      
      We assumed that vm_mmap() would reject an attempt to mmap past the end of
      the filp (our object), but we were wrong.
      
      Applications that tried to use the mmap beyond the end of the object
      would be greeted by a SIGBUS. After this patch, those applications will
      be told about the error on creating the mmap, rather than at a random
      moment on later access.
      Reported-by: default avatarAntonio Argenziano <antonio.argenziano@intel.com>
      Testcase: igt/gem_mmap/bad-size
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Antonio Argenziano <antonio.argenziano@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190314075829.16838-1-chris@chris-wilson.co.uk
      (cherry picked from commit 794a11cb)
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fba4f7c1
    • Joonas Lahtinen's avatar
      drm/i915: Handle vm_mmap error during I915_GEM_MMAP ioctl with WC set · 6423a2ad
      Joonas Lahtinen authored
      [ Upstream commit ebfb6977 ]
      
      Add err goto label and use it when VMA can't be established or changes
      underneath.
      
      v2:
      - Dropping Fixes: as it's indeed impossible to race an object to the
        error address. (Chris)
      v3:
      - Use IS_ERR_VALUE (Chris)
      Reported-by: default avatarAdam Zabrocki <adamza@microsoft.com>
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: Adam Zabrocki <adamza@microsoft.com>
      Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> #v2
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190207085454.10598-2-joonas.lahtinen@linux.intel.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      6423a2ad
    • Pavel Shilovsky's avatar
      CIFS: Fix leaking locked VFS cache pages in writeback retry · 778d626c
      Pavel Shilovsky authored
      [ Upstream commit 165df9a0 ]
      
      If we don't find a writable file handle when retrying writepages
      we break of the loop and do not unlock and put pages neither from
      wdata2 nor from the original wdata. Fix this by walking through
      all the remaining pages and cleanup them properly.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      778d626c
    • Pavel Shilovsky's avatar
      CIFS: Fix error paths in writeback code · fb2dabea
      Pavel Shilovsky authored
      [ Upstream commit 9a66396f ]
      
      This patch aims to address writeback code problems related to error
      paths. In particular it respects EINTR and related error codes and
      stores and returns the first error occurred during writeback.
      Signed-off-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Acked-by: default avatarJeff Layton <jlayton@kernel.org>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fb2dabea
    • Ben Dooks's avatar
      drm: add __user attribute to ptr_to_compat() · e407b58c
      Ben Dooks authored
      [ Upstream commit e552f085 ]
      
      The ptr_to_compat() call takes a "void __user *", so cast
      the compat drm calls that use it to avoid the following
      warnings from sparse:
      
      drivers/gpu/drm/drm_ioc32.c:188:39: warning: incorrect type in argument 1 (different address spaces)
      drivers/gpu/drm/drm_ioc32.c:188:39:    expected void [noderef] <asn:1>*uptr
      drivers/gpu/drm/drm_ioc32.c:188:39:    got void *[addressable] [assigned] handle
      drivers/gpu/drm/drm_ioc32.c:529:41: warning: incorrect type in argument 1 (different address spaces)
      drivers/gpu/drm/drm_ioc32.c:529:41:    expected void [noderef] <asn:1>*uptr
      drivers/gpu/drm/drm_ioc32.c:529:41:    got void *[addressable] [assigned] handle
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBen Dooks <ben.dooks@codethink.co.uk>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190301120046.26961-1-ben.dooks@codethink.co.ukSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      e407b58c
    • Bjorn Andersson's avatar
      PCI: qcom: Don't deassert reset GPIO during probe · e1a12c3b
      Bjorn Andersson authored
      [ Upstream commit 02b485e3 ]
      
      Acquiring the reset GPIO low means that reset is being deasserted, this
      is followed almost immediately with qcom_pcie_host_init() asserting it,
      initializing it and then finally deasserting it again, for the link to
      come up.
      
      Some PCIe devices requires a minimum time between the initial deassert
      and subsequent reset cycles. In a platform that boots with the reset
      GPIO asserted this requirement is being violated by this deassert/assert
      pulse.
      
      Acquire the reset GPIO high to prevent this situation by matching the
      state to the subsequent asserted state.
      
      Fixes: 82a82383 ("PCI: qcom: Add Qualcomm PCIe controller driver")
      Signed-off-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      [lorenzo.pieralisi@arm.com: updated commit log]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarStanimir Varbanov <svarbanov@mm-sol.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e1a12c3b
    • Bjorn Andersson's avatar
      PCI: qcom: Fix error handling in runtime PM support · be905d0f
      Bjorn Andersson authored
      [ Upstream commit 6e5da6f7 ]
      
      The driver does not cope with the fact that probe can fail in a number
      of cases after enabling runtime PM on the device; this results in
      warnings about "Unbalanced pm_runtime_enable". Furthermore if probe
      fails after invoking qcom_pcie_host_init() the power-domain will be left
      referenced.
      
      As it is not possible for the error handling in qcom_pcie_host_init() to
      handle errors happening after returning from that function the
      pm_runtime_get_sync() is moved to qcom_pcie_probe() as well.
      
      Fixes: 854b69ef ("PCI: qcom: add runtime pm support to pcie_port")
      Signed-off-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      [lorenzo.pieralisi@arm.com: updated commit log]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarStanimir Varbanov <svarbanov@mm-sol.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      be905d0f
    • Dan Robertson's avatar
      btrfs: init csum_list before possible free · 476ecc14
      Dan Robertson authored
      [ Upstream commit e49be14b ]
      
      The scrub_ctx csum_list member must be initialized before scrub_free_ctx
      is called. If the csum_list is not initialized beforehand, the
      list_empty call in scrub_free_csums will result in a null deref if the
      allocation fails in the for loop.
      
      Fixes: a2de733c ("btrfs: scrub")
      CC: stable@vger.kernel.org # 3.0+
      Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarDan Robertson <dan@dlrobertson.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      476ecc14
    • Anand Jain's avatar
      btrfs: scrub: fix circular locking dependency warning · 936690bd
      Anand Jain authored
      [ Upstream commit 1cec3f27 ]
      
      This fixes a longstanding lockdep warning triggered by
      fstests/btrfs/011.
      
      Circular locking dependency check reports warning[1], that's because the
      btrfs_scrub_dev() calls the stack #0 below with, the fs_info::scrub_lock
      held. The test case leading to this warning:
      
        $ mkfs.btrfs -f /dev/sdb
        $ mount /dev/sdb /btrfs
        $ btrfs scrub start -B /btrfs
      
      In fact we have fs_info::scrub_workers_refcnt to track if the init and destroy
      of the scrub workers are needed. So once we have incremented and decremented
      the fs_info::scrub_workers_refcnt value in the thread, its ok to drop the
      scrub_lock, and then actually do the btrfs_destroy_workqueue() part. So this
      patch drops the scrub_lock before calling btrfs_destroy_workqueue().
      
        [359.258534] ======================================================
        [359.260305] WARNING: possible circular locking dependency detected
        [359.261938] 5.0.0-rc6-default #461 Not tainted
        [359.263135] ------------------------------------------------------
        [359.264672] btrfs/20975 is trying to acquire lock:
        [359.265927] 00000000d4d32bea ((wq_completion)"%s-%s""btrfs", name){+.+.}, at: flush_workqueue+0x87/0x540
        [359.268416]
        [359.268416] but task is already holding lock:
        [359.270061] 0000000053ea26a6 (&fs_info->scrub_lock){+.+.}, at: btrfs_scrub_dev+0x322/0x590 [btrfs]
        [359.272418]
        [359.272418] which lock already depends on the new lock.
        [359.272418]
        [359.274692]
        [359.274692] the existing dependency chain (in reverse order) is:
        [359.276671]
        [359.276671] -> #3 (&fs_info->scrub_lock){+.+.}:
        [359.278187]        __mutex_lock+0x86/0x9c0
        [359.279086]        btrfs_scrub_pause+0x31/0x100 [btrfs]
        [359.280421]        btrfs_commit_transaction+0x1e4/0x9e0 [btrfs]
        [359.281931]        close_ctree+0x30b/0x350 [btrfs]
        [359.283208]        generic_shutdown_super+0x64/0x100
        [359.284516]        kill_anon_super+0x14/0x30
        [359.285658]        btrfs_kill_super+0x12/0xa0 [btrfs]
        [359.286964]        deactivate_locked_super+0x29/0x60
        [359.288242]        cleanup_mnt+0x3b/0x70
        [359.289310]        task_work_run+0x98/0xc0
        [359.290428]        exit_to_usermode_loop+0x83/0x90
        [359.291445]        do_syscall_64+0x15b/0x180
        [359.292598]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
        [359.294011]
        [359.294011] -> #2 (sb_internal#2){.+.+}:
        [359.295432]        __sb_start_write+0x113/0x1d0
        [359.296394]        start_transaction+0x369/0x500 [btrfs]
        [359.297471]        btrfs_finish_ordered_io+0x2aa/0x7c0 [btrfs]
        [359.298629]        normal_work_helper+0xcd/0x530 [btrfs]
        [359.299698]        process_one_work+0x246/0x610
        [359.300898]        worker_thread+0x3c/0x390
        [359.302020]        kthread+0x116/0x130
        [359.303053]        ret_from_fork+0x24/0x30
        [359.304152]
        [359.304152] -> #1 ((work_completion)(&work->normal_work)){+.+.}:
        [359.306100]        process_one_work+0x21f/0x610
        [359.307302]        worker_thread+0x3c/0x390
        [359.308465]        kthread+0x116/0x130
        [359.309357]        ret_from_fork+0x24/0x30
        [359.310229]
        [359.310229] -> #0 ((wq_completion)"%s-%s""btrfs", name){+.+.}:
        [359.311812]        lock_acquire+0x90/0x180
        [359.312929]        flush_workqueue+0xaa/0x540
        [359.313845]        drain_workqueue+0xa1/0x180
        [359.314761]        destroy_workqueue+0x17/0x240
        [359.315754]        btrfs_destroy_workqueue+0x57/0x200 [btrfs]
        [359.317245]        scrub_workers_put+0x2c/0x60 [btrfs]
        [359.318585]        btrfs_scrub_dev+0x336/0x590 [btrfs]
        [359.319944]        btrfs_dev_replace_by_ioctl.cold.19+0x179/0x1bb [btrfs]
        [359.321622]        btrfs_ioctl+0x28a4/0x2e40 [btrfs]
        [359.322908]        do_vfs_ioctl+0xa2/0x6d0
        [359.324021]        ksys_ioctl+0x3a/0x70
        [359.325066]        __x64_sys_ioctl+0x16/0x20
        [359.326236]        do_syscall_64+0x54/0x180
        [359.327379]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
        [359.328772]
        [359.328772] other info that might help us debug this:
        [359.328772]
        [359.330990] Chain exists of:
        [359.330990]   (wq_completion)"%s-%s""btrfs", name --> sb_internal#2 --> &fs_info->scrub_lock
        [359.330990]
        [359.334376]  Possible unsafe locking scenario:
        [359.334376]
        [359.336020]        CPU0                    CPU1
        [359.337070]        ----                    ----
        [359.337821]   lock(&fs_info->scrub_lock);
        [359.338506]                                lock(sb_internal#2);
        [359.339506]                                lock(&fs_info->scrub_lock);
        [359.341461]   lock((wq_completion)"%s-%s""btrfs", name);
        [359.342437]
        [359.342437]  *** DEADLOCK ***
        [359.342437]
        [359.343745] 1 lock held by btrfs/20975:
        [359.344788]  #0: 0000000053ea26a6 (&fs_info->scrub_lock){+.+.}, at: btrfs_scrub_dev+0x322/0x590 [btrfs]
        [359.346778]
        [359.346778] stack backtrace:
        [359.347897] CPU: 0 PID: 20975 Comm: btrfs Not tainted 5.0.0-rc6-default #461
        [359.348983] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626cc-prebuilt.qemu-project.org 04/01/2014
        [359.350501] Call Trace:
        [359.350931]  dump_stack+0x67/0x90
        [359.351676]  print_circular_bug.isra.37.cold.56+0x15c/0x195
        [359.353569]  check_prev_add.constprop.44+0x4f9/0x750
        [359.354849]  ? check_prev_add.constprop.44+0x286/0x750
        [359.356505]  __lock_acquire+0xb84/0xf10
        [359.357505]  lock_acquire+0x90/0x180
        [359.358271]  ? flush_workqueue+0x87/0x540
        [359.359098]  flush_workqueue+0xaa/0x540
        [359.359912]  ? flush_workqueue+0x87/0x540
        [359.360740]  ? drain_workqueue+0x1e/0x180
        [359.361565]  ? drain_workqueue+0xa1/0x180
        [359.362391]  drain_workqueue+0xa1/0x180
        [359.363193]  destroy_workqueue+0x17/0x240
        [359.364539]  btrfs_destroy_workqueue+0x57/0x200 [btrfs]
        [359.365673]  scrub_workers_put+0x2c/0x60 [btrfs]
        [359.366618]  btrfs_scrub_dev+0x336/0x590 [btrfs]
        [359.367594]  ? start_transaction+0xa1/0x500 [btrfs]
        [359.368679]  btrfs_dev_replace_by_ioctl.cold.19+0x179/0x1bb [btrfs]
        [359.369545]  btrfs_ioctl+0x28a4/0x2e40 [btrfs]
        [359.370186]  ? __lock_acquire+0x263/0xf10
        [359.370777]  ? kvm_clock_read+0x14/0x30
        [359.371392]  ? kvm_sched_clock_read+0x5/0x10
        [359.372248]  ? sched_clock+0x5/0x10
        [359.372786]  ? sched_clock_cpu+0xc/0xc0
        [359.373662]  ? do_vfs_ioctl+0xa2/0x6d0
        [359.374552]  do_vfs_ioctl+0xa2/0x6d0
        [359.375378]  ? do_sigaction+0xff/0x250
        [359.376233]  ksys_ioctl+0x3a/0x70
        [359.376954]  __x64_sys_ioctl+0x16/0x20
        [359.377772]  do_syscall_64+0x54/0x180
        [359.378841]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
        [359.380422] RIP: 0033:0x7f5429296a97
      
      Backporting to older kernels: scrub_nocow_workers must be freed the same
      way as the others.
      
      CC: stable@vger.kernel.org # 4.4+
      Signed-off-by: default avatarAnand Jain <anand.jain@oracle.com>
      [ update changelog ]
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      936690bd
    • David Sterba's avatar
      btrfs: scrub: move scrub_setup_ctx allocation out of device_list_mutex · ff55333f
      David Sterba authored
      [ Upstream commit 0e94c4f4 ]
      
      The scrub context is allocated with GFP_KERNEL and called from
      btrfs_scrub_dev under the fs_info::device_list_mutex. This is not safe
      regarding reclaim that could try to flush filesystem data in order to
      get the memory. And the device_list_mutex is held during superblock
      commit, so this would cause a lockup.
      
      Move the alocation and initialization before any changes that require
      the mutex.
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ff55333f
    • David Sterba's avatar
      btrfs: scrub: pass fs_info to scrub_setup_ctx · 8ba3169d
      David Sterba authored
      [ Upstream commit 92f7ba43 ]
      
      We can pass fs_info directly as this is the only member of btrfs_device
      that's bing used inside scrub_setup_ctx.
      Reviewed-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8ba3169d
    • Takeshi Saito's avatar
      mmc: renesas_sdhi: Fix card initialization failure in high speed mode · df732920
      Takeshi Saito authored
      [ Upstream commit d30ae056 ]
      
      This fixes card initialization failure in high speed mode.
      
      If U-Boot uses SDR or HS200/400 mode before starting Linux and Linux
      DT does not enable SDR/HS200/HS400 mode, card initialization fails in
      high speed mode.
      
      It is necessary to initialize SCC registers during card initialization
      phase. HW reset function is registered only for a port with either of
      SDR/HS200/HS400 properties in device tree. If SDR/HS200/HS400 properties
      are not present in device tree, SCC registers will not be reset. In SoC
      that support SCC registers, HW reset function should be registered
      regardless of the configuration of device tree.
      
      Reproduction procedure:
      - Use U-Boot that support MMC HS200/400 mode.
      - Delete HS200/HS400 properties in device tree.
        (Delete mmc-hs200-1_8v and mmc-hs400-1_8v)
      - MMC port works high speed mode and all commands fail.
      Signed-off-by: default avatarTakeshi Saito <takeshi.saito.xv@renesas.com>
      Signed-off-by: default avatarMarek Vasut <marek.vasut+renesas@gmail.com>
      Cc: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
      Cc: Simon Horman <horms+renesas@verge.net.au>
      Reviewed-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      df732920
    • Michael Ellerman's avatar
      powerpc/kvm: Save and restore host AMR/IAMR/UAMOR · 915c9d0a
      Michael Ellerman authored
      [ Upstream commit c3c7470c ]
      
      When the hash MMU is active the AMR, IAMR and UAMOR are used for
      pkeys. The AMR is directly writable by user space, and the UAMOR masks
      those writes, meaning both registers are effectively user register
      state. The IAMR is used to create an execute only key.
      
      Also we must maintain the value of at least the AMR when running in
      process context, so that any memory accesses done by the kernel on
      behalf of the process are correctly controlled by the AMR.
      
      Although we are correctly switching all registers when going into a
      guest, on returning to the host we just write 0 into all regs, except
      on Power9 where we restore the IAMR correctly.
      
      This could be observed by a user process if it writes the AMR, then
      runs a guest and we then return immediately to it without
      rescheduling. Because we have written 0 to the AMR that would have the
      effect of granting read/write permission to pages that the process was
      trying to protect.
      
      In addition, when using the Radix MMU, the AMR can prevent inadvertent
      kernel access to userspace data, writing 0 to the AMR disables that
      protection.
      
      So save and restore AMR, IAMR and UAMOR.
      
      Fixes: cf43d3b2 ("powerpc: Enable pkey subsystem")
      Cc: stable@vger.kernel.org # v4.16+
      Signed-off-by: default avatarRussell Currey <ruscur@russell.cc>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Acked-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      915c9d0a
    • Russell King's avatar
      spi: spi-gpio: fix SPI_CS_HIGH capability · b3f864b8
      Russell King authored
      [ Upstream commit b89fefda ]
      
      spi-gpio is capable of dealing with active-high chip-selects.
      Unfortunately, commit 4b859db2 ("spi: spi-gpio: add SPI_3WIRE
      support") broke this by setting master->mode_bits, which overrides
      the setting in the spi-bitbang code.  Fix this.
      
      [Fixed a trivial conflict with SPI_3WIRE_HIZ support -- broonie]
      
      Fixes: 4b859db2 ("spi: spi-gpio: add SPI_3WIRE support")
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b3f864b8
    • Pavel Tatashin's avatar
      x86/kvmclock: set offset for kvm unstable clock · 1d60902a
      Pavel Tatashin authored
      [ Upstream commit b5179ec4 ]
      
      VMs may show incorrect uptime and dmesg printk offsets on hypervisors with
      unstable clock. The problem is produced when VM is rebooted without exiting
      from qemu.
      
      The fix is to calculate clock offset not only for stable clock but for
      unstable clock as well, and use kvm_sched_clock_read() which substracts
      the offset for both clocks.
      
      This is safe, because pvclock_clocksource_read() does the right thing and
      makes sure that clock always goes forward, so once offset is calculated
      with unstable clock, we won't get new reads that are smaller than offset,
      and thus won't get negative results.
      
      Thank you Jon DeVree for helping to reproduce this issue.
      
      Fixes: 857baa87 ("sched/clock: Enable sched clock early")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarDominique Martinet <asmadeus@codewreck.org>
      Signed-off-by: default avatarPavel Tatashin <pasha.tatashin@soleen.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1d60902a
    • Ihab Zhaika's avatar
      iwlwifi: add new card for 9260 series · 716b0cfa
      Ihab Zhaika authored
      [ Upstream commit 3941310c ]
      
      Add one PCI ID for 9260 series.
      
      CC: <stable@vger.kernel.org> # 4.14+
      Signed-off-by: default avatarIhab Zhaika <ihab.zhaika@intel.com>
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      716b0cfa
    • Luca Coelho's avatar
      iwlwifi: fix devices with PCI Device ID 0x34F0 and 11ac RF modules · 213566a9
      Luca Coelho authored
      [ Upstream commit ab27926d ]
      
      The devices with PCI device ID 0x34F0 are part of the SoC and can be
      combined with some different external RF modules.  The configuration
      for these devices should reflect that, but are currently mixed up.  To
      avoid confusion with discrete devices, add part of the firmware to be
      used and the official name of the device to the cfg structs.
      
      This is least reorganization possible (without messing things even
      more) that could be done as a bugfix for this SoC.  Further
      reorganization of this code will be done separately.
      Signed-off-by: default avatarLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      213566a9
    • Lyude Paul's avatar
      drm/nouveau: Don't WARN_ON VCPI allocation failures · 2b76fcb6
      Lyude Paul authored
      [ Upstream commit b513a18c ]
      
      This is much louder then we want. VCPI allocation failures are quite
      normal, since they will happen if any part of the modesetting process is
      interrupted by removing the DP MST topology in question. So just print a
      debugging message on VCPI failures instead.
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Fixes: f479c0ba ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream")
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: dri-devel@lists.freedesktop.org
      Cc: nouveau@lists.freedesktop.org
      Cc: <stable@vger.kernel.org> # v4.10+
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2b76fcb6
    • Felix Fietkau's avatar
      mt76: fix corrupted software generated tx CCMP PN · 173b6557
      Felix Fietkau authored
      [ Upstream commit 906d2d3f ]
      
      Since ccmp_pn is u8 *, the second half needs to start at array index 4
      instead of 0. Fixes a connection stall after a certain amount of traffic
      
      Fixes: 23405236 ("mt76: fix transmission of encrypted management frames")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      173b6557
    • Krzysztof Kozlowski's avatar
      iio: adc: exynos-adc: Use proper number of channels for Exynos4x12 · 0d7f329e
      Krzysztof Kozlowski authored
      [ Upstream commit 103cda6a ]
      
      Exynos4212 and Exynos4412 have only four ADC channels so using
      "samsung,exynos-adc-v1" compatible (for eight channels ADCv1) on them is
      wrong.  Add a new compatible for Exynos4x12.
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0d7f329e
    • Jonathan Bakker's avatar
      dt-bindings: iio: adc: exynos-adc: Add S5PV210 variant · 4e516b72
      Jonathan Bakker authored
      [ Upstream commit a9b0a2a7 ]
      
      Add information about new compatible for S5PV210
      Signed-off-by: default avatarJonathan Bakker <xc-racer2@live.ca>
      Signed-off-by: default avatarPaweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4e516b72
    • Jonathan Bakker's avatar
      iio: adc: exynos-adc: Add S5PV210 variant · 7f588a72
      Jonathan Bakker authored
      [ Upstream commit 882bf52f ]
      
      S5PV210's ADC variant is almost the same as v1 except that it has 10
      channels and doesn't require the pmu register
      Signed-off-by: default avatarJonathan Bakker <xc-racer2@live.ca>
      Signed-off-by: default avatarPaweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7f588a72
    • Sean Christopherson's avatar
      KVM: VMX: Compare only a single byte for VMCS' "launched" in vCPU-run · cd490d44
      Sean Christopherson authored
      [ Upstream commit 61c08aa9 ]
      
      The vCPU-run asm blob does a manual comparison of a VMCS' launched
      status to execute the correct VM-Enter instruction, i.e. VMLAUNCH vs.
      VMRESUME.  The launched flag is a bool, which is a typedef of _Bool.
      C99 does not define an exact size for _Bool, stating only that is must
      be large enough to hold '0' and '1'.  Most, if not all, compilers use
      a single byte for _Bool, including gcc[1].
      
      Originally, 'launched' was of type 'int' and so the asm blob used 'cmpl'
      to check the launch status.  When 'launched' was moved to be stored on a
      per-VMCS basis, struct vcpu_vmx's "temporary" __launched flag was added
      in order to avoid having to pass the current VMCS into the asm blob.
      The new  '__launched' was defined as a 'bool' and not an 'int', but the
      'cmp' instruction was not updated.
      
      This has not caused any known problems, likely due to compilers aligning
      variables to 4-byte or 8-byte boundaries and KVM zeroing out struct
      vcpu_vmx during allocation.  I.e. vCPU-run accesses "junk" data, it just
      happens to always be zero and so doesn't affect the result.
      
      [1] https://gcc.gnu.org/ml/gcc-patches/2000-10/msg01127.html
      
      Fixes: d462b819 ("KVM: VMX: Keep list of loaded VMCSs, instead of vcpus")
      Cc: <stable@vger.kernel.org>
      Reviewed-by: default avatarJim Mattson <jmattson@google.com>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cd490d44
    • Tang Junhui's avatar
      bcache: treat stale && dirty keys as bad keys · 687e470e
      Tang Junhui authored
      [ Upstream commit 58ac3230 ]
      
      Stale && dirty keys can be produced in the follow way:
      After writeback in write_dirty_finish(), dirty keys k1 will
      replace by clean keys k2
      ==>ret = bch_btree_insert(dc->disk.c, &keys, NULL, &w->key);
      ==>btree_insert_fn(struct btree_op *b_op, struct btree *b)
      ==>static int bch_btree_insert_node(struct btree *b,
             struct btree_op *op,
             struct keylist *insert_keys,
             atomic_t *journal_ref,
      Then two steps:
      A) update k1 to k2 in btree node memory;
         bch_btree_insert_keys(b, op, insert_keys, replace_key)
      B) Write the bset(contains k2) to cache disk by a 30s delay work
         bch_btree_leaf_dirty(b, journal_ref).
      But before the 30s delay work write the bset to cache device,
      these things happened:
      A) GC works, and reclaim the bucket k2 point to;
      B) Allocator works, and invalidate the bucket k2 point to,
         and increase the gen of the bucket, and place it into free_inc
         fifo;
      C) Until now, the 30s delay work still does not finish work,
         so in the disk, the key still is k1, it is dirty and stale
         (its gen is smaller than the gen of the bucket). and then the
         machine power off suddenly happens;
      D) When the machine power on again, after the btree reconstruction,
         the stale dirty key appear.
      
      In bch_extent_bad(), when expensive_debug_checks is off, it would
      treat the dirty key as good even it is stale keys, and it would
      cause bellow probelms:
      A) In read_dirty() it would cause machine crash:
         BUG_ON(ptr_stale(dc->disk.c, &w->key, 0));
      B) It could be worse when reads hits stale dirty keys, it would
         read old incorrect data.
      
      This patch tolerate the existence of these stale && dirty keys,
      and treat them as bad key in bch_extent_bad().
      
      (Coly Li: fix indent which was modified by sender's email client)
      Signed-off-by: default avatarTang Junhui <tang.junhui.linux@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      687e470e
    • Coly Li's avatar
      bcache: replace hard coded number with BUCKET_GC_GEN_MAX · d1cec665
      Coly Li authored
      [ Upstream commit 149d0efa ]
      
      In extents.c:bch_extent_bad(), number 96 is used as parameter to call
      btree_bug_on(). The purpose is to check whether stale gen value exceeds
      BUCKET_GC_GEN_MAX, so it is better to use macro BUCKET_GC_GEN_MAX to
      make the code more understandable.
      Signed-off-by: default avatarColy Li <colyli@suse.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d1cec665
    • Jarkko Sakkinen's avatar
      tpm: Fix some name collisions with drivers/char/tpm.h · ee30121f
      Jarkko Sakkinen authored
      [ Upstream commit 8ab547a2 ]
      
      * Rename TPM_BUFSIZE defined in drivers/char/tpm/st33zp24/st33zp24.h to
        ST33ZP24_BUFSIZE.
      * Rename TPM_BUFSIZE defined in drivers/char/tpm/tpm_i2c_infineon.c to
        TPM_I2C_INFINEON_BUFSIZE.
      * Rename TPM_RETRY in tpm_i2c_nuvoton to TPM_I2C_RETRIES.
      * Remove TPM_HEADER_SIZE from tpm_i2c_nuvoton.
      
      Cc: stable@vger.kernel.org
      Fixes: bf38b871 ("tpm/tpm_i2c_stm_st33: Split tpm_i2c_tpm_st33 in 2 layers (core + phy)")
      Fixes: aad628c1 ("char/tpm: Add new driver for Infineon I2C TIS TPM")
      Fixes: 32d33b29 ("TPM: Retry SaveState command in suspend path")
      Signed-off-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ee30121f
    • Jarkko Nikula's avatar
      mfd: Kconfig: Fix I2C_DESIGNWARE_PLATFORM dependencies · c207ac66
      Jarkko Nikula authored
      [ Upstream commit 09fdc985 ]
      
      INTEL_SOC_PMIC, INTEL_SOC_PMIC_CHTWC and MFD_TPS68470 select the
      I2C_DESIGNWARE_PLATFORM without its dependencies making it possible to see
      warning and build error like below:
      
      WARNING: unmet direct dependencies detected for I2C_DESIGNWARE_PLATFORM
        Depends on [n]: I2C [=y] && HAS_IOMEM [=y] && (ACPI [=y] && COMMON_CLK [=n] || !ACPI [=y])
        Selected by [y]:
        - MFD_TPS68470 [=y] && HAS_IOMEM [=y] && ACPI [=y] && I2C [=y]=y
      
      /usr/bin/ld: drivers/i2c/busses/i2c-designware-platdrv.o: in function `dw_i2c_plat_resume':
      i2c-designware-platdrv.c:(.text+0x62): undefined reference to `i2c_dw_prepare_clk'
      /usr/bin/ld: drivers/i2c/busses/i2c-designware-platdrv.o: in function `dw_i2c_plat_suspend':
      i2c-designware-platdrv.c:(.text+0x9a): undefined reference to `i2c_dw_prepare_clk'
      /usr/bin/ld: drivers/i2c/busses/i2c-designware-platdrv.o: in function `dw_i2c_plat_probe':
      i2c-designware-platdrv.c:(.text+0x41c): undefined reference to `i2c_dw_prepare_clk'
      /usr/bin/ld: i2c-designware-platdrv.c:(.text+0x438): undefined reference to `i2c_dw_read_comp_param'
      /usr/bin/ld: i2c-designware-platdrv.c:(.text+0x545): undefined reference to `i2c_dw_probe'
      /usr/bin/ld: i2c-designware-platdrv.c:(.text+0x727): undefined reference to `i2c_dw_probe_slave'
      
      Fix this by making above options to depend on I2C_DESIGNWARE_PLATFORM
      being built-in. I2C_DESIGNWARE_PLATFORM is a visible symbol with
      dependencies so in general the select should be avoided.
      
      Fixes: acebcff9 ("mfd: intel_soc_pmic: Select designware i2c-bus driver")
      Fixes: de85d79f ("mfd: Add Cherry Trail Whiskey Cove PMIC driver")
      Fixes: 9bbf6a15 ("mfd: Add support for TPS68470 device")
      Cc: Stable <stable@vger.kernel.org> # v4.14+
      Reported-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarJarkko Nikula <jarkko.nikula@linux.intel.com>
      Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c207ac66
    • José Roberto de Souza's avatar
      drm/i915/ilk: Fix warning when reading emon_status with no output · 6fd5e50a
      José Roberto de Souza authored
      [ Upstream commit cab870b7 ]
      
      When there is no output no one will hold a runtime_pm reference
      causing a warning when trying to read emom_status in debugfs.
      
      [22.756480] ------------[ cut here ]------------
      [22.756489] RPM wakelock ref not held during HW access
      [22.756578] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915]
      [22.756580] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core e1000e snd_pcm mei_me prime_numbers mei lpc_ich
      [22.756595] CPU: 0 PID: 1058 Comm: debugfs_test Not tainted 4.20.0-rc1-CI-Trybot_3219+ #1
      [22.756597] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011
      [22.756634] RIP: 0010:gen5_read32+0x16b/0x1a0 [i915]
      [22.756637] Code: a4 ea e0 0f 0b e9 d2 fe ff ff 80 3d a5 71 19 00 00 0f 85 d3 fe ff ff 48 c7 c7 48 d0 2d a0 c6 05 91 71 19 00 01 e8 35 a4 ea e0 <0f> 0b e9 b9 fe ff ff e8 69 c6 f2 e0 85 c0 75 92 48 c7 c2 78 d0 2d
      [22.756639] RSP: 0018:ffffc90000f1fd38 EFLAGS: 00010282
      [22.756642] RAX: 0000000000000000 RBX: ffff8801f7ab0000 RCX: 0000000000000006
      [22.756643] RDX: 0000000000000006 RSI: ffffffff8212886a RDI: ffffffff820d6d57
      [22.756645] RBP: 0000000000011020 R08: 0000000043e3d1a8 R09: 0000000000000000
      [22.756647] R10: ffffc90000f1fd80 R11: 0000000000000000 R12: 0000000000000001
      [22.756649] R13: ffff8801f7ab0068 R14: 0000000000000001 R15: ffff88020d53d188
      [22.756651] FS:  00007f2878849980(0000) GS:ffff880213a00000(0000) knlGS:0000000000000000
      [22.756653] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [22.756655] CR2: 00005638deedf028 CR3: 0000000203292001 CR4: 00000000000206f0
      [22.756657] Call Trace:
      [22.756689]  i915_mch_val+0x1b/0x60 [i915]
      [22.756721]  i915_emon_status+0x45/0xd0 [i915]
      [22.756730]  seq_read+0xdb/0x3c0
      [22.756736]  ? lockdep_hardirqs_off+0x94/0xd0
      [22.756740]  ? __slab_free+0x24e/0x510
      [22.756746]  full_proxy_read+0x52/0x90
      [22.756752]  __vfs_read+0x31/0x170
      [22.756759]  ? do_sys_open+0x13b/0x240
      [22.756763]  ? rcu_read_lock_sched_held+0x6f/0x80
      [22.756766]  vfs_read+0x9e/0x140
      [22.756770]  ksys_read+0x50/0xc0
      [22.756775]  do_syscall_64+0x55/0x190
      [22.756781]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [22.756783] RIP: 0033:0x7f28781dc34e
      [22.756786] Code: 00 00 00 00 48 8b 15 71 8c 20 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 0f 1f 40 00 8b 05 ba d0 20 00 85 c0 75 16 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5a f3 c3 0f 1f 84 00 00 00 00 00 41 54 55 49
      [22.756787] RSP: 002b:00007ffd33fa0d08 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
      [22.756790] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f28781dc34e
      [22.756792] RDX: 0000000000000200 RSI: 00007ffd33fa0d50 RDI: 0000000000000008
      [22.756794] RBP: 00007ffd33fa0f60 R08: 0000000000000000 R09: 0000000000000020
      [22.756796] R10: 0000000000000000 R11: 0000000000000246 R12: 00005638de45c2c0
      [22.756797] R13: 00007ffd33fa14b0 R14: 0000000000000000 R15: 0000000000000000
      [22.756806] irq event stamp: 47950
      [22.756811] hardirqs last  enabled at (47949): [<ffffffff810fba74>] vprintk_emit+0x124/0x320
      [22.756813] hardirqs last disabled at (47950): [<ffffffff810019b0>] trace_hardirqs_off_thunk+0x1a/0x1c
      [22.756816] softirqs last  enabled at (47518): [<ffffffff81c0033a>] __do_softirq+0x33a/0x4b9
      [22.756820] softirqs last disabled at (47479): [<ffffffff8108df29>] irq_exit+0xa9/0xc0
      [22.756858] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915]
      [22.756860] ---[ end trace bf56fa7d6a3cbf7a ]
      Signed-off-by: default avatarJosé Roberto de Souza <jose.souza@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181119230101.32460-1-jose.souza@intel.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      6fd5e50a
    • Ville Syrjälä's avatar
      drm/vblank: Allow dynamic per-crtc max_vblank_count · 2b4f5679
      Ville Syrjälä authored
      [ Upstream commit ed20151a ]
      
      On i965gm we need to adjust max_vblank_count dynamically
      depending on whether the TV encoder is used or not. To
      that end add a per-crtc max_vblank_count that takes
      precedence over its device wide counterpart. The driver
      can now call drm_crtc_set_max_vblank_count() to configure
      the per-crtc value before calling drm_vblank_on().
      
      Also looks like there was some discussion about exynos needing
      similar treatment.
      
      v2: Drop the extra max_vblank_count!=0 check for the
          WARN(last!=current), will take care of it in i915 code (Daniel)
          WARN_ON(!inmodeset) (Daniel)
          WARN_ON(dev->max_vblank_count)
          Pimp up the docs (Daniel)
      
      Cc: stable@vger.kernel.org
      Cc: Inki Dae <inki.dae@samsung.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20181127182004.28885-1-ville.syrjala@linux.intel.comReviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2b4f5679