1. 15 Jun, 2019 40 commits
    • Marek Szyprowski's avatar
      ARM: exynos: Fix undefined instruction during Exynos5422 resume · 06a94102
      Marek Szyprowski authored
      [ Upstream commit 4d8e3e95 ]
      
      During early system resume on Exynos5422 with performance counters enabled
      the following kernel oops happens:
      
          Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP ARM
          Modules linked in:
          CPU: 0 PID: 1433 Comm: bash Tainted: G        W         5.0.0-rc5-next-20190208-00023-gd5fb5a8a13e6-dirty #5480
          Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
          ...
          Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment none
          Control: 10c5387d  Table: 4451006a  DAC: 00000051
          Process bash (pid: 1433, stack limit = 0xb7e0e22f)
          ...
          (reset_ctrl_regs) from [<c0112ad0>] (dbg_cpu_pm_notify+0x1c/0x24)
          (dbg_cpu_pm_notify) from [<c014c840>] (notifier_call_chain+0x44/0x84)
          (notifier_call_chain) from [<c014cbc0>] (__atomic_notifier_call_chain+0x7c/0x128)
          (__atomic_notifier_call_chain) from [<c01ffaac>] (cpu_pm_notify+0x30/0x54)
          (cpu_pm_notify) from [<c055116c>] (syscore_resume+0x98/0x3f4)
          (syscore_resume) from [<c0189350>] (suspend_devices_and_enter+0x97c/0xe74)
          (suspend_devices_and_enter) from [<c0189fb8>] (pm_suspend+0x770/0xc04)
          (pm_suspend) from [<c0187740>] (state_store+0x6c/0xcc)
          (state_store) from [<c09fa698>] (kobj_attr_store+0x14/0x20)
          (kobj_attr_store) from [<c030159c>] (sysfs_kf_write+0x4c/0x50)
          (sysfs_kf_write) from [<c0300620>] (kernfs_fop_write+0xfc/0x1e0)
          (kernfs_fop_write) from [<c0282be8>] (__vfs_write+0x2c/0x160)
          (__vfs_write) from [<c0282ea4>] (vfs_write+0xa4/0x16c)
          (vfs_write) from [<c0283080>] (ksys_write+0x40/0x8c)
          (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
      
      Undefined instruction is triggered during CP14 reset, because bits: #16
      (Secure privileged invasive debug disabled) and #17 (Secure privileged
      noninvasive debug disable) are set in DSCR. Those bits depend on SPNIDEN
      and SPIDEN lines, which are provided by Secure JTAG hardware block. That
      block in turn is powered from cluster 0 (big/Eagle), but the Exynos5422
      boots on cluster 1 (LITTLE/KFC).
      
      To fix this issue it is enough to turn on the power on the cluster 0 for
      a while. This lets the Secure JTAG block to propagate the needed signals
      to LITTLE/KFC cores and change their DSCR.
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      06a94102
    • Phong Hoang's avatar
      pwm: Fix deadlock warning when removing PWM device · e940d550
      Phong Hoang authored
      [ Upstream commit 347ab948 ]
      
      This patch fixes deadlock warning if removing PWM device
      when CONFIG_PROVE_LOCKING is enabled.
      
      This issue can be reproceduced by the following steps on
      the R-Car H3 Salvator-X board if the backlight is disabled:
      
       # cd /sys/class/pwm/pwmchip0
       # echo 0 > export
       # ls
       device  export  npwm  power  pwm0  subsystem  uevent  unexport
       # cd device/driver
       # ls
       bind  e6e31000.pwm  uevent  unbind
       # echo e6e31000.pwm > unbind
      
      [   87.659974] ======================================================
      [   87.666149] WARNING: possible circular locking dependency detected
      [   87.672327] 5.0.0 #7 Not tainted
      [   87.675549] ------------------------------------------------------
      [   87.681723] bash/2986 is trying to acquire lock:
      [   87.686337] 000000005ea0e178 (kn->count#58){++++}, at: kernfs_remove_by_name_ns+0x50/0xa0
      [   87.694528]
      [   87.694528] but task is already holding lock:
      [   87.700353] 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
      [   87.707405]
      [   87.707405] which lock already depends on the new lock.
      [   87.707405]
      [   87.715574]
      [   87.715574] the existing dependency chain (in reverse order) is:
      [   87.723048]
      [   87.723048] -> #1 (pwm_lock){+.+.}:
      [   87.728017]        __mutex_lock+0x70/0x7e4
      [   87.732108]        mutex_lock_nested+0x1c/0x24
      [   87.736547]        pwm_request_from_chip.part.6+0x34/0x74
      [   87.741940]        pwm_request_from_chip+0x20/0x40
      [   87.746725]        export_store+0x6c/0x1f4
      [   87.750820]        dev_attr_store+0x18/0x28
      [   87.754998]        sysfs_kf_write+0x54/0x64
      [   87.759175]        kernfs_fop_write+0xe4/0x1e8
      [   87.763615]        __vfs_write+0x40/0x184
      [   87.767619]        vfs_write+0xa8/0x19c
      [   87.771448]        ksys_write+0x58/0xbc
      [   87.775278]        __arm64_sys_write+0x18/0x20
      [   87.779721]        el0_svc_common+0xd0/0x124
      [   87.783986]        el0_svc_compat_handler+0x1c/0x24
      [   87.788858]        el0_svc_compat+0x8/0x18
      [   87.792947]
      [   87.792947] -> #0 (kn->count#58){++++}:
      [   87.798260]        lock_acquire+0xc4/0x22c
      [   87.802353]        __kernfs_remove+0x258/0x2c4
      [   87.806790]        kernfs_remove_by_name_ns+0x50/0xa0
      [   87.811836]        remove_files.isra.1+0x38/0x78
      [   87.816447]        sysfs_remove_group+0x48/0x98
      [   87.820971]        sysfs_remove_groups+0x34/0x4c
      [   87.825583]        device_remove_attrs+0x6c/0x7c
      [   87.830197]        device_del+0x11c/0x33c
      [   87.834201]        device_unregister+0x14/0x2c
      [   87.838638]        pwmchip_sysfs_unexport+0x40/0x4c
      [   87.843509]        pwmchip_remove+0xf4/0x13c
      [   87.847773]        rcar_pwm_remove+0x28/0x34
      [   87.852039]        platform_drv_remove+0x24/0x64
      [   87.856651]        device_release_driver_internal+0x18c/0x21c
      [   87.862391]        device_release_driver+0x14/0x1c
      [   87.867175]        unbind_store+0xe0/0x124
      [   87.871265]        drv_attr_store+0x20/0x30
      [   87.875442]        sysfs_kf_write+0x54/0x64
      [   87.879618]        kernfs_fop_write+0xe4/0x1e8
      [   87.884055]        __vfs_write+0x40/0x184
      [   87.888057]        vfs_write+0xa8/0x19c
      [   87.891887]        ksys_write+0x58/0xbc
      [   87.895716]        __arm64_sys_write+0x18/0x20
      [   87.900154]        el0_svc_common+0xd0/0x124
      [   87.904417]        el0_svc_compat_handler+0x1c/0x24
      [   87.909289]        el0_svc_compat+0x8/0x18
      [   87.913378]
      [   87.913378] other info that might help us debug this:
      [   87.913378]
      [   87.921374]  Possible unsafe locking scenario:
      [   87.921374]
      [   87.927286]        CPU0                    CPU1
      [   87.931808]        ----                    ----
      [   87.936331]   lock(pwm_lock);
      [   87.939293]                                lock(kn->count#58);
      [   87.945120]                                lock(pwm_lock);
      [   87.950599]   lock(kn->count#58);
      [   87.953908]
      [   87.953908]  *** DEADLOCK ***
      [   87.953908]
      [   87.959821] 4 locks held by bash/2986:
      [   87.963563]  #0: 00000000ace7bc30 (sb_writers#6){.+.+}, at: vfs_write+0x188/0x19c
      [   87.971044]  #1: 00000000287991b2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xb4/0x1e8
      [   87.978872]  #2: 00000000f739d016 (&dev->mutex){....}, at: device_release_driver_internal+0x40/0x21c
      [   87.988001]  #3: 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
      [   87.995481]
      [   87.995481] stack backtrace:
      [   87.999836] CPU: 0 PID: 2986 Comm: bash Not tainted 5.0.0 #7
      [   88.005489] Hardware name: Renesas Salvator-X board based on r8a7795 ES1.x (DT)
      [   88.012791] Call trace:
      [   88.015235]  dump_backtrace+0x0/0x190
      [   88.018891]  show_stack+0x14/0x1c
      [   88.022204]  dump_stack+0xb0/0xec
      [   88.025514]  print_circular_bug.isra.32+0x1d0/0x2e0
      [   88.030385]  __lock_acquire+0x1318/0x1864
      [   88.034388]  lock_acquire+0xc4/0x22c
      [   88.037958]  __kernfs_remove+0x258/0x2c4
      [   88.041874]  kernfs_remove_by_name_ns+0x50/0xa0
      [   88.046398]  remove_files.isra.1+0x38/0x78
      [   88.050487]  sysfs_remove_group+0x48/0x98
      [   88.054490]  sysfs_remove_groups+0x34/0x4c
      [   88.058580]  device_remove_attrs+0x6c/0x7c
      [   88.062671]  device_del+0x11c/0x33c
      [   88.066154]  device_unregister+0x14/0x2c
      [   88.070070]  pwmchip_sysfs_unexport+0x40/0x4c
      [   88.074421]  pwmchip_remove+0xf4/0x13c
      [   88.078163]  rcar_pwm_remove+0x28/0x34
      [   88.081906]  platform_drv_remove+0x24/0x64
      [   88.085996]  device_release_driver_internal+0x18c/0x21c
      [   88.091215]  device_release_driver+0x14/0x1c
      [   88.095478]  unbind_store+0xe0/0x124
      [   88.099048]  drv_attr_store+0x20/0x30
      [   88.102704]  sysfs_kf_write+0x54/0x64
      [   88.106359]  kernfs_fop_write+0xe4/0x1e8
      [   88.110275]  __vfs_write+0x40/0x184
      [   88.113757]  vfs_write+0xa8/0x19c
      [   88.117065]  ksys_write+0x58/0xbc
      [   88.120374]  __arm64_sys_write+0x18/0x20
      [   88.124291]  el0_svc_common+0xd0/0x124
      [   88.128034]  el0_svc_compat_handler+0x1c/0x24
      [   88.132384]  el0_svc_compat+0x8/0x18
      
      The sysfs unexport in pwmchip_remove() is completely asymmetric
      to what we do in pwmchip_add_with_polarity() and commit 0733424c
      ("pwm: Unexport children before chip removal") is a strong indication
      that this was wrong to begin with. We should just move
      pwmchip_sysfs_unexport() where it belongs, which is right after
      pwmchip_sysfs_unexport_children(). In that case, we do not need
      separate functions anymore either.
      
      We also really want to remove sysfs irrespective of whether or not
      the chip will be removed as a result of pwmchip_remove(). We can only
      assume that the driver will be gone after that, so we shouldn't leave
      any dangling sysfs files around.
      
      This warning disappears if we move pwmchip_sysfs_unexport() to
      the top of pwmchip_remove(), pwmchip_sysfs_unexport_children().
      That way it is also outside of the pwm_lock section, which indeed
      doesn't seem to be needed.
      
      Moving the pwmchip_sysfs_export() call outside of that section also
      seems fine and it'd be perfectly symmetric with pwmchip_remove() again.
      
      So, this patch fixes them.
      Signed-off-by: default avatarPhong Hoang <phong.hoang.wz@renesas.com>
      [shimoda: revise the commit log and code]
      Fixes: 76abbdde ("pwm: Add sysfs interface")
      Fixes: 0733424c ("pwm: Unexport children before chip removal")
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Tested-by: default avatarHoan Nguyen An <na-hoan@jinso.co.jp>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Reviewed-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarThierry Reding <thierry.reding@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e940d550
    • Krzysztof Kozlowski's avatar
      ARM: dts: exynos: Always enable necessary APIO_1V8 and ABB_1V8 regulators on Arndale Octa · 6e63900b
      Krzysztof Kozlowski authored
      [ Upstream commit 5ab99cf7 ]
      
      The PVDD_APIO_1V8 (LDO2) and PVDD_ABB_1V8 (LDO8) regulators were turned
      off by Linux kernel as unused.  However they supply critical parts of
      SoC so they should be always on:
      
      1. PVDD_APIO_1V8 supplies SYS pins (gpx[0-3], PSHOLD), HDMI level shift,
         RTC, VDD1_12 (DRAM internal 1.8 V logic), pull-up for PMIC interrupt
         lines, TTL/UARTR level shift, reset pins and SW-TACT1 button.
         It also supplies unused blocks like VDDQ_SRAM (for SROM controller) and
         VDDQ_GPIO (gpm7, gpy7).
         The LDO2 cannot be turned off (S2MPS11 keeps it on anyway) so
         marking it "always-on" only reflects its real status.
      
      2. PVDD_ABB_1V8 supplies Adaptive Body Bias Generator for ARM cores,
         memory and Mali (G3D).
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6e63900b
    • Sakari Ailus's avatar
      media: v4l2-fwnode: Defaults may not override endpoint configuration in firmware · 4effefce
      Sakari Ailus authored
      [ Upstream commit 9d386373 ]
      
      The lack of defaults provided by the caller to
      v4l2_fwnode_endpoint_parse() signals the use of the default lane mapping.
      The default lane mapping must not be used however if the firmmare contains
      the lane mapping. Disable the default lane mapping in that case, and
      improve the debug messages telling of the use of the defaults.
      
      This was missed previously since the default mapping will only unsed in
      this case if the bus type is set, and no driver did both while still
      needing the lane mapping configuration.
      
      Fixes: b4357d21 ("media: v4l: fwnode: Support default CSI-2 lane mapping for drivers")
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4effefce
    • Christoph Vogtländer's avatar
      pwm: tiehrpwm: Update shadow register for disabling PWMs · 465a2271
      Christoph Vogtländer authored
      [ Upstream commit b00ef530 ]
      
      It must be made sure that immediate mode is not already set, when
      modifying shadow register value in ehrpwm_pwm_disable(). Otherwise
      modifications to the action-qualifier continuous S/W force
      register(AQSFRC) will be done in the active register.
      This may happen when both channels are being disabled. In this case,
      only the first channel state will be recorded as disabled in the shadow
      register. Later, when enabling the first channel again, the second
      channel would be enabled as well. Setting RLDCSF to zero, first, ensures
      that the shadow register is updated as desired.
      
      Fixes: 38dabd91 ("pwm: tiehrpwm: Fix disabling of output of PWMs")
      Signed-off-by: default avatarChristoph Vogtländer <c.vogtlaender@sigma-surface-science.com>
      [vigneshr@ti.com: Improve commit message]
      Signed-off-by: default avatarVignesh Raghavendra <vigneshr@ti.com>
      Signed-off-by: default avatarThierry Reding <thierry.reding@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      465a2271
    • Andy Shevchenko's avatar
      dmaengine: idma64: Use actual device for DMA transfers · 754b995f
      Andy Shevchenko authored
      [ Upstream commit 5ba846b1 ]
      
      Intel IOMMU, when enabled, tries to find the domain of the device,
      assuming it's a PCI one, during DMA operations, such as mapping or
      unmapping. Since we are splitting the actual PCI device to couple of
      children via MFD framework (see drivers/mfd/intel-lpss.c for details),
      the DMA device appears to be a platform one, and thus not an actual one
      that performs DMA. In a such situation IOMMU can't find or allocate
      a proper domain for its operations. As a result, all DMA operations are
      failed.
      
      In order to fix this, supply parent of the platform device
      to the DMA engine framework and fix filter functions accordingly.
      
      We may rely on the fact that parent is a real PCI device, because no
      other configuration is present in the wild.
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: default avatarMark Brown <broonie@kernel.org>
      Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [for tty parts]
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      754b995f
    • Christopher N Bednarz's avatar
      ice: Do not set LB_EN for prune switch rules · 6e578116
      Christopher N Bednarz authored
      [ Upstream commit b58dafbc ]
      
      LB_EN for prune switch rules was causing all TX traffic
      to loopback to the internal switch and dropped.  When
      running bi-directional stress workloads with RDMA
      the RDPU would hang blocking tx and rx traffic.
      Signed-off-by: default avatarChristopher N Bednarz <christopher.n.bednarz@intel.com>
      Reviewed-by: default avatarBruce Allan <bruce.w.allan@intel.com>
      Signed-off-by: default avatarAnirudh Venkataramanan <anirudh.venkataramanan@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6e578116
    • Yashaswini Raghuram Prathivadi Bhayankaram's avatar
      ice: Enable LAN_EN for the right recipes · e4774bc4
      [ Upstream commit 277b3a45 ]
      
      In VEB mode, enable LAN_EN bit in the action fields for filter rules
      corresponding to the right recipes.
      Signed-off-by: default avatarYashaswini Raghuram Prathivadi Bhayankaram <yashaswini.raghuram.prathivadi.bhayankaram@intel.com>
      Reviewed-by: default avatarBruce Allan <bruce.w.allan@intel.com>
      Signed-off-by: default avatarAnirudh Venkataramanan <anirudh.venkataramanan@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e4774bc4
    • Sven Eckelmann's avatar
      batman-adv: Adjust name for batadv_dat_send_data · b7630b79
      Sven Eckelmann authored
      [ Upstream commit c2d8b9a6 ]
      
      The send functions in batman-adv are expected to consume the skb when
      either the data is queued up for the underlying driver or when some
      precondition failed. batadv_dat_send_data didn't do this and instead
      created a copy of the skb, modified it and queued the copy up for
      transmission. The caller has to take care that the skb is handled correctly
      (for example free'd) when batadv_dat_send_data returns.
      
      This unclear behavior already lead to memory leaks in the recent past.
      Renaming the function to batadv_dat_forward_data should make it easier to
      identify that the data is forwarded but the skb is not actually
      send+consumed.
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b7630b79
    • Dafna Hirschfeld's avatar
      media: v4l2-ctrl: v4l2_ctrl_request_setup returns with error upon failure · 864c051b
      Dafna Hirschfeld authored
      [ Upstream commit 09ca38a5 ]
      
      If one of the controls fails to set,
      then 'v4l2_ctrl_request_setup'
      immediately returns with the error code.
      Signed-off-by: default avatarDafna Hirschfeld <dafna3@gmail.com>
      Reviewed-by: default avatarPaul Kocialkowski <paul.kocialkowski@bootlin.com>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      864c051b
    • Brett Creeley's avatar
      ice: Add missing case in print_link_msg for printing flow control · 75224c88
      Brett Creeley authored
      [ Upstream commit 203a068a ]
      
      Currently we aren't checking for the ICE_FC_NONE case for the current
      flow control mode. This is causing "Unknown" to be printed for the
      current flow control method if flow control is disabled. Fix this by
      adding the case for ICE_FC_NONE to print "None".
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Signed-off-by: default avatarAnirudh Venkataramanan <anirudh.venkataramanan@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      75224c88
    • Tony Lindgren's avatar
      gpio: gpio-omap: limit errata 1.101 handling to wkup domain gpios only · 086542a2
      Tony Lindgren authored
      [ Upstream commit 21e2118f ]
      
      We need to only apply errata 1.101 handling to clear non-wakeup edge gpios
      for idle to the gpio bank(s) in the wkup domain to prevent spurious wake-up
      events.
      
      And we must restore what we did after idle manually as the gpio bank in
      wkup domain is not restored otherwise.
      
      Let's keep bank->saved_datain register reading separate, that's not related
      to the 1.101 errata and is used separately on restore.
      
      Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Keerthy <j-keerthy@ti.com>
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Russell King <rmk+kernel@armlinux.org.uk>
      Cc: Tero Kristo <t-kristo@ti.com>
      Reported-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      086542a2
    • Tony Lindgren's avatar
      gpio: gpio-omap: add check for off wake capable gpios · 0bbdfcb1
      Tony Lindgren authored
      [ Upstream commit da38ef3e ]
      
      We are currently assuming all GPIOs are non-wakeup capable GPIOs as we
      not configuring the bank->non_wakeup_gpios like we used to earlier with
      platform_data.
      
      Let's add omap_gpio_is_off_wakeup_capable() to make the handling clearer
      while considering that later patches may want to configure SoC specific
      bank->non_wakeup_gpios for the GPIOs in wakeup domain.
      
      Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Keerthy <j-keerthy@ti.com>
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Russell King <rmk+kernel@armlinux.org.uk>
      Cc: Tero Kristo <t-kristo@ti.com>
      Reported-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0bbdfcb1
    • Bjorn Andersson's avatar
      arm64: dts: qcom: qcs404: Fix regulator supply names · 1b53c68f
      Bjorn Andersson authored
      [ Upstream commit f95f57e4 ]
      
      The regulator definition got their supply names cleaned up during
      upstreaming, so they no longer match the driver defined names. Update
      the supply names.
      
      Also fill out the missing voltage of SMPS 5.
      
      Fixes: 0b363f5b ("arm64: dts: qcom: qcs404: Add PMS405 RPM regulators")
      Reported-by: default avatarNicolas Dechesne <nicolas.dechesne@linaro.org>
      Reviewed-by: default avatarNiklas Cassel <niklas.cassel@linaro.org>
      Signed-off-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Signed-off-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1b53c68f
    • Kangjie Lu's avatar
      PCI: xilinx: Check for __get_free_pages() failure · dc73a380
      Kangjie Lu authored
      [ Upstream commit 699ca301 ]
      
      If __get_free_pages() fails, return -ENOMEM to avoid a NULL pointer
      dereference.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: default avatarSteven Price <steven.price@arm.com>
      Reviewed-by: default avatarMukesh Ojha <mojha@codeaurora.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dc73a380
    • Paolo Valente's avatar
      block, bfq: increase idling for weight-raised queues · 404ee275
      Paolo Valente authored
      [ Upstream commit 778c02a2 ]
      
      If a sync bfq_queue has a higher weight than some other queue, and
      remains temporarily empty while in service, then, to preserve the
      bandwidth share of the queue, it is necessary to plug I/O dispatching
      until a new request arrives for the queue. In addition, a timeout
      needs to be set, to avoid waiting for ever if the process associated
      with the queue has actually finished its I/O.
      
      Even with the above timeout, the device is however not fed with new
      I/O for a while, if the process has finished its I/O. If this happens
      often, then throughput drops and latencies grow. For this reason, the
      timeout is kept rather low: 8 ms is the current default.
      
      Unfortunately, such a low value may cause, on the opposite end, a
      violation of bandwidth guarantees for a process that happens to issue
      new I/O too late. The higher the system load, the higher the
      probability that this happens to some process. This is a problem in
      scenarios where service guarantees matter more than throughput. One
      important case are weight-raised queues, which need to be granted a
      very high fraction of the bandwidth.
      
      To address this issue, this commit lower-bounds the plugging timeout
      for weight-raised queues to 20 ms. This simple change provides
      relevant benefits. For example, on a PLEXTOR PX-256M5S, with which
      gnome-terminal starts in 0.6 seconds if there is no other I/O in
      progress, the same applications starts in
      - 0.8 seconds, instead of 1.2 seconds, if ten files are being read
        sequentially in parallel
      - 1 second, instead of 2 seconds, if, in parallel, five files are
        being read sequentially, and five more files are being written
        sequentially
      Tested-by: default avatarHolger Hoffstätte <holger@applied-asynchrony.com>
      Tested-by: default avatarOleksandr Natalenko <oleksandr@natalenko.name>
      Signed-off-by: default avatarPaolo Valente <paolo.valente@linaro.org>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      404ee275
    • Kangjie Lu's avatar
      video: imsttfb: fix potential NULL pointer dereferences · cd4fb576
      Kangjie Lu authored
      [ Upstream commit 1d84353d ]
      
      In case ioremap fails, the fix releases resources and returns
      -ENOMEM to avoid NULL pointer dereferences.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Cc: Aditya Pakki <pakki001@umn.edu>
      Cc: Finn Thain <fthain@telegraphics.com.au>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      [b.zolnierkie: minor patch summary fixup]
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cd4fb576
    • Kangjie Lu's avatar
      video: hgafb: fix potential NULL pointer dereference · 317cc03a
      Kangjie Lu authored
      [ Upstream commit ec7f6aad ]
      
      When ioremap fails, hga_vram should not be dereferenced. The fix
      check the failure to avoid NULL pointer dereference.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Cc: Aditya Pakki <pakki001@umn.edu>
      Cc: Ferenc Bakonyi <fero@drama.obuda.kando.hu>
      [b.zolnierkie: minor patch summary fixup]
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      317cc03a
    • Jagan Teki's avatar
      Input: goodix - add GT5663 CTP support · 15337c4e
      Jagan Teki authored
      [ Upstream commit a5f50c50 ]
      
      GT5663 is capacitive touch controller with customized smart
      wakeup gestures.
      
      Add support for it by adding compatible and supported chip data.
      
      The chip data on GT5663 is similar to GT1151, like
      - config data register has 0x8050 address
      - config data register max len is 240
      - config data checksum has 16-bit
      Signed-off-by: default avatarJagan Teki <jagan@amarulasolutions.com>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      15337c4e
    • Giridhar Malavali's avatar
      scsi: qla2xxx: Reset the FCF_ASYNC_{SENT|ACTIVE} flags · f6023d95
      Giridhar Malavali authored
      [ Upstream commit 0257eda0 ]
      
      Driver maintains state machine for processing and completing switch
      commands. This patch resets FCF_ASYNC_{SENT|ACTIVE} flag to indicate if the
      previous command is active or sent, in order for next GPSC command to
      advance the state machine.
      
      [mkp: commit desc typo]
      Signed-off-by: default avatarGiridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: default avatarHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f6023d95
    • Marek Vasut's avatar
      PCI: rcar: Fix 64bit MSI message address handling · e29094bf
      Marek Vasut authored
      [ Upstream commit 954b4b75 ]
      
      The MSI message address in the RC address space can be 64 bit. The
      R-Car PCIe RC supports such a 64bit MSI message address as well.
      The code currently uses virt_to_phys(__get_free_pages()) to obtain
      a reserved page for the MSI message address, and the return value
      of which can be a 64 bit physical address on 64 bit system.
      
      However, the driver only programs PCIEMSIALR register with the bottom
      32 bits of the virt_to_phys(__get_free_pages()) return value and does
      not program the top 32 bits into PCIEMSIAUR, but rather programs the
      PCIEMSIAUR register with 0x0. This worked fine on older 32 bit R-Car
      SoCs, however may fail on new 64 bit R-Car SoCs.
      
      Since from a PCIe controller perspective, an inbound MSI is a memory
      write to a special address (in case of this controller, defined by
      the value in PCIEMSIAUR:PCIEMSIALR), which triggers an interrupt, but
      never hits the DRAM _and_ because allocation of an MSI by a PCIe card
      driver obtains the MSI message address by reading PCIEMSIAUR:PCIEMSIALR
      in rcar_msi_setup_irqs(), incorrectly programmed PCIEMSIAUR cannot
      cause memory corruption or other issues.
      
      There is however the possibility that if virt_to_phys(__get_free_pages())
      returned address above the 32bit boundary _and_ PCIEMSIAUR was programmed
      to 0x0 _and_ if the system had physical RAM at the address matching the
      value of PCIEMSIALR, a PCIe card driver could allocate a buffer with a
      physical address matching the value of PCIEMSIALR and a remote write to
      such a buffer by a PCIe card would trigger a spurious MSI.
      
      Fixes: e015f88c ("PCI: rcar: Add support for R-Car H3 to pcie-rcar")
      Signed-off-by: default avatarMarek Vasut <marek.vasut+renesas@gmail.com>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: Phil Edworthy <phil.edworthy@renesas.com>
      Cc: Simon Horman <horms+renesas@verge.net.au>
      Cc: Wolfram Sang <wsa@the-dreams.de>
      Cc: linux-renesas-soc@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e29094bf
    • Kangjie Lu's avatar
      PCI: rcar: Fix a potential NULL pointer dereference · d1ee5d2a
      Kangjie Lu authored
      [ Upstream commit f0d14edd ]
      
      In case __get_free_pages() fails and returns NULL, fix the return
      value to -ENOMEM and release resources to avoid dereferencing a
      NULL pointer.
      Signed-off-by: default avatarKangjie Lu <kjlu@umn.edu>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: default avatarUlrich Hecht <uli+renesas@fpond.eu>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d1ee5d2a
    • Kishon Vijay Abraham I's avatar
      PCI: dwc: Remove default MSI initialization for platform specific MSI chips · 4e15f6d7
      Kishon Vijay Abraham I authored
      [ Upstream commit fd8a44bd ]
      
      Platforms which populate msi_host_init() have their own MSI controller
      logic. Writing to MSI control registers on platforms which do not use
      Designware's MSI controller logic might have side effects.
      
      To be safe, do not write to MSI control registers if the platform uses
      its own MSI controller logic instead of Designware's MSI one.
      Signed-off-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      [lorenzo.pieralisi@arm.com: updated commit log]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4e15f6d7
    • Peng Li's avatar
      net: hns3: return 0 and print warning when hit duplicate MAC · 21bd6db4
      Peng Li authored
      [ Upstream commit 72110b56 ]
      
      When set 2 same MAC to different function of one port, IMP
      will return error as the later one may modify the origin one.
      This will cause bond fail for 2 VFs of one port.
      
      Driver just print warning and return 0 with this patch, so
      if set same MAC address, it will return 0 but do not really
      configure HW.
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      21bd6db4
    • Chao Yu's avatar
      f2fs: fix potential recursive call when enabling data_flush · dae43810
      Chao Yu authored
      [ Upstream commit 186857c5 ]
      
      As Hagbard Celine reported:
      
      Hi, this is a long standing bug that I've hit before on older kernels,
      but I was not able to get the syslog saved because of the nature of
      the bug. This time I had booted form a pen-drive, and was able to save
      the log to it's efi-partition.
      What i did to trigger it was to create a partition and format it f2fs,
      then mount it with options:
      "rw,relatime,lazytime,background_gc=on,disable_ext_identify,discard,heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,data_flush,extent_cache,mode=adaptive,active_logs=6,whint_mode=fs-based,alloc_mode=default,fsync_mode=strict".
      Then I unpacked a big .tar.xz to the partition (I used a
      gentoo-stage3-tarball as I was in process of installing Gentoo).
      
      Same options just without data_flush gives no problems.
      
      Mar 20 20:54:01 usbgentoo kernel: FAT-fs (nvme0n1p4): Volume was not
      properly unmounted. Some data may be corrupt. Please run fsck.
      Mar 20 21:05:23 usbgentoo kernel: kworker/dying (1588) used greatest
      stack depth: 12064 bytes left
      Mar 20 21:06:40 usbgentoo kernel: BUG: stack guard page was hit at
      00000000a4b0733c (stack is 0000000056016422..0000000096e7463f)
      Mar 20 21:06:40 usbgentoo kernel: kernel stack overflow
      
      ......
      
      Mar 20 21:06:40 usbgentoo kernel: Call Trace:
      Mar 20 21:06:40 usbgentoo kernel:  read_node_page+0x71/0xf0
      Mar 20 21:06:40 usbgentoo kernel:  ? xas_load+0x8/0x50
      Mar 20 21:06:40 usbgentoo kernel:  __get_node_page+0x73/0x2a0
      Mar 20 21:06:40 usbgentoo kernel:  f2fs_get_dnode_of_data+0x34e/0x580
      Mar 20 21:06:40 usbgentoo kernel:  f2fs_write_inline_data+0x5e/0x2a0
      Mar 20 21:06:40 usbgentoo kernel:  __write_data_page+0x421/0x690
      Mar 20 21:06:40 usbgentoo kernel:  f2fs_write_cache_pages+0x1cf/0x460
      Mar 20 21:06:40 usbgentoo kernel:  f2fs_write_data_pages+0x2b3/0x2e0
      Mar 20 21:06:40 usbgentoo kernel:  ? f2fs_inode_chksum_verify+0x1d/0xc0
      Mar 20 21:06:40 usbgentoo kernel:  ? read_node_page+0x71/0xf0
      Mar 20 21:06:40 usbgentoo kernel:  do_writepages+0x3c/0xd0
      Mar 20 21:06:40 usbgentoo kernel:  __filemap_fdatawrite_range+0x7c/0xb0
      Mar 20 21:06:40 usbgentoo kernel:  f2fs_sync_dirty_inodes+0xf2/0x200
      Mar 20 21:06:40 usbgentoo kernel:  f2fs_balance_fs_bg+0x2a3/0x2c0
      Mar 20 21:06:40 usbgentoo kernel:  ? f2fs_inode_dirtied+0x21/0xc0
      Mar 20 21:06:40 usbgentoo kernel:  f2fs_balance_fs+0xd6/0x2b0
      Mar 20 21:06:40 usbgentoo kernel:  __write_data_page+0x4fb/0x690
      
      ......
      
      Mar 20 21:06:40 usbgentoo kernel:  __writeback_single_inode+0x2a1/0x340
      Mar 20 21:06:40 usbgentoo kernel:  ? soft_cursor+0x1b4/0x220
      Mar 20 21:06:40 usbgentoo kernel:  writeback_sb_inodes+0x1d5/0x3e0
      Mar 20 21:06:40 usbgentoo kernel:  __writeback_inodes_wb+0x58/0xa0
      Mar 20 21:06:40 usbgentoo kernel:  wb_writeback+0x250/0x2e0
      Mar 20 21:06:40 usbgentoo kernel:  ? 0xffffffff8c000000
      Mar 20 21:06:40 usbgentoo kernel:  ? cpumask_next+0x16/0x20
      Mar 20 21:06:40 usbgentoo kernel:  wb_workfn+0x2f6/0x3b0
      Mar 20 21:06:40 usbgentoo kernel:  ? __switch_to_asm+0x40/0x70
      Mar 20 21:06:40 usbgentoo kernel:  process_one_work+0x1f5/0x3f0
      Mar 20 21:06:40 usbgentoo kernel:  worker_thread+0x28/0x3c0
      Mar 20 21:06:40 usbgentoo kernel:  ? rescuer_thread+0x330/0x330
      Mar 20 21:06:40 usbgentoo kernel:  kthread+0x10e/0x130
      Mar 20 21:06:40 usbgentoo kernel:  ? kthread_create_on_node+0x60/0x60
      Mar 20 21:06:40 usbgentoo kernel:  ret_from_fork+0x35/0x40
      
      The root cause is that we run into an infinite recursive calling in
      between f2fs_balance_fs_bg and writepage() as described below:
      
      - f2fs_write_data_pages		--- A
       - __write_data_page
        - f2fs_balance_fs
         - f2fs_balance_fs_bg		--- B
          - f2fs_sync_dirty_inodes
           - filemap_fdatawrite
            - f2fs_write_data_pages	--- A
      ...
                - f2fs_balance_fs_bg	--- B
      ...
      
      In order to fix this issue, let's detect such condition in __write_data_page()
      and just skip calling f2fs_balance_fs() recursively.
      Reported-by: default avatarHagbard Celine <hagbardcelin@gmail.com>
      Signed-off-by: default avatarChao Yu <yuchao0@huawei.com>
      Signed-off-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      dae43810
    • Sven Van Asbroeck's avatar
      power: supply: max14656: fix potential use-before-alloc · 95b1b9a1
      Sven Van Asbroeck authored
      [ Upstream commit 0cd0e497 ]
      
      Call order on probe():
      - max14656_hw_init() enables interrupts on the chip
      - devm_request_irq() starts processing interrupts, isr
        could be called immediately
      -    isr: schedules delayed work (irq_work)
      -    irq_work: calls power_supply_changed()
      - devm_power_supply_register() registers the power supply
      
      Depending on timing, it's possible that power_supply_changed()
      is called on an unregistered power supply structure.
      
      Fix by registering the power supply before requesting the irq.
      
      Cc: Alexander Kurz <akurz@blala.de>
      Signed-off-by: default avatarSven Van Asbroeck <TheSven73@gmail.com>
      Signed-off-by: default avatarSebastian Reichel <sebastian.reichel@collabora.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      95b1b9a1
    • Junxiao Chang's avatar
      platform/x86: intel_pmc_ipc: adding error handling · 93e97bcf
      Junxiao Chang authored
      [ Upstream commit e61985d0 ]
      
      If punit or telemetry device initialization fails, pmc driver should
      unregister and return failure.
      
      This change is to fix a kernel panic when removing kernel module
      intel_pmc_ipc.
      
      Fixes: 48c19170 ("platform:x86: Add Intel telemetry platform device")
      Signed-off-by: default avatarJunxiao Chang <junxiao.chang@intel.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      93e97bcf
    • Binbin Wu's avatar
      pinctrl: pinctrl-intel: move gpio suspend/resume to noirq phase · db5d63c1
      Binbin Wu authored
      [ Upstream commit 2fef3276 ]
      
      In current driver, SET_LATE_SYSTEM_SLEEP_PM_OPS is used to install the
      callbacks for suspend/resume.
      GPIO pin may be used as the interrupt pin by some device. However, using
      SET_LATE_SYSTEM_SLEEP_PM_OPS() to install the callbacks, the resume
      callback is called after resume_device_irqs(). Unintended interrupts may
      arrive due to resuming device irqs first, but the GPIO controller is not
      properly restored.
      
      Normally, for a SMP system, there are multiple cores, so even when there are
      unintended interrupts, BSP gets the chance to initialize the GPIO chip soon.
      But when there is only 1 core is active (other cores are offlined or
      single core) during resume, it is more easily to observe the unintended
      interrupts.
      
      This patch renames the suspend/resume function by adding suffix "_noirq",
      and installs the callbacks using SET_NOIRQ_SYSTEM_SLEEP_PM_OPS().
      Signed-off-by: default avatarBinbin Wu <binbin.wu@intel.com>
      Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      db5d63c1
    • Kabir Sahane's avatar
      ARM: OMAP2+: pm33xx-core: Do not Turn OFF CEFUSE as PPA may be using it · 8274eb86
      Kabir Sahane authored
      [ Upstream commit 72aff4ec ]
      
      This area is used to store keys by HSPPA in case of AM438x SOC. Leave it
      active.
      Signed-off-by: default avatarKabir Sahane <x0153567@ti.com>
      Signed-off-by: default avatarAndrew F. Davis <afd@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8274eb86
    • Nicholas Kazlauskas's avatar
      drm/amd/display: Use plane->color_space for dpp if specified · f02b8f4d
      Nicholas Kazlauskas authored
      [ Upstream commit a1e07ba8 ]
      
      [Why]
      The input color space for the plane was previously ignored even if it
      was set.
      
      If a limited range YUV format was given to DC then the
      wrong color transformation matrix was being used since DC assumed that
      it was full range instead.
      
      [How]
      Respect the given color_space format for the plane if it isn't
      COLOR_SPACE_UNKNOWN. Otherwise, use the implicit default since DM
      didn't specify.
      Signed-off-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: default avatarSun peng Li <Sunpeng.Li@amd.com>
      Acked-by: default avatarAric Cyr <Aric.Cyr@amd.com>
      Acked-by: default avatarLeo Li <sunpeng.li@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f02b8f4d
    • Anthony Koo's avatar
      drm/amd/display: disable link before changing link settings · cac1f3c2
      Anthony Koo authored
      [ Upstream commit 15ae3b28 ]
      
      [Why]
      If link is already enabled at a different rate (for example 5.4 Gbps)
      then calling VBIOS command table to switch to a new rate
      (for example 2.7 Gbps) will not take effect.
      This can lead to link training failure to occur.
      
      [How]
      If the requested link rate is different than the current link rate,
      the link must be disabled in order to re-enable at the new
      link rate.
      
      In today's logic it is currently only impacting eDP since DP
      connection types will always disable the link during display
      detection, when initial link verification occurs.
      Signed-off-by: default avatarAnthony Koo <Anthony.Koo@amd.com>
      Reviewed-by: default avatarAric Cyr <Aric.Cyr@amd.com>
      Acked-by: default avatarLeo Li <sunpeng.li@amd.com>
      Acked-by: default avatarTony Cheng <Tony.Cheng@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cac1f3c2
    • Tyrel Datwyler's avatar
      PCI: rpadlpar: Fix leaked device_node references in add/remove paths · 9ed244b1
      Tyrel Datwyler authored
      [ Upstream commit fb26228b ]
      
      The find_dlpar_node() helper returns a device node with its reference
      incremented.  Both the add and remove paths use this helper for find the
      appropriate node, but fail to release the reference when done.
      
      Annotate the find_dlpar_node() helper with a comment about the incremented
      reference count and call of_node_put() on the obtained device_node in the
      add and remove paths.  Also, fixup a reference leak in the find_vio_slot()
      helper where we fail to call of_node_put() on the vdevice node after we
      iterate over its children.
      Signed-off-by: default avatarTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9ed244b1
    • Andrey Smirnov's avatar
      ARM: dts: imx6qdl: Specify IMX6QDL_CLK_IPG as "ipg" clock to SDMA · 09c9989c
      Andrey Smirnov authored
      [ Upstream commit b14c872e ]
      
      Since 25aaa75d 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 IMX6QDL_CLK_SDMA results in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality(this at least
      breaks RAVE SP serdev driver on RDU2). Fix the code to specify
      IMX6QDL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect
      clock ratio.
      Signed-off-by: default avatarAndrey Smirnov <andrew.smirnov@gmail.com>
      Reviewed-by: default avatarLucas Stach <l.stach@pengutronix.de>
      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
      Tested-by: default avatarAdam Ford <aford173@gmail.com>
      Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      09c9989c
    • Andrey Smirnov's avatar
      ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ipg" clock to SDMA · afac6100
      Andrey Smirnov authored
      [ Upstream commit 89791177 ]
      
      Since 25aaa75d 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 IMX6SX_CLK_SDMA results in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality. Fix the code
      to specify IMX6SX_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
      incorrect clock ratio.
      Signed-off-by: default avatarAndrey 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: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      afac6100
    • Andrey Smirnov's avatar
      ARM: dts: imx6ul: Specify IMX6UL_CLK_IPG as "ipg" clock to SDMA · af792fef
      Andrey Smirnov authored
      [ Upstream commit 7b3132ec ]
      
      Since 25aaa75d 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 IMX6UL_CLK_SDMA results in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality. Fix the code
      to specify IMX6UL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
      incorrect clock ratio.
      Signed-off-by: default avatarAndrey 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: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      af792fef
    • Andrey Smirnov's avatar
      ARM: dts: imx7d: Specify IMX7D_CLK_IPG as "ipg" clock to SDMA · 9edec202
      Andrey Smirnov authored
      [ Upstream commit 412b032a ]
      
      Since 25aaa75d 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: default avatarAndrey 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: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      9edec202
    • Andrey Smirnov's avatar
      ARM: dts: imx6sll: Specify IMX6SLL_CLK_IPG as "ipg" clock to SDMA · ad63ba19
      Andrey Smirnov authored
      [ Upstream commit c5ed5daa ]
      
      Since 25aaa75d 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: default avatarAndrey 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: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ad63ba19
    • Andrey Smirnov's avatar
      ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ahb" clock to SDMA · 949b328b
      Andrey Smirnov authored
      [ Upstream commit cc839d0f ]
      
      Since 25aaa75d 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: default avatarAndrey 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: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      949b328b
    • Andrey Smirnov's avatar
      ARM: dts: imx53: Specify IMX5_CLK_IPG as "ahb" clock to SDMA · 360d0b29
      Andrey Smirnov authored
      [ Upstream commit 28c16801 ]
      
      Since 25aaa75d 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: default avatarAndrey 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: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      360d0b29
    • Andrey Smirnov's avatar
      ARM: dts: imx50: Specify IMX5_CLK_IPG as "ahb" clock to SDMA · cc6fa2bd
      Andrey Smirnov authored
      [ Upstream commit b7b4fda2 ]
      
      Since 25aaa75d 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: default avatarAndrey 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: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cc6fa2bd