1. 07 8月, 2019 20 次提交
    • A
      ACPI: blacklist: fix clang warning for unused DMI table · d5568763
      Arnd Bergmann 提交于
      [ Upstream commit b80d6a42bdc97bdb6139107d6034222e9843c6e2 ]
      
      When CONFIG_DMI is disabled, we only have a tentative declaration,
      which causes a warning from clang:
      
      drivers/acpi/blacklist.c:20:35: error: tentative array definition assumed to have one element [-Werror]
      static const struct dmi_system_id acpi_rev_dmi_table[] __initconst;
      
      As the variable is not actually used here, hide it entirely
      in an #ifdef to shut up the warning.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d5568763
    • J
      ceph: return -ERANGE if virtual xattr value didn't fit in buffer · c47e2552
      Jeff Layton 提交于
      [ Upstream commit 3b421018f48c482bdc9650f894aa1747cf90e51d ]
      
      The getxattr manpage states that we should return ERANGE if the
      destination buffer size is too small to hold the value.
      ceph_vxattrcb_layout does this internally, but we should be doing
      this for all vxattrs.
      
      Fix the only caller of getxattr_cb to check the returned size
      against the buffer length and return -ERANGE if it doesn't fit.
      Drop the same check in ceph_vxattrcb_layout and just rely on the
      caller to handle it.
      Signed-off-by: NJeff Layton <jlayton@kernel.org>
      Reviewed-by: N"Yan, Zheng" <zyan@redhat.com>
      Acked-by: NIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c47e2552
    • A
      ceph: fix improper use of smp_mb__before_atomic() · b39c377e
      Andrea Parri 提交于
      [ Upstream commit 749607731e26dfb2558118038c40e9c0c80d23b5 ]
      
      This barrier only applies to the read-modify-write operations; in
      particular, it does not apply to the atomic64_set() primitive.
      
      Replace the barrier with an smp_mb().
      
      Fixes: fdd4e158 ("ceph: rework dcache readdir")
      Reported-by: N"Paul E. McKenney" <paulmck@linux.ibm.com>
      Reported-by: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NAndrea Parri <andrea.parri@amarulasolutions.com>
      Reviewed-by: N"Yan, Zheng" <zyan@redhat.com>
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b39c377e
    • R
      cifs: Fix a race condition with cifs_echo_request · d29fbf67
      Ronnie Sahlberg 提交于
      [ Upstream commit f2caf901c1b7ce65f9e6aef4217e3241039db768 ]
      
      There is a race condition with how we send (or supress and don't send)
      smb echos that will cause the client to incorrectly think the
      server is unresponsive and thus needs to be reconnected.
      
      Summary of the race condition:
       1) Daisy chaining scheduling creates a gap.
       2) If traffic comes unfortunate shortly after
          the last echo, the planned echo is suppressed.
       3) Due to the gap, the next echo transmission is delayed
          until after the timeout, which is set hard to twice
          the echo interval.
      
      This is fixed by changing the timeouts from 2 to three times the echo interval.
      
      Detailed description of the bug: https://lutz.donnerhacke.de/eng/Blog/Groundhog-Day-with-SMB-remountSigned-off-by: NRonnie Sahlberg <lsahlber@redhat.com>
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d29fbf67
    • Q
      btrfs: qgroup: Don't hold qgroup_ioctl_lock in btrfs_qgroup_inherit() · f96c70fa
      Qu Wenruo 提交于
      [ Upstream commit e88439debd0a7f969b3ddba6f147152cd0732676 ]
      
      [BUG]
      Lockdep will report the following circular locking dependency:
      
        WARNING: possible circular locking dependency detected
        5.2.0-rc2-custom #24 Tainted: G           O
        ------------------------------------------------------
        btrfs/8631 is trying to acquire lock:
        000000002536438c (&fs_info->qgroup_ioctl_lock#2){+.+.}, at: btrfs_qgroup_inherit+0x40/0x620 [btrfs]
      
        but task is already holding lock:
        000000003d52cc23 (&fs_info->tree_log_mutex){+.+.}, at: create_pending_snapshot+0x8b6/0xe60 [btrfs]
      
        which lock already depends on the new lock.
      
        the existing dependency chain (in reverse order) is:
      
        -> #2 (&fs_info->tree_log_mutex){+.+.}:
               __mutex_lock+0x76/0x940
               mutex_lock_nested+0x1b/0x20
               btrfs_commit_transaction+0x475/0xa00 [btrfs]
               btrfs_commit_super+0x71/0x80 [btrfs]
               close_ctree+0x2bd/0x320 [btrfs]
               btrfs_put_super+0x15/0x20 [btrfs]
               generic_shutdown_super+0x72/0x110
               kill_anon_super+0x18/0x30
               btrfs_kill_super+0x16/0xa0 [btrfs]
               deactivate_locked_super+0x3a/0x80
               deactivate_super+0x51/0x60
               cleanup_mnt+0x3f/0x80
               __cleanup_mnt+0x12/0x20
               task_work_run+0x94/0xb0
               exit_to_usermode_loop+0xd8/0xe0
               do_syscall_64+0x210/0x240
               entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
        -> #1 (&fs_info->reloc_mutex){+.+.}:
               __mutex_lock+0x76/0x940
               mutex_lock_nested+0x1b/0x20
               btrfs_commit_transaction+0x40d/0xa00 [btrfs]
               btrfs_quota_enable+0x2da/0x730 [btrfs]
               btrfs_ioctl+0x2691/0x2b40 [btrfs]
               do_vfs_ioctl+0xa9/0x6d0
               ksys_ioctl+0x67/0x90
               __x64_sys_ioctl+0x1a/0x20
               do_syscall_64+0x65/0x240
               entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
        -> #0 (&fs_info->qgroup_ioctl_lock#2){+.+.}:
               lock_acquire+0xa7/0x190
               __mutex_lock+0x76/0x940
               mutex_lock_nested+0x1b/0x20
               btrfs_qgroup_inherit+0x40/0x620 [btrfs]
               create_pending_snapshot+0x9d7/0xe60 [btrfs]
               create_pending_snapshots+0x94/0xb0 [btrfs]
               btrfs_commit_transaction+0x415/0xa00 [btrfs]
               btrfs_mksubvol+0x496/0x4e0 [btrfs]
               btrfs_ioctl_snap_create_transid+0x174/0x180 [btrfs]
               btrfs_ioctl_snap_create_v2+0x11c/0x180 [btrfs]
               btrfs_ioctl+0xa90/0x2b40 [btrfs]
               do_vfs_ioctl+0xa9/0x6d0
               ksys_ioctl+0x67/0x90
               __x64_sys_ioctl+0x1a/0x20
               do_syscall_64+0x65/0x240
               entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
        other info that might help us debug this:
      
        Chain exists of:
          &fs_info->qgroup_ioctl_lock#2 --> &fs_info->reloc_mutex --> &fs_info->tree_log_mutex
      
         Possible unsafe locking scenario:
      
               CPU0                    CPU1
               ----                    ----
          lock(&fs_info->tree_log_mutex);
                                       lock(&fs_info->reloc_mutex);
                                       lock(&fs_info->tree_log_mutex);
          lock(&fs_info->qgroup_ioctl_lock#2);
      
         *** DEADLOCK ***
      
        6 locks held by btrfs/8631:
         #0: 00000000ed8f23f6 (sb_writers#12){.+.+}, at: mnt_want_write_file+0x28/0x60
         #1: 000000009fb1597a (&type->i_mutex_dir_key#10/1){+.+.}, at: btrfs_mksubvol+0x70/0x4e0 [btrfs]
         #2: 0000000088c5ad88 (&fs_info->subvol_sem){++++}, at: btrfs_mksubvol+0x128/0x4e0 [btrfs]
         #3: 000000009606fc3e (sb_internal#2){.+.+}, at: start_transaction+0x37a/0x520 [btrfs]
         #4: 00000000f82bbdf5 (&fs_info->reloc_mutex){+.+.}, at: btrfs_commit_transaction+0x40d/0xa00 [btrfs]
         #5: 000000003d52cc23 (&fs_info->tree_log_mutex){+.+.}, at: create_pending_snapshot+0x8b6/0xe60 [btrfs]
      
      [CAUSE]
      Due to the delayed subvolume creation, we need to call
      btrfs_qgroup_inherit() inside commit transaction code, with a lot of
      other mutex hold.
      This hell of lock chain can lead to above problem.
      
      [FIX]
      On the other hand, we don't really need to hold qgroup_ioctl_lock if
      we're in the context of create_pending_snapshot().
      As in that context, we're the only one being able to modify qgroup.
      
      All other qgroup functions which needs qgroup_ioctl_lock are either
      holding a transaction handle, or will start a new transaction:
        Functions will start a new transaction():
        * btrfs_quota_enable()
        * btrfs_quota_disable()
        Functions hold a transaction handler:
        * btrfs_add_qgroup_relation()
        * btrfs_del_qgroup_relation()
        * btrfs_create_qgroup()
        * btrfs_remove_qgroup()
        * btrfs_limit_qgroup()
        * btrfs_qgroup_inherit() call inside create_subvol()
      
      So we have a higher level protection provided by transaction, thus we
      don't need to always hold qgroup_ioctl_lock in btrfs_qgroup_inherit().
      
      Only the btrfs_qgroup_inherit() call in create_subvol() needs to hold
      qgroup_ioctl_lock, while the btrfs_qgroup_inherit() call in
      create_pending_snapshot() is already protected by transaction.
      
      So the fix is to detect the context by checking
      trans->transaction->state.
      If we're at TRANS_STATE_COMMIT_DOING, then we're in commit transaction
      context and no need to get the mutex.
      Reported-by: NNikolay Borisov <nborisov@suse.com>
      Signed-off-by: NQu Wenruo <wqu@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f96c70fa
    • D
      btrfs: fix minimum number of chunk errors for DUP · d9245dab
      David Sterba 提交于
      [ Upstream commit 0ee5f8ae082e1f675a2fb6db601c31ac9958a134 ]
      
      The list of profiles in btrfs_chunk_max_errors lists DUP as a profile
      DUP able to tolerate 1 device missing. Though this profile is special
      with 2 copies, it still needs the device, unlike the others.
      
      Looking at the history of changes, thre's no clear reason why DUP is
      there, functions were refactored and blocks of code merged to one
      helper.
      
      d20983b4 Btrfs: fix writing data into the seed filesystem
        - factor code to a helper
      
      de11cc12 Btrfs: don't pre-allocate btrfs bio
        - unrelated change, DUP still in the list with max errors 1
      
      a236aed1 Btrfs: Deal with failed writes in mirrored configurations
        - introduced the max errors, leaves DUP and RAID1 in the same group
      Reviewed-by: NQu Wenruo <wqu@suse.com>
      Signed-off-by: NDavid Sterba <dsterba@suse.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d9245dab
    • C
      clk: sprd: Add check for return value of sprd_clk_regmap_init() · e7fcc587
      Chunyan Zhang 提交于
      [ Upstream commit c974c48deeb969c5e4250e4f06af91edd84b1f10 ]
      
      sprd_clk_regmap_init() doesn't always return success, adding check
      for its return value should make the code more strong.
      Signed-off-by: NChunyan Zhang <zhang.chunyan@linaro.org>
      Reviewed-by: NBaolin Wang <baolin.wang@linaro.org>
      [sboyd@kernel.org: Add a missing int ret]
      Signed-off-by: NStephen Boyd <sboyd@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e7fcc587
    • R
      fs/adfs: super: fix use-after-free bug · a093208b
      Russell King 提交于
      [ Upstream commit 5808b14a1f52554de612fee85ef517199855e310 ]
      
      Fix a use-after-free bug during filesystem initialisation, where we
      access the disc record (which is stored in a buffer) after we have
      released the buffer.
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a093208b
    • J
      clk: tegra210: fix PLLU and PLLU_OUT1 · 85d854b4
      JC Kuo 提交于
      [ Upstream commit 0d34dfbf3023cf119b83f6470692c0b10c832495 ]
      
      Full-speed and low-speed USB devices do not work with Tegra210
      platforms because of incorrect PLLU/PLLU_OUT1 clock settings.
      
      When full-speed device is connected:
      [   14.059886] usb 1-3: new full-speed USB device number 2 using tegra-xusb
      [   14.196295] usb 1-3: device descriptor read/64, error -71
      [   14.436311] usb 1-3: device descriptor read/64, error -71
      [   14.675749] usb 1-3: new full-speed USB device number 3 using tegra-xusb
      [   14.812335] usb 1-3: device descriptor read/64, error -71
      [   15.052316] usb 1-3: device descriptor read/64, error -71
      [   15.164799] usb usb1-port3: attempt power cycle
      
      When low-speed device is connected:
      [   37.610949] usb usb1-port3: Cannot enable. Maybe the USB cable is bad?
      [   38.557376] usb usb1-port3: Cannot enable. Maybe the USB cable is bad?
      [   38.564977] usb usb1-port3: attempt power cycle
      
      This commit fixes the issue by:
       1. initializing PLLU_OUT1 before initializing XUSB_FS_SRC clock
          because PLLU_OUT1 is parent of XUSB_FS_SRC.
       2. changing PLLU post-divider to /2 (DIVP=1) according to Technical
          Reference Manual.
      
      Fixes: e745f992 ("clk: tegra: Rework pll_u")
      Signed-off-by: NJC Kuo <jckuo@nvidia.com>
      Acked-By: NPeter De Schrijver <pdeschrijver@nvidia.com>
      Signed-off-by: NStephen Boyd <sboyd@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      85d854b4
    • G
      dmaengine: rcar-dmac: Reject zero-length slave DMA requests · cf0fcc7f
      Geert Uytterhoeven 提交于
      [ Upstream commit 78efb76ab4dfb8f74f290ae743f34162cd627f19 ]
      
      While the .device_prep_slave_sg() callback rejects empty scatterlists,
      it still accepts single-entry scatterlists with a zero-length segment.
      These may happen if a driver calls dmaengine_prep_slave_single() with a
      zero len parameter.  The corresponding DMA request will never complete,
      leading to messages like:
      
          rcar-dmac e7300000.dma-controller: Channel Address Error happen
      
      and DMA timeouts.
      
      Although requesting a zero-length DMA request is a driver bug, rejecting
      it early eases debugging.  Note that the .device_prep_dma_memcpy()
      callback already rejects requests to copy zero bytes.
      Reported-by: NEugeniu Rosca <erosca@de.adit-jv.com>
      Analyzed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NVinod Koul <vkoul@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cf0fcc7f
    • P
      MIPS: lantiq: Fix bitfield masking · a3524486
      Petr Cvek 提交于
      [ Upstream commit ba1bc0fcdeaf3bf583c1517bd2e3e29cf223c969 ]
      
      The modification of EXIN register doesn't clean the bitfield before
      the writing of a new value. After a few modifications the bitfield would
      accumulate only '1's.
      Signed-off-by: NPetr Cvek <petrcvekcz@gmail.com>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: hauke@hauke-m.de
      Cc: john@phrozen.org
      Cc: linux-mips@vger.kernel.org
      Cc: openwrt-devel@lists.openwrt.org
      Cc: pakahmar@hotmail.com
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a3524486
    • J
      firmware/psci: psci_checker: Park kthreads before stopping them · cdee3f53
      Jean-Philippe Brucker 提交于
      [ Upstream commit 92e074acf6f7694e96204265eb18ac113f546e80 ]
      
      Since commit 85f1abe0 ("kthread, sched/wait: Fix kthread_parkme()
      completion issue"), kthreads that are bound to a CPU must be parked
      before being stopped. At the moment the PSCI checker calls
      kthread_stop() directly on the suspend kthread, which triggers the
      following warning:
      
      [    6.068288] WARNING: CPU: 1 PID: 1 at kernel/kthread.c:398 __kthread_bind_mask+0x20/0x78
                     ...
      [    6.190151] Call trace:
      [    6.192566]  __kthread_bind_mask+0x20/0x78
      [    6.196615]  kthread_unpark+0x74/0x80
      [    6.200235]  kthread_stop+0x44/0x1d8
      [    6.203769]  psci_checker+0x3bc/0x484
      [    6.207389]  do_one_initcall+0x48/0x260
      [    6.211180]  kernel_init_freeable+0x2c8/0x368
      [    6.215488]  kernel_init+0x10/0x100
      [    6.218935]  ret_from_fork+0x10/0x1c
      [    6.222467] ---[ end trace e05e22863d043cd3 ]---
      
      kthread_unpark() tries to bind the thread to its CPU and aborts with a
      WARN() if the thread wasn't in TASK_PARKED state. Park the kthreads
      before stopping them.
      
      Fixes: 85f1abe0 ("kthread, sched/wait: Fix kthread_parkme() completion issue")
      Signed-off-by: NJean-Philippe Brucker <jean-philippe.brucker@arm.com>
      Reviewed-by: NSudeep Holla <sudeep.holla@arm.com>
      Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cdee3f53
    • P
      kernel/module.c: Only return -EEXIST for modules that have finished loading · 09ec6c67
      Prarit Bhargava 提交于
      [ Upstream commit 6e6de3dee51a439f76eb73c22ae2ffd2c9384712 ]
      
      Microsoft HyperV disables the X86_FEATURE_SMCA bit on AMD systems, and
      linux guests boot with repeated errors:
      
      amd64_edac_mod: Unknown symbol amd_unregister_ecc_decoder (err -2)
      amd64_edac_mod: Unknown symbol amd_register_ecc_decoder (err -2)
      amd64_edac_mod: Unknown symbol amd_report_gart_errors (err -2)
      amd64_edac_mod: Unknown symbol amd_unregister_ecc_decoder (err -2)
      amd64_edac_mod: Unknown symbol amd_register_ecc_decoder (err -2)
      amd64_edac_mod: Unknown symbol amd_report_gart_errors (err -2)
      
      The warnings occur because the module code erroneously returns -EEXIST
      for modules that have failed to load and are in the process of being
      removed from the module list.
      
      module amd64_edac_mod has a dependency on module edac_mce_amd.  Using
      modules.dep, systemd will load edac_mce_amd for every request of
      amd64_edac_mod.  When the edac_mce_amd module loads, the module has
      state MODULE_STATE_UNFORMED and once the module load fails and the state
      becomes MODULE_STATE_GOING.  Another request for edac_mce_amd module
      executes and add_unformed_module() will erroneously return -EEXIST even
      though the previous instance of edac_mce_amd has MODULE_STATE_GOING.
      Upon receiving -EEXIST, systemd attempts to load amd64_edac_mod, which
      fails because of unknown symbols from edac_mce_amd.
      
      add_unformed_module() must wait to return for any case other than
      MODULE_STATE_LIVE to prevent a race between multiple loads of
      dependent modules.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: NBarret Rhoden <brho@google.com>
      Cc: David Arcari <darcari@redhat.com>
      Cc: Jessica Yu <jeyu@kernel.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NJessica Yu <jeyu@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      09ec6c67
    • H
      arm64: dts: rockchip: fix isp iommu clocks and power domain · fd53e45a
      Helen Koike 提交于
      [ Upstream commit c432a29d3fc9ee928caeca2f5cf68b3aebfa6817 ]
      
      isp iommu requires wrapper variants of the clocks.
      noc variants are always on and using the wrapper variants will activate
      {A,H}CLK_ISP{0,1} due to the hierarchy.
      
      Tested using the pending isp patch set (which is not upstream
      yet). Without this patch, streaming from the isp stalls.
      
      Also add the respective power domain and remove the "disabled" status.
      
      Refer:
       RK3399 TRM v1.4 Fig. 2-4 RK3399 Clock Architecture Diagram
       RK3399 TRM v1.4 Fig. 8-1 RK3399 Power Domain Partition
      Signed-off-by: NHelen Koike <helen.koike@collabora.com>
      Tested-by: NManivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      fd53e45a
    • D
      dmaengine: tegra-apb: Error out if DMA_PREP_INTERRUPT flag is unset · d8388cbd
      Dmitry Osipenko 提交于
      [ Upstream commit dc161064beb83c668e0f85766b92b1e7ed186e58 ]
      
      Apparently driver was never tested with DMA_PREP_INTERRUPT flag being
      unset since it completely disables interrupt handling instead of skipping
      the callbacks invocations, hence putting channel into unusable state.
      
      The flag is always set by all of kernel drivers that use APB DMA, so let's
      error out in otherwise case for consistency. It won't be difficult to
      support that case properly if ever will be needed.
      Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
      Acked-by: NJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: NVinod Koul <vkoul@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d8388cbd
    • C
      ftrace: Enable trampoline when rec count returns back to one · f486088d
      Cheng Jian 提交于
      [ Upstream commit a124692b698b00026a58d89831ceda2331b2e1d0 ]
      
      Custom trampolines can only be enabled if there is only a single ops
      attached to it. If there's only a single callback registered to a function,
      and the ops has a trampoline registered for it, then we can call the
      trampoline directly. This is very useful for improving the performance of
      ftrace and livepatch.
      
      If more than one callback is registered to a function, the general
      trampoline is used, and the custom trampoline is not restored back to the
      direct call even if all the other callbacks were unregistered and we are
      back to one callback for the function.
      
      To fix this, set FTRACE_FL_TRAMP flag if rec count is decremented
      to one, and the ops that left has a trampoline.
      
      Testing After this patch :
      
      insmod livepatch_unshare_files.ko
      cat /sys/kernel/debug/tracing/enabled_functions
      
      	unshare_files (1) R I	tramp: 0xffffffffc0000000(klp_ftrace_handler+0x0/0xa0) ->ftrace_ops_assist_func+0x0/0xf0
      
      echo unshare_files > /sys/kernel/debug/tracing/set_ftrace_filter
      echo function > /sys/kernel/debug/tracing/current_tracer
      cat /sys/kernel/debug/tracing/enabled_functions
      
      	unshare_files (2) R I ->ftrace_ops_list_func+0x0/0x150
      
      echo nop > /sys/kernel/debug/tracing/current_tracer
      cat /sys/kernel/debug/tracing/enabled_functions
      
      	unshare_files (1) R I	tramp: 0xffffffffc0000000(klp_ftrace_handler+0x0/0xa0) ->ftrace_ops_assist_func+0x0/0xf0
      
      Link: http://lkml.kernel.org/r/1556969979-111047-1-git-send-email-cj.chengjian@huawei.comSigned-off-by: NCheng Jian <cj.chengjian@huawei.com>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f486088d
    • D
      ARM: dts: rockchip: Mark that the rk3288 timer might stop in suspend · ea26b427
      Douglas Anderson 提交于
      [ Upstream commit 8ef1ba39a9fa53d2205e633bc9b21840a275908e ]
      
      This is similar to commit e6186820 ("arm64: dts: rockchip: Arch
      counter doesn't tick in system suspend").  Specifically on the rk3288
      it can be seen that the timer stops ticking in suspend if we end up
      running through the "osc_disable" path in rk3288_slp_mode_set().  In
      that path the 24 MHz clock will turn off and the timer stops.
      
      To test this, I ran this on a Chrome OS filesystem:
        before=$(date); \
        suspend_stress_test -c1 --suspend_min=30 --suspend_max=31; \
        echo ${before}; date
      
      ...and I found that unless I plug in a device that requests USB wakeup
      to be active that the two calls to "date" would show that fewer than
      30 seconds passed.
      
      NOTE: deep suspend (where the 24 MHz clock gets disabled) isn't
      supported yet on upstream Linux so this was tested on a downstream
      kernel.
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ea26b427
    • D
      ARM: dts: rockchip: Make rk3288-veyron-mickey's emmc work again · 22befe67
      Douglas Anderson 提交于
      [ Upstream commit 99fa066710f75f18f4d9a5bc5f6a711968a581d5 ]
      
      When I try to boot rk3288-veyron-mickey I totally fail to make the
      eMMC work.  Specifically my logs (on Chrome OS 4.19):
      
        mmc_host mmc1: card is non-removable.
        mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
        mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
        mmc1: switch to bus width 8 failed
        mmc1: switch to bus width 4 failed
        mmc1: new high speed MMC card at address 0001
        mmcblk1: mmc1:0001 HAG2e 14.7 GiB
        mmcblk1boot0: mmc1:0001 HAG2e partition 1 4.00 MiB
        mmcblk1boot1: mmc1:0001 HAG2e partition 2 4.00 MiB
        mmcblk1rpmb: mmc1:0001 HAG2e partition 3 4.00 MiB, chardev (243:0)
        mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
        mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
        mmc1: switch to bus width 8 failed
        mmc1: switch to bus width 4 failed
        mmc1: tried to HW reset card, got error -110
        mmcblk1: error -110 requesting status
        mmcblk1: recovery failed!
        print_req_error: I/O error, dev mmcblk1, sector 0
        ...
      
      When I remove the '/delete-property/mmc-hs200-1_8v' then everything is
      hunky dory.
      
      That line comes from the original submission of the mickey dts
      upstream, so presumably at the time the HS200 was failing and just
      enumerating things as a high speed device was fine.  ...or maybe it's
      just that some mickey devices work when enumerating at "high speed",
      just not mine?
      
      In any case, hs200 seems good now.  Let's turn it on.
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      22befe67
    • D
      ARM: dts: rockchip: Make rk3288-veyron-minnie run at hs200 · 8c5a33d3
      Douglas Anderson 提交于
      [ Upstream commit 1c0479023412ab7834f2e98b796eb0d8c627cd62 ]
      
      As some point hs200 was failing on rk3288-veyron-minnie.  See commit
      98492678 ("ARM: dts: rockchip: temporarily remove emmc hs200 speed
      from rk3288 minnie").  Although I didn't track down exactly when it
      started working, it seems to work OK now, so let's turn it back on.
      
      To test this, I booted from SD card and then used this script to
      stress the enumeration process after fixing a memory leak [1]:
        cd /sys/bus/platform/drivers/dwmmc_rockchip
        for i in $(seq 1 3000); do
          echo "========================" $i
          echo ff0f0000.dwmmc > unbind
          sleep .5
          echo ff0f0000.dwmmc > bind
          while true; do
            if [ -e /dev/mmcblk2 ]; then
              break;
            fi
            sleep .1
          done
        done
      
      It worked fine.
      
      [1] https://lkml.kernel.org/r/20190503233526.226272-1-dianders@chromium.orgSigned-off-by: NDouglas Anderson <dianders@chromium.org>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8c5a33d3
    • R
      ARM: riscpc: fix DMA · 3c1d1bad
      Russell King 提交于
      [ Upstream commit ffd9a1ba9fdb7f2bd1d1ad9b9243d34e96756ba2 ]
      
      DMA got broken a while back in two different ways:
      1) a change in the behaviour of disable_irq() to wait for the interrupt
         to finish executing causes us to deadlock at the end of DMA.
      2) a change to avoid modifying the scatterlist left the first transfer
         uninitialised.
      
      DMA is only used with expansion cards, so has gone unnoticed.
      
      Fixes: fa4e9989 ("[ARM] dma: RiscPC: don't modify DMA SG entries")
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3c1d1bad
  2. 04 8月, 2019 20 次提交