Skip to content

L
linux
Switch branch/tag
  1. 29 Dec, 2018 32 commits
  3. 21 Dec, 2018 8 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.14.90 · 592f5569
      Greg Kroah-Hartman authored
      592f5569
    • Nicolas Schichan's avatar
      bpf, arm: fix emit_ldx_r and emit_mov_i using TMP_REG_1 · ad962d20
      Nicolas Schichan authored 
      emit_ldx_r() and emit_a32_mov_i() were both using TMP_REG_1 and
clashing with each other. Using TMP_REG_2 in emit_ldx_r() fixes
the issue.

Fixes: ec19e02b ("ARM: net: bpf: fix LDX instructions")
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: default avatarNicolas Schichan <nschichan@freebox.fr>
Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ad962d20
    • Trent Piepho's avatar
      rtc: snvs: Add timeouts to avoid kernel lockups · f1e1eb5c
      Trent Piepho authored 
      [ Upstream commit cd7f3a24 ]

In order to read correctly from asynchronously updated RTC registers,
it's necessary to read repeatedly until their values do not change from
read to read.  It's also necessary to wait for three RTC clock ticks for
certain operations.  There are no timeouts in this code and these
operations could possibly loop forever.

To avoid kernel hangs, put in timeouts.

The iMX7d can be configured to stop the SRTC on a tamper event, which
will lockup the kernel inside this driver as described above.

These hangs can happen when running under qemu, which doesn't emulate
the SNVS RTC, though currently the driver will refuse to load on qemu
due to a timeout in the driver probe method.

It could also happen if the SRTC block where somehow placed into reset
or the slow speed clock that drives the SRTC counter (but not the CPU)
were to stop.

The symptoms on a two core iMX7d are a work queue hang on
rtc_timer_do_work(), which eventually blocks a systemd fsnotify
operation that triggers a work queue flush, causing systemd to hang and
thus causing all services that should be started by systemd, like a
console getty, to fail to start or stop.

Also optimize the wait code to wait less.  It only needs to wait for the
clock to advance three ticks, not to see it change three times.

Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Signed-off-by: default avatarTrent Piepho <tpiepho@impinj.com>
Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f1e1eb5c
    • Israel Rukshin's avatar
      nvmet-rdma: fix response use after free · 60e3480e
      Israel Rukshin authored 
      [ Upstream commit d7dcdf9d ]

nvmet_rdma_release_rsp() may free the response before using it at error
flow.

Fixes: 8407879c ("nvmet-rdma: fix possible bogus dereference under heavy load")
Signed-off-by: default avatarIsrael Rukshin <israelr@mellanox.com>
Reviewed-by: default avatarSagi Grimberg <sagi@grimberg.me>
Reviewed-by: default avatarMax Gurtovoy <maxg@mellanox.com>
Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      60e3480e
    • Masahiro Yamada's avatar
      i2c: uniphier-f: fix violation of tLOW requirement for Fast-mode · 07d4f1c4
      Masahiro Yamada authored 
      [ Upstream commit ece27a33 ]

Currently, the clock duty is set as tLOW/tHIGH = 1/1. For Fast-mode,
tLOW is set to 1.25 us while the I2C spec requires tLOW >= 1.3 us.

tLOW/tHIGH = 5/4 would meet both Standard-mode and Fast-mode:
  Standard-mode: tLOW = 5.56 us, tHIGH = 4.44 us
  Fast-mode:     tLOW = 1.39 us, tHIGH = 1.11 us
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      07d4f1c4
    • Masahiro Yamada's avatar
      i2c: uniphier: fix violation of tLOW requirement for Fast-mode · 90265a60
      Masahiro Yamada authored 
      [ Upstream commit 8469636a ]

Currently, the clock duty is set as tLOW/tHIGH = 1/1. For Fast-mode,
tLOW is set to 1.25 us while the I2C spec requires tLOW >= 1.3 us.

tLOW/tHIGH = 5/4 would meet both Standard-mode and Fast-mode:
  Standard-mode: tLOW = 5.56 us, tHIGH = 4.44 us
  Fast-mode:     tLOW = 1.39 us, tHIGH = 1.11 us
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      90265a60
    • Hans de Goede's avatar
      i2c: scmi: Fix probe error on devices with an empty SMB0001 ACPI device node · c39910b5
      Hans de Goede authored 
      [ Upstream commit 0544ee4b ]

Some AMD based HP laptops have a SMB0001 ACPI device node which does not
define any methods.

This leads to the following error in dmesg:

[    5.222731] cmi: probe of SMB0001:00 failed with error -5

This commit makes acpi_smbus_cmi_add() return -ENODEV instead in this case
silencing the error. In case of a failure of the i2c_add_adapter() call
this commit now propagates the error from that call instead of -EIO.
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c39910b5
    • Adamski, Krzysztof (Nokia - PL/Wroclaw)'s avatar
      i2c: axxia: properly handle master timeout · 4bdfff5c
      Adamski, Krzysztof (Nokia - PL/Wroclaw) authored 
      [ Upstream commit 6c7f25ca ]

According to Intel (R) Axxia TM Lionfish Communication Processor
Peripheral Subsystem Hardware Reference Manual, the AXXIA I2C module
have a programmable Master Wait Timer, which among others, checks the
time between commands send in manual mode. When a timeout (25ms) passes,
TSS bit is set in Master Interrupt Status register and a Stop command is
issued by the hardware.

The axxia_i2c_xfer(), does not properly handle this situation, however.
For each message a separate axxia_i2c_xfer_msg() is called and this
function incorrectly assumes that any interrupt might happen only when
waiting for completion. This is mostly correct but there is one
exception - a master timeout can trigger if enough time has passed
between individual transfers. It will, by definition, happen between
transfers when the interrupts are disabled by the code. If that happens,
the hardware issues Stop command.

The interrupt indicating timeout will not be triggered as soon as we
enable them since the Master Interrupt Status is cleared when master
mode is entered again (which happens before enabling irqs) meaning this
error is lost and the transfer is continued even though the Stop was
issued on the bus. The subsequent operations completes without error but
a bogus value (0xFF in case of read) is read as the client device is
confused because aborted transfer. No error is returned from
master_xfer() making caller believe that a valid value was read.

To fix the problem, the TSS bit (indicating timeout) in Master Interrupt
Status register is checked before each transfer. If it is set, there was
a timeout before this transfer and (as described above) the hardware
already issued Stop command so the transaction should be aborted thus
-ETIMEOUT is returned from the master_xfer() callback. In order to be
sure no timeout was issued we can't just read the status just before
starting new transaction as there will always be a small window of time
(few CPU cycles at best) where this might still happen. For this reason
we have to temporally disable the timer before checking for TSS bit.
Disabling it will, however, clear the TSS bit so in order to preserve
that information, we have to read it in ISR so we have to ensure that
the TSS interrupt is not masked between transfers of one transaction.
There is no need to call bus recovery or controller reinitialization if
that happens so it's skipped.
Signed-off-by: default avatarKrzysztof Adamski <krzysztof.adamski@nokia.com>
Reviewed-by: default avatarAlexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      4bdfff5c
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7