1. 19 Jun, 2019 17 commits
  2. 17 Jun, 2019 5 commits
  3. 15 Jun, 2019 18 commits
    • Greg Kroah-Hartman's avatar
      Linux 5.1.10 · 7e1bdd68
      Greg Kroah-Hartman authored
      7e1bdd68
    • Jens Axboe's avatar
      io_uring: fix failure to verify SQ_AFF cpu · cf1fa8c9
      Jens Axboe authored
      commit 44a9bd18 upstream.
      
      The test case we have is rightfully failing with the current kernel:
      
      io_uring_setup(1, 0x7ffe2cafebe0), flags: IORING_SETUP_SQPOLL|IORING_SETUP_SQ_AFF, resv: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000, sq_thread_cpu: 4
      expected -1, got 3
      
      This is in a vm, and CPU3 is the last valid one, hence asking for 4
      should fail the setup with -EINVAL, not succeed. The problem is that
      we're using array_index_nospec() with nr_cpu_ids as the index, hence we
      wrap and end up using CPU0 instead of CPU4. This makes the setup
      succeed where it should be failing.
      
      We don't need to use array_index_nospec() as we're not indexing any
      array with this. Instead just compare with nr_cpu_ids directly. This
      is fine as we're checking with cpu_online() afterwards.
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cf1fa8c9
    • Takashi Iwai's avatar
      ALSA: seq: Cover unsubscribe_port() in list_mutex · bc9dcb27
      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>
      bc9dcb27
    • Amir Goldstein's avatar
      ovl: support stacked SEEK_HOLE/SEEK_DATA · f40c32fd
      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>
      f40c32fd
    • Jiufei Xue's avatar
      ovl: check the capability before cred overridden · 289e5e05
      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>
      289e5e05
    • Greg Kroah-Hartman's avatar
      Revert "drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)" · e73b09c7
      Greg Kroah-Hartman authored
      This reverts commit 1e07d637 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>
      e73b09c7
    • Greg Kroah-Hartman's avatar
      Revert "Bluetooth: Align minimum encryption key size for LE and BR/EDR connections" · b528880e
      Greg Kroah-Hartman authored
      This reverts commit 07e38998 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>
      b528880e
    • Dennis Zhou's avatar
      percpu: do not search past bitmap when allocating an area · 6a5abd6b
      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>
      6a5abd6b
    • Andrey Smirnov's avatar
      gpio: vf610: Do not share irq_chip · e92c1e9a
      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>
      e92c1e9a
    • Marek Vasut's avatar
      ARM: shmobile: porter: enable R-Car Gen2 regulator quirk · 718910bf
      Marek Vasut authored
      [ Upstream commit d5aa8408 ]
      
      Porter needs the regulator quirk, just like the other boards.
      But unlike the other boards, the Porter uses DA9063L, which
      is at 0x5a. Otherwise, DA9063L and DA9210 IRQ line is still
      connected to CPU IRQ2 .
      Signed-off-by: default avatarMarek Vasut <marek.vasut+renesas@gmail.com>
      Acked-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Reviewed-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>
      718910bf
    • Takeshi Kihara's avatar
      soc: renesas: Identify R-Car M3-W ES1.3 · 183e82c6
      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>
      183e82c6
    • Hans de Goede's avatar
      usb: typec: fusb302: Check vconn is off when we start toggling · e5f2c46c
      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>
      e5f2c46c
    • 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