1. 15 6月, 2019 40 次提交
    • A
      ARM: dts: imx7d: Specify IMX7D_CLK_IPG as "ipg" clock to SDMA · 36a7fda0
      Andrey Smirnov 提交于
      [ Upstream commit 412b032a1dc72fc9d1c258800355efa6671b6315 ]
      
      Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
      clock to determine if it needs to configure the IP block as operating
      at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
      clocks as IMX7D_CLK_SDMA results in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality. Fix the code
      to specify IMX7D_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
      incorrect clock ratio.
      Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Cc: Angus Ainslie (Purism) <angus@akkea.ca>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      36a7fda0
    • A
      ARM: dts: imx6sll: Specify IMX6SLL_CLK_IPG as "ipg" clock to SDMA · c84911bb
      Andrey Smirnov 提交于
      [ Upstream commit c5ed5daa65d5f665e666b76c3dbfa503066defde ]
      
      Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
      clock to determine if it needs to configure the IP block as operating
      at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
      clocks as IMX6SLL_CLK_SDMA result in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality. Fix the code
      to specify IMX6SLL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
      incorrect clock ratio.
      Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Cc: Angus Ainslie (Purism) <angus@akkea.ca>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c84911bb
    • A
      ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ahb" clock to SDMA · a2e661f9
      Andrey Smirnov 提交于
      [ Upstream commit cc839d0f8c284fcb7591780b568f13415bbb737c ]
      
      Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
      clock to determine if it needs to configure the IP block as operating
      at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
      clocks as IMX6SL_CLK_SDMA results in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality. Fix the code
      to specify IMX6SL_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
      incorrect clock ratio.
      Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Cc: Angus Ainslie (Purism) <angus@akkea.ca>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a2e661f9
    • A
      ARM: dts: imx53: Specify IMX5_CLK_IPG as "ahb" clock to SDMA · 461f4183
      Andrey Smirnov 提交于
      [ Upstream commit 28c168018e0902c67eb9c60d0fc4c8aa166c4efe ]
      
      Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
      clock to determine if it needs to configure the IP block as operating
      at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
      clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality. Fix the code
      to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
      incorrect clock ratio.
      Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Cc: Angus Ainslie (Purism) <angus@akkea.ca>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      461f4183
    • A
      ARM: dts: imx50: Specify IMX5_CLK_IPG as "ahb" clock to SDMA · 998860d0
      Andrey Smirnov 提交于
      [ Upstream commit b7b4fda2636296471e29b78c2aa9535d7bedb7a0 ]
      
      Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
      clock to determine if it needs to configure the IP block as operating
      at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
      clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality. Fix the code
      to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
      incorrect clock ratio.
      Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Cc: Angus Ainslie (Purism) <angus@akkea.ca>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      998860d0
    • A
      ARM: dts: imx51: Specify IMX5_CLK_IPG as "ahb" clock to SDMA · 70465bbb
      Andrey Smirnov 提交于
      [ Upstream commit 918bbde8085ae147a43dcb491953e0dd8f3e9d6a ]
      
      Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
      clock to determine if it needs to configure the IP block as operating
      at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
      clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality. Fix the code
      to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
      incorrect clock ratio.
      Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Cc: Angus Ainslie (Purism) <angus@akkea.ca>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      70465bbb
    • D
      soc: rockchip: Set the proper PWM for rk3288 · 57f89084
      Douglas Anderson 提交于
      [ Upstream commit bbdc00a7de24cc90315b1775fb74841373fe12f7 ]
      
      The rk3288 SoC has two PWM implementations available, the "old"
      implementation and the "new" one.  You can switch between the two of
      them by flipping a bit in the grf.
      
      The "old" implementation is the default at chip power up but isn't the
      one that's officially supposed to be used.  ...and, in fact, the
      driver that gets selected in Linux using the rk3288 device tree only
      supports the "new" implementation.
      
      Long ago I tried to get a switch to the right IP block landed in the
      PWM driver (search for "rk3288: Switch to use the proper PWM IP") but
      that got rejected.  In the mean time the grf has grown a full-fledged
      driver that already sets other random bits like this.  That means we
      can now get the fix landed.
      
      For those wondering how things could have possibly worked for the last
      4.5 years, folks have mostly been relying on the bootloader to set
      this bit.  ...but occasionally folks have pointed back to my old patch
      series [1] in downstream kernels.
      
      [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1391597.htmlSigned-off-by: NDouglas Anderson <dianders@chromium.org>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      57f89084
    • D
      clk: rockchip: Turn on "aclk_dmac1" for suspend on rk3288 · b1659486
      Douglas Anderson 提交于
      [ Upstream commit 57a20248ef3e429dc822f0774bc4e00136c46c83 ]
      
      Experimentally it can be seen that going into deep sleep (specifically
      setting PMU_CLR_DMA and PMU_CLR_BUS in RK3288_PMU_PWRMODE_CON1)
      appears to fail unless "aclk_dmac1" is on.  The failure is that the
      system never signals that it made it into suspend on the GLOBAL_PWROFF
      pin and it just hangs.
      
      NOTE that it's confirmed that it's the actual suspend that fails, not
      one of the earlier calls to read/write registers.  Specifically if you
      comment out the "PMU_GLOBAL_INT_DISABLE" setting in
      rk3288_slp_mode_set() and then comment out the "cpu_do_idle()" call in
      rockchip_lpmode_enter() then you can exercise the whole suspend path
      without any crashing.
      
      This is currently not a problem with suspend upstream because there is
      no current way to exercise the deep suspend code.  However, anyone
      trying to make it work will run into this issue.
      
      This was not a problem on shipping rk3288-based Chromebooks because
      those devices all ran on an old kernel based on 3.14.  On that kernel
      "aclk_dmac1" appears to be left on all the time.
      
      There are several ways to skin this problem.
      
      A) We could add "aclk_dmac1" to the list of critical clocks and that
      apperas to work, but presumably that wastes power.
      
      B) We could keep a list of "struct clk" objects to enable at suspend
      time in clk-rk3288.c and use the standard clock APIs.
      
      C) We could make the rk3288-pmu driver keep a list of clocks to enable
      at suspend time.  Presumably this would require a dts and bindings
      change.
      
      D) We could just whack the clock on in the existing syscore suspend
      function where we whack a bunch of other clocks.  This is particularly
      easy because we know for sure that the clock's only parent
      ("aclk_cpu") is a critical clock so we don't need to do anything more
      than ungate it.
      
      In this case I have chosen D) because it seemed like the least work,
      but any of the other options would presumably also work fine.
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Reviewed-by: NElaine Zhang <zhangqing@rock-chips.com>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b1659486
    • N
      soc: mediatek: pwrap: Zero initialize rdata in pwrap_init_cipher · 8e9dd864
      Nathan Chancellor 提交于
      [ Upstream commit 89e28da82836530f1ac7a3a32fecc31f22d79b3e ]
      
      When building with -Wsometimes-uninitialized, Clang warns:
      
      drivers/soc/mediatek/mtk-pmic-wrap.c:1358:6: error: variable 'rdata' is
      used uninitialized whenever '||' condition is true
      [-Werror,-Wsometimes-uninitialized]
      
      If pwrap_write returns non-zero, pwrap_read will not be called to
      initialize rdata, meaning that we will use some random uninitialized
      stack value in our print statement. Zero initialize rdata in case this
      happens.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/401Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
      Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8e9dd864
    • K
      PCI: keystone: Prevent ARM32 specific code to be compiled for ARM64 · f7c0e670
      Kishon Vijay Abraham I 提交于
      [ Upstream commit f316a2b53cd7f37963ae20ec7072eb27a349a4ce ]
      
      hook_fault_code() is an ARM32 specific API for hooking into data abort.
      
      AM65X platforms (that integrate ARM v8 cores and select CONFIG_ARM64 as
      arch) rely on pci-keystone.c but on them the enumeration of a
      non-present BDF does not trigger a bus error, so the fixup exception
      provided by calling hook_fault_code() is not needed and can be guarded
      with CONFIG_ARM.
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      [lorenzo.pieralisi@arm.com: commit log]
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f7c0e670
    • E
      platform/chrome: cros_ec_proto: check for NULL transfer function · a357310a
      Enrico Granata 提交于
      [ Upstream commit 94d4e7af14a1170e34cf082d92e4c02de9e9fb88 ]
      
      As new transfer mechanisms are added to the EC codebase, they may
      not support v2 of the EC protocol.
      
      If the v3 initial handshake transfer fails, the kernel will try
      and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer
      will be NULL, and the code will end up causing a kernel panic.
      
      Add a check for NULL before calling the transfer function, along
      with a helpful comment explaining how one might end up in this
      situation.
      Signed-off-by: NEnrico Granata <egranata@chromium.org>
      Reviewed-by: NJett Rink <jettrink@chromium.org>
      Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a357310a
    • A
      i40e: Queues are reserved despite "Invalid argument" error · b78a9b28
      Adam Ludkiewicz 提交于
      [ Upstream commit 3e957b377bf4262aec2dd424f28ece94e36814d4 ]
      
      Added a new local variable in the i40e_setup_tc function named
      old_queue_pairs so num_queue_pairs can be restored to the correct
      value in case configuring queue channels fails. Additionally, moved
      the exit label in the i40e_setup_tc function so the if (need_reset)
      block can be executed.
      Also, fixed data packing in the i40e_setup_tc function.
      Signed-off-by: NAdam Ludkiewicz <adam.ludkiewicz@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b78a9b28
    • W
      x86/PCI: Fix PCI IRQ routing table memory leak · aeb743db
      Wenwen Wang 提交于
      [ Upstream commit ea094d53580f40c2124cef3d072b73b2425e7bfd ]
      
      In pcibios_irq_init(), the PCI IRQ routing table 'pirq_table' is first
      found through pirq_find_routing_table().  If the table is not found and
      CONFIG_PCI_BIOS is defined, the table is then allocated in
      pcibios_get_irq_routing_table() using kmalloc().  Later, if the I/O APIC is
      used, this table is actually not used.  In that case, the allocated table
      is not freed, which is a memory leak.
      
      Free the allocated table if it is not used.
      Signed-off-by: NWenwen Wang <wang6495@umn.edu>
      [bhelgaas: added Ingo's reviewed-by, since the only change since v1 was to
      use the irq_routing_table local variable name he suggested]
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      aeb743db
    • M
      net: thunderbolt: Unregister ThunderboltIP protocol handler when suspending · 47e6a354
      Mika Westerberg 提交于
      [ Upstream commit 9872760eb7b1d4f6066ad8b560714a5d0a728fdb ]
      
      The XDomain protocol messages may start as soon as Thunderbolt control
      channel is started. This means that if the other host starts sending
      ThunderboltIP packets early enough they will be passed to the network
      driver which then gets confused because its resume hook is not called
      yet.
      
      Fix this by unregistering the ThunderboltIP protocol handler when
      suspending and registering it back on resume.
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      47e6a354
    • W
      switchtec: Fix unintended mask of MRPC event · 31aa2a7a
      Wesley Sheng 提交于
      [ Upstream commit 083c1b5e50b701899dc32445efa8b153685260d5 ]
      
      When running application tool switchtec-user's `firmware update` and `event
      wait` commands concurrently, sometimes the firmware update speed reduced
      significantly.
      
      It is because when the MRPC event happened after MRPC event occurrence
      check but before the event mask loop reaches its header register in event
      ISR, the MRPC event would be masked unintentionally.  Since there's no
      chance to enable it again except for a module reload, all the following
      MRPC execution completion checks time out.
      
      Fix this bug by skipping the mask operation for MRPC event in event ISR,
      same as what we already do for LINK event.
      
      Fixes: 52eabba5 ("switchtec: Add IOCTLs to the Switchtec driver")
      Signed-off-by: NWesley Sheng <wesley.sheng@microchip.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NLogan Gunthorpe <logang@deltatee.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      31aa2a7a
    • W
      iommu/arm-smmu-v3: Don't disable SMMU in kdump kernel · 4b19a45e
      Will Deacon 提交于
      [ Upstream commit 3f54c447df34ff9efac7809a4a80fd3208efc619 ]
      
      Disabling the SMMU when probing from within a kdump kernel so that all
      incoming transactions are terminated can prevent the core of the crashed
      kernel from being transferred off the machine if all I/O devices are
      behind the SMMU.
      
      Instead, continue to probe the SMMU after it is disabled so that we can
      reinitialise it entirely and re-attach the DMA masters as they are reset.
      Since the kdump kernel may not have drivers for all of the active DMA
      masters, we suppress fault reporting to avoid spamming the console and
      swamping the IRQ threads.
      Reported-by: N"Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
      Tested-by: N"Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
      Tested-by: NBhupesh Sharma <bhsharma@redhat.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4b19a45e
    • F
      vfio: Fix WARNING "do not call blocking ops when !TASK_RUNNING" · f7883f9b
      Farhan Ali 提交于
      [ Upstream commit 41be3e2618174fdf3361e49e64f2bf530f40c6b0 ]
      
      vfio_dev_present() which is the condition to
      wait_event_interruptible_timeout(), will call vfio_group_get_device
      and try to acquire the mutex group->device_lock.
      
      wait_event_interruptible_timeout() will set the state of the current
      task to TASK_INTERRUPTIBLE, before doing the condition check. This
      means that we will try to acquire the mutex while already in a
      sleeping state. The scheduler warns us by giving the following
      warning:
      
      [ 4050.264464] ------------[ cut here ]------------
      [ 4050.264508] do not call blocking ops when !TASK_RUNNING; state=1 set at [<00000000b33c00e2>] prepare_to_wait_event+0x14a/0x188
      [ 4050.264529] WARNING: CPU: 12 PID: 35924 at kernel/sched/core.c:6112 __might_sleep+0x76/0x90
      ....
      
       4050.264756] Call Trace:
      [ 4050.264765] ([<000000000017bbaa>] __might_sleep+0x72/0x90)
      [ 4050.264774]  [<0000000000b97edc>] __mutex_lock+0x44/0x8c0
      [ 4050.264782]  [<0000000000b9878a>] mutex_lock_nested+0x32/0x40
      [ 4050.264793]  [<000003ff800d7abe>] vfio_group_get_device+0x36/0xa8 [vfio]
      [ 4050.264803]  [<000003ff800d87c0>] vfio_del_group_dev+0x238/0x378 [vfio]
      [ 4050.264813]  [<000003ff8015f67c>] mdev_remove+0x3c/0x68 [mdev]
      [ 4050.264825]  [<00000000008e01b0>] device_release_driver_internal+0x168/0x268
      [ 4050.264834]  [<00000000008de692>] bus_remove_device+0x162/0x190
      [ 4050.264843]  [<00000000008daf42>] device_del+0x1e2/0x368
      [ 4050.264851]  [<00000000008db12c>] device_unregister+0x64/0x88
      [ 4050.264862]  [<000003ff8015ed84>] mdev_device_remove+0xec/0x130 [mdev]
      [ 4050.264872]  [<000003ff8015f074>] remove_store+0x6c/0xa8 [mdev]
      [ 4050.264881]  [<000000000046f494>] kernfs_fop_write+0x14c/0x1f8
      [ 4050.264890]  [<00000000003c1530>] __vfs_write+0x38/0x1a8
      [ 4050.264899]  [<00000000003c187c>] vfs_write+0xb4/0x198
      [ 4050.264908]  [<00000000003c1af2>] ksys_write+0x5a/0xb0
      [ 4050.264916]  [<0000000000b9e270>] system_call+0xdc/0x2d8
      [ 4050.264925] 4 locks held by sh/35924:
      [ 4050.264933]  #0: 000000001ef90325 (sb_writers#4){.+.+}, at: vfs_write+0x9e/0x198
      [ 4050.264948]  #1: 000000005c1ab0b3 (&of->mutex){+.+.}, at: kernfs_fop_write+0x1cc/0x1f8
      [ 4050.264963]  #2: 0000000034831ab8 (kn->count#297){++++}, at: kernfs_remove_self+0x12e/0x150
      [ 4050.264979]  #3: 00000000e152484f (&dev->mutex){....}, at: device_release_driver_internal+0x5c/0x268
      [ 4050.264993] Last Breaking-Event-Address:
      [ 4050.265002]  [<000000000017bbaa>] __might_sleep+0x72/0x90
      [ 4050.265010] irq event stamp: 7039
      [ 4050.265020] hardirqs last  enabled at (7047): [<00000000001cee7a>] console_unlock+0x6d2/0x740
      [ 4050.265029] hardirqs last disabled at (7054): [<00000000001ce87e>] console_unlock+0xd6/0x740
      [ 4050.265040] softirqs last  enabled at (6416): [<0000000000b8fe26>] __udelay+0xb6/0x100
      [ 4050.265049] softirqs last disabled at (6415): [<0000000000b8fe06>] __udelay+0x96/0x100
      [ 4050.265057] ---[ end trace d04a07d39d99a9f9 ]---
      
      Let's fix this as described in the article
      https://lwn.net/Articles/628628/.
      Signed-off-by: NFarhan Ali <alifm@linux.ibm.com>
      [remove now redundant vfio_dev_present()]
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f7883f9b
    • A
      nfsd: avoid uninitialized variable warning · 806e8395
      Arnd Bergmann 提交于
      [ Upstream commit 0ab88ca4bcf18ba21058d8f19220f60afe0d34d8 ]
      
      clang warns that 'contextlen' may be accessed without an initialization:
      
      fs/nfsd/nfs4xdr.c:2911:9: error: variable 'contextlen' is uninitialized when used here [-Werror,-Wuninitialized]
                                                                      contextlen);
                                                                      ^~~~~~~~~~
      fs/nfsd/nfs4xdr.c:2424:16: note: initialize the variable 'contextlen' to silence this warning
              int contextlen;
                            ^
                             = 0
      
      Presumably this cannot happen, as FATTR4_WORD2_SECURITY_LABEL is
      set if CONFIG_NFSD_V4_SECURITY_LABEL is enabled.
      Adding another #ifdef like the other two in this function
      avoids the warning.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      806e8395
    • J
      nfsd: allow fh_want_write to be called twice · b4330e4a
      J. Bruce Fields 提交于
      [ Upstream commit 0b8f62625dc309651d0efcb6a6247c933acd8b45 ]
      
      A fuzzer recently triggered lockdep warnings about potential sb_writers
      deadlocks caused by fh_want_write().
      
      Looks like we aren't careful to pair each fh_want_write() with an
      fh_drop_write().
      
      It's not normally a problem since fh_put() will call fh_drop_write() for
      us.  And was OK for NFSv3 where we'd do one operation that might call
      fh_want_write(), and then put the filehandle.
      
      But an NFSv4 protocol fuzzer can do weird things like call unlink twice
      in a compound, and then we get into trouble.
      
      I'm a little worried about this approach of just leaving everything to
      fh_put().  But I think there are probably a lot of
      fh_want_write()/fh_drop_write() imbalances so for now I think we need it
      to be more forgiving.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b4330e4a
    • K
      fuse: retrieve: cap requested size to negotiated max_write · ae35c325
      Kirill Smelkov 提交于
      [ Upstream commit 7640682e67b33cab8628729afec8ca92b851394f ]
      
      FUSE filesystem server and kernel client negotiate during initialization
      phase, what should be the maximum write size the client will ever issue.
      Correspondingly the filesystem server then queues sys_read calls to read
      requests with buffer capacity large enough to carry request header + that
      max_write bytes. A filesystem server is free to set its max_write in
      anywhere in the range between [1*page, fc->max_pages*page]. In particular
      go-fuse[2] sets max_write by default as 64K, wheres default fc->max_pages
      corresponds to 128K. Libfuse also allows users to configure max_write, but
      by default presets it to possible maximum.
      
      If max_write is < fc->max_pages*page, and in NOTIFY_RETRIEVE handler we
      allow to retrieve more than max_write bytes, corresponding prepared
      NOTIFY_REPLY will be thrown away by fuse_dev_do_read, because the
      filesystem server, in full correspondence with server/client contract, will
      be only queuing sys_read with ~max_write buffer capacity, and
      fuse_dev_do_read throws away requests that cannot fit into server request
      buffer. In turn the filesystem server could get stuck waiting indefinitely
      for NOTIFY_REPLY since NOTIFY_RETRIEVE handler returned OK which is
      understood by clients as that NOTIFY_REPLY was queued and will be sent
      back.
      
      Cap requested size to negotiate max_write to avoid the problem.  This
      aligns with the way NOTIFY_RETRIEVE handler works, which already
      unconditionally caps requested retrieve size to fuse_conn->max_pages.  This
      way it should not hurt NOTIFY_RETRIEVE semantic if we return less data than
      was originally requested.
      
      Please see [1] for context where the problem of stuck filesystem was hit
      for real, how the situation was traced and for more involving patch that
      did not make it into the tree.
      
      [1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2
      [2] https://github.com/hanwen/go-fuseSigned-off-by: NKirill Smelkov <kirr@nexedi.com>
      Cc: Han-Wen Nienhuys <hanwen@google.com>
      Cc: Jakob Unterwurzacher <jakobunt@gmail.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ae35c325
    • C
      nvmem: sunxi_sid: Support SID on A83T and H5 · 1c2e9746
      Chen-Yu Tsai 提交于
      [ Upstream commit da75b8909756160b8e785104ba421a20b756c975 ]
      
      The device tree binding already lists compatible strings for these two
      SoCs. They don't have the defect as seen on the H3, and the size and
      register layout is the same as the A64. Furthermore, the driver does
      not include nvmem cell definitions.
      
      Add support for these two compatible strings, re-using the config for
      the A64.
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>
      Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1c2e9746
    • J
      nvmem: core: fix read buffer in place · 0412a885
      Jorge Ramirez-Ortiz 提交于
      [ Upstream commit 2fe518fecb3a4727393be286db9804cd82ee2d91 ]
      
      When the bit_offset in the cell is zero, the pointer to the msb will
      not be properly initialized (ie, will still be pointing to the first
      byte in the buffer).
      
      This being the case, if there are bits to clear in the msb, those will
      be left untouched while the mask will incorrectly clear bit positions
      on the first byte.
      
      This commit also makes sure that any byte unused in the cell is
      cleared.
      Signed-off-by: NJorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
      Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0412a885
    • T
      ALSA: hda - Register irq handler after the chip initialization · 962ce402
      Takashi Iwai 提交于
      [ Upstream commit f495222e28275222ab6fd93813bd3d462e16d340 ]
      
      Currently the IRQ handler in HD-audio controller driver is registered
      before the chip initialization.  That is, we have some window opened
      between the azx_acquire_irq() call and the CORB/RIRB setup.  If an
      interrupt is triggered in this small window, the IRQ handler may
      access to the uninitialized RIRB buffer, which leads to a NULL
      dereference Oops.
      
      This is usually no big problem since most of Intel chips do register
      the IRQ via MSI, and we've already fixed the order of the IRQ
      enablement and the CORB/RIRB setup in the former commit b61749a8
      ("sound: enable interrupt after dma buffer initialization"), hence the
      IRQ won't be triggered in that room.  However, some platforms use a
      shared IRQ, and this may allow the IRQ trigger by another source.
      
      Another possibility is the kdump environment: a stale interrupt might
      be present in there, the IRQ handler can be falsely triggered as well.
      
      For covering this small race, let's move the azx_acquire_irq() call
      after hda_intel_init_chip() call.  Although this is a bit radical
      change, it can cover more widely than checking the CORB/RIRB setup
      locally in the callee side.
      Reported-by: NLiwei Song <liwei.song@windriver.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      962ce402
    • T
      netfilter: nf_flow_table: fix netdev refcnt leak · 028b3d8d
      Taehee Yoo 提交于
      [ Upstream commit 26a302afbe328ecb7507cae2035d938e6635131b ]
      
      flow_offload_alloc() calls nf_route() to get a dst_entry. Internally,
      nf_route() calls ip_route_output_key() that allocates a dst_entry and
      holds it. So, a dst_entry should be released by dst_release() if
      nf_route() is successful.
      
      Otherwise, netns exit routine cannot be finished and the following
      message is printed:
      
      [  257.490952] unregister_netdevice: waiting for lo to become free. Usage count = 1
      
      Fixes: ac2a6666 ("netfilter: add generic flow table infrastructure")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      028b3d8d
    • T
      netfilter: nf_flow_table: check ttl value in flow offload data path · 650a4b7c
      Taehee Yoo 提交于
      [ Upstream commit 33cc3c0cfa64c86b6c4bbee86997aea638534931 ]
      
      nf_flow_offload_ip_hook() and nf_flow_offload_ipv6_hook() do not check
      ttl value. So, ttl value overflow may occur.
      
      Fixes: 97add9f0 ("netfilter: flow table support for IPv4")
      Fixes: 09952107 ("netfilter: flow table support for IPv6")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      650a4b7c
    • K
      nvme-pci: shutdown on timeout during deletion · 52d7b067
      Keith Busch 提交于
      [ Upstream commit 9dc1a38ef1925d23c2933c5867df816386d92ff8 ]
      
      We do not restart a controller in a deleting state for timeout errors.
      When in this state, unblock potential request dispatchers with failed
      completions by shutting down the controller on timeout detection.
      Reported-by: NYufen Yu <yuyufen@huawei.com>
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      52d7b067
    • K
      nvme-pci: unquiesce admin queue on shutdown · 6ce2ad24
      Keith Busch 提交于
      [ Upstream commit c8e9e9b7646ebe1c5066ddc420d7630876277eb4 ]
      
      Just like IO queues, the admin queue also will not be restarted after a
      controller shutdown. Unquiesce this queue so that we do not block
      request dispatch on a permanently disabled controller.
      Reported-by: NYufen Yu <yuyufen@huawei.com>
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6ce2ad24
    • K
      PCI: designware-ep: Use aligned ATU window for raising MSI interrupts · e9db9312
      Kishon Vijay Abraham I 提交于
      [ Upstream commit 6b7330303a8186fb211357e6d379237fe9d2ece1 ]
      
      Certain platforms like K2G reguires the outbound ATU window to be
      aligned. The alignment size is already present in mem->page_size.
      Use the alignment size present in mem->page_size to configure an
      aligned ATU window. In order to raise an interrupt, CPU has to write
      to address offset from the start of the window unlike before where
      writes were always to the beginning of the ATU window.
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e9db9312
    • K
      misc: pci_endpoint_test: Fix test_reg_bar to be updated in pci_endpoint_test · a7f27994
      Kishon Vijay Abraham I 提交于
      [ Upstream commit 8f220664570e755946db1282f48e07f26e1f2cb4 ]
      
      commit 834b9051 ("misc: pci_endpoint_test: Add support for
      PCI_ENDPOINT_TEST regs to be mapped to any BAR") while adding
      test_reg_bar in order to map PCI_ENDPOINT_TEST regs to be mapped to any
      BAR failed to update test_reg_bar in pci_endpoint_test, resulting in
      test_reg_bar having invalid value when used outside probe.
      
      Fix it.
      
      Fixes: 834b9051 ("misc: pci_endpoint_test: Add support for PCI_ENDPOINT_TEST regs to be mapped to any BAR")
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a7f27994
    • L
      iommu/vt-d: Set intel_iommu_gfx_mapped correctly · ed6efdb7
      Lu Baolu 提交于
      [ Upstream commit cf1ec4539a50bdfe688caad4615ca47646884316 ]
      
      The intel_iommu_gfx_mapped flag is exported by the Intel
      IOMMU driver to indicate whether an IOMMU is used for the
      graphic device. In a virtualized IOMMU environment (e.g.
      QEMU), an include-all IOMMU is used for graphic device.
      This flag is found to be clear even the IOMMU is used.
      
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
      Cc: Kevin Tian <kevin.tian@intel.com>
      Reported-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      Fixes: c0771df8 ("intel-iommu: Export a flag indicating that the IOMMU is used for iGFX.")
      Suggested-by: NKevin Tian <kevin.tian@intel.com>
      Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ed6efdb7
    • M
      blk-mq: move cancel of requeue_work into blk_mq_release · 525b5265
      Ming Lei 提交于
      [ Upstream commit fbc2a15e3433058582e5635aabe48a3011a644a8 ]
      
      With holding queue's kobject refcount, it is safe for driver
      to schedule requeue. However, blk_mq_kick_requeue_list() may
      be called after blk_sync_queue() is done because of concurrent
      requeue activities, then requeue work may not be completed when
      freeing queue, and kernel oops is triggered.
      
      So moving the cancel of requeue_work into blk_mq_release() for
      avoiding race between requeue and freeing queue.
      
      Cc: Dongli Zhang <dongli.zhang@oracle.com>
      Cc: James Smart <james.smart@broadcom.com>
      Cc: Bart Van Assche <bart.vanassche@wdc.com>
      Cc: linux-scsi@vger.kernel.org,
      Cc: Martin K . Petersen <martin.petersen@oracle.com>,
      Cc: Christoph Hellwig <hch@lst.de>,
      Cc: James E . J . Bottomley <jejb@linux.vnet.ibm.com>,
      Reviewed-by: NBart Van Assche <bvanassche@acm.org>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: NHannes Reinecke <hare@suse.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Tested-by: NJames Smart <james.smart@broadcom.com>
      Signed-off-by: NMing Lei <ming.lei@redhat.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      525b5265
    • V
      watchdog: fix compile time error of pretimeout governors · d6c80b60
      Vladimir Zapolskiy 提交于
      [ Upstream commit a223770bfa7b6647f3a70983257bd89f9cafce46 ]
      
      CONFIG_WATCHDOG_PRETIMEOUT_GOV build symbol adds watchdog_pretimeout.o
      object to watchdog.o, the latter is compiled only if CONFIG_WATCHDOG_CORE
      is selected, so it rightfully makes sense to add it as a dependency.
      
      The change fixes the next compilation errors, if CONFIG_WATCHDOG_CORE=n
      and CONFIG_WATCHDOG_PRETIMEOUT_GOV=y are selected:
      
        drivers/watchdog/pretimeout_noop.o: In function `watchdog_gov_noop_register':
        drivers/watchdog/pretimeout_noop.c:35: undefined reference to `watchdog_register_governor'
        drivers/watchdog/pretimeout_noop.o: In function `watchdog_gov_noop_unregister':
        drivers/watchdog/pretimeout_noop.c:40: undefined reference to `watchdog_unregister_governor'
      
        drivers/watchdog/pretimeout_panic.o: In function `watchdog_gov_panic_register':
        drivers/watchdog/pretimeout_panic.c:35: undefined reference to `watchdog_register_governor'
        drivers/watchdog/pretimeout_panic.o: In function `watchdog_gov_panic_unregister':
        drivers/watchdog/pretimeout_panic.c:40: undefined reference to `watchdog_unregister_governor'
      Reported-by: NKuo, Hsuan-Chi <hckuo2@illinois.edu>
      Fixes: ff84136c ("watchdog: add watchdog pretimeout governor framework")
      Signed-off-by: NVladimir Zapolskiy <vz@mleia.com>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NWim Van Sebroeck <wim@linux-watchdog.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d6c80b60
    • G
      watchdog: imx2_wdt: Fix set_timeout for big timeout values · 0f50c30c
      Georg Hofmann 提交于
      [ Upstream commit b07e228eee69601addba98b47b1a3850569e5013 ]
      
      The documentated behavior is: if max_hw_heartbeat_ms is implemented, the
      minimum of the set_timeout argument and max_hw_heartbeat_ms should be used.
      This patch implements this behavior.
      Previously only the first 7bits were used and the input argument was
      returned.
      Signed-off-by: NGeorg Hofmann <georg@hofmannsweb.com>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NWim Van Sebroeck <wim@linux-watchdog.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0f50c30c
    • F
      netfilter: nf_tables: fix base chain stat rcu_dereference usage · dc58e402
      Florian Westphal 提交于
      [ Upstream commit edbd82c5fba009f68d20b5db585be1e667c605f6 ]
      
      Following splat gets triggered when nfnetlink monitor is running while
      xtables-nft selftests are running:
      
      net/netfilter/nf_tables_api.c:1272 suspicious rcu_dereference_check() usage!
      other info that might help us debug this:
      
      1 lock held by xtables-nft-mul/27006:
       #0: 00000000e0f85be9 (&net->nft.commit_mutex){+.+.}, at: nf_tables_valid_genid+0x1a/0x50
      Call Trace:
       nf_tables_fill_chain_info.isra.45+0x6cc/0x6e0
       nf_tables_chain_notify+0xf8/0x1a0
       nf_tables_commit+0x165c/0x1740
      
      nf_tables_fill_chain_info() can be called both from dumps (rcu read locked)
      or from the transaction path if a userspace process subscribed to nftables
      notifications.
      
      In the 'table dump' case, rcu_access_pointer() cannot be used: We do not
      hold transaction mutex so the pointer can be NULLed right after the check.
      Just unconditionally fetch the value, then have the helper return
      immediately if its NULL.
      
      In the notification case we don't hold the rcu read lock, but updates are
      prevented due to transaction mutex. Use rcu_dereference_check() to make lockdep
      aware of this.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      dc58e402
    • S
      mips: Make sure dt memory regions are valid · 2d433cc9
      Serge Semin 提交于
      [ Upstream commit 93fa5b280761a4dbb14c5330f260380385ab2b49 ]
      
      There are situations when memory regions coming from dts may be
      too big for the platform physical address space. This especially
      concerns XPA-capable systems. Bootloader may determine more than 4GB
      memory available and pass it to the kernel over dts memory node, while
      kernel is built without XPA/64BIT support. In this case the region
      may either simply be truncated by add_memory_region() method
      or by u64->phys_addr_t type casting. But in worst case the method
      can even drop the memory region if it exceeds PHYS_ADDR_MAX size.
      So lets make sure the retrieved from dts memory regions are valid,
      and if some of them aren't, just manually truncate them with a warning
      printed out.
      Signed-off-by: NSerge Semin <fancer.lancer@gmail.com>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Mike Rapoport <rppt@linux.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Thomas Bogendoerfer <tbogendoerfer@suse.de>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: Stefan Agner <stefan@agner.ch>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Serge Semin <Sergey.Semin@t-platforms.ru>
      Cc: linux-mips@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2d433cc9
    • J
      netfilter: nf_conntrack_h323: restore boundary check correctness · 2aed9dfe
      Jakub Jankowski 提交于
      [ Upstream commit f5e85ce8e733c2547827f6268136b70b802eabdb ]
      
      Since commit bc7d811a ("netfilter: nf_ct_h323: Convert
      CHECK_BOUND macro to function"), NAT traversal for H.323
      doesn't work, failing to parse H323-UserInformation.
      nf_h323_error_boundary() compares contents of the bitstring,
      not the addresses, preventing valid H.323 packets from being
      conntrack'd.
      
      This looks like an oversight from when CHECK_BOUND macro was
      converted to a function.
      
      To fix it, stop dereferencing bs->cur and bs->end.
      
      Fixes: bc7d811a ("netfilter: nf_ct_h323: Convert CHECK_BOUND macro to function")
      Signed-off-by: NJakub Jankowski <shasta@toxcorp.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2aed9dfe
    • T
      netfilter: nf_flow_table: fix missing error check for rhashtable_insert_fast · d0941980
      Taehee Yoo 提交于
      [ Upstream commit 43c8f131184faf20c07221f3e09724611c6525d8 ]
      
      rhashtable_insert_fast() may return an error value when memory
      allocation fails, but flow_offload_add() does not check for errors.
      This patch just adds missing error checking.
      
      Fixes: ac2a6666 ("netfilter: add generic flow table infrastructure")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d0941980
    • L
      mmc: mmci: Prevent polling for busy detection in IRQ context · 217ec4a6
      Ludovic Barre 提交于
      [ Upstream commit 8520ce1e17799b220ff421d4f39438c9c572ade3 ]
      
      The IRQ handler, mmci_irq(), loops until all status bits have been cleared.
      However, the status bit signaling busy in variant->busy_detect_flag, may be
      set even if busy detection isn't monitored for the current request.
      
      This may be the case for the CMD11 when switching the I/O voltage, which
      leads to that mmci_irq() busy loops in IRQ context. Fix this problem, by
      clearing the status bit for busy, before continuing to validate the
      condition for the loop. This is safe, because the busy status detection has
      already been taken care of by mmci_cmd_irq().
      Signed-off-by: NLudovic Barre <ludovic.barre@st.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      217ec4a6
    • A
      ovl: do not generate duplicate fsnotify events for "fake" path · 06382ad6
      Amir Goldstein 提交于
      [ Upstream commit d989903058a83e8536cc7aadf9256a47d5c173fe ]
      
      Overlayfs "fake" path is used for stacked file operations on underlying
      files.  Operations on files with "fake" path must not generate fsnotify
      events with path data, because those events have already been generated at
      overlayfs layer and because the reported event->fd for fanotify marks on
      underlying inode/filesystem will have the wrong path (the overlayfs path).
      
      Link: https://lore.kernel.org/linux-fsdevel/20190423065024.12695-1-jencce.kernel@gmail.com/Reported-by: NMurphy Zhou <jencce.kernel@gmail.com>
      Fixes: d1d04ef8 ("ovl: stack file ops")
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      06382ad6
    • J
      PCI: dwc: Free MSI IRQ page in dw_pcie_free_msi() · 5fbe39bf
      Jisheng Zhang 提交于
      [ Upstream commit dc69a3d567941784c3d00e1d0834582b42b0b3e7 ]
      
      To avoid a memory leak, free the page allocated for MSI IRQ in
      dw_pcie_free_msi().
      Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NGustavo Pimentel <gustavo.pimentel@synopsys.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5fbe39bf