This writel writes the exact same value as the previous writel and is
thus unnecessary. It accidentally became unnecessary in e3538c37ee
("tty: xuartps: Beautify read-modify writes"), but the new behaviour is
now expected.
Link: https://www.spinics.net/lists/linux-serial/msg23168.html
Signed-off-by: Helmut Grohne <h.grohne@intenta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After sending data to the uart, the driver was waiting until the TX
FIFO was empty (for every single char written). After that, TX was
disabled by writing the original TX state to the status register. At
that time however, the state machine could still be shifting
characters. Not waiting can result in strange hardware states,
especially when coupled with calls to cdns_uart_set_termios, whose
symptom generally is garbage characters being received from uart or a
hang.
According to UG585, the TACTIVE bit of the channel status register
indicates the shifter operation and we should be waiting for that bit
to clear.
Sending characters does not require the TX FIFO to be empty, but merely
to not be full. So cdns_uart_console_putchar is updated accordingly.
During tests with an instrumented kernel and an oscilloscope, we could
determine that the chance of a race is reduced by this patch. It is not
removed entirely. On the oscilloscope, one can see that disabling the
transmitter early can result in the transmission hanging in the middle
of a character for a tiny duration. This hiccup is enough to
desynchronize with a remote device for a sequence of characters until a
data bit doesn't match the start or stop bits anymore.
Link: https://www.spinics.net/lists/linux-serial/msg23156.html
Link: https://www.spinics.net/lists/linux-serial/msg26139.html
Signed-off-by: Helmut Grohne <h.grohne@intenta.de>
Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The bit mask changes in commit 6e14f7c1f2 ("tty: xuartps: Improve
startup function") doesn't do what the commit message advertises. The
original behaviour was clearing the RX_DIS bit, but due to missing ~,
that bit is now the only bit kept.
Currently, the regression is harmless, because the previous write to the
control register sets it to TXRST | RXRST. Thus the RX_DIS bit is
previously cleared. The *RST bits are cleared by the hardware, so this
commit does not currently change behaviour, but makes future changes
less risky.
Link: https://www.spinics.net/lists/linux-serial/msg23157.html
Signed-off-by: Helmut Grohne <h.grohne@intenta.de>
Fixes: 6e14f7c1f2 ("tty: xuartps: Improve startup function")
Reviewed-by: Sören Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When pcmcia_loop_config fails, the lack of error-handling code may
cause unexpected results.
This patch adds error-handling code after calling pcmcia_loop_config.
Signed-off-by: Zhouyang Jia <jiazhouyang09@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
AM654 uses a UART controller that is compatible (partially) with
existing 8250 UART, however, has a few differences with respect to DMA
support and control paths. Introduce a base definition that allows us
to build up the differences in follow on patches.
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Vignesh R <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
AM654 uses a UART controller that is only partially compatible with
existing 8250 UART. UART DMA integration is substantially different
and even a match against standard 8250 or omap4 would result in
non-working UART once DMA is enabled by default.
Introduce a specific compatible to help build up the differences in
follow on patches.
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Vignesh R <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark found ldsem_cmpxchg() needed an (atomic_long_t *) cast to keep
working after making the atomic_long interface type safe.
Needing casts is bad form, which made me look at the code. There are no
ld_semaphore::count users outside of these functions so there is no
reason why it can not be an atomic_long_t in the first place, obviating
the need for this cast.
That also ensures the loads use atomic_long_read(), which implies (at
least) READ_ONCE() in order to guarantee single-copy-atomic loads.
When using atomic_long_try_cmpxchg() the ldsem_cmpxchg() wrapper gets
very thin (the only difference is not changing *old on success, which
most callers don't seem to care about).
So rework the whole thing to use atomic_long_t and its accessors
directly.
While there, fixup all the horrible comment styles.
Cc: Peter Hurley <peter@hurleysoftware.com>
Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Move the non-board-specific part of the RS485 initialization from
iot2040_rs485_config function to a new generic function used also for
other boards.
This allows using TIOCGRS485 and TIOCSRS485 on boards (such as mPCIe
serial IO modules) which are hard-wired to RS485 or have jumpers for
their configurations.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add support for controller runtime power management to serdev core. This
is needed to allow slave drivers to manage the runtime PM state of the
underlying serial controller when its driver, in turn, implements more
aggressive runtime power management (e.g. using autosuspend).
For some applications, for example, where loss off initial data after a
remote-wakeup event is acceptable or where rx is not used at all,
aggressive serial controller runtime PM may be used without further
involvement of the slave driver. But when this is not the case, the
slave driver must be able to indicate when incoming data is expected in
order to avoid data loss.
To facilitate the common case, where the serial controller power state
is active whenever the port is open (which is the case with just about
every serial driver), and where data loss is not acceptable and cannot
even be prevented by explicit controller runtime power management, an
RPM reference is taken in serdev open and put again at close. This
reference can later be balanced by any serdev driver which wants and/or
can handle aggressive controller runtime PM.
Note that the .ignore_children flag is set for the serdev controller to
allow the underlying hardware to idle when no I/O is expected, regardless
of the slave device RPM state.
Acked-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If port.line is out of range, we still need to release some resources, or
we will leak them.
Fixes: afc7851fab ("serial: pxa: Fix out-of-bounds access through serial port index")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This chip has a diagnostics status bit informing about the state and
stability of the clock subsystem. According to the datasheet (STSint
register, bit 5, ClockReady), this bit works with the crystal
oscillator, but even without the PLL. Therefore:
- ensure that the clock check is done even when PLL is not active
- warn when the chip thinks that the clock is not ready yet
There are HW features which would let us wait asynchronously (there's a
maskable IRQ for that bit), but I think that even this simple check is a
net improvement. It would have saved me two days of debugging :).
Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The automated VFS conversion to timespec64 has left one caller of
the deprecated get_seconds() function in the tty driver, this cleans
it up to call ktime_get_real_seconds() instead, fixing the possible
overflow.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Correct to check the right rx dma cookie status in spit of it
works because only one cookie is running in the current sdma.
But it will not once sdma driver support multi cookies
running based on virt-dma.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The i.MX UART peripheral uses the RST_B signal as input, and CTS_B as
output. This is just like the DCE role in RS-232. This is true
regardless of the "DTE mode" setting of this peripheral.
As a result, rs485 support hardware must use the CTS_B signal to control
the RS-485 transceiver. This is in contrast to generic rs485 kernel
code, documentation, and DT property names that consistently refer to
the RTS as transceiver control signal.
Add a note in the DT binding document about that, to reduce the
confusion somewhat.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Initially when register shadowing was introduced (commit 3a0ab62f43
("serial: imx: implement shadow registers for UCRx and UFCR")) the logic
to handle UCR2_SRST was wrong but documented consistently. Later the
handling was fixed, but the comment was not. This change makes up leeway
for the latter.
Fixes: 0aa821d846 ("serial: imx: fix cached UCR2 read on software reset")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For architectures that do not use per-device dma ops we need to export
the dma_map_ops structure returned from get_arch_dma_ops().
Fixes: 10314e09 ("riscv: add swiotlb support")
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Andreas Schwab <schwab@suse.de>
Here are bunch of new device ids for cp210x.
All have been in linux-next with no reported issues.
Signed-off-by: Johan Hovold <johan@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEHszNKQClByu0A+9RQQ3kT97htJUFAlszd/sRHGpvaGFuQGtl
cm5lbC5vcmcACgkQQQ3kT97htJWnCg/+PRGUNfhJSlgp6bcRRz+Iifh4mnJc9kZU
mwjXoxNWO62jr0tZlJdFESeZpyB7S8zs1Cne6OKruxKivjHUeeCrJojSWriq8DVT
+9rUpawG8TxLv7FERNv+H0ny/Di06CoX+aolzXGYDp8PDSiTBmBoaE2SEdtn0Cmi
VT0ws1mce3P+TCS12BUXNeEFOksFdyIKQc+YO9Ai9kfQNiBVhPv/alQ/gg1bcPL3
A6tCqzMdML1rXR8J0REpZuiTxKohTiJhiPSLGA9onHgf3yukzqvSXeClKMEOY5+f
idil28ChYkMLAyuGQ6anuEOJpt+NgeuQZ7AEdH5GRL2hTN0NuvaA8eAiCYaDhqN/
IIKr/0N+i2EAmNbfpTpywF4xQOzvFUp6jY/ZNwIspeckKNvSXZryxZEUyutzh01a
nFvvjACtt/ubrhUitzz3531Y2ZuB/NpIx6P7e9mZuDX7+we8pxHY18aBNMsW/OES
GrJfbTVt7+B1CLgzDaFcwh1E8zKDn1VmFe+Cm4iOpq1UgJqEvIeLVZsbX2UocqSV
bXkQ+JV2iHs6X3ARwluLYvIJidUCp1hFTm95EDGn9JzS7sGWJJbASLKgVDLMvovd
ixD69y1JRz/Z3ztN/Pls7I9i7yWLQa0XFo3dc4iIUzQzee3ygbRwaphUek143mRu
o17EV0gE/dE=
=+oP9
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-4.18-rc3' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
Johan writes:
USB-serial fixes for v4.18-rc3
Here are bunch of new device ids for cp210x.
All have been in linux-next with no reported issues.
Signed-off-by: Johan Hovold <johan@kernel.org>
If a power failure happens while the qgroup rescan kthread is running,
the next mount operation will always fail. This is because of a recent
regression that makes qgroup_rescan_init() incorrectly return -EINVAL
when we are mounting the filesystem (through btrfs_read_qgroup_config()).
This causes the -EINVAL error to be returned regardless of any qgroup
flags being set instead of returning the error only when neither of
the flags BTRFS_QGROUP_STATUS_FLAG_RESCAN nor BTRFS_QGROUP_STATUS_FLAG_ON
are set.
A test case for fstests follows up soon.
Fixes: 9593bf4967 ("btrfs: qgroup: show more meaningful qgroup_rescan_init error message")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The vm_fault_t conversion commit introduced a ret2 variable for tracking
the integer return values from internal btrfs functions. It was
sometimes returning VM_FAULT_LOCKED for pages that were actually invalid
and had been removed from the radix. Something like this:
ret2 = btrfs_delalloc_reserve_space() // returns zero on success
lock_page(page)
if (page->mapping != inode->i_mapping)
goto out_unlock;
...
out_unlock:
if (!ret2) {
...
return VM_FAULT_LOCKED;
}
This ends up triggering this WARNING in btrfs_destroy_inode()
WARN_ON(BTRFS_I(inode)->block_rsv.size);
xfstests generic/095 was able to reliably reproduce the errors.
Since out_unlock: is only used for errors, this fix moves it below the
if (!ret2) check we use to return VM_FAULT_LOCKED for success.
Fixes: a528a24150 (btrfs: change return type of btrfs_page_mkwrite to vm_fault_t)
Signed-off-by: Chris Mason <clm@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Commit ff3d27a048 ("btrfs: qgroup: Finish rescan when hit the last leaf
of extent tree") added a new exit for rescan finish.
However after finishing quota rescan, we set
fs_info->qgroup_rescan_progress to (u64)-1 before we exit through the
original exit path.
While we missed that assignment of (u64)-1 in the new exit path.
The end result is, the quota status item doesn't have the same value.
(-1 vs the last bytenr + 1)
Although it doesn't affect quota accounting, it's still better to keep
the original behavior.
Reported-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
Fixes: ff3d27a048 ("btrfs: qgroup: Finish rescan when hit the last leaf of extent tree")
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
kmemleak reported some memory leak on reading proc files. After adding
some debug lines, find that proc_seq_fops is using seq_release as
release handler, which won't handle the free of 'private' field of
seq_file, while in fact the open handler proc_seq_open could create
the private data with __seq_open_private when state_size is greater
than zero. So after reading files created with proc_create_seq_private,
such as /proc/timer_list and /proc/vmallocinfo, the private mem of a
seq_file is not freed. Fix it by adding the paired proc_seq_release
as the default release handler of proc_seq_ops instead of seq_release.
Fixes: 44414d82cf ("proc: introduce proc_create_seq_private")
Reviewed-by: Christoph Hellwig <hch@lst.de>
CC: Christoph Hellwig <hch@lst.de>
Signed-off-by: Chunyu Hu <chuhu@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
meson-gxl-mali.dtsi is only used on GXL SoCs. Thus it should use the GXL
specific compatible string instead of the GXBB one.
For now this is purely cosmetic since the (out-of-tree) lima driver for
this GPU currently uses the "arm,mali-450" match instead of the SoC
specific one. However, update the .dts to match the documentation since
this driver behavior might change in the future.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Like the odroid-c2 and wetek, the s400 uses the RTL8211F and seems to
suffer from the kind of stability issue.
Doing an iperf3 download test, we can see a significant number of LPI
interrupts on the tx path. After a short while (5 to 15 seconds), the
network connection dies. If using rootfs over NFS, the connection may
also break during the boot sequence.
We still don't have a real explanation for this problem so let's disable
EEE once again.
Fixes: f6f6ac914b ("ARM64: dts: meson-axg: enable ethernet for A113D S400 board")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Vendor firmware/uboot has different reserved regions depending on
firmware version, but current codebase reserves the same regions on
GXL and GXBB, so move the additional reserved memory region to common
.dtsi.
Found when putting a recent vendor u-boot on meson-gxbb-p200.
Suggested-by: Neil Armstrong <narmstrong@baylibre.com>
Cc: stable@vger.kernel.org
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Like LibreTech-CC, the USB0 needs the 5V regulator to be enabled to power the
devices on the P212 Reference Design based boards.
Fixes: b9f07cb4f4 ("ARM64: dts: meson-gxl-s905x-p212: enable the USB controller")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Based on updated information from Amlogic, correct the register range
for the SD/eMMC blocks to the right size.
Reported-by: Yixun Lan <yixun.lan@amlogic.com>
Tested-by: Yixun Lan <yixun.lan@amlogic.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
There is a problem with the sd-uhs mode when doing a soft reboot.
Switching back from 1.8v to 3.3v messes with the card, which no longer
respond (timeout errors). According to the specification, we should
perform a card reset (power cycling the card) but this is something we
cannot control on this design.
Then the only solution to restore the communication with the card is an
"unplug-plug" which is not acceptable
Until we find a solution, if any, disable the sd-uhs modes on this design.
For the people using uhs at the moment, there will a performance drop as
a result.
Fixes: 3cde63ebc8 ("ARM64: dts: meson-gxl: libretech-cc: enable high speed modes")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Cc: stable@vger.kernel.org
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Currently, amdgpu_do_flip() spinlocks crtc->dev->event_lock and
releases it only after committing updates to the stream.
dc_commit_updates_for_stream() should be moved out of
spinlock for the below reasons:
1. event_lock is supposed to protect access to acrct->pflip_status _only_
2. dc_commit_updates_for_stream() has potential sleep's
and also its not appropriate to be in an atomic state
for such long sequences of code.
Signed-off-by: Shirish S <shirish.s@amd.com>
Suggested-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Support new VCN FW version naming convention:
[31, 28] for VEP interface major version if applicable
[27, 24] for decode interface major version
[23, 20] for encode interface major version
[19, 12] for encode interface minor version
[11, 0] for firmware revision
Bit 20-23, it is encode major and non-zero for new naming convention.
This field is part of version minor and DRM_DISABLED_FLAG in old naming
convention. Since the latest version minor is 0x5B and DRM_DISABLED_FLAG
is zero in old naming convention, this field is always zero so far.
These four bits are used to tell which naming convention is present.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Fang, Peter <Peter.Fang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Here is the UBSAN dump:
[ 3.866656] index 2 is out of range for type 'amdgpu_uvd_inst [2]'
[ 3.866693] Workqueue: events work_for_cpu_fn
[ 3.866702] Call Trace:
[ 3.866710] dump_stack+0x85/0xc5
[ 3.866719] ubsan_epilogue+0x9/0x40
[ 3.866727] __ubsan_handle_out_of_bounds+0x89/0x90
[ 3.866737] ? rcu_read_lock_sched_held+0x58/0x60
[ 3.866746] ? __kmalloc+0x26c/0x2d0
[ 3.866846] amdgpu_fence_driver_start_ring+0x259/0x280 [amdgpu]
[ 3.866896] amdgpu_ring_init+0x12c/0x710 [amdgpu]
[ 3.866906] ? sprintf+0x42/0x50
[ 3.866956] amdgpu_gfx_kiq_init_ring+0x1bc/0x3a0 [amdgpu]
[ 3.867009] gfx_v8_0_sw_init+0x1ad3/0x2360 [amdgpu]
[ 3.867062] ? smu7_init+0xec/0x160 [amdgpu]
[ 3.867109] amdgpu_device_init+0x112c/0x1dc0 [amdgpu]
'ring->me' might be set as 2 with 'amdgpu_gfx_kiq_init_ring', that would
cause out of range for 'amdgpu_uvd_inst[2]'.
v2: simplified with ring type
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
- More metadata validation strengthening to prevent crashes.
- Fix extent offset overflow problem when insert_range on a 512b block fs
- Fix some off-by-one errors in the realtime fsmap code
- Fix some math errors in the default resblks calculation when free space
is low
- Fix a problem where stale page contents are exposed via mmap read
after a zero_range at eof
- Fix accounting problems with per-ag reservations causing statfs
reports to vary incorrectly
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAlsv6mQACgkQ+H93GTRK
tOv3ZA//W9QVf6aGv3fefg7ZkleRpKPhpvrdgy+LnnhGdkToKGsOIJGavFjBYfBh
cFSOXrKamNiSZiJzzQ8NiFaZ8wrD2NAhOybatp7jAGKGb+a3VTtoz7v+4VwJ5Psw
gPdZ+zADqsbbUg4Xx08TDqdQDHlIXz6kTvrM+MGBq5TynICAIUgS2o9fJT1HKf12
xfbC2dh2cK/7TnN0MNCLzekrPoiLfuEPsMkrnWv/PBre0AhfcCJLbNhQi5+mCWcs
e71vttXAc3kkSly6G4D9SSb+5Mn1Q1SkBsORn82fJdI59eHjFn1ujLvkfPM1w1Iu
oDjJw8PCyrG7NFZiTh46MuJhvH/Tc6ZZvop/YJyJJApHOYYx6K64enpJrWcg+CKp
Rcl5gQocvlIfMyzBvyozpHctlIuOjkQsSmyEXXx8PAsr7zU+FehXS5ENzCOtdg5U
LivcsXmh0bvSU1PdzA3oiANcIPAfVX6+RoM4rQpDjT+IS7Ud9F2hELD0Yi/pmk4l
oC91+e4oPJ4HsoCDmxePLl29Gqm4n1lY9i3l1PsZe8yWeYxs991R/hJuxKvRQLul
sxkgKk5nvdG2PjSmAKx9XYRrHEf/3uK+TEtrQtrm06i1QEI881qqSEMHpaoRj0qo
awESWimVodllaag+ugFLi+u+UAh8LA0jTAmijBqczLtspU1Cg0c=
=Aw39
-----END PGP SIGNATURE-----
Merge tag 'xfs-4.18-fixes-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
Pull xfs fixes from Darrick Wong:
"Here are some patches for 4.18 to fix regressions, accounting
problems, overflow problems, and to strengthen metadata validation to
prevent corruption.
This series has been run through a full xfstests run over the weekend
and through a quick xfstests run against this morning's master, with
no major failures reported.
Changes since last update:
- more metadata validation strengthening to prevent crashes.
- fix extent offset overflow problem when insert_range on a 512b
block fs
- fix some off-by-one errors in the realtime fsmap code
- fix some math errors in the default resblks calculation when free
space is low
- fix a problem where stale page contents are exposed via mmap read
after a zero_range at eof
- fix accounting problems with per-ag reservations causing statfs
reports to vary incorrectly"
* tag 'xfs-4.18-fixes-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
xfs: fix fdblocks accounting w/ RMAPBT per-AG reservation
xfs: ensure post-EOF zeroing happens after zeroing part of a file
xfs: fix off-by-one error in xfs_rtalloc_query_range
xfs: fix uninitialized field in rtbitmap fsmap backend
xfs: recheck reflink state after grabbing ILOCK_SHARED for a write
xfs: don't allow insert-range to shift extents past the maximum offset
xfs: don't trip over negative free space in xfs_reserve_blocks
xfs: allow empty transactions while frozen
xfs: xfs_iflush_abort() can be called twice on cluster writeback failure
xfs: More robust inode extent count validation
xfs: simplify xfs_bmap_punch_delalloc_range
Timur Tabi no longer works for Qualcomm, and he now has a kernel.org
email address, so update MAINTAINERS accordingly.
Signed-off-by: Timur Tabi <timur@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 7f0b1bf045 ("arm64: Fix barriers used for page table modifications")
fixed a reported issue with fixmap page-table entries not being visible
to the walker due to a missing DSB instruction. At the same time, it added
ISB instructions to the arm64 set_{pte,pmd,pud} functions, which are not
required by the architecture and make little sense in isolation.
Remove the redundant ISBs.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The implementation of flush_icache_range() includes instruction sequences
which are themselves patched at runtime, so it is not safe to call from
the patching framework.
This patch reworks the alternatives cache-flushing code so that it rolls
its own internal D-cache maintenance using DC CIVAC before invalidating
the entire I-cache after all alternatives have been applied at boot.
Modules don't cause any issues, since flush_icache_range() is safe to
call by the time they are loaded.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Reported-by: Rohit Khanna <rokhanna@nvidia.com>
Cc: Alexander Van Brunt <avanbrunt@nvidia.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
- Adjust rseq_signal_deliver() & rseq_handle_notify_resume() calls to
add the ksig argument introduced in v4.18-rc2, around the same time
as the unadjusted MIPS rseq support.
-----BEGIN PGP SIGNATURE-----
iIsEABYIADMWIQRgLjeFAZEXQzy86/s+p5+stXUA3QUCWzO56xUccGF1bC5idXJ0
b25AbWlwcy5jb20ACgkQPqefrLV1AN226gD+O19wJrNvk1oERx5Hyt3dUB78yXPk
SLl5UmSyNmbvJTQBAKdebByLshiuGAepwuHLSTF8zcVFkSkvq4yAeXCVyuAC
=wa/j
-----END PGP SIGNATURE-----
Merge tag 'mips_fixes_4.18_2' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
Pull MIPS build fix from Paul Burton:
"A single build fix for 4.18:
Adjust rseq_signal_deliver() & rseq_handle_notify_resume() calls to
add the ksig argument introduced in v4.18-rc2, around the same time as
the unadjusted MIPS rseq support"
* tag 'mips_fixes_4.18_2' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
MIPS: Add ksig argument to rseq_{signal_deliver,handle_notify_resume}
A handful of fixes, nothing really concerning and most touching devicetree
files for various platforms.
I also regenerated the shared multiplatform defconfigs; they have drifted
quite a bit due to Kconfig changes and reordering, and several platform
maintainers tried doing the same which resulted in a lot of conflict pain
-- this way we get everybody onto the same base for next merge window.
-----BEGIN PGP SIGNATURE-----
iQJDBAABCAAtFiEElf+HevZ4QCAJmMQ+jBrnPN6EHHcFAlsznAAPHG9sb2ZAbGl4
b20ubmV0AAoJEIwa5zzehBx3b44P/jFlGH355coEdGrbLyOa/rJSjmvXejWpdgEJ
w/ZR1BE9KhTjG6bxGcFVX43qoP9Bc/Pz/cbW0fGtSmEZOHjy1JfQY6R9dcAI9Bi9
jbwpAWSYLdk7ebV2rRAIlXLFShdbZfFTXPuHD26/Je2R949oKo8SG+tpmX2kuTIY
ShdoCRY2pMjkPqtyqS0Zj4JJA9y3yQ36yI9OILTm+Dt8+fep2wjEtVlbZYO4Uvqu
VfXsgIbfh7Pmo5nV3yWgHuzoenOuj37KjvbhdPB29jxCATOH1kqLAhNg6lMG9Wyg
4sGunrHNdaORyAhcBqLUfVffo0MfJHShW7TdpqcGZ2GuDQVc1PT8O1Vt1EatI9fa
qWCRzn6DZIPdN9Ob+QTRp2BPbjhyttj2hxMbOrQT1Galo2T3yyjJId0J19osx4SP
L49CV5pi1phwDVPAxYdivNB7IfL+xx0RoEN9LPYsgKxhnGeYUBgMEU7R7lBanniW
12HgCCoO6teDxj3hMw7NlQhY8QNFCDdkg4ZS2Ns6SSVGeQE4Vz6g2QZ1kbYfkVub
y2Yx9xtJON0+XZ0OtdxcW6jIzPnqMgVD+H2NBMOJLSmUIe7Gn9MtrNecSqNGdsdY
EZQrDOTrP6fuThzdkiT2SqSKcJjNEuwc5+Z39gBxP6i0++6SJ4g98Tv/Ok/efOS5
OYzSQb5I
=QzLy
-----END PGP SIGNATURE-----
Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"A handful of fixes, nothing really concerning and most touching
devicetree files for various platforms.
I also regenerated the shared multiplatform defconfigs; they have
drifted quite a bit due to Kconfig changes and reordering, and several
platform maintainers tried doing the same which resulted in a lot of
conflict pain -- this way we get everybody onto the same base for next
merge window"
* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (31 commits)
arm64: dts: uniphier: fix widget name of headphone for LD11/LD20 boards
ARM: dts: Fix SPI node for Arria10
arm64: dts: stratix10: Fix SPI nodes for Stratix10
qcom: cmd-db: enforce CONFIG_OF_RESERVED_MEM dependency
ARM: Always build secure_cntvoff.S on ARM V7 to fix shmobile !SMP build
ARM: multi_v7_defconfig: renormalize based on recent additions
arm64: defconfig: renormalize based on recent additions
arm64: dts: msm8916: fix Coresight ETF graph connections
arm64: dts: apq8096-db820c: disable uart0 by default
ARM: dts: imx6sx: fix irq for pcie bridge
arm64: dts: Stingray: Fix I2C controller interrupt type
arm64: dts: ns2: Fix PCIe controller interrupt type
arm64: dts: ns2: Fix I2C controller interrupt type
arm64: dts: specify 1.8V EMMC capabilities for bcm958742t
arm64: dts: specify 1.8V EMMC capabilities for bcm958742k
ARM: dts: Cygnus: Fix PCIe controller interrupt type
ARM: dts: Cygnus: Fix I2C controller interrupt type
ARM: dts: BCM5301x: Fix i2c controller interrupt type
ARM: dts: HR2: Fix interrupt types for i2c and PCIe
ARM: dts: NSP: Fix PCIe controllers interrupt types
...
Three small bug fixes (barrier elimination, memory leak on unload,
spinlock recursion) and a technical enhancement left over from the
merge window: the TCMU read length support is required for tape
devices read when the length of the read is greater than the tape
block size.
Signed-off-by: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
-----BEGIN PGP SIGNATURE-----
iJwEABMIAEQWIQTnYEDbdso9F2cI+arnQslM7pishQUCWzL0MSYcamFtZXMuYm90
dG9tbGV5QGhhbnNlbnBhcnRuZXJzaGlwLmNvbQAKCRDnQslM7pishc/IAP9clsIx
CwZd3X/c/AffETSGIIMAjjfOAUJq7xEcR+cyUgD/ZSaIaI/PlvdpIfXPPEd7W3UC
W1maxi8MwP4OF6Xi7mw=
=TQl+
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Three small bug fixes (barrier elimination, memory leak on unload,
spinlock recursion) and a technical enhancement left over from the
merge window: the TCMU read length support is required for tape
devices read when the length of the read is greater than the tape
block size"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: scsi_debug: Fix memory leak on module unload
scsi: qla2xxx: Spinlock recursion in qla_target
scsi: ipr: Eliminate duplicate barriers
scsi: target: tcmu: add read length support
Pull input updates from Dmitry Torokhov:
- the main change is a fix for my brain-dead patch to PS/2 button
reporting for some protocols that made it in 4.17
- there is a new driver for Spreadtum vibrator that I intended to send
during merge window but ended up not sending the 2nd pull request.
Given that this is a brand new driver we should not see regressions
here
- a fixup to Elantech PS/2 driver to avoid decoding errors on Thinkpad
P52
- addition of few more ACPI IDs for Silead and Elan drivers
- RMI4 is switched to using IRQ domain code instead of rolling its own
implementation
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: psmouse - fix button reporting for basic protocols
Input: xpad - fix GPD Win 2 controller name
Input: elan_i2c_smbus - fix more potential stack buffer overflows
Input: elan_i2c - add ELAN0618 (Lenovo v330 15IKB) ACPI ID
Input: elantech - fix V4 report decoding for module with middle key
Input: elantech - enable middle button of touchpads on ThinkPad P52
Input: do not assign new tracking ID when changing tool type
Input: make input_report_slot_state() return boolean
Input: synaptics-rmi4 - fix axis-swap behavior
Input: synaptics-rmi4 - fix the error return code in rmi_probe_interrupts()
Input: synaptics-rmi4 - convert irq distribution to irq_domain
Input: silead - add MSSL0002 ACPI HID
Input: goldfish_events - fix checkpatch warnings
Input: add Spreadtrum vibrator driver
Pull more security subsystem fixes from James Morris:
"Two further fixes for the keys subsystem"
* 'fixes-v4.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
dh key: fix rounding up KDF output length
certs/blacklist: fix const confusion
It may not be the actual real stable mailing list address, but the
stable scripts to actually pick up on the traditional way to mark stable
patches.
There are also reasons to explicitly avoid using the actual mailing list
address, since security patches with embargo dates generally do want the
stable marking, but don't want tools etc to mistakenly send the patch
out to the mailing list early.
So don't warn for things that are still actively used and explicitly
supported.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch fixes wrong name of headphone widget for receiving events
of insert/remove headphone plug from simple-card or audio-graph-card.
If we use wrong widget name then we get warning messages such as
"asoc-audio-graph-card sound: ASoC: DAPM unknown pin Headphones"
when the plug is inserted or removed from headphone jack.
Fixes: fb21a0acaa ("arm64: dts: uniphier: add sound node")
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Discards issued to a DM thin device can complete to userspace (via
fstrim) _before_ the metadata changes associated with the discards is
reflected in the thinp superblock (e.g. free blocks). As such, if a
user constructs a test that loops repeatedly over these steps, block
allocation can fail due to discards not having completed yet:
1) fill thin device via filesystem file
2) remove file
3) fstrim
From initial report, here:
https://www.redhat.com/archives/dm-devel/2018-April/msg00022.html
"The root cause of this issue is that dm-thin will first remove
mapping and increase corresponding blocks' reference count to prevent
them from being reused before DISCARD bios get processed by the
underlying layers. However. increasing blocks' reference count could
also increase the nr_allocated_this_transaction in struct sm_disk
which makes smd->old_ll.nr_allocated +
smd->nr_allocated_this_transaction bigger than smd->old_ll.nr_blocks.
In this case, alloc_data_block() will never commit metadata to reset
the begin pointer of struct sm_disk, because sm_disk_get_nr_free()
always return an underflow value."
While there is room for improvement to the space-map accounting that
thinp is making use of: the reality is this test is inherently racey and
will result in the previous iteration's fstrim's discard(s) completing
vs concurrent block allocation, via dd, in the next iteration of the
loop.
No amount of space map accounting improvements will be able to allow
user's to use a block before a discard of that block has completed.
So the best we can really do is allow DM thinp to gracefully handle such
aggressive use of all the pool's data by degrading the pool into
out-of-data-space (OODS) mode. We _should_ get that behaviour already
(if space map accounting didn't falsely cause alloc_data_block() to
believe free space was available).. but short of that we handle the
current reality that dm_pool_alloc_data_block() can return -ENOSPC.
Reported-by: Dennis Yang <dennisyang@qnap.com>
Cc: stable@vger.kernel.org
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
The intc #interrupt-cells is equal to 1. Currently gpio
node has 2 cells per IRQ which is wrong. Remove the additional
cell for each of the interrupts.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Fixes: 2e38b946dc ("ARM: davinci: da850: add GPIO DT node")
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
- Remove 'nx_warning' and 'smep_warning', which are just pointless obfuscation.
- Also convert to pr_crit().
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180627090715.28076-1-dvyukov@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Document the recently introduced hwp_dynamic_boost sysfs knob
allowing user space to tell intel_pstate to use iowait boosting
in the active mode with HWP enabled (to improve performance).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Fix an incorrect sysfs path in the intel_pstate admin-guide
documentation.
Fixes: 33fc30b470 (cpufreq: intel_pstate: Document the current behavior and user interface)
Reported-by: Pawit Pornkitprasan <p.pawit@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Helmut Grohne