1. 13 11月, 2019 40 次提交
    • J
      drm/i915: Disable Secure Batches for gen6+ · f1ff7708
      Jon Bloomfield 提交于
      commit 44157641d448cbc0c4b73c5231d2b911f0cb0427 upstream.
      
      Retroactively stop reporting support for secure batches
      through the api for gen6+ so that older binaries trigger
      the fallback path instead.
      
      Older binaries use secure batches pre gen6 to access resources
      that are not available to normal usermode processes. However,
      all known userspace explicitly checks for HAS_SECURE_BATCHES
      before relying on the secure batch feature.
      
      Since there are no known binaries relying on this for newer gens
      we can kill secure batches from gen6, via I915_PARAM_HAS_SECURE_BATCHES.
      
      v2: rebase (Mika)
      v3: rebase (Mika)
      Signed-off-by: NJon Bloomfield <jon.bloomfield@intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: NChris Wilson <chris.p.wilson@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f1ff7708
    • J
      drm/i915: Rename gen7 cmdparser tables · b4b1abdc
      Jon Bloomfield 提交于
      commit 0a2f661b6c21815a7fa60e30babe975fee8e73c6 upstream.
      
      We're about to introduce some new tables for later gens, and the
      current naming for the gen7 tables will no longer make sense.
      
      v2: rebase
      Signed-off-by: NJon Bloomfield <jon.bloomfield@intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: NChris Wilson <chris.p.wilson@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b4b1abdc
    • S
      vsock/virtio: fix sock refcnt holding during the shutdown · e238e05e
      Stefano Garzarella 提交于
      [ Upstream commit ad8a7220355d39cddce8eac1cea9677333e8b821 ]
      
      The "42f5cda5eaf4" commit rightly set SOCK_DONE on peer shutdown,
      but there is an issue if we receive the SHUTDOWN(RDWR) while the
      virtio_transport_close_timeout() is scheduled.
      In this case, when the timeout fires, the SOCK_DONE is already
      set and the virtio_transport_close_timeout() will not call
      virtio_transport_reset() and virtio_transport_do_close().
      This causes that both sockets remain open and will never be released,
      preventing the unloading of [virtio|vhost]_transport modules.
      
      This patch fixes this issue, calling virtio_transport_reset() and
      virtio_transport_do_close() when we receive the SHUTDOWN(RDWR)
      and there is nothing left to read.
      
      Fixes: 42f5cda5eaf4 ("vsock/virtio: set SOCK_DONE on peer shutdown")
      Cc: Stephen Barber <smbarber@chromium.org>
      Signed-off-by: NStefano Garzarella <sgarzare@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e238e05e
    • S
      iio: imu: mpu6050: Fix FIFO layout for ICM20602 · 2e7e3f16
      Steve Moskovchenko 提交于
      [ Upstream commit 1615fe41a1959a2ee2814ba62736b2bb54e9802a ]
      
      The MPU6050 driver has recently gained support for the
      ICM20602 IMU, which is very similar to MPU6xxx. However,
      the ICM20602's FIFO data specifically includes temperature
      readings, which were not present on MPU6xxx parts. As a
      result, the driver will under-read the ICM20602's FIFO
      register, causing the same (partial) sample to be returned
      for all reads, until the FIFO overflows.
      
      Fix this by adding a table of scan elements specifically
      for the ICM20602, which takes the extra temperature data
      into consideration.
      
      While we're at it, fix the temperature offset and scaling
      on ICM20602, since it uses different scale/offset constants
      than the rest of the MPU6xxx devices.
      Signed-off-by: NSteve Moskovchenko <stevemo@skydio.com>
      Fixes: 22904bdff978 ("iio: imu: mpu6050: Add support for the ICM 20602 IMU")
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2e7e3f16
    • E
      net: prevent load/store tearing on sk->sk_stamp · 99ea48af
      Eric Dumazet 提交于
      [ Upstream commit f75359f3ac855940c5718af10ba089b8977bf339 ]
      
      Add a couple of READ_ONCE() and WRITE_ONCE() to prevent
      load-tearing and store-tearing in sock_read_timestamp()
      and sock_write_timestamp()
      
      This might prevent another KCSAN report.
      
      Fixes: 3a0ed3e96197 ("sock: Make sock->sk_stamp thread-safe")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Deepa Dinamani <deepa.kernel@gmail.com>
      Acked-by: NDeepa Dinamani <deepa.kernel@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      99ea48af
    • S
      netfilter: ipset: Copy the right MAC address in hash:ip,mac IPv6 sets · d32629dc
      Stefano Brivio 提交于
      [ Upstream commit 97664bc2c77e2b65cdedddcae2643fc93291d958 ]
      
      Same as commit 1b4a75108d5b ("netfilter: ipset: Copy the right MAC
      address in bitmap:ip,mac and hash:ip,mac sets"), another copy and paste
      went wrong in commit 8cc4ccf58379 ("netfilter: ipset: Allow matching on
      destination MAC address for mac and ipmac sets").
      
      When I fixed this for IPv4 in 1b4a75108d5b, I didn't realise that
      hash:ip,mac sets also support IPv6 as family, and this is covered by a
      separate function, hash_ipmac6_kadt().
      
      In hash:ip,mac sets, the first dimension is the IP address, and the
      second dimension is the MAC address: check the IPSET_DIM_TWO_SRC flag
      in flags while deciding which MAC address to copy, destination or
      source.
      
      This way, mixing source and destination matches for the two dimensions
      of ip,mac hash type works as expected, also for IPv6. With this setup:
      
        ip netns add A
        ip link add veth1 type veth peer name veth2 netns A
        ip addr add 2001:db8::1/64 dev veth1
        ip -net A addr add 2001:db8::2/64 dev veth2
        ip link set veth1 up
        ip -net A link set veth2 up
      
        dst=$(ip netns exec A cat /sys/class/net/veth2/address)
      
        ip netns exec A ipset create test_hash hash:ip,mac family inet6
        ip netns exec A ipset add test_hash 2001:db8::1,${dst}
        ip netns exec A ip6tables -A INPUT -p icmpv6 --icmpv6-type 135 -j ACCEPT
        ip netns exec A ip6tables -A INPUT -m set ! --match-set test_hash src,dst -j DROP
      
      ipset now correctly matches a test packet:
      
        # ping -c1 2001:db8::2 >/dev/null
        # echo $?
        0
      Reported-by: NChen, Yi <yiche@redhat.com>
      Fixes: 8cc4ccf58379 ("netfilter: ipset: Allow matching on destination MAC address for mac and ipmac sets")
      Signed-off-by: NStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: NJozsef Kadlecsik <kadlec@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d32629dc
    • S
      usbip: Fix free of unallocated memory in vhci tx · 5833560d
      Suwan Kim 提交于
      [ Upstream commit d4d8257754c3300ea2a465dadf8d2b02c713c920 ]
      
      iso_buffer should be set to NULL after use and free in the while loop.
      In the case of isochronous URB in the while loop, iso_buffer is
      allocated and after sending it to server, buffer is deallocated. And
      then, if the next URB in the while loop is not a isochronous pipe,
      iso_buffer still holds the previously deallocated buffer address and
      kfree tries to free wrong buffer address.
      
      Fixes: ea44d190764b ("usbip: Implement SG support to vhci-hcd and stub driver")
      Reported-by: Nkbuild test robot <lkp@intel.com>
      Reported-by: NJulia Lawall <julia.lawall@lip6.fr>
      Signed-off-by: NSuwan Kim <suwan.kim027@gmail.com>
      Reviewed-by: NJulia Lawall <julia.lawall@lip6.fr>
      Acked-by: NShuah Khan <skhan@linuxfoundation.org>
      Link: https://lore.kernel.org/r/20191022093017.8027-1-suwan.kim027@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5833560d
    • T
      cgroup,writeback: don't switch wbs immediately on dead wbs if the memcg is dead · 6890b4bc
      Tejun Heo 提交于
      commit 65de03e251382306a4575b1779c57c87889eee49 upstream.
      
      cgroup writeback tries to refresh the associated wb immediately if the
      current wb is dead.  This is to avoid keeping issuing IOs on the stale
      wb after memcg - blkcg association has changed (ie. when blkcg got
      disabled / enabled higher up in the hierarchy).
      
      Unfortunately, the logic gets triggered spuriously on inodes which are
      associated with dead cgroups.  When the logic is triggered on dead
      cgroups, the attempt fails only after doing quite a bit of work
      allocating and initializing a new wb.
      
      While c3aab9a0bd91 ("mm/filemap.c: don't initiate writeback if mapping
      has no dirty pages") alleviated the issue significantly as it now only
      triggers when the inode has dirty pages.  However, the condition can
      still be triggered before the inode is switched to a different cgroup
      and the logic simply doesn't make sense.
      
      Skip the immediate switching if the associated memcg is dying.
      
      This is a simplified version of the following two patches:
      
       * https://lore.kernel.org/linux-mm/20190513183053.GA73423@dennisz-mbp/
       * http://lkml.kernel.org/r/156355839560.2063.5265687291430814589.stgit@buzz
      
      Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Fixes: e8a7abf5 ("writeback: disassociate inodes from dying bdi_writebacks")
      Acked-by: NDennis Zhou <dennis@kernel.org>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6890b4bc
    • K
      mm/filemap.c: don't initiate writeback if mapping has no dirty pages · d3b3c0a1
      Konstantin Khlebnikov 提交于
      commit c3aab9a0bd91b696a852169479b7db1ece6cbf8c upstream.
      
      Functions like filemap_write_and_wait_range() should do nothing if inode
      has no dirty pages or pages currently under writeback.  But they anyway
      construct struct writeback_control and this does some atomic operations if
      CONFIG_CGROUP_WRITEBACK=y - on fast path it locks inode->i_lock and
      updates state of writeback ownership, on slow path might be more work.
      Current this path is safely avoided only when inode mapping has no pages.
      
      For example generic_file_read_iter() calls filemap_write_and_wait_range()
      at each O_DIRECT read - pretty hot path.
      
      This patch skips starting new writeback if mapping has no dirty tags set.
      If writeback is already in progress filemap_write_and_wait_range() will
      wait for it.
      
      Link: http://lkml.kernel.org/r/156378816804.1087.8607636317907921438.stgit@buzzSigned-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Reviewed-by: NJan Kara <jack@suse.cz>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d3b3c0a1
    • J
      iio: imu: inv_mpu6050: fix no data on MPU6050 · 285eb6af
      Jean-Baptiste Maneyrol 提交于
      [ Upstream commit 6e82ae6b8d11b948b74e71396efd8e074c415f44 ]
      
      Some chips have a fifo overflow bit issue where the bit is always
      set. The result is that every data is dropped.
      
      Change fifo overflow management by checking fifo count against
      a maximum value.
      
      Add fifo size in chip hardware set of values.
      
      Fixes: f5057e7b ("iio: imu: inv_mpu6050: better fifo overflow handling")
      Cc: stable@vger.kernel.org
      Signed-off-by: NJean-Baptiste Maneyrol <jmaneyrol@invensense.com>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      285eb6af
    • R
      iio: imu: mpu6050: Add support for the ICM 20602 IMU · d888a807
      Randolph Maaßen 提交于
      [ Upstream commit 22904bdff97839960bd98b3452a583b1daee628b ]
      
      The Invensense ICM-20602 is a 6-axis MotionTracking device that
      combines a 3-axis gyroscope and an 3-axis accelerometer. It is very
      similar to the ICM-20608 imu which is already supported by the mpu6050
      driver. The main difference is that the ICM-20602 has the i2c bus
      disable bit in a separate register.
      Signed-off-by: NRandolph Maaßen <gaireg@gaireg.de>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d888a807
    • T
      blkcg: make blkcg_print_stat() print stats only for online blkgs · 52212812
      Tejun Heo 提交于
      [ Upstream commit b0814361a25cba73a224548843ed92d8ea78715a ]
      
      blkcg_print_stat() iterates blkgs under RCU and doesn't test whether
      the blkg is online.  This can call into pd_stat_fn() on a pd which is
      still being initialized leading to an oops.
      
      The heaviest operation - recursively summing up rwstat counters - is
      already done while holding the queue_lock.  Expand queue_lock to cover
      the other operations and skip the blkg if it isn't online yet.  The
      online state is protected by both blkcg and queue locks, so this
      guarantees that only online blkgs are processed.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NRoman Gushchin <guro@fb.com>
      Cc: Josef Bacik <jbacik@fb.com>
      Fixes: 903d23f0 ("blk-cgroup: allow controllers to output their own stats")
      Cc: stable@vger.kernel.org # v4.19+
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      52212812
    • H
      pinctrl: cherryview: Fix irq_valid_mask calculation · 30b96939
      Hans de Goede 提交于
      [ Upstream commit 63bdef6cd6941917c823b9cc9aa0219d19fcb716 ]
      
      Commit 03c4749d ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux
      GPIO translation") has made the cherryview gpio numbers sparse, to get
      a 1:1 mapping between ACPI pin numbers and gpio numbers in Linux.
      
      This has greatly simplified things, but the code setting the
      irq_valid_mask was not updated for this, so the valid mask is still in
      the old "compressed" numbering with the gaps in the pin numbers skipped,
      which is wrong as irq_valid_mask needs to be expressed in gpio numbers.
      
      This results in the following error on devices using pin 24 (0x0018) on
      the north GPIO controller as an ACPI event source:
      
      [    0.422452] cherryview-pinctrl INT33FF:01: Failed to translate GPIO to IRQ
      
      This has been reported (by email) to be happening on a Caterpillar CAT T20
      tablet and I've reproduced this myself on a Medion Akoya e2215t 2-in-1.
      
      This commit uses the pin number instead of the compressed index into
      community->pins to clear the correct bits in irq_valid_mask for GPIOs
      using GPEs for interrupts, fixing these errors and in case of the
      Medion Akoya e2215t also fixing the LID switch not working.
      
      Cc: stable@vger.kernel.org
      Fixes: 03c4749d ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation")
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      30b96939
    • S
      ocfs2: protect extent tree in ocfs2_prepare_inode_for_write() · ca79bb7e
      Shuning Zhang 提交于
      [ Upstream commit e74540b285569d2b1e14fe7aee92297078f235ce ]
      
      When the extent tree is modified, it should be protected by inode
      cluster lock and ip_alloc_sem.
      
      The extent tree is accessed and modified in the
      ocfs2_prepare_inode_for_write, but isn't protected by ip_alloc_sem.
      
      The following is a case.  The function ocfs2_fiemap is accessing the
      extent tree, which is modified at the same time.
      
        kernel BUG at fs/ocfs2/extent_map.c:475!
        invalid opcode: 0000 [#1] SMP
        Modules linked in: tun ocfs2 ocfs2_nodemanager configfs ocfs2_stackglue [...]
        CPU: 16 PID: 14047 Comm: o2info Not tainted 4.1.12-124.23.1.el6uek.x86_64 #2
        Hardware name: Oracle Corporation ORACLE SERVER X7-2L/ASM, MB MECH, X7-2L, BIOS 42040600 10/19/2018
        task: ffff88019487e200 ti: ffff88003daa4000 task.ti: ffff88003daa4000
        RIP: ocfs2_get_clusters_nocache.isra.11+0x390/0x550 [ocfs2]
        Call Trace:
          ocfs2_fiemap+0x1e3/0x430 [ocfs2]
          do_vfs_ioctl+0x155/0x510
          SyS_ioctl+0x81/0xa0
          system_call_fastpath+0x18/0xd8
        Code: 18 48 c7 c6 60 7f 65 a0 31 c0 bb e2 ff ff ff 48 8b 4a 40 48 8b 7a 28 48 c7 c2 78 2d 66 a0 e8 38 4f 05 00 e9 28 fe ff ff 0f 1f 00 <0f> 0b 66 0f 1f 44 00 00 bb 86 ff ff ff e9 13 fe ff ff 66 0f 1f
        RIP  ocfs2_get_clusters_nocache.isra.11+0x390/0x550 [ocfs2]
        ---[ end trace c8aa0c8180e869dc ]---
        Kernel panic - not syncing: Fatal exception
        Kernel Offset: disabled
      
      This issue can be reproduced every week in a production environment.
      
      This issue is related to the usage mode.  If others use ocfs2 in this
      mode, the kernel will panic frequently.
      
      [akpm@linux-foundation.org: coding style fixes]
      [Fix new warning due to unused function by removing said function - Linus ]
      Link: http://lkml.kernel.org/r/1568772175-2906-2-git-send-email-sunny.s.zhang@oracle.comSigned-off-by: NShuning Zhang <sunny.s.zhang@oracle.com>
      Reviewed-by: NJunxiao Bi <junxiao.bi@oracle.com>
      Reviewed-by: NGang He <ghe@suse.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Joseph Qi <jiangqi903@gmail.com>
      Cc: Changwei Ge <gechangwei@live.cn>
      Cc: Jun Piao <piaojun@huawei.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ca79bb7e
    • A
      pinctrl: intel: Avoid potential glitches if pin is in GPIO mode · 2c655a11
      Andy Shevchenko 提交于
      [ Upstream commit 29c2c6aa32405dfee4a29911a51ba133edcedb0f ]
      
      When consumer requests a pin, in order to be on the safest side,
      we switch it first to GPIO mode followed by immediate transition
      to the input state. Due to posted writes it's luckily to be a single
      I/O transaction.
      
      However, if firmware or boot loader already configures the pin
      to the GPIO mode, user expects no glitches for the requested pin.
      We may check if the pin is pre-configured and leave it as is
      till the actual consumer toggles its state to avoid glitches.
      
      Fixes: 7981c001 ("pinctrl: intel: Add Intel Sunrisepoint pin controller and GPIO support")
      Depends-on: f5a26acf ("pinctrl: intel: Initialize GPIO properly when used through irqchip")
      Cc: stable@vger.kernel.org
      Cc: fei.yang@intel.com
      Reported-by: NOliver Barta <oliver.barta@aptiv.com>
      Reported-by: NMalin Jonsson <malin.jonsson@ericsson.com>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2c655a11
    • W
      e1000: fix memory leaks · 713adf6d
      Wenwen Wang 提交于
      [ Upstream commit 8472ba62154058b64ebb83d5f57259a352d28697 ]
      
      In e1000_set_ringparam(), 'tx_old' and 'rx_old' are not deallocated if
      e1000_up() fails, leading to memory leaks. Refactor the code to fix this
      issue.
      Signed-off-by: NWenwen Wang <wenwen@cs.uga.edu>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      713adf6d
    • M
      igb: Fix constant media auto sense switching when no cable is connected · 4a055717
      Manfred Rudigier 提交于
      [ Upstream commit 8d5cfd7f76a2414e23c74bb8858af7540365d985 ]
      
      At least on the i350 there is an annoying behavior that is maybe also
      present on 82580 devices, but was probably not noticed yet as MAS is not
      widely used.
      
      If no cable is connected on both fiber/copper ports the media auto sense
      code will constantly swap between them as part of the watchdog task and
      produce many unnecessary kernel log messages.
      
      The swap code responsible for this behavior (switching to fiber) should
      not be executed if the current media type is copper and there is no signal
      detected on the fiber port. In this case we can safely wait until the
      AUTOSENSE_EN bit is cleared.
      Signed-off-by: NManfred Rudigier <manfred.rudigier@omicronenergy.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4a055717
    • C
      net: ethernet: arc: add the missed clk_disable_unprepare · 1baab835
      Chuhong Yuan 提交于
      [ Upstream commit 4202e219edd6cc164c042e16fa327525410705ae ]
      
      The remove misses to disable and unprepare priv->macclk like what is done
      when probe fails.
      Add the missed call in remove.
      Signed-off-by: NChuhong Yuan <hslester96@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1baab835
    • T
      NFSv4: Don't allow a cached open with a revoked delegation · 24523745
      Trond Myklebust 提交于
      [ Upstream commit be3df3dd4c70ee020587a943a31b98a0fb4b6424 ]
      
      If the delegation is marked as being revoked, we must not use it
      for cached opens.
      
      Fixes: 869f9dfa ("NFSv4: Fix races between nfs_remove_bad_delegation() and delegation return")
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      24523745
    • F
      usb: dwc3: gadget: fix race when disabling ep with cancelled xfers · 440a748e
      Felipe Balbi 提交于
      [ Upstream commit d8eca64eec7103ab1fbabc0a187dbf6acfb2af93 ]
      
      When disabling an endpoint which has cancelled requests, we should
      make sure to giveback requests that are currently pending in the
      cancelled list, otherwise we may fall into a situation where command
      completion interrupt fires after endpoint has been disabled, therefore
      causing a splat.
      
      Fixes: fec9095bdef4 "usb: dwc3: gadget: remove wait_end_transfer"
      Reported-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Link: https://lore.kernel.org/r/20191031090713.1452818-1-felipe.balbi@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      440a748e
    • H
      hv_netvsc: Fix error handling in netvsc_attach() · e66f52eb
      Haiyang Zhang 提交于
      [ Upstream commit 719b85c336ed35565d0f3982269d6f684087bb00 ]
      
      If rndis_filter_open() fails, we need to remove the rndis device created
      in earlier steps, before returning an error code. Otherwise, the retry of
      netvsc_attach() from its callers will fail and hang.
      
      Fixes: 7b2ee50c ("hv_netvsc: common detach logic")
      Signed-off-by: NHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e66f52eb
    • M
      drm/amd/display: Passive DP->HDMI dongle detection fix · 99d5f18c
      Michael Strauss 提交于
      [ Upstream commit bc2fde42e2418808dbfc04de1a6da91d7d31cf1a ]
      
      [WHY]
      i2c_read is called to differentiate passive DP->HDMI and DP->DVI-D dongles
      The call is expected to fail in DVI-D case but pass in HDMI case
      Some HDMI dongles have a chance to fail as well, causing misdetection as DVI-D
      
      [HOW]
      Retry i2c_read to ensure failed result is valid
      Signed-off-by: NMichael Strauss <michael.strauss@amd.com>
      Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
      Acked-by: NLeo Li <sunpeng.li@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      99d5f18c
    • A
      drm/amdgpu: If amdgpu_ib_schedule fails return back the error. · e5edbf9c
      Andrey Grodzovsky 提交于
      [ Upstream commit 57c0f58e9f562089de5f0b60da103677d232374c ]
      
      Use ERR_PTR to return back the error happened during amdgpu_ib_schedule.
      Signed-off-by: NAndrey Grodzovsky <andrey.grodzovsky@amd.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e5edbf9c
    • T
      iommu/amd: Apply the same IVRS IOAPIC workaround to Acer Aspire A315-41 · b651ddc1
      Takashi Iwai 提交于
      [ Upstream commit ad3e8da2d422c63c13819a53d3c5ea9312cc0b9d ]
      
      Acer Aspire A315-41 requires the very same workaround as the existing
      quirk for Dell Latitude 5495.  Add the new entry for that.
      
      BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1137799Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b651ddc1
    • V
      net: mscc: ocelot: refuse to overwrite the port's native vlan · 214e4f0e
      Vladimir Oltean 提交于
      [ Upstream commit b9cd75e6689560140dadaed98eb4b41aad75d55d ]
      
      The switch driver keeps a "vid" variable per port, which signifies _the_
      VLAN ID that is stripped on that port's egress (aka the native VLAN on a
      trunk port).
      
      That is the way the hardware is designed (mostly). The port->vid is
      programmed into REW:PORT:PORT_VLAN_CFG:PORT_VID and the rewriter is told
      to send all traffic as tagged except the one having port->vid.
      
      There exists a possibility of finer-grained egress untagging decisions:
      using the VCAP IS1 engine, one rule can be added to match every
      VLAN-tagged frame whose VLAN should be untagged, and set POP_CNT=1 as
      action. However, the IS1 can hold at most 512 entries, and the VLANs are
      in the order of 6 * 4096.
      
      So the code is fine for now. But this sequence of commands:
      
      $ bridge vlan add dev swp0 vid 1 pvid untagged
      $ bridge vlan add dev swp0 vid 2 untagged
      
      makes untagged and pvid-tagged traffic be sent out of swp0 as tagged
      with VID 1, despite user's request.
      
      Prevent that from happening. The user should temporarily remove the
      existing untagged VLAN (1 in this case), add it back as tagged, and then
      add the new untagged VLAN (2 in this case).
      
      Cc: Antoine Tenart <antoine.tenart@bootlin.com>
      Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
      Fixes: 7142529f ("net: mscc: ocelot: add VLAN filtering")
      Signed-off-by: NVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Acked-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      214e4f0e
    • V
      net: mscc: ocelot: fix vlan_filtering when enslaving to bridge before link is up · 5aedcc8a
      Vladimir Oltean 提交于
      [ Upstream commit 1c44ce560b4de639f237b458be1729489ff44d0a ]
      
      Background information: the driver operates the hardware in a mode where
      a single VLAN can be transmitted as untagged on a particular egress
      port. That is the "native VLAN on trunk port" use case. Its value is
      held in port->vid.
      
      Consider the following command sequence (no network manager, all
      interfaces are down, debugging prints added by me):
      
      $ ip link add dev br0 type bridge vlan_filtering 1
      $ ip link set dev swp0 master br0
      
      Kernel code path during last command:
      
      br_add_slave -> ocelot_netdevice_port_event (NETDEV_CHANGEUPPER):
      [   21.401901] ocelot_vlan_port_apply: port 0 vlan aware 0 pvid 0 vid 0
      
      br_add_slave -> nbp_vlan_init -> switchdev_port_attr_set -> ocelot_port_attr_set (SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING):
      [   21.413335] ocelot_vlan_port_apply: port 0 vlan aware 1 pvid 0 vid 0
      
      br_add_slave -> nbp_vlan_init -> nbp_vlan_add -> br_switchdev_port_vlan_add -> switchdev_port_obj_add -> ocelot_port_obj_add -> ocelot_vlan_vid_add
      [   21.667421] ocelot_vlan_port_apply: port 0 vlan aware 1 pvid 1 vid 1
      
      So far so good. The bridge has replaced the driver's default pvid used
      in standalone mode (0) with its own default_pvid (1). The port's vid
      (native VLAN) has also changed from 0 to 1.
      
      $ ip link set dev swp0 up
      
      [   31.722956] 8021q: adding VLAN 0 to HW filter on device swp0
      do_setlink -> dev_change_flags -> vlan_vid_add -> ocelot_vlan_rx_add_vid -> ocelot_vlan_vid_add:
      [   31.728700] ocelot_vlan_port_apply: port 0 vlan aware 1 pvid 1 vid 0
      
      The 8021q module uses the .ndo_vlan_rx_add_vid API on .ndo_open to make
      ports be able to transmit and receive 802.1p-tagged traffic by default.
      This API is supposed to offload a VLAN sub-interface, which for a switch
      port means to add a VLAN that is not a pvid, and tagged on egress.
      
      But the driver implementation of .ndo_vlan_rx_add_vid is wrong: it adds
      back vid 0 as "egress untagged". Now back to the initial paragraph:
      there is a single untagged VID that the driver keeps track of, and that
      has just changed from 1 (the pvid) to 0. So this breaks the bridge
      core's expectation, because it has changed vid 1 from untagged to
      tagged, when what the user sees is.
      
      $ bridge vlan
      port    vlan ids
      swp0     1 PVID Egress Untagged
      
      br0      1 PVID Egress Untagged
      
      But curiously, instead of manifesting itself as "untagged and
      pvid-tagged traffic gets sent as tagged on egress", the bug:
      
      - is hidden when vlan_filtering=0
      - manifests as dropped traffic when vlan_filtering=1, due to this setting:
      
      	if (port->vlan_aware && !port->vid)
      		/* If port is vlan-aware and tagged, drop untagged and priority
      		 * tagged frames.
      		 */
      		val |= ANA_PORT_DROP_CFG_DROP_UNTAGGED_ENA |
      		       ANA_PORT_DROP_CFG_DROP_PRIO_S_TAGGED_ENA |
      		       ANA_PORT_DROP_CFG_DROP_PRIO_C_TAGGED_ENA;
      
      which would have made sense if it weren't for this bug. The setting's
      intention was "this is a trunk port with no native VLAN, so don't accept
      untagged traffic". So the driver was never expecting to set VLAN 0 as
      the value of the native VLAN, 0 was just encoding for "invalid".
      
      So the fix is to not send 802.1p traffic as untagged, because that would
      change the port's native vlan to 0, unbeknownst to the bridge, and
      trigger unexpected code paths in the driver.
      
      Cc: Antoine Tenart <antoine.tenart@bootlin.com>
      Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
      Fixes: 7142529f ("net: mscc: ocelot: add VLAN filtering")
      Signed-off-by: NVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Acked-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Reviewed-by: NHoratiu Vultur <horatiu.vultur@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5aedcc8a
    • J
      net: hisilicon: Fix "Trying to free already-free IRQ" · 3b956e63
      Jiangfeng Xiao 提交于
      [ Upstream commit 63a41746827cb16dc6ad0d4d761ab4e7dda7a0c3 ]
      
      When rmmod hip04_eth.ko, we can get the following warning:
      
      Task track: rmmod(1623)>bash(1591)>login(1581)>init(1)
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 1623 at kernel/irq/manage.c:1557 __free_irq+0xa4/0x2ac()
      Trying to free already-free IRQ 200
      Modules linked in: ping(O) pramdisk(O) cpuinfo(O) rtos_snapshot(O) interrupt_ctrl(O) mtdblock mtd_blkdevrtfs nfs_acl nfs lockd grace sunrpc xt_tcpudp ipt_REJECT iptable_filter ip_tables x_tables nf_reject_ipv
      CPU: 0 PID: 1623 Comm: rmmod Tainted: G           O    4.4.193 #1
      Hardware name: Hisilicon A15
      [<c020b408>] (rtos_unwind_backtrace) from [<c0206624>] (show_stack+0x10/0x14)
      [<c0206624>] (show_stack) from [<c03f2be4>] (dump_stack+0xa0/0xd8)
      [<c03f2be4>] (dump_stack) from [<c021a780>] (warn_slowpath_common+0x84/0xb0)
      [<c021a780>] (warn_slowpath_common) from [<c021a7e8>] (warn_slowpath_fmt+0x3c/0x68)
      [<c021a7e8>] (warn_slowpath_fmt) from [<c026876c>] (__free_irq+0xa4/0x2ac)
      [<c026876c>] (__free_irq) from [<c0268a14>] (free_irq+0x60/0x7c)
      [<c0268a14>] (free_irq) from [<c0469e80>] (release_nodes+0x1c4/0x1ec)
      [<c0469e80>] (release_nodes) from [<c0466924>] (__device_release_driver+0xa8/0x104)
      [<c0466924>] (__device_release_driver) from [<c0466a80>] (driver_detach+0xd0/0xf8)
      [<c0466a80>] (driver_detach) from [<c0465e18>] (bus_remove_driver+0x64/0x8c)
      [<c0465e18>] (bus_remove_driver) from [<c02935b0>] (SyS_delete_module+0x198/0x1e0)
      [<c02935b0>] (SyS_delete_module) from [<c0202ed0>] (__sys_trace_return+0x0/0x10)
      ---[ end trace bb25d6123d849b44 ]---
      
      Currently "rmmod hip04_eth.ko" call free_irq more than once
      as devres_release_all and hip04_remove both call free_irq.
      This results in a 'Trying to free already-free IRQ' warning.
      To solve the problem free_irq has been moved out of hip04_remove.
      Signed-off-by: NJiangfeng Xiao <xiaojiangfeng@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3b956e63
    • W
      fjes: Handle workqueue allocation failure · f09b99c8
      Will Deacon 提交于
      [ Upstream commit 85ac30fa2e24f628e9f4f9344460f4015d33fd7d ]
      
      In the highly unlikely event that we fail to allocate either of the
      "/txrx" or "/control" workqueues, we should bail cleanly rather than
      blindly march on with NULL queue pointer(s) installed in the
      'fjes_adapter' instance.
      
      Cc: "David S. Miller" <davem@davemloft.net>
      Reported-by: NNicolas Waisman <nico@semmle.com>
      Link: https://lore.kernel.org/lkml/CADJ_3a8WFrs5NouXNqS5WYe7rebFP+_A5CheeqAyD_p7DFJJcg@mail.gmail.com/Signed-off-by: NWill Deacon <will@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f09b99c8
    • A
      nvme-multipath: fix possible io hang after ctrl reconnect · 6376736d
      Anton Eidelman 提交于
      [ Upstream commit af8fd0424713a2adb812d10d55e86718152cf656 ]
      
      The following scenario results in an IO hang:
      1) ctrl completes a request with NVME_SC_ANA_TRANSITION.
         NVME_NS_ANA_PENDING bit in ns->flags is set and ana_work is triggered.
      2) ana_work: nvme_read_ana_log() tries to get the ANA log page from the ctrl.
         This fails because ctrl disconnects.
         Therefore nvme_update_ns_ana_state() is not called
         and NVME_NS_ANA_PENDING bit in ns->flags is not cleared.
      3) ctrl reconnects: nvme_mpath_init(ctrl,...) calls
         nvme_read_ana_log(ctrl, groups_only=true).
         However, nvme_update_ana_state() does not update namespaces
         because nr_nsids = 0 (due to groups_only mode).
      4) scan_work calls nvme_validate_ns() finds the ns and re-validates OK.
      
      Result:
      The ctrl is now live but NVME_NS_ANA_PENDING bit in ns->flags is still set.
      Consequently ctrl will never be considered a viable path by __nvme_find_path().
      IO will hang if ctrl is the only or the last path to the namespace.
      
      More generally, while ctrl is reconnecting, its ANA state may change.
      And because nvme_mpath_init() requests ANA log in groups_only mode,
      these changes are not propagated to the existing ctrl namespaces.
      This may result in a mal-function or an IO hang.
      
      Solution:
      nvme_mpath_init() will nvme_read_ana_log() with groups_only set to false.
      This will not harm the new ctrl case (no namespaces present),
      and will make sure the ANA state of namespaces gets updated after reconnect.
      
      Note: Another option would be for nvme_mpath_init() to invoke
      nvme_parse_ana_log(..., nvme_set_ns_ana_state) for each existing namespace.
      Reviewed-by: NSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: NAnton Eidelman <anton@lightbitslabs.com>
      Signed-off-by: NKeith Busch <kbusch@kernel.org>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6376736d
    • N
      scsi: qla2xxx: stop timer in shutdown path · 1372527e
      Nicholas Piggin 提交于
      [ Upstream commit d3566abb1a1e7772116e4d50fb6a58d19c9802e5 ]
      
      In shutdown/reboot paths, the timer is not stopped:
      
        qla2x00_shutdown
        pci_device_shutdown
        device_shutdown
        kernel_restart_prepare
        kernel_restart
        sys_reboot
      
      This causes lockups (on powerpc) when firmware config space access calls
      are interrupted by smp_send_stop later in reboot.
      
      Fixes: e30d1756 ("[SCSI] qla2xxx: Addition of shutdown callback handler.")
      Link: https://lore.kernel.org/r/20191024063804.14538-1-npiggin@gmail.comSigned-off-by: NNicholas Piggin <npiggin@gmail.com>
      Acked-by: NHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1372527e
    • L
      RDMA/hns: Prevent memory leaks of eq->buf_list · f2bab3ed
      Lijun Ou 提交于
      [ Upstream commit b681a0529968d2261aa15d7a1e78801b2c06bb07 ]
      
      eq->buf_list->buf and eq->buf_list should also be freed when eqe_hop_num
      is set to 0, or there will be memory leaks.
      
      Fixes: a5073d60 ("RDMA/hns: Add eq support of hip08")
      Link: https://lore.kernel.org/r/1572072995-11277-3-git-send-email-liweihang@hisilicon.comSigned-off-by: NLijun Ou <oulijun@huawei.com>
      Signed-off-by: NWeihang Li <liweihang@hisilicon.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f2bab3ed
    • P
      RDMA/iw_cxgb4: Avoid freeing skb twice in arp failure case · 55ca0834
      Potnuri Bharat Teja 提交于
      [ Upstream commit d4934f45693651ea15357dd6c7c36be28b6da884 ]
      
      _put_ep_safe() and _put_pass_ep_safe() free the skb before it is freed by
      process_work(). fix double free by freeing the skb only in process_work().
      
      Fixes: 1dad0ebe ("iw_cxgb4: Avoid touch after free error in ARP failure handlers")
      Link: https://lore.kernel.org/r/1572006880-5800-1-git-send-email-bharat@chelsio.comSigned-off-by: NDakshaja Uppalapati <dakshaja@chelsio.com>
      Signed-off-by: NPotnuri Bharat Teja <bharat@chelsio.com>
      Reviewed-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      55ca0834
    • G
      usbip: tools: Fix read_usb_vudc_device() error path handling · e36be795
      GwanYeong Kim 提交于
      [ Upstream commit 28df0642abbf6d66908a2858922a7e4b21cdd8c2 ]
      
      This isn't really accurate right. fread() doesn't always
      return 0 in error. It could return < number of elements
      and set errno.
      Signed-off-by: NGwanYeong Kim <gy741.kim@gmail.com>
      Acked-by: NShuah Khan <skhan@linuxfoundation.org>
      Link: https://lore.kernel.org/r/20191018032223.4644-1-gy741.kim@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e36be795
    • J
      USB: ldusb: use unsigned size format specifiers · cd9561a5
      Johan Hovold 提交于
      [ Upstream commit 88f6bf3846ee90bf33aa1ce848cd3bfb3229f4a4 ]
      
      A recent info-leak bug manifested itself along with warning about a
      negative buffer overflow:
      
      	ldusb 1-1:0.28: Read buffer overflow, -131383859965943 bytes dropped
      
      when it was really a rather large positive one.
      
      A sanity check that prevents this has now been put in place, but let's
      fix up the size format specifiers, which should all be unsigned.
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Link: https://lore.kernel.org/r/20191022143203.5260-3-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cd9561a5
    • A
      USB: Skip endpoints with 0 maxpacket length · c753113a
      Alan Stern 提交于
      [ Upstream commit d482c7bb0541d19dea8bff437a9f3c5563b5b2d2 ]
      
      Endpoints with a maxpacket length of 0 are probably useless.  They
      can't transfer any data, and it's not at all unlikely that an HCD will
      crash or hang when trying to handle an URB for such an endpoint.
      
      Currently the USB core does not check for endpoints having a maxpacket
      value of 0.  This patch adds a check, printing a warning and skipping
      over any endpoints it catches.
      
      Now, the USB spec does not rule out endpoints having maxpacket = 0.
      But since they wouldn't have any practical use, there doesn't seem to
      be any good reason for us to accept them.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      
      Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1910281050420.1485-100000@iolanthe.rowland.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c753113a
    • K
      perf/x86/uncore: Fix event group support · ef38f4d1
      Kan Liang 提交于
      [ Upstream commit 75be6f703a141b048590d659a3954c4fedd30bba ]
      
      The events in the same group don't start or stop simultaneously.
      Here is the ftrace when enabling event group for uncore_iio_0:
      
        # perf stat -e "{uncore_iio_0/event=0x1/,uncore_iio_0/event=0xe/}"
      
                  <idle>-0     [000] d.h.  8959.064832: read_msr: a41, value
        b2b0b030		//Read counter reg of IIO unit0 counter0
                  <idle>-0     [000] d.h.  8959.064835: write_msr: a48, value
        400001			//Write Ctrl reg of IIO unit0 counter0 to enable
        counter0. <------ Although counter0 is enabled, Unit Ctrl is still
        freezed. Nothing will count. We are still good here.
                  <idle>-0     [000] d.h.  8959.064836: read_msr: a40, value
        30100                   //Read Unit Ctrl reg of IIO unit0
                  <idle>-0     [000] d.h.  8959.064838: write_msr: a40, value
        30000			//Write Unit Ctrl reg of IIO unit0 to enable all
        counters in the unit by clear Freeze bit  <------Unit0 is un-freezed.
        Counter0 has been enabled. Now it starts counting. But counter1 has not
        been enabled yet. The issue starts here.
                  <idle>-0     [000] d.h.  8959.064846: read_msr: a42, value 0
      			//Read counter reg of IIO unit0 counter1
                  <idle>-0     [000] d.h.  8959.064847: write_msr: a49, value
        40000e			//Write Ctrl reg of IIO unit0 counter1 to enable
        counter1.   <------ Now, counter1 just starts to count. Counter0 has
        been running for a while.
      
      Current code un-freezes the Unit Ctrl right after the first counter is
      enabled. The subsequent group events always loses some counter values.
      
      Implement pmu_enable and pmu_disable support for uncore, which can help
      to batch hardware accesses.
      
      No one uses uncore_enable_box and uncore_disable_box. Remove them.
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: linux-drivers-review@eclists.intel.com
      Cc: linux-perf@eclists.intel.com
      Fixes: 087bfbb0 ("perf/x86: Add generic Intel uncore PMU support")
      Link: https://lkml.kernel.org/r/1572014593-31591-1-git-send-email-kan.liang@linux.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ef38f4d1
    • K
      perf/x86/amd/ibs: Handle erratum #420 only on the affected CPU family (10h) · f1475165
      Kim Phillips 提交于
      [ Upstream commit e431e79b60603079d269e0c2a5177943b95fa4b6 ]
      
      This saves us writing the IBS control MSR twice when disabling the
      event.
      
      I searched revision guides for all families since 10h, and did not
      find occurrence of erratum #420, nor anything remotely similar:
      so we isolate the secondary MSR write to family 10h only.
      
      Also unconditionally update the count mask for IBS Op implementations
      that have read & writeable current count (CurCnt) fields in addition
      to the MaxCnt field.  These bits were reserved on prior
      implementations, and therefore shouldn't have negative impact.
      Signed-off-by: NKim Phillips <kim.phillips@amd.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Fixes: c9574fe0 ("perf/x86-ibs: Implement workaround for IBS erratum #420")
      Link: https://lkml.kernel.org/r/20191023150955.30292-2-kim.phillips@amd.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f1475165
    • K
      perf/x86/amd/ibs: Fix reading of the IBS OpData register and thus precise RIP validity · 5b99e97b
      Kim Phillips 提交于
      [ Upstream commit 317b96bb14303c7998dbcd5bc606bd8038fdd4b4 ]
      
      The loop that reads all the IBS MSRs into *buf stopped one MSR short of
      reading the IbsOpData register, which contains the RipInvalid status bit.
      
      Fix the offset_max assignment so the MSR gets read, so the RIP invalid
      evaluation is based on what the IBS h/w output, instead of what was
      left in memory.
      Signed-off-by: NKim Phillips <kim.phillips@amd.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Fixes: d47e8238 ("perf/x86-ibs: Take instruction pointer from ibs sample")
      Link: https://lkml.kernel.org/r/20191023150955.30292-1-kim.phillips@amd.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5b99e97b
    • Y
      usb: dwc3: remove the call trace of USBx_GFLADJ · 45944c4a
      Yinbo Zhu 提交于
      [ Upstream commit a7d9874c6f3fbc8d25cd9ceba35b6822612c4ebf ]
      
      layerscape board sometimes reported some usb call trace, that is due to
      kernel sent LPM tokerns automatically when it has no pending transfers
      and think that the link is idle enough to enter L1, which procedure will
      ask usb register has a recovery,then kernel will compare USBx_GFLADJ and
      set GFLADJ_30MHZ, GFLADJ_30MHZ_REG until GFLADJ_30MHZ is equal 0x20, if
      the conditions were met then issue occur, but whatever the conditions
      whether were met that usb is all need keep GFLADJ_30MHZ of value is 0x20
      (xhci spec ask use GFLADJ_30MHZ to adjust any offset from clock source
      that generates the clock that drives the SOF counter, 0x20 is default
      value of it)That is normal logic, so need remove the call trace.
      Signed-off-by: NYinbo Zhu <yinbo.zhu@nxp.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      45944c4a
    • P
      usb: gadget: configfs: fix concurrent issue between composite APIs · dff38149
      Peter Chen 提交于
      [ Upstream commit 1a1c851bbd706ea9f3a9756c2d3db28523506d3b ]
      
      We meet several NULL pointer issues if configfs_composite_unbind
      and composite_setup (or composite_disconnect) are running together.
      These issues occur when do the function switch stress test, the
      configfs_compsoite_unbind is called from user mode by
      echo "" to /sys/../UDC entry, and meanwhile, the setup interrupt
      or disconnect interrupt occurs by hardware. The composite_setup
      will get the cdev from get_gadget_data, but configfs_composite_unbind
      will set gadget data as NULL, so the NULL pointer issue occurs.
      This concurrent is hard to reproduce by native kernel, but can be
      reproduced by android kernel.
      
      In this commit, we introduce one spinlock belongs to structure
      gadget_info since we can't use the same spinlock in usb_composite_dev
      due to exclusive running together between composite_setup and
      configfs_composite_unbind. And one bit flag 'unbind' to indicate the
      code is at unbind routine, this bit is needed due to we release the
      lock at during configfs_composite_unbind sometimes, and composite_setup
      may be run at that time.
      
      Several oops:
      
      oops 1:
      android_work: sent uevent USB_STATE=CONNECTED
      configfs-gadget gadget: super-speed config #1: b
      android_work: sent uevent USB_STATE=CONFIGURED
      init: Received control message 'start' for 'adbd' from pid: 3515 (system_server)
      Unable to handle kernel NULL pointer dereference at virtual address 0000002a
      init: Received control message 'stop' for 'adbd' from pid: 3375 (/vendor/bin/hw/android.hardware.usb@1.1-servic)
      Mem abort info:
        Exception class = DABT (current EL), IL = 32 bits
        SET = 0, FnV = 0
        EA = 0, S1PTW = 0
      Data abort info:
        ISV = 0, ISS = 0x00000004
        CM = 0, WnR = 0
      user pgtable: 4k pages, 48-bit VAs, pgd = ffff8008f1b7f000
      [000000000000002a] *pgd=0000000000000000
      Internal error: Oops: 96000004 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 4 PID: 2457 Comm: irq/125-5b11000 Not tainted 4.14.98-07846-g0b40a9b-dirty #16
      Hardware name: Freescale i.MX8QM MEK (DT)
      task: ffff8008f2a98000 task.stack: ffff00000b7b8000
      PC is at composite_setup+0x44/0x1508
      LR is at android_setup+0xb8/0x13c
      pc : [<ffff0000089ffb3c>] lr : [<ffff000008a032fc>] pstate: 800001c5
      sp : ffff00000b7bbb80
      x29: ffff00000b7bbb80 x28: ffff8008f2a3c010
      x27: 0000000000000001 x26: 0000000000000000                                                          [1232/1897]
      audit: audit_lost=25791 audit_rate_limit=5 audit_backlog_limit=64
      x25: 00000000ffffffa1 x24: ffff8008f2a3c010
      audit: rate limit exceeded
      x23: 0000000000000409 x22: ffff000009c8e000
      x21: ffff8008f7a8b428 x20: ffff00000afae000
      x19: ffff0000089ff000 x18: 0000000000000000
      x17: 0000000000000000 x16: ffff0000082b7c9c
      x15: 0000000000000000 x14: f1866f5b952aca46
      x13: e35502e30d44349c x12: 0000000000000008
      x11: 0000000000000008 x10: 0000000000000a30
      x9 : ffff00000b7bbd00 x8 : ffff8008f2a98a90
      x7 : ffff8008f27a9c90 x6 : 0000000000000001
      x5 : 0000000000000000 x4 : 0000000000000001
      x3 : 0000000000000000 x2 : 0000000000000006
      x1 : ffff0000089ff8d0 x0 : 732a010310b9ed00
      
      X7: 0xffff8008f27a9c10:
      9c10  00000002 00000000 00000001 00000000 13110000 ffff0000 00000002 00208040
      9c30  00000000 00000000 00000000 00000000 00000000 00000005 00000029 00000000
      9c50  00051778 00000001 f27a8e00 ffff8008 00000005 00000000 00000078 00000078
      9c70  00000078 00000000 09031d48 ffff0000 00100000 00000000 00400000 00000000
      9c90  00000001 00000000 00000000 00000000 00000000 00000000 ffefb1a0 ffff8008
      9cb0  f27a9ca8 ffff8008 00000000 00000000 b9d88037 00000173 1618a3eb 00000001
      9cd0  870a792a 0000002e 16188fe6 00000001 0000242b 00000000 00000000 00000000
      using random self ethernet address
      9cf0  019a4646 00000000 000547f3 00000000 ecfd6c33 00000002 00000000
      using random host ethernet address
       00000000
      
      X8: 0xffff8008f2a98a10:
      8a10  00000000 00000000 f7788d00 ffff8008 00000001 00000000 00000000 00000000
      8a30  eb218000 ffff8008 f2a98000 ffff8008 f2a98000 ffff8008 09885000 ffff0000
      8a50  f34df480 ffff8008 00000000 00000000 f2a98648 ffff8008 09c8e000 ffff0000
      8a70  fff2c800 ffff8008 09031d48 ffff0000 0b7bbd00 ffff0000 0b7bbd00 ffff0000
      8a90  080861bc ffff0000 00000000 00000000 00000000 00000000 00000000 00000000
      8ab0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      8ad0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      8af0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      
      X21: 0xffff8008f7a8b3a8:
      b3a8  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      b3c8  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      b3e8  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      b408  00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000000
      b428  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      b448  0053004d 00540046 00300031 00010030 eb07b520 ffff8008 20011201 00000003
      b468  e418d109 0104404e 00010302 00000000 eb07b558 ffff8008 eb07b558 ffff8008
      b488  f7a8b488 ffff8008 f7a8b488 ffff8008 f7a8b300 ffff8008 00000000 00000000
      
      X24: 0xffff8008f2a3bf90:
      bf90  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      bfb0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      bfd0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      bff0  00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008
      c010  00000000 00000000 f2a3c018 ffff8008 f2a3c018 ffff8008 08a067dc ffff0000
      c030  f2a5a000 ffff8008 091c3650 ffff0000 f716fd18 ffff8008 f716fe30 ffff8008
      c050  f2ce4a30 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000
      c070  f76c8010 ffff8008 f2ce4b00 ffff8008 095cac68 ffff0000 f2a5a028 ffff8008
      
      X28: 0xffff8008f2a3bf90:
      bf90  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      bfb0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      bfd0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      bff0  00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008
      c010  00000000 00000000 f2a3c018 ffff8008 f2a3c018 ffff8008 08a067dc ffff0000
      c030  f2a5a000 ffff8008 091c3650 ffff0000 f716fd18 ffff8008 f716fe30 ffff8008
      c050  f2ce4a30 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000
      c070  f76c8010 ffff8008 f2ce4b00 ffff8008 095cac68 ffff0000 f2a5a028 ffff8008
      
      Process irq/125-5b11000 (pid: 2457, stack limit = 0xffff00000b7b8000)
      Call trace:
      Exception stack(0xffff00000b7bba40 to 0xffff00000b7bbb80)
      ba40: 732a010310b9ed00 ffff0000089ff8d0 0000000000000006 0000000000000000
      ba60: 0000000000000001 0000000000000000 0000000000000001 ffff8008f27a9c90
      ba80: ffff8008f2a98a90 ffff00000b7bbd00 0000000000000a30 0000000000000008
      baa0: 0000000000000008 e35502e30d44349c f1866f5b952aca46 0000000000000000
      bac0: ffff0000082b7c9c 0000000000000000 0000000000000000 ffff0000089ff000
      bae0: ffff00000afae000 ffff8008f7a8b428 ffff000009c8e000 0000000000000409
      bb00: ffff8008f2a3c010 00000000ffffffa1 0000000000000000 0000000000000001
      bb20: ffff8008f2a3c010 ffff00000b7bbb80 ffff000008a032fc ffff00000b7bbb80
      bb40: ffff0000089ffb3c 00000000800001c5 ffff00000b7bbb80 732a010310b9ed00
      bb60: ffffffffffffffff ffff0000080f777c ffff00000b7bbb80 ffff0000089ffb3c
      [<ffff0000089ffb3c>] composite_setup+0x44/0x1508
      [<ffff000008a032fc>] android_setup+0xb8/0x13c
      [<ffff0000089bd9a8>] cdns3_ep0_delegate_req+0x44/0x70
      [<ffff0000089bdff4>] cdns3_check_ep0_interrupt_proceed+0x33c/0x654
      [<ffff0000089bca44>] cdns3_device_thread_irq_handler+0x4b0/0x4bc
      [<ffff0000089b77b4>] cdns3_thread_irq+0x48/0x68
      [<ffff000008145bf0>] irq_thread_fn+0x28/0x88
      [<ffff000008145e38>] irq_thread+0x13c/0x228
      [<ffff0000080fed70>] kthread+0x104/0x130
      [<ffff000008085064>] ret_from_fork+0x10/0x18
      
      oops2:
      composite_disconnect: Calling disconnect on a Gadget that is                      not connected
      android_work: did not send uevent (0 0           (null))
      init: Received control message 'stop' for 'adbd' from pid: 3359 (/vendor/bin/hw/android.hardware.usb@1.1-service.imx)
      init: Sending signal 9 to service 'adbd' (pid 22343) process group...
      ------------[ cut here ]------------
      audit: audit_lost=180038 audit_rate_limit=5 audit_backlog_limit=64
      audit: rate limit exceeded
      WARNING: CPU: 0 PID: 3468 at kernel_imx/drivers/usb/gadget/composite.c:2009 composite_disconnect+0x80/0x88
      Modules linked in:
      CPU: 0 PID: 3468 Comm: HWC-UEvent-Thre Not tainted 4.14.98-07846-g0b40a9b-dirty #16
      Hardware name: Freescale i.MX8QM MEK (DT)
      task: ffff8008f2349c00 task.stack: ffff00000b0a8000
      PC is at composite_disconnect+0x80/0x88
      LR is at composite_disconnect+0x80/0x88
      pc : [<ffff0000089ff9b0>] lr : [<ffff0000089ff9b0>] pstate: 600001c5
      sp : ffff000008003dd0
      x29: ffff000008003dd0 x28: ffff8008f2349c00
      x27: ffff000009885018 x26: ffff000008004000
      Timeout for IPC response!
      x25: ffff000009885018 x24: ffff000009c8e280
      x23: ffff8008f2d98010 x22: 00000000000001c0
      x21: ffff8008f2d98394 x20: ffff8008f2d98010
      x19: 0000000000000000 x18: 0000e3956f4f075a
      fxos8700 4-001e: i2c block read acc failed
      x17: 0000e395735727e8 x16: ffff00000829f4d4
      x15: ffffffffffffffff x14: 7463656e6e6f6320
      x13: 746f6e2009090920 x12: 7369207461687420
      x11: 7465676461472061 x10: 206e6f207463656e
      x9 : 6e6f637369642067 x8 : ffff000009c8e280
      x7 : ffff0000086ca6cc x6 : ffff000009f15e78
      x5 : 0000000000000000 x4 : 0000000000000000
      x3 : ffffffffffffffff x2 : c3f28b86000c3900
      x1 : c3f28b86000c3900 x0 : 000000000000004e
      
      X20: 0xffff8008f2d97f90:
      7f90  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      7fb0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      libprocessgroup: Failed to kill process cgroup uid 0 pid 22343 in 215ms, 1 processes remain
      7fd0
      Timeout for IPC response!
       00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      using random self ethernet address
      7ff0  00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008
      8010  00000100 00000000 f2d98018 ffff8008 f2d98018 ffff8008 08a067dc
      using random host ethernet address
       ffff0000
      8030  f206d800 ffff8008 091c3650 ffff0000 f7957b18 ffff8008 f7957730 ffff8008
      8050  f716a630 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000
      8070  f76c8010 ffff8008 f716a800 ffff8008 095cac68 ffff0000 f206d828 ffff8008
      
      X21: 0xffff8008f2d98314:
      8314  ffff8008 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      8334  00000000 00000000 00000000 00000000 00000000 08a04cf4 ffff0000 00000000
      8354  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      8374  00000000 00000000 00000000 00001001 00000000 00000000 00000000 00000000
      8394  e4bbe4bb 0f230000 ffff0000 0afae000 ffff0000 ae001000 00000000 f206d400
      Timeout for IPC response!
      83b4  ffff8008 00000000 00000000 f7957b18 ffff8008 f7957718 ffff8008 f7957018
      83d4  ffff8008 f7957118 ffff8008 f7957618 ffff8008 f7957818 ffff8008 f7957918
      83f4  ffff8008 f7957d18 ffff8008 00000000 00000000 00000000 00000000 00000000
      
      X23: 0xffff8008f2d97f90:
      7f90  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      7fb0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      7fd0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      7ff0  00000000 00000000 00000000 00000000 f76c8010 ffff8008 f76c8010 ffff8008
      8010  00000100 00000000 f2d98018 ffff8008 f2d98018 ffff8008 08a067dc ffff0000
      8030  f206d800 ffff8008 091c3650 ffff0000 f7957b18 ffff8008 f7957730 ffff8008
      8050  f716a630 ffff8008 00000000 00000005 00000000 00000000 095d1568 ffff0000
      8070  f76c8010 ffff8008 f716a800 ffff8008 095cac68 ffff0000 f206d828 ffff8008
      
      X28: 0xffff8008f2349b80:
      9b80  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      9ba0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      9bc0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      9be0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      9c00  00000022 00000000 ffffffff ffffffff 00010001 00000000 00000000 00000000
      9c20  0b0a8000 ffff0000 00000002 00404040 00000000 00000000 00000000 00000000
      9c40  00000001 00000000 00000001 00000000 001ebd44 00000001 f390b800 ffff8008
      9c60  00000000 00000001 00000070 00000070 00000070 00000000 09031d48 ffff0000
      
      Call trace:
      Exception stack(0xffff000008003c90 to 0xffff000008003dd0)
      3c80:                                   000000000000004e c3f28b86000c3900
      3ca0: c3f28b86000c3900 ffffffffffffffff 0000000000000000 0000000000000000
      3cc0: ffff000009f15e78 ffff0000086ca6cc ffff000009c8e280 6e6f637369642067
      3ce0: 206e6f207463656e 7465676461472061 7369207461687420 746f6e2009090920
      3d00: 7463656e6e6f6320 ffffffffffffffff ffff00000829f4d4 0000e395735727e8
      3d20: 0000e3956f4f075a 0000000000000000 ffff8008f2d98010 ffff8008f2d98394
      3d40: 00000000000001c0 ffff8008f2d98010 ffff000009c8e280 ffff000009885018
      3d60: ffff000008004000 ffff000009885018 ffff8008f2349c00 ffff000008003dd0
      3d80: ffff0000089ff9b0 ffff000008003dd0 ffff0000089ff9b0 00000000600001c5
      3da0: ffff8008f33f2cd8 0000000000000000 0000ffffffffffff 0000000000000000
      init: Received control message 'start' for 'adbd' from pid: 3359 (/vendor/bin/hw/android.hardware.usb@1.1-service.imx)
      3dc0: ffff000008003dd0 ffff0000089ff9b0
      [<ffff0000089ff9b0>] composite_disconnect+0x80/0x88
      [<ffff000008a044d4>] android_disconnect+0x3c/0x68
      [<ffff0000089ba9f8>] cdns3_device_irq_handler+0xfc/0x2c8
      [<ffff0000089b84c0>] cdns3_irq+0x44/0x94
      [<ffff00000814494c>] __handle_irq_event_percpu+0x60/0x24c
      [<ffff000008144c0c>] handle_irq_event+0x58/0xc0
      [<ffff00000814873c>] handle_fasteoi_irq+0x98/0x180
      [<ffff000008143a10>] generic_handle_irq+0x24/0x38
      [<ffff000008144170>] __handle_domain_irq+0x60/0xac
      [<ffff0000080819c4>] gic_handle_irq+0xd4/0x17c
      Signed-off-by: NPeter Chen <peter.chen@nxp.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      dff38149