1. 19 6月, 2019 7 次提交
    • J
      HID: wacom: Correct button numbering 2nd-gen Intuos Pro over Bluetooth · dd1d71ad
      Jason Gerecke 提交于
      commit 6441fc781c344df61402be1fde582c4491fa35fa upstream.
      
      The button numbering of the 2nd-gen Intuos Pro is not consistent between
      the USB and Bluetooth interfaces. Over USB, the HID_GENERIC codepath
      enumerates the eight ExpressKeys first (BTN_0 - BTN_7) followed by the
      center modeswitch button (BTN_8). The Bluetooth codepath, however, has
      the center modeswitch button as BTN_0 and the the eight ExpressKeys as
      BTN_1 - BTN_8. To ensure userspace button mappings do not change
      depending on how the tablet is connected, modify the Bluetooth codepath
      to report buttons in the same order as USB.
      
      To ensure the mode switch LED continues to toggle in response to the
      mode switch button, the `wacom_is_led_toggled` function also requires
      a small update.
      
      Link: https://github.com/linuxwacom/input-wacom/pull/79
      Fixes: 4922cd26 ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
      Cc: <stable@vger.kernel.org> # 4.11+
      Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: NAaron Skomra <aaron.skomra@wacom.com>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dd1d71ad
    • J
      HID: wacom: Send BTN_TOUCH in response to INTUOSP2_BT eraser contact · 52901353
      Jason Gerecke 提交于
      commit fe7f8d73d1af19b678171170e4e5384deb57833d upstream.
      
      The Bluetooth reports from the 2nd-gen Intuos Pro have separate bits for
      indicating if the tip or eraser is in contact with the tablet. At the
      moment, only the tip contact bit controls the state of the BTN_TOUCH
      event. This prevents the eraser from working as expected. This commit
      changes the driver to send BTN_TOUCH whenever either the tip or eraser
      contact bit is set.
      
      Fixes: 4922cd26 ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
      Cc: <stable@vger.kernel.org> # 4.11+
      Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: NAaron Skomra <aaron.skomra@wacom.com>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      52901353
    • J
      HID: wacom: Don't report anything prior to the tool entering range · 3e9c0eb1
      Jason Gerecke 提交于
      commit e92a7be7fe5b2510fa60965eaf25f9e3dc08b8cc upstream.
      
      If the tool spends some time in prox before entering range, a series of
      events (e.g. ABS_DISTANCE, MSC_SERIAL) can be sent before we or userspace
      have any clue about the pen whose data is being reported. We need to hold
      off on reporting anything until the pen has entered range. Since we still
      want to report events that occur "in prox" after the pen has *left* range
      we use 'wacom-tool[0]' as the indicator that the pen did at one point
      enter range and provide us/userspace with tool type and serial number
      information.
      
      Fixes: a48324de ("HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range")
      Cc: <stable@vger.kernel.org> # 4.11+
      Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: NAaron Armstrong Skomra <aaron.skomra@wacom.com>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e9c0eb1
    • J
      HID: wacom: Don't set tool type until we're in range · 52a7d604
      Jason Gerecke 提交于
      commit 2cc08800a6b9fcda7c7afbcf2da1a6e8808da725 upstream.
      
      The serial number and tool type information that is reported by the tablet
      while a pen is merely "in prox" instead of fully "in range" can be stale
      and cause us to report incorrect tool information. Serial number, tool
      type, and other information is only valid once the pen comes fully in range
      so we should be careful to not use this information until that point.
      
      In particular, this issue may cause the driver to incorectly report
      BTN_TOOL_RUBBER after switching from the eraser tool back to the pen.
      
      Fixes: a48324de ("HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range")
      Cc: <stable@vger.kernel.org> # 4.11+
      Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: NAaron Armstrong Skomra <aaron.skomra@wacom.com>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      52a7d604
    • B
      HID: multitouch: handle faulty Elo touch device · fa212dd5
      Benjamin Tissoires 提交于
      commit 81bcbad53bab4bf9f200eda303d7a05cdb9bd73b upstream.
      
      Since kernel v5.0, one single win8 touchscreen device failed.
      And it turns out this is because it reports 2 InRange usage per touch.
      
      It's a first, and I *really* wonder how this was allowed by Microsoft in
      the first place. But IIRC, Breno told me this happened *after* a firmware
      upgrade...
      
      Anyway, better be safe for those crappy devices, and make sure we have
      a full slot before jumping to the next.
      This won't prevent all crappy devices to fail here, but at least we will
      have a safeguard as long as the contact ID and the X and Y coordinates
      are placed in the report after the grabage.
      
      Fixes: 01eaac7e ("HID: multitouch: remove one copy of values")
      CC: stable@vger.kernel.org # v5.0+
      Reported-and-tested-by: NBreno Leitao <leitao@debian.org>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fa212dd5
    • T
      nouveau: Fix build with CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT disabled · 9ae306d8
      Thomas Backlund 提交于
      Not-entirely-upstream-sha1-but-equivalent: bed2dd8421
      ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()")
      
      Setting CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n (added by commit: b30a43ac7132)
      causes the build to fail with:
      
      ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
      
      This does not happend upstream as the offending code got removed in:
      bed2dd8421 ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()")
      
      Fix that by adding check for CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT around
      the drm_legacy_mmap() call.
      
      Also, as Sven Joachim pointed out, we need to make the check in
      CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n case return -EINVAL as its done
      for basically all other gpu drivers, especially in upstream kernels
      drivers/gpu/drm/ttm/ttm_bo_vm.c as of the upstream commit bed2dd8421.
      
      NOTE. This is a minimal stable-only fix for trees where b30a43ac7132 is
      backported as the build error affects nouveau only.
      
      Fixes: b30a43ac7132 ("drm/nouveau: add kconfig option to turn off nouveau
             legacy contexts. (v3)")
      Signed-off-by: NThomas Backlund <tmb@mageia.org>
      Cc: stable@vger.kernel.org
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Sven Joachim <svenjoac@gmx.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9ae306d8
    • D
      drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3) · d54e1b84
      Dave Airlie 提交于
      commit b30a43ac7132cdda833ac4b13dd1ebd35ace14b7 upstream.
      
      There was a nouveau DDX that relied on legacy context ioctls to work,
      but we fixed it years ago, give distros that have a modern DDX the
      option to break the uAPI and close the mess of holes that legacy
      context support is.
      
      Full context of the story:
      
      commit 0e975980
      Author: Peter Antoine <peter.antoine@intel.com>
      Date:   Tue Jun 23 08:18:49 2015 +0100
      
          drm: Turn off Legacy Context Functions
      
          The context functions are not used by the i915 driver and should not
          be used by modeset drivers. These driver functions contain several bugs
          and security holes. This change makes these functions optional can be
          turned on by a setting, they are turned off by default for modeset
          driver with the exception of the nouvea driver that may require them with
          an old version of libdrm.
      
          The previous attempt was
      
          commit 7c510133
          Author: Daniel Vetter <daniel.vetter@ffwll.ch>
          Date:   Thu Aug 8 15:41:21 2013 +0200
      
              drm: mark context support as a legacy subsystem
      
          but this had to be reverted
      
          commit c21eb21c
          Author: Dave Airlie <airlied@redhat.com>
          Date:   Fri Sep 20 08:32:59 2013 +1000
      
              Revert "drm: mark context support as a legacy subsystem"
      
          v2: remove returns from void function, and formatting (Daniel Vetter)
      
          v3:
          - s/Nova/nouveau/ in the commit message, and add references to the
            previous attempts
          - drop the part touching the drm hw lock, that should be a separate
            patch.
      
          Signed-off-by: Peter Antoine <peter.antoine@intel.com> (v2)
          Cc: Peter Antoine <peter.antoine@intel.com> (v2)
      Reviewed-by: NPeter Antoine <peter.antoine@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      
      v2: move DRM_VM dependency into legacy config.
      v3: fix missing dep (kbuild robot)
      
      Cc: stable@vger.kernel.org
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d54e1b84
  2. 18 6月, 2019 5 次提交
  3. 15 6月, 2019 28 次提交
    • 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
    • B
      ice: Add missing case in print_link_msg for printing flow control · da00c89f
      Brett Creeley 提交于
      [ Upstream commit 203a068ac9e2722e4d118116acaa3a5586f9468a ]
      
      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: NBrett Creeley <brett.creeley@intel.com>
      Signed-off-by: NAnirudh Venkataramanan <anirudh.venkataramanan@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      da00c89f
    • T
      gpio: gpio-omap: add check for off wake capable gpios · 456e3563
      Tony Lindgren 提交于
      [ Upstream commit da38ef3ed10a09248e13ae16530c2c6d448dc47d ]
      
      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: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      456e3563
    • K
      PCI: xilinx: Check for __get_free_pages() failure · 47d281bb
      Kangjie Lu 提交于
      [ Upstream commit 699ca30162686bf305cdf94861be02eb0cf9bda2 ]
      
      If __get_free_pages() fails, return -ENOMEM to avoid a NULL pointer
      dereference.
      Signed-off-by: NKangjie Lu <kjlu@umn.edu>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NSteven Price <steven.price@arm.com>
      Reviewed-by: NMukesh Ojha <mojha@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      47d281bb
    • P
      block, bfq: increase idling for weight-raised queues · b5a185ee
      Paolo Valente 提交于
      [ Upstream commit 778c02a236a8728bb992de10ed1f12c0be5b7b0e ]
      
      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: NHolger Hoffstätte <holger@applied-asynchrony.com>
      Tested-by: NOleksandr Natalenko <oleksandr@natalenko.name>
      Signed-off-by: NPaolo Valente <paolo.valente@linaro.org>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b5a185ee
    • K
      video: imsttfb: fix potential NULL pointer dereferences · e06d7a92
      Kangjie Lu 提交于
      [ Upstream commit 1d84353d205a953e2381044953b7fa31c8c9702d ]
      
      In case ioremap fails, the fix releases resources and returns
      -ENOMEM to avoid NULL pointer dereferences.
      Signed-off-by: NKangjie 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: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e06d7a92
    • K
      video: hgafb: fix potential NULL pointer dereference · 1f2611af
      Kangjie Lu 提交于
      [ Upstream commit ec7f6aad57ad29e4e66cc2e18e1e1599ddb02542 ]
      
      When ioremap fails, hga_vram should not be dereferenced. The fix
      check the failure to avoid NULL pointer dereference.
      Signed-off-by: NKangjie 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: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1f2611af
    • G
      scsi: qla2xxx: Reset the FCF_ASYNC_{SENT|ACTIVE} flags · 5957f6f5
      Giridhar Malavali 提交于
      [ Upstream commit 0257eda08e806b82ee1fc90ef73583b6f022845c ]
      
      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: NGiridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: NHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5957f6f5
    • M
      PCI: rcar: Fix 64bit MSI message address handling · c2c7b6fe
      Marek Vasut 提交于
      [ Upstream commit 954b4b752a4c4e963b017ed8cef4c453c5ed308d ]
      
      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: NMarek Vasut <marek.vasut+renesas@gmail.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
      Reviewed-by: NGeert 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: NSasha Levin <sashal@kernel.org>
      c2c7b6fe
    • K
      PCI: rcar: Fix a potential NULL pointer dereference · dd54e70c
      Kangjie Lu 提交于
      [ Upstream commit f0d14edd2ba43b995bef4dd5da5ffe0ae19321a1 ]
      
      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: NKangjie Lu <kjlu@umn.edu>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NUlrich Hecht <uli+renesas@fpond.eu>
      Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      dd54e70c
    • P
      net: hns3: return 0 and print warning when hit duplicate MAC · 272f8c3d
      Peng Li 提交于
      [ Upstream commit 72110b567479f0282489a9b3747e76d8c67d75f5 ]
      
      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: NPeng Li <lipeng321@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      272f8c3d
    • S
      power: supply: max14656: fix potential use-before-alloc · 5a286ced
      Sven Van Asbroeck 提交于
      [ Upstream commit 0cd0e49711556d2331a06b1117b68dd786cb54d2 ]
      
      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: NSven Van Asbroeck <TheSven73@gmail.com>
      Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5a286ced
    • J
      platform/x86: intel_pmc_ipc: adding error handling · 901daed2
      Junxiao Chang 提交于
      [ Upstream commit e61985d0550df8c2078310202aaad9b41049c36c ]
      
      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: NJunxiao Chang <junxiao.chang@intel.com>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      901daed2