- A tqma8mpql board fix from Alexander Stein to correct vqmmc-supply for
usdhc3
- A change from Joe Hattori to fix OF node leak in imx-scu driver probe
- A soc-imx8m driver fix from Peng Fan unregister cpufreq and soc device
in cleanup path
- A couple of changes from Stefan Eichenberger to fix iMX6 Apalis
poweroff and iMX8M verdin-dahlia sound-card descriptions
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmfAN/4UHHNoYXduZ3Vv
QGtlcm5lbC5vcmcACgkQUFdYWoewfM4sswf+KA9QBYQomjw4vzrjtSDLbGFY2xhH
lovwDFXFI4U1uAMccbo/uEGiGXNfgT9CuieelgNKasdJzOoH0UmZmJG70ohIV69A
zy2IzsG1JyqENf9j7YYm5aQYvuiwgKP04c8vMRsDBLCxB9FPN7MxA8M8gAAGXJVx
JjsxN8jl4CT4r6BeUMNhz7vc3XsYmhqNYGxYDJW9Q2zAb17R/IvZTdaz8UPAmCak
7PvuU1LeRHDP4G//lcocRRgymW/6KSkPULRkIMosLv+hfFl0jZ5nL6UumrhzAB3i
CeMF6woWn44MfaqJ9fFfjZM2ToBQo0ALJd5ZtjowBapvTZl9GIEcrZ7+Pw==
=N+Yn
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmfJwCEACgkQYKtH/8kJ
Uif2Og//UMvMtwTWB5xUMks1uHNoM/pajJsVlqfeMPUr7kvpjOjZ8vmAa1mqIBp2
u3KLDq8P336b/m/ct6vt0tX4itfW9YtWasz1bu4u0qs/s/RWjgysJxIvzINfLxpK
vm45pI48LPedoouxa365ATXW8uDQXMdQQK4TECpH3pfNi8tISkQ/8UAV8TiAJAvb
VKwfqcnETMqSXisG5rHNZi7jldzoHn1PEpMtIMkamXrjIZybfWRkSbOcR5S9jLDm
I58OWiIw0qCxTe4wg+qSP8mw8V60RXIf36lJbIjkTinC7o3hEFjkJ9aZk/Rvx/rw
EonGWSezBcaoNUaaYEVqgw0Z+Frk8WC39gyUfBhNhQMaz64OUmqSwah4xn151NRA
aHJMuw7j16BIDYrc4BZzicntOBoStzjkzg3CSj4Q1QobDVYYkvd0wCX5yy0UtYfa
Z3ItaW9VB/VwwIhwQM9z9F1vvEcrdWuKWhdlo5/dsuH6Oll0qLFAi2ye5nHNAyrG
3Rg7g61Hnb20anMNM6/U64tLfwiaO/i+joS9dCFMv6oCLyJhSOJdJJ/FKKHDJVCu
eubtQJv26JUN665H0QWnB9ZmAdIjpOAj8yeC41kapOrBsdYQP5WmSA7ChwG4T5B9
NwuwAuRrk8ItX4VtniWcI5+G4CFdzzCyrfOapflpyfkKqLDm8fc=
=t1ga
-----END PGP SIGNATURE-----
Merge tag 'imx-fixes-6.14' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes
i.MX fixes for 6.14:
- A tqma8mpql board fix from Alexander Stein to correct vqmmc-supply for
usdhc3
- A change from Joe Hattori to fix OF node leak in imx-scu driver probe
- A soc-imx8m driver fix from Peng Fan unregister cpufreq and soc device
in cleanup path
- A couple of changes from Stefan Eichenberger to fix iMX6 Apalis
poweroff and iMX8M verdin-dahlia sound-card descriptions
* tag 'imx-fixes-6.14' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
arm64: dts: freescale: imx8mm-verdin-dahlia: add Microphone Jack to sound card
arm64: dts: freescale: imx8mp-verdin-dahlia: add Microphone Jack to sound card
soc: imx8m: Unregister cpufreq and soc dev in cleanup path
ARM: dts: imx6qdl-apalis: Fix poweroff on Apalis iMX6
arm64: dts: freescale: tqma8mpql: Fix vqmmc-supply
firmware: imx-scu: fix OF node leak in .probe()
Link: https://lore.kernel.org/r/Z8A+rihFV4K3l8QR@dragon
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
for 6.14, please pull the following:
- Phil fixes the Raspberry Pi 5 PL011 UART primecell ID to indicate it
is r1p5 and thus has a 32-byte FIFO
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAme+HGQACgkQh9CWnEQH
BwSK1A/+NmDnvV3wNNtyzeg/6L84dDVOJl40GJ02QnbCNkqvRQQeuWO9L6lPmF2v
9pBqvGHTOtjywEqpsA6ylCpJEGMXQhGcNNPZ/pnnYVb8/cU+9e8Uu+lGvEB2Fb1C
gZ+qk1/Bu2LQeVS8A+VNOCELokLWBtb7HPeHHYmWYmLcRvyG+ZOZHx8D0ekd4y/2
FVjVLDAbDWIUdRofy6bh10w6odXJvBjjXQjnJ3E0f1j7gyFzCUpcqf79z/DBkmZQ
MboX0AxwHocSAjoTXRsau8YuUZLCB6aTNMyMMpLEuzNSFG04GkBmIj9BW410ZxVy
NdDd0CXVn7ypCLxh1y+lnuMBvZBXCSnHkRf8a+HsMAS1oCgEFvq5KGEEB3aZ9WHH
XFvmO6iLW07Rij9/ulKWjsXzAba5rIahF323RZHxO7F0vUj0wcwXOyqdK4MrIt8D
H4TnBD2twTgWCt1jVZVRmp6Tkc/3cLlChCodEBWfLGU99mBrx4vBKtTsPCgapO32
SyLO/bVPnELPaL2cQXkQGcoQyyiRXumXP7KZJOmlAvMXdX1DrMTe5yhL/uBW9hTV
rb7njhzF/a3frO8kpLCQsTVUZT2ZolEkLOENZKp7P+LkiOwQ0XxaJRFhmXr1QnFf
zUjt27oxiIPUiNtBwlfDdV29iu3JKKcCo4T92RtG4YOpVCZHORI=
=ToOt
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmfJwAIACgkQYKtH/8kJ
UidwDg//T/tZHMZ5NqAgJ+pyQw8+oz0dsJmZ3oJUIVpgvuANyxM4t7ADitpdp3NY
L9eYriCfhqQzvxifGrQg1oQwavrddjB3+sQsxcmjXMPWl9BGb5fPCPHL6roZ6G2T
qWxM948/vmbE1Fnj8R56NxbUxyFlAOaoMnDVPok+Uv9quoB3+Kgf8cqrIHWz/Kt3
5nyaMo/yR/G0d3zkzxyT07tHbzCayM07+mG4xgl6JVbVJ0lfv8w0Rynu2RiKtgFj
G2Mn3OFK48maVPuzAoxLwDx+SVHyxSQ4rDbkOwr74+OWq0+3wNE6fGdhTcvITJ9H
WPyjqWdjuWTwTwpiT3kOb1L0ltoBLylkXHgFBEDDeJHf8DWnlh9BD5gn3H7QUL+N
e0eaLPhqFpCP9xXI43ycJ7tANI2k4tn/KERmbCU24s5ErgN8+teNy/MdRxuNuNvK
c+GunafwYC9+XAqQxmgwNw81RROAXD4q5ohQyY+Rcq+553FOGSb2cNhwoT5zwwks
IHpWpt1tV7z+7im0bwyI9WOn92CFlirw+XVmhD9Nib1sAGwGNps3XuKV/QTnc5lJ
NoMaFGxUNHdNZG+cW0yhW1+HtIH8pPf8Uis8FaaDyPYlPJLk68e5P1Ny0S6ui9SP
vPBRRu2tAAElK8fNNnut/P5jnYfJhke9an6d//FYv7skZupjmyI=
=6MuZ
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-6.14/devicetree-arm64-fixes' of https://github.com/Broadcom/stblinux into arm/fixes
This pull request contains Broadcom ARM64-based SoCs Device Tree fixes
for 6.14, please pull the following:
- Phil fixes the Raspberry Pi 5 PL011 UART primecell ID to indicate it
is r1p5 and thus has a 32-byte FIFO
* tag 'arm-soc/for-6.14/devicetree-arm64-fixes' of https://github.com/Broadcom/stblinux:
arm64: dts: bcm2712: PL011 UARTs are actually r1p5
Link: https://lore.kernel.org/r/20250225194041.1063762-2-florian.fainelli@broadcom.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
6.14:
- Stefan fixes the xHCI power domain on the Raspberry Pi 4
- Phil fixes the Raspberry Pi 4 PL011 UART primecell ID to indicate they are
r1p5 and thus have a 32-byte FIFO
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAme+HCwACgkQh9CWnEQH
BwSt1A//YrQYTuDw85E9wbLwIjuy1j5TU4MLYQeN9uNoCC35Nj5UVbgVq0aUgxWm
3I89+M7f1qkj8qEMIH2DnNNgxzk7AlsGPkdp5y8YUeIG99bv5snPVMyZqADGYcKO
6XiS0ORnUvEKggpcTUdDUasGhufc/EwSrYG01iNTK6hyh8bszjp6yDZDgoCK2m/D
J/cCtBJob8lxIR8sxGOeiLVZ/znveN1UY2u9H1JgVQpetReiV7bRII4O3Vf6daJX
s78nu1sGi+oXCf8vt7ssjw8RYB4md9MXZd3BGmM+jJq+PVoUeI2nMhI+qfpTUaYV
GM3Qo7F0LPwvuj6yMlv76mIHyyBsX012bWypRfbvKCwPAtfEdva880c/zYjQ/Rg5
jOMpUp50YlTidujTsUi5ODFBU5ElzEgiMLiMsLjEXan346cmA+qVjmTwLXzMwozR
HhrQvXXetI+5UoFO9xzXi/UqLB6ga2VIKGUfSB+dAxngHipy9goHo+gP+DDulkpF
5U7ldKc2MS0t83pOKM8XAbIgwdz54Qg9TKYAG9szwMCEGNYPXqRavCxouHw6ER+S
J92pI7zVQ+c6SafcFzQm8aV/U8IUywZXwYI2vGTcAXGIVRq7EFxTx56ZzbIML0uM
bTfrCEdoXSA4E57JJt7EhpnSRmIn8t4xwLnKycRGuEsl7x/cF/U=
=alce
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmfJv9AACgkQYKtH/8kJ
Uiej3A//VqVGkTyZWVeEYjFAGBMGMY/BPkQptfi5f3U94yKJhwj2fGTBeciIU5Kk
3QvvAIzZrBh1Nc65gVmkKK0LkvIx2f5xd0e+GIxBJ7pb5sXJmZOoIHCpfruiqFal
3yBe4WKNklzKz7CApa1p4rZ+TrXeWbJXasFzWScch5qygCv15HI4qTuPjA6iuiTi
ejwwgr7hiFTbOJWPsCDQ6lpRpoh6+/1VIcCY0P++jl3ePb0MPedxJ4iVh/0nicZz
YUgCdNJzzAS/s9H1QW8lLpBCe7THie6LEDPV3VMDeQD7a1y0eUpm27Cie+nUvXVH
xOAdT9/G4WPFRPFfx85N5Nsle4Pi2pmT79Ou4RD8JAOh0vR5W9UGn/tpFfASc/DO
1cDC2PMI20E0WWHV6VKF/uXE5ZRWVkhMcqV0jDHZqeZBR6uKoI7vlE1DPJK1afPr
akGPio10/AdQ3W0tKzhpgbPp8xo06N3FWqzzq7b2kYvDwrvCwt2graOtjMMZ3MSm
CasiJ0IfvEfws5O5f3hSGqfYZl9iLw73LTbqAeyy77PuNKwuI/etZIpC4ixk63lw
DHkaGxazIxYhDFDlFx8bt5yW7XZB2f4iEjWQ9VPiaTUg3n7EsaUyc/oL2Z56Zz6J
Q4GIwwaiB7xCg9qrKDXZvwWjs9YLFqLpHRKjHwQYFesyjUQh8Ic=
=Mfaf
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-6.14/devicetree-fixes' of https://github.com/Broadcom/stblinux into arm/fixes
This pull request contains Broadcom ARM-based SoCs Device Tree fixes for
6.14:
- Stefan fixes the xHCI power domain on the Raspberry Pi 4
- Phil fixes the Raspberry Pi 4 PL011 UART primecell ID to indicate they are
r1p5 and thus have a 32-byte FIFO
* tag 'arm-soc/for-6.14/devicetree-fixes' of https://github.com/Broadcom/stblinux:
ARM: dts: bcm2711: PL011 UARTs are actually r1p5
ARM: dts: bcm2711: Fix xHCI power-domain
Link: https://lore.kernel.org/r/20250225194041.1063762-1-florian.fainelli@broadcom.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This patch introduces formal support for shrinking the cache origin by
reducing the cache target length via table reloads. Cache blocks mapped
beyond the new target length must be clean and are invalidated during
preresume. If any dirty blocks exist in the area being removed, the
preresume operation fails without setting the NEEDS_CHECK flag in
superblock, and the resume ioctl returns EFBIG. The cache device remains
suspended until a table reload with target length that fits existing
mappings is performed.
Without this patch, reducing the cache target length could result in
io errors (RHBZ: 2134334), out-of-bounds memory access to the discard
bitset, and security concerns regarding data leakage.
Verification steps:
1. create a cache metadata with some cached blocks mapped to the tail
of the origin device. Here we use cache_restore v1.0 to build a
metadata with one clean block mapped to the last origin block.
cat <<EOF >> cmeta.xml
<superblock uuid="" block_size="128" nr_cache_blocks="512" \
policy="smq" hint_width="4">
<mappings>
<mapping cache_block="0" origin_block="4095" dirty="false"/>
</mappings>
</superblock>
EOF
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"
cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2
dmsetup remove cmeta
2. bring up the cache whilst shrinking the cache origin by one block:
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"
dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"
dmsetup create corig --table "0 524160 linear /dev/sdc 262144"
dmsetup create cache --table "0 524160 cache /dev/mapper/cmeta \
/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
3. check the number of cached data blocks via dmsetup status. It is
expected to be zero.
dmsetup status cache | cut -d ' ' -f 7
In addition to the script above, this patch can be verified using the
"cache/resize" tests in dmtest-python:
./dmtest run --rx cache/resize/shrink_origin --result-set default
Signed-off-by: Ming-Hung Tsai <mtsai@redhat.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
There is a truncation of badblocks length issue when set badblocks as
follow:
echo "2055 4294967299" > bad_blocks
cat bad_blocks
2055 3
Change 'sectors' argument type from 'int' to 'sector_t'.
This change avoids truncation of badblocks length for large sectors by
replacing 'int' with 'sector_t' (u64), enabling proper handling of larger
disk sizes and ensuring compatibility with 64-bit sector addressing.
Fixes: 9e0e252a04 ("badblocks: Add core badblock management code")
Signed-off-by: Zheng Qixing <zhengqixing@huawei.com>
Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Coly Li <colyli@kernel.org>
Link: https://lore.kernel.org/r/20250227075507.151331-13-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
rdev_set_badblocks() only indicates success/failure, so convert its return
type from int to boolean for better semantic clarity.
rdev_clear_badblocks() return value is never used by any caller, convert it
to void. This removes unnecessary value returns.
Also update narrow_write_error() in both raid1 and raid10 to use boolean
return type to match rdev_set_badblocks().
Signed-off-by: Zheng Qixing <zhengqixing@huawei.com>
Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Link: https://lore.kernel.org/r/20250227075507.151331-12-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Change the return type of badblocks_set() and badblocks_clear()
from int to bool, indicating success or failure. Specifically:
- _badblocks_set() and _badblocks_clear() functions now return
true for success and false for failure.
- All calls to these functions are updated to handle the new
boolean return type.
- This change improves code clarity and ensures a more consistent
handling of success and failure states.
Signed-off-by: Zheng Qixing <zhengqixing@huawei.com>
Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Coly Li <colyli@kernel.org>
Acked-by: Ira Weiny <ira.weiny@intel.com>
Link: https://lore.kernel.org/r/20250227075507.151331-11-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The bad blocks check would miss bad blocks when retrying under contention,
as checking parameters are not reset. These stale values from the previous
attempt could lead to incorrect scanning in the subsequent retry.
Move seqlock to outer function and reinitialize checking state for each
retry. This ensures a clean state for each check attempt, preventing any
missed bad blocks.
Fixes: 3ea3354cb9 ("badblocks: improve badblocks_check() for multiple ranges handling")
Signed-off-by: Zheng Qixing <zhengqixing@huawei.com>
Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Coly Li <colyli@kernel.org>
Link: https://lore.kernel.org/r/20250227075507.151331-10-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
There is a merge issue when adding badblocks as follow:
echo 0 10 > bad_blocks
echo 30 10 > bad_blocks
echo 20 10 > bad_blocks
cat bad_blocks
0 10
20 10 //should be merged with (30 10)
30 10
In this case, if new badblocks does not intersect with prev, it is added
by insert_at(). If there is an intersection with prev+1, the merge will
be processed in the next re_insert loop.
However, when the end of the new badblocks is exactly equal to the offset
of prev+1, no further re_insert loop occurs, and the two badblocks are not
merge.
Fix it by inc prev, badblocks can be merged during the subsequent code.
Fixes: aa511ff821 ("badblocks: switch to the improved badblock handling code")
Signed-off-by: Li Nan <linan122@huawei.com>
Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Link: https://lore.kernel.org/r/20250227075507.151331-9-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Regardless of whether overlap_front() returns true or false,
can_merge_front() will be executed first. Therefore, move
can_merge_front() in front of can_merge_front() to simplify code.
Signed-off-by: Li Nan <linan122@huawei.com>
Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Link: https://lore.kernel.org/r/20250227075507.151331-8-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The number of badblocks cannot exceed MAX_BADBLOCKS, but it should be
allowed to equal MAX_BADBLOCKS.
Fixes: aa511ff821 ("badblocks: switch to the improved badblock handling code")
Fixes: c3c6a86e9e ("badblocks: add helper routines for badblock ranges handling")
Signed-off-by: Li Nan <linan122@huawei.com>
Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev>
Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Coly Li <colyli@kernel.org>
Link: https://lore.kernel.org/r/20250227075507.151331-7-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
_badblocks_set() returns success if at least one badblock is set
successfully, even if others fail. This can lead to data inconsistencies
in raid, where a failed badblock set should trigger the disk to be kicked
out to prevent future reads from failed write areas.
_badblocks_set() should return error if any badblock set fails. Instead
of relying on 'rv', directly returning 'sectors' for clearer logic. If all
badblocks are successfully set, 'sectors' will be 0, otherwise it
indicates the number of badblocks that have not been set yet, thus
signaling failure.
By the way, it can also fix an issue: when a newly set unack badblock is
included in an existing ack badblock, the setting will return an error.
···
echo "0 100" /sys/block/md0/md/dev-loop1/bad_blocks
echo "0 100" /sys/block/md0/md/dev-loop1/unacknowledged_bad_blocks
-bash: echo: write error: No space left on device
```
After fix, it will return success.
Fixes: aa511ff821 ("badblocks: switch to the improved badblock handling code")
Signed-off-by: Li Nan <linan122@huawei.com>
Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Coly Li <colyli@kernel.org>
Link: https://lore.kernel.org/r/20250227075507.151331-6-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
In the current handling of badblocks settings, a lot of processing has
been done for scenarios where the number of badblocks exceeds 512.
This makes the code look quite complex and also introduces some issues,
For example, if there is 512 badblocks already:
for((i=0; i<510; i++)); do ((sector=i*2)); echo "$sector 1" > bad_blocks; done
echo 2100 10 > bad_blocks
echo 2200 10 > bad_blocks
Set new one, exceed 512:
echo 2000 500 > bad_blocks
Expected:
2000 500
Actual:
2100 400
In fact, a disk shouldn't have too many badblocks, and for disks with
512 badblocks, attempting to set more bad blocks doesn't make much sense.
At that point, the more appropriate action would be to replace the disk.
Therefore, to resolve these issues and simplify the code somewhat, return
error directly when setting badblocks exceeds 512.
Fixes: aa511ff821 ("badblocks: switch to the improved badblock handling code")
Signed-off-by: Li Nan <linan122@huawei.com>
Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Link: https://lore.kernel.org/r/20250227075507.151331-5-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
If ack and unack badblocks are adjacent, they will not be merged and will
remain as two separate badblocks. Even after the bad blocks are written
to disk and both become ack, they will still remain as two independent
bad blocks. This is not ideal as it wastes the limited space for
badblocks. Therefore, during ack_all_badblocks(), attempt to merge
badblocks if they are adjacent.
Fixes: aa511ff821 ("badblocks: switch to the improved badblock handling code")
Signed-off-by: Li Nan <linan122@huawei.com>
Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Coly Li <colyli@kernel.org>
Link: https://lore.kernel.org/r/20250227075507.151331-4-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
'bb->shift' is used directly in badblocks. It is wrong, fix it.
Fixes: 3ea3354cb9 ("badblocks: improve badblocks_check() for multiple ranges handling")
Signed-off-by: Li Nan <linan122@huawei.com>
Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Coly Li <colyli@kernel.org>
Link: https://lore.kernel.org/r/20250227075507.151331-2-zhengqixing@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Currently, BLK_INTEGRITY_NOGENERATE and BLK_INTEGRITY_NOVERIFY are not
explicitly set during integrity initialization. This can lead to
incorrect reporting of read_verify and write_generate sysfs values,
particularly when a device does not support integrity. Ensure that these
flags are correctly initialized by default.
Reported-by: M Nikhil <nikh1092@linux.ibm.com>
Link: https://lore.kernel.org/linux-block/f6130475-3ccd-45d2-abde-3ccceada0f0a@linux.ibm.com/
Fixes: 9f4aa46f2a ("block: invert the BLK_INTEGRITY_{GENERATE,VERIFY} flags")
Signed-off-by: Anuj Gupta <anuj20.g@samsung.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20250305063033.1813-3-anuj20.g@samsung.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
queue_limits_stack_integrity() incorrectly sets
BLK_INTEGRITY_DEVICE_CAPABLE for a DM device even when none of its
underlying devices support integrity. This happens because the flag is
inherited unconditionally. Ensure that integrity capabilities are
correctly propagated only when the underlying devices actually support
integrity.
Reported-by: M Nikhil <nikh1092@linux.ibm.com>
Link: https://lore.kernel.org/linux-block/f6130475-3ccd-45d2-abde-3ccceada0f0a@linux.ibm.com/
Fixes: c6e56cf6b2 ("block: move integrity information into queue_limits")
Signed-off-by: Anuj Gupta <anuj20.g@samsung.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20250305063033.1813-2-anuj20.g@samsung.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
of_parse_phandle_with_fixed_args() requires its caller to
call into of_node_put() on the node pointer from the output
structure, but such a call is currently missing.
Call into of_node_put() to rectify that.
Fixes: 159f8a0209 ("gpio-rcar: Add DT support")
Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20250305163753.34913-2-fabrizio.castro.jz@renesas.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
raid10_handle_discard should wait barrier before returning a discard bio
which has REQ_NOWAIT. And there is no need to print warning calltrace
if a discard bio has REQ_NOWAIT flag. Quality engineer usually checks
dmesg and reports error if dmesg has warning/error calltrace.
Fixes: c9aa889b03 ("md: raid10 add nowait support")
Signed-off-by: Xiao Ni <xni@redhat.com>
Acked-by: Coly Li <colyli@kernel.org>
Link: https://lore.kernel.org/linux-raid/20250306094938.48952-1-xni@redhat.com
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
That was purely for the transition from static to dynamic dma-buf
handling and can be removed again now.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250211163109.12200-5-christian.koenig@amd.com
As a workaround to smoothly transit from static to dynamic DMA-buf
handling we cached the sg_table on attach if dynamic handling mismatched
between exporter and importer.
Since Dmitry and Thomas cleaned that up and also documented the lock
handling we can drop this workaround now.
V2: implement Sima's comments
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20250211163109.12200-4-christian.koenig@amd.com
The fence_value_str and timeline_value_str callbacks were just an
unnecessary abstraction in the SW sync implementation.
The only caller of those callbacks already knew that the fence in
questions is a timeline_fence. So print the values directly instead
of using a redirection.
Additional to that remove the implementations from virtgpu and vgem.
As far as I can see those were never used in the first place.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20250211163109.12200-3-christian.koenig@amd.com
There isn't much worse than documentation giving an incorrect advise.
Grabbing a spinlock while interrupts are disabled usually means that you
must also disable interrupts for all other uses of this spinlock.
Otherwise really hard to debug issues can occur. So fix that invalid
documentation.
v2: use Dmitry's suggestion on the documentation
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch> (v1)
Link: https://patchwork.freedesktop.org/patch/msgid/20250211163109.12200-2-christian.koenig@amd.com
MNT Reform 2 is an open source laptop with replaceable CPU modules,
including a version with the RK3588-based MNT RCORE[1], which is based
on Firefly's iCore-3588Q SoM:
- Rockchip RK3588
- Quad A76 and Quad A55 CPU
- 6 TOPS NPU
- up to 32GB LPDDR4x RAM
- SD Card slot
- Gigabit ethernet port
- HDMI port
- 2x mPCIe ports for WiFi or NVMe
- 3x USB 3.0 Type-A HOST port
[1] https://shop.mntre.com/products/mnt-reform
Co-developed-by: "Lukas F. Hartmann" <lukas@mntre.com>
Signed-off-by: "Lukas F. Hartmann" <lukas@mntre.com>
Signed-off-by: Patrick Wildt <patrick@blueri.se>
Link: https://lore.kernel.org/r/Z8S6uDM634KJuyKP@windev.fritz.box
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Document board compatible bindings for the MNT Reform 2 with it's RCORE
SoM, which is based on Firefly's iCore-3588Q.
Signed-off-by: Patrick Wildt <patrick@blueri.se>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/Z8S5SHqUqKYiT6Wd@windev.fritz.box
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add btrfs_free_chunk_map() to free the memory allocated
by btrfs_alloc_chunk_map() if btrfs_add_chunk_map() fails.
Fixes: 7dc66abb5a ("btrfs: use a dedicated data structure for chunk maps")
CC: stable@vger.kernel.org
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
Signed-off-by: David Sterba <dsterba@suse.com>
We currently call intel_set_cdclk_post_plane_update() far
too early. When pipes are active during the reprogramming
the current spot only works for the cd2x divider update
case, as that is synchronize to the pipe's vblank. Squashing
and crawling are not synchronized in any way, so doing the
programming while the pipes/planes are potentially still using
the old hardware state could lead to underruns.
Move the post plane reprgramming to a spot where we know
that the pipes/planes have switched over the new hardware
state.
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250218211913.27867-2-ville.syrjala@linux.intel.com
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
The devm_ioremap() function returns NULL on error, it doesn't return
error pointers. Fix the check to match.
Fixes: 79b8a705e2 ("spi: stm32: Add OSPI driver")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Link: https://patch.msgid.link/bc4c9123-df43-4616-962f-765801d30b4c@stanley.mountain
Signed-off-by: Mark Brown <broonie@kernel.org>
The custom suspend function causes a build warning when CONFIG_PM_SLEEP
is disabled:
sound/soc/codecs/cs42l43.c:2405:12: error: unused function 'cs42l43_codec_runtime_force_suspend' [-Werror,-Wunused-function]
Change SET_SYSTEM_SLEEP_PM_OPS() to the newer SYSTEM_SLEEP_PM_OPS(),
to avoid this.
Fixes: 164b7dd454 ("ASoC: cs42l43: Add jack delay debounce after suspend")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250305172738.3437513-1-arnd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The changes to DECLARE_ADAU17X1_DSP_MUX_CTRL did avoid the issue with a
compiler not liking all the macro indirection. However it introduced a
new issue with respect to the mux not being declared static:
sound/soc/codecs/adau17x1.c:275:8: sparse: sparse: symbol
'adau17x1_dac_mux' was not declared. Should it be static?
sound/soc/codecs/adau17x1.c:278:8: sparse: sparse: symbol
'adau17x1_capture_mux' was not declared. Should it be static?
Fix this up by going back to the inline declaration of the soc_enum, but
just call SOC_ENUM_EXT directly rather than indirecting through
SOC_DAPM_ENUM_EXT.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202503061119.4QGlnOi6-lkp@intel.com/
Fixes: c951b20766 ("ASoC: dapm: Use ASoC control macros where possible")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250306104233.1638625-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
After the erdma_cep_put(new_cep) being called, new_cep will be freed,
and the following dereference will cause a UAF problem. Fix this issue.
Fixes: 920d93eac8 ("RDMA/erdma: Add connection management (CM) support")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Cheng Xu <chengyou@linux.alibaba.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Add compatible string for VPU GRF found on RK3528 SoC.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Acked-by: "Rob Herring (Arm)" <robh@kernel.org>
Link: https://lore.kernel.org/r/20250305194217.47052-3-ziyao@disroot.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add compatible string for VO GRF found on RK3528 SoC.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Acked-by: "Rob Herring (Arm)" <robh@kernel.org>
Link: https://lore.kernel.org/r/20250305194217.47052-2-ziyao@disroot.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Rockchip RK3588 has a built-in HDMI receiver block from
Synopsys. Let's enable the driver for it.
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://lore.kernel.org/r/20250306072842.287142-4-dmitry.osipenko@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The call to flush_work before tearing down a table from the netlink
notifier was supposed to make sure that all earlier updates (e.g. rule
add) that might reference that table have been processed.
Unfortunately, flush_work() waits for the last queued instance.
This could be an instance that is different from the one that we must
wait for.
This is because transactions are protected with a pernet mutex, but the
work item is global, so holding the transaction mutex doesn't prevent
another netns from queueing more work.
Make the work item pernet so that flush_work() will wait for all
transactions queued from this netns.
A welcome side effect is that we no longer need to wait for transaction
objects from foreign netns.
The gc work queue is still global. This seems to be ok because nft_set
structures are reference counted and each container structure owns a
reference on the net namespace.
The destroy_list is still protected by a global spinlock rather than
pernet one but the hold time is very short anyway.
v2: call cancel_work_sync before reaping the remaining tables (Pablo).
Fixes: 9f6958ba2e ("netfilter: nf_tables: unconditionally flush pending work before notifier")
Reported-by: syzbot+5d8c5789c8cb076b2c25@syzkaller.appspotmail.com
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
The i.MX8QM and i.MX8QXP/DXP have an additional interrupt for DMA.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250225102726.654070-2-alexander.stein@ew.tq-group.com
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Formalise the binding for the PCI controllers in the Freescale MPC8xxx
chip family. Information about PCI-X-specific properties was taken from
fsl,pci.txt. The examples were taken from mpc8315erdb.dts and
xpedite5200_xmon.dts.
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250220-ppcyaml-pci-v3-1-ca94a4f62a85@posteo.net
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Document the PCIe controller on IPQ5332 platform. IPQ5332 will use
IPQ9574 as the compatible fallback in the future.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
Link: https://lore.kernel.org/r/20250220094251.230936-6-quic_varada@quicinc.com
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Background:
===========
Currently kernel-mode FPU is not always usable in softirq context on
x86, since softirqs can nest inside a kernel-mode FPU section in task
context, and nested use of kernel-mode FPU is not supported.
Therefore, x86 SIMD-optimized code that can be called in softirq context
has to sometimes fall back to non-SIMD code. There are two options for
the fallback, both of which are pretty terrible:
(a) Use a scalar fallback. This can be 10-100x slower than vectorized
code because it cannot use specialized instructions like AES, SHA,
or carryless multiplication.
(b) Execute the request asynchronously using a kworker. In other
words, use the "crypto SIMD helper" in crypto/simd.c.
Currently most of the x86 en/decryption code (skcipher and aead
algorithms) uses option (b), since this avoids the slow scalar fallback
and it is easier to wire up. But option (b) is still really bad for its
own reasons:
- Punting the request to a kworker is bad for performance too.
- It forces the algorithm to be marked as asynchronous
(CRYPTO_ALG_ASYNC), preventing it from being used by crypto API
users who request a synchronous algorithm. That's another huge
performance problem, which is especially unfortunate for users who
don't even do en/decryption in softirq context.
- It makes all en/decryption operations take a detour through
crypto/simd.c. That involves additional checks and an additional
indirect call, which slow down en/decryption for *everyone*.
Fortunately, the skcipher and aead APIs are only usable in task and
softirq context in the first place. Thus, if kernel-mode FPU were to be
reliably usable in softirq context, no fallback would be needed.
Indeed, other architectures such as arm, arm64, and riscv have already
done this.
Changes implemented:
====================
Therefore, this patch updates x86 accordingly to reliably support
kernel-mode FPU in softirqs.
This is done by just disabling softirq processing in kernel-mode FPU
sections (when hardirqs are not already disabled), as that prevents the
nesting that was problematic.
This will delay some softirqs slightly, but only ones that would have
otherwise been nested inside a task context kernel-mode FPU section.
Any such softirqs would have taken the slow fallback path before if they
tried to do any en/decryption. Now these softirqs will just run at the
end of the task context kernel-mode FPU section (since local_bh_enable()
runs pending softirqs) and will no longer take the slow fallback path.
Alternatives considered:
========================
- Make kernel-mode FPU sections fully preemptible. This would require
growing task_struct by another struct fpstate which is more than 2K.
- Make softirqs save/restore the kernel-mode FPU state to a per-CPU
struct fpstate when nested use is detected. Somewhat interesting, but
seems unnecessary when a simpler solution exists.
Performance results:
====================
I did some benchmarks with AES-XTS encryption of 16-byte messages (which is
unrealistically small, but this makes it easier to see the overhead of
kernel-mode FPU...). The baseline was 384 MB/s. Removing the use of
crypto/simd.c, which this work makes possible, increases it to 487 MB/s,
a +27% improvement in throughput.
CPU was AMD Ryzen 9 9950X (Zen 5). No debugging options were enabled.
[ mingo: Prettified the changelog and added performance results. ]
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Uros Bizjak <ubizjak@gmail.com>
Link: https://lore.kernel.org/r/20250304204954.3901-1-ebiggers@kernel.org
Since commit 5f73e7d038 ("kbuild: refactor cross-compiling
linux-headers package"), the linux-headers pacman package fails
to build when "O=" is set. The build system complains:
/mnt/chroot/linux/scripts/Makefile.build:41: mnt/chroots/linux-mainline/pacman/linux-upstream/pkg/linux-upstream-headers/usr//lib/modules/6.14.0-rc3-00350-g771dba31fffc/build/scripts/Makefile: No such file or directory
This is because the "srcroot" variable is set to "." and the
"build" variable is set to the absolute path. This makes the
"src" variables point to wrong directory.
Change the "build" variable to a relative path to "." to
fix build.
Fixes: 5f73e7d038 ("kbuild: refactor cross-compiling linux-headers package")
Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Since pci_get_domain_bus_and_slot() can return NULL, add NULL check for
pci_gfx_root in the mid_get_vbt_data().
This change is similar to the checks implemented in mid_get_fuse_settings()
and mid_get_pci_revID(), which were introduced by commit 0cecdd818c
("gma500: Final enables for Oaktrail") as "additional minor
bulletproofing".
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: f910b41105 ("gma500: Add the glue to the various BIOS and firmware interfaces")
Signed-off-by: Ivan Abramov <i.abramov@mt-integration.ru>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250306112046.17144-1-i.abramov@mt-integration.ru
Jann reported a possible issue when trampoline_check_ip returns
address near the bottom of the address space that is allowed to
call into the syscall if uretprobes are not set up:
https://lore.kernel.org/bpf/202502081235.5A6F352985@keescook/T/#m9d416df341b8fbc11737dacbcd29f0054413cbbf
Though the mmap minimum address restrictions will typically prevent
creating mappings there, let's make sure uretprobe syscall checks
for that.
Fixes: ff474a78ce ("uprobe: Add uretprobe syscall to speed up return probe")
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Kees Cook <kees@kernel.org>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Acked-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250212220433.3624297-1-jolsa@kernel.org
Use fault injection infrastructure to allow specific functions to
be configured over debugfs for failing during the execution of
xe_exec_queue_create_ioctl(). xe_exec_queue_destroy_ioctl() and
xe_exec_queue_get_property_ioctl() are not considered as there is
no unwinding code to test with fault injection.
This allows more thorough testing from user space by going through
code paths for error handling and unwinding which cannot be reached
by simply injecting errors in IOCTL arguments. This can help
increase code robustness.
The corresponding IGT series is:
https://patchwork.freedesktop.org/series/144138/
Reviewed-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250305150659.46276-1-francois.dugast@intel.com
Signed-off-by: Francois Dugast <francois.dugast@intel.com>
The correct name for FE990 is FE990A so use it in order to avoid
confusion with FE990B.
Cc: stable@vger.kernel.org
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
