1. 17 Jun, 2019 3 commits
  2. 15 Jun, 2019 37 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.19.51 · 7aa823a9
      Greg Kroah-Hartman authored
      7aa823a9
    • Takashi Iwai's avatar
      ALSA: seq: Cover unsubscribe_port() in list_mutex · b323914c
      Takashi Iwai authored
      commit 7c32ae35 upstream.
      
      The call of unsubscribe_port() which manages the group count and
      module refcount from delete_and_unsubscribe_port() looks racy; it's
      not covered by the group list lock, and it's likely a cause of the
      reported unbalance at port deletion.  Let's move the call inside the
      group list_mutex to plug the hole.
      
      Reported-by: syzbot+e4c8abb920efa77bace9@syzkaller.appspotmail.com
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b323914c
    • Helen Koike's avatar
      drm/vc4: fix fb references in async update · 3af96f34
      Helen Koike authored
      commit c16b8555 upstream.
      
      Async update callbacks are expected to set the old_fb in the new_state
      so prepare/cleanup framebuffers are balanced.
      
      Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
      fb and put the old fb) is not required, as it's taken care by
      drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane().
      
      Cc: <stable@vger.kernel.org> # v4.19+
      Fixes: 539c320b ("drm/vc4: update cursors asynchronously through atomic")
      Suggested-by: default avatarBoris Brezillon <boris.brezillon@collabora.com>
      Signed-off-by: default avatarHelen Koike <helen.koike@collabora.com>
      Reviewed-by: default avatarBoris Brezillon <boris.brezillon@collabora.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@collabora.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-5-helen.koike@collabora.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3af96f34
    • Amir Goldstein's avatar
      ovl: support stacked SEEK_HOLE/SEEK_DATA · afec7068
      Amir Goldstein authored
      commit 9e46b840 upstream.
      
      Overlay file f_pos is the master copy that is preserved
      through copy up and modified on read/write, but only real
      fs knows how to SEEK_HOLE/SEEK_DATA and real fs may impose
      limitations that are more strict than ->s_maxbytes for specific
      files, so we use the real file to perform seeks.
      
      We do not call real fs for SEEK_CUR:0 query and for SEEK_SET:0
      requests.
      
      Fixes: d1d04ef8 ("ovl: stack file ops")
      Reported-by: default avatarEddie Horng <eddiehorng.tw@gmail.com>
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      afec7068
    • Jiufei Xue's avatar
      ovl: check the capability before cred overridden · 22dac6cc
      Jiufei Xue authored
      commit 98487de3 upstream.
      
      We found that it return success when we set IMMUTABLE_FL flag to a file in
      docker even though the docker didn't have the capability
      CAP_LINUX_IMMUTABLE.
      
      The commit d1d04ef8 ("ovl: stack file ops") and dab5ca8f ("ovl: add
      lsattr/chattr support") implemented chattr operations on a regular overlay
      file. ovl_real_ioctl() overridden the current process's subjective
      credentials with ofs->creator_cred which have the capability
      CAP_LINUX_IMMUTABLE so that it will return success in
      vfs_ioctl()->cap_capable().
      
      Fix this by checking the capability before cred overridden. And here we
      only care about APPEND_FL and IMMUTABLE_FL, so get these information from
      inode.
      
      [SzM: move check and call to underlying fs inside inode locked region to
      prevent two such calls from racing with each other]
      Signed-off-by: default avatarJiufei Xue <jiufei.xue@linux.alibaba.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Cc: Amir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22dac6cc
    • Greg Kroah-Hartman's avatar
      Revert "drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)" · b616b9db
      Greg Kroah-Hartman authored
      This reverts commit 61038233 which is
      commit b30a43ac upstream.
      
      Sven reports:
      	Commit 1e07d637 ("drm/nouveau: add kconfig option to turn off nouveau
      	legacy contexts. (v3)") has caused a build failure for me when I
      	actually tried that option (CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n):
      
      	,----
      	| Kernel: arch/x86/boot/bzImage is ready  (#1)
      	|   Building modules, stage 2.
      	|   MODPOST 290 modules
      	| ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
      	| scripts/Makefile.modpost:91: recipe for target '__modpost' failed
      	`----
      
      	Upstream does not have that problem, as commit bed2dd84 ("drm/ttm:
      	Quick-test mmap offset in ttm_bo_mmap()") has removed the use of
      	drm_legacy_mmap from nouveau_ttm.c.  Unfortunately that commit does not
      	apply in 5.1.9.
      
      The ensuing discussion proposed a number of one-off patches, but no
      solid agreement was made, so just revert the commit for now to get
      people's systems building again.
      Reported-by: default avatarSven Joachim <svenjoac@gmx.de>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Thomas Backlund <tmb@mageia.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b616b9db
    • Greg Kroah-Hartman's avatar
      Revert "Bluetooth: Align minimum encryption key size for LE and BR/EDR connections" · 8e5483ae
      Greg Kroah-Hartman authored
      This reverts commit 38f092c4 which is
      commit d5bb334a upstream.
      
      Lots of people have reported issues with this patch, and as there does
      not seem to be a fix going into Linus's kernel tree any time soon,
      revert the commit in the stable trees so as to get people's machines
      working properly again.
      Reported-by: default avatarVasily Khoruzhick <anarsoul@gmail.com>
      Reported-by: default avatarHans de Goede <hdegoede@redhat.com>
      Cc: Jeremy Cline <jeremy@jcline.org>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: Johan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e5483ae
    • Dennis Zhou's avatar
      percpu: do not search past bitmap when allocating an area · 526972e9
      Dennis Zhou authored
      [ Upstream commit 8c43004a ]
      
      pcpu_find_block_fit() guarantees that a fit is found within
      PCPU_BITMAP_BLOCK_BITS. Iteration is used to determine the first fit as
      it compares against the block's contig_hint. This can lead to
      incorrectly scanning past the end of the bitmap. The behavior was okay
      given the check after for bit_off >= end and the correctness of the
      hints from pcpu_find_block_fit().
      
      This patch fixes this by bounding the end offset by the number of bits
      in a chunk.
      Signed-off-by: default avatarDennis Zhou <dennis@kernel.org>
      Reviewed-by: default avatarPeng Fan <peng.fan@nxp.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      526972e9
    • Andrey Smirnov's avatar
      gpio: vf610: Do not share irq_chip · d4d5dce6
      Andrey Smirnov authored
      [ Upstream commit 338aa107 ]
      
      Fix the warning produced by gpiochip_set_irq_hooks() by allocating a
      dedicated IRQ chip per GPIO chip/port.
      Signed-off-by: default avatarAndrey Smirnov <andrew.smirnov@gmail.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Cc: Fabio Estevam <festevam@gmail.com>
      Cc: linux-gpio@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-imx@nxp.com
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      d4d5dce6
    • Takeshi Kihara's avatar
      soc: renesas: Identify R-Car M3-W ES1.3 · 28229df6
      Takeshi Kihara authored
      [ Upstream commit 15160f6d ]
      
      The Product Register of R-Car M3-W ES1.3 incorrectly identifies the SoC
      revision as ES2.1. Add a workaround to fix this.
      Signed-off-by: default avatarTakeshi Kihara <takeshi.kihara.df@renesas.com>
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      28229df6
    • Hans de Goede's avatar
      usb: typec: fusb302: Check vconn is off when we start toggling · db54e08c
      Hans de Goede authored
      [ Upstream commit 32a155b1 ]
      
      The datasheet says the vconn MUST be off when we start toggling. The
      tcpm.c state-machine is responsible to make sure vconn is off, but lets
      add a WARN to catch any cases where vconn is not off for some reason.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      db54e08c
    • Marek Szyprowski's avatar
      ARM: exynos: Fix undefined instruction during Exynos5422 resume · ce183fad
      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>
      ce183fad
    • Phong Hoang's avatar
      pwm: Fix deadlock warning when removing PWM device · 384642ff
      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>
      384642ff
    • Krzysztof Kozlowski's avatar
      ARM: dts: exynos: Always enable necessary APIO_1V8 and ABB_1V8 regulators on Arndale Octa · 7905b233
      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>
      7905b233
    • Christoph Vogtländer's avatar
      pwm: tiehrpwm: Update shadow register for disabling PWMs · 78002e38
      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>
      78002e38
    • Andy Shevchenko's avatar
      dmaengine: idma64: Use actual device for DMA transfers · 9fdcb04e
      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>
      9fdcb04e
    • Brett Creeley's avatar
      ice: Add missing case in print_link_msg for printing flow control · da00c89f
      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>
      da00c89f
    • Tony Lindgren's avatar
      gpio: gpio-omap: add check for off wake capable gpios · 456e3563
      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>
      456e3563
    • Kangjie Lu's avatar
      PCI: xilinx: Check for __get_free_pages() failure · 47d281bb
      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>
      47d281bb
    • Paolo Valente's avatar
      block, bfq: increase idling for weight-raised queues · b5a185ee
      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>
      b5a185ee
    • Kangjie Lu's avatar
      video: imsttfb: fix potential NULL pointer dereferences · e06d7a92
      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>
      e06d7a92
    • Kangjie Lu's avatar
      video: hgafb: fix potential NULL pointer dereference · 1f2611af
      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>
      1f2611af
    • Giridhar Malavali's avatar
      scsi: qla2xxx: Reset the FCF_ASYNC_{SENT|ACTIVE} flags · 5957f6f5
      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>
      5957f6f5
    • Marek Vasut's avatar
      PCI: rcar: Fix 64bit MSI message address handling · c2c7b6fe
      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>
      c2c7b6fe
    • Kangjie Lu's avatar
      PCI: rcar: Fix a potential NULL pointer dereference · dd54e70c
      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>
      dd54e70c
    • Peng Li's avatar
      net: hns3: return 0 and print warning when hit duplicate MAC · 272f8c3d
      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>
      272f8c3d
    • Sven Van Asbroeck's avatar
      power: supply: max14656: fix potential use-before-alloc · 5a286ced
      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>
      5a286ced
    • Junxiao Chang's avatar
      platform/x86: intel_pmc_ipc: adding error handling · 901daed2
      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>
      901daed2
    • Kabir Sahane's avatar
      ARM: OMAP2+: pm33xx-core: Do not Turn OFF CEFUSE as PPA may be using it · 613752b3
      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>
      613752b3
    • Nicholas Kazlauskas's avatar
      drm/amd/display: Use plane->color_space for dpp if specified · 668440f6
      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>
      668440f6
    • Tyrel Datwyler's avatar
      PCI: rpadlpar: Fix leaked device_node references in add/remove paths · 671fc900
      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>
      671fc900
    • Andrey Smirnov's avatar
      ARM: dts: imx6qdl: Specify IMX6QDL_CLK_IPG as "ipg" clock to SDMA · b531acbd
      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>
      b531acbd
    • Andrey Smirnov's avatar
      ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ipg" clock to SDMA · 584cabc6
      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>
      584cabc6
    • Andrey Smirnov's avatar
      ARM: dts: imx6ul: Specify IMX6UL_CLK_IPG as "ipg" clock to SDMA · 02936545
      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>
      02936545
    • Andrey Smirnov's avatar
      ARM: dts: imx7d: Specify IMX7D_CLK_IPG as "ipg" clock to SDMA · 36a7fda0
      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>
      36a7fda0
    • Andrey Smirnov's avatar
      ARM: dts: imx6sll: Specify IMX6SLL_CLK_IPG as "ipg" clock to SDMA · c84911bb
      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>
      c84911bb
    • Andrey Smirnov's avatar
      ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ahb" clock to SDMA · a2e661f9
      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>
      a2e661f9