1. 19 6月, 2019 19 次提交
  2. 18 6月, 2019 5 次提交
  3. 15 6月, 2019 16 次提交
    • G
      Linux 4.19.51 · 7aa823a9
      Greg Kroah-Hartman 提交于
      7aa823a9
    • T
      ALSA: seq: Cover unsubscribe_port() in list_mutex · b323914c
      Takashi Iwai 提交于
      commit 7c32ae35fbf9cffb7aa3736f44dec10c944ca18e 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: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b323914c
    • H
      drm/vc4: fix fb references in async update · 3af96f34
      Helen Koike 提交于
      commit c16b85559dcfb5a348cc085a7b4c75ed49b05e2c 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: NBoris Brezillon <boris.brezillon@collabora.com>
      Signed-off-by: NHelen Koike <helen.koike@collabora.com>
      Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@collabora.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-5-helen.koike@collabora.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3af96f34
    • A
      ovl: support stacked SEEK_HOLE/SEEK_DATA · afec7068
      Amir Goldstein 提交于
      commit 9e46b840c7053b5f7a245e98cd239b60d189a96c 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: NEddie Horng <eddiehorng.tw@gmail.com>
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      afec7068
    • J
      ovl: check the capability before cred overridden · 22dac6cc
      Jiufei Xue 提交于
      commit 98487de318a6f33312471ae1e2afa16fbf8361fe 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: NJiufei Xue <jiufei.xue@linux.alibaba.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Cc: Amir Goldstein <amir73il@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22dac6cc
    • G
      Revert "drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)" · b616b9db
      Greg Kroah-Hartman 提交于
      This reverts commit 61038233 which is
      commit b30a43ac7132cdda833ac4b13dd1ebd35ace14b7 upstream.
      
      Sven reports:
      	Commit 1e07d63749 ("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 bed2dd8421 ("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: NSven 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: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b616b9db
    • G
      Revert "Bluetooth: Align minimum encryption key size for LE and BR/EDR connections" · 8e5483ae
      Greg Kroah-Hartman 提交于
      This reverts commit 38f092c4 which is
      commit d5bb334a8e171b262e48f378bd2096c0ea458265 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: NVasily Khoruzhick <anarsoul@gmail.com>
      Reported-by: NHans 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: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e5483ae
    • D
      percpu: do not search past bitmap when allocating an area · 526972e9
      Dennis Zhou 提交于
      [ Upstream commit 8c43004af01635cc9fbb11031d070e5e0d327ef2 ]
      
      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: NDennis Zhou <dennis@kernel.org>
      Reviewed-by: NPeng Fan <peng.fan@nxp.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      526972e9
    • A
      gpio: vf610: Do not share irq_chip · d4d5dce6
      Andrey Smirnov 提交于
      [ Upstream commit 338aa10750ba24d04beeaf5dc5efc032e5cf343f ]
      
      Fix the warning produced by gpiochip_set_irq_hooks() by allocating a
      dedicated IRQ chip per GPIO chip/port.
      Signed-off-by: NAndrey 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: NBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d4d5dce6
    • T
      soc: renesas: Identify R-Car M3-W ES1.3 · 28229df6
      Takeshi Kihara 提交于
      [ Upstream commit 15160f6de0bba712fcea078c5ac7571fe33fcd5d ]
      
      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: NTakeshi Kihara <takeshi.kihara.df@renesas.com>
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      28229df6
    • H
      usb: typec: fusb302: Check vconn is off when we start toggling · db54e08c
      Hans de Goede 提交于
      [ Upstream commit 32a155b1a83d6659e2272e8e1eec199667b1897e ]
      
      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: NHans de Goede <hdegoede@redhat.com>
      Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      db54e08c
    • M
      ARM: exynos: Fix undefined instruction during Exynos5422 resume · ce183fad
      Marek Szyprowski 提交于
      [ Upstream commit 4d8e3e951a856777720272ce27f2c738a3eeef8c ]
      
      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: NMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ce183fad
    • P
      pwm: Fix deadlock warning when removing PWM device · 384642ff
      Phong Hoang 提交于
      [ Upstream commit 347ab9480313737c0f1aaa08e8f2e1a791235535 ]
      
      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: NPhong 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: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Tested-by: NHoan Nguyen An <na-hoan@jinso.co.jp>
      Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
      Reviewed-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: NThierry Reding <thierry.reding@gmail.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      384642ff
    • K
      ARM: dts: exynos: Always enable necessary APIO_1V8 and ABB_1V8 regulators on Arndale Octa · 7905b233
      Krzysztof Kozlowski 提交于
      [ Upstream commit 5ab99cf7d5e96e3b727c30e7a8524c976bd3723d ]
      
      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: NKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7905b233
    • C
      pwm: tiehrpwm: Update shadow register for disabling PWMs · 78002e38
      Christoph Vogtländer 提交于
      [ Upstream commit b00ef53053191d3025c15e8041699f8c9d132daf ]
      
      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: NChristoph Vogtländer <c.vogtlaender@sigma-surface-science.com>
      [vigneshr@ti.com: Improve commit message]
      Signed-off-by: NVignesh Raghavendra <vigneshr@ti.com>
      Signed-off-by: NThierry Reding <thierry.reding@gmail.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      78002e38
    • A
      dmaengine: idma64: Use actual device for DMA transfers · 9fdcb04e
      Andy Shevchenko 提交于
      [ Upstream commit 5ba846b1ee0792f5a596b9b0b86d6e8cdebfab06 ]
      
      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: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: NMark Brown <broonie@kernel.org>
      Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [for tty parts]
      Signed-off-by: NVinod Koul <vkoul@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9fdcb04e