drm_sched_backend_ops.timedout_job()'s documentation is outdated. It
mentions the deprecated function drm_sched_resubmit_jobs(). Furthermore,
it does not point out the important distinction between hardware and
firmware schedulers.
Since firmware schedulers typically only use one entity per scheduler,
timeout handling is significantly more simple because the entity the
faulted job came from can just be killed without affecting innocent
processes.
Update the documentation with that distinction and other details.
Reformat the docstring to work to a unified style with the other
handles.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250305130551.136682-5-phasta@kernel.org
drm_sched_backend_ops.run_job() returns a dma_fence for the scheduler.
That fence is signalled by the driver once the hardware completed the
associated job. The scheduler does not increment the reference count on
that fence, but implicitly expects to inherit this fence from run_job().
This is relatively subtle and prone to misunderstandings.
This implies that, to keep a reference for itself, a driver needs to
call dma_fence_get() in addition to dma_fence_init() in that callback.
It's further complicated by the fact that the scheduler even decrements
the refcount in drm_sched_run_job_work() since it created a new
reference in drm_sched_fence_scheduled(). It does, however, still use
its pointer to the fence after calling dma_fence_put() - which is safe
because of the aforementioned new reference, but actually still violates
the refcounting rules.
Move the call to dma_fence_put() to the position behind the last usage
of the fence.
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250305130551.136682-4-phasta@kernel.org
When GENERIC_IRQ_CHIP is disabled, OMAP1 kernels fail to link:
arm-linux-gnueabi-ld: arch/arm/mach-omap1/irq.o: in function `omap1_init_irq':
irq.c:(.init.text+0x1e8): undefined reference to `irq_alloc_generic_chip'
arm-linux-gnueabi-ld: irq.c:(.init.text+0x228): undefined reference to `irq_setup_generic_chip'
arm-linux-gnueabi-ld: irq.c:(.init.text+0x2a8): undefined reference to `irq_gc_set_wake'
arm-linux-gnueabi-ld: irq.c:(.init.text+0x2b0): undefined reference to `irq_gc_mask_set_bit'
arm-linux-gnueabi-ld: irq.c:(.init.text+0x2b4): undefined reference to `irq_gc_mask_clr_bit'
This has apparently been the case for many years, but I never caught it
in randconfig builds until now, as there are dozens of other drivers
that also 'select GENERIC_IRQ_CHIP' and statistically there is almost
always one of them enabled.
Fixes: 55b4477443 ("ARM: OMAP1: Switch to use generic irqchip in preparation for sparse IRQ")
Link: https://lore.kernel.org/r/20250205121151.289535-1-arnd@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The documentation for drm_sched_backend_ops.run_job() mentions a certain
function called drm_sched_job_recovery(). This function does not exist.
What's actually meant is drm_sched_resubmit_jobs(), which is by now also
deprecated.
Furthermore, the scheduler expects to "inherit" a reference on the fence
from the run_job() callback. This, so far, is also not documented.
Remove the mention of the removed function.
Discourage the behavior of drm_sched_backend_ops.run_job() being called
multiple times for the same job.
Document the necessity of incrementing the refcount in run_job().
Acked-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250305130551.136682-3-phasta@kernel.org
A single fix for an incorrect define in the jh7110 pinctrl header.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZ8hOeAAKCRB4tDGHoIJi
0ti5AQD7CJrTmBBqP5nxQHvgvz1KSSqfzpOMrtA3YpOkDaqYigD/Ww6z12oSHFuK
lLFSnpVJLqFd01N0wP1e+TUrbZ++Hg4=
=WHwP
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmfJwJIACgkQYKtH/8kJ
Uidt6RAApTAvDdwAR4FAxHqSCK+mJkC7njGkGr5t1xNBFpWdKwsONdet84ErEEzl
ift1XFMWwZ98jIR4cHAnsPinHyFZUDH48rOJw8AmygSaikmaH27604lqLF+i55nV
JjqBrQDCA3T6haH/1uM6+Te8c7FH/klG6sAymZs+x+l8UER2l4U8eNThaU0Xk1/n
ZMXQK/R1buv+6oGeY5mXNkdIerXM9fz/BjwcfECwZHyTk5gMTrwzM+6emlo78Y/V
OvnX/FJOGZ3MNL/rj9LDFu8QDqYf7p7D7fkYpGqRgScFs6LMTjKb37uCVfU7i4i8
4zMwUZjwOkaJOxBgnDHmySCLmlBhcj0FN34kRsVgdqG5YAYzcTzTBdBPeOjNCDpa
7i8kg3mJQD5hVbZFHWIvTqpBXOxFJTKKbU+W8dmlTsB7DyK4uV3WPym+MnqIZWw/
+xcBi7dJZEyMaEThuWjCfTrJu0rWJg3WeZjFLgxoiz+yB0NzDivXMN7lrmoYe/1U
dIoP4yDCOzVmJIeW9CIXVd/sXTOHPVaWRSUV0dqjHYefUl/wz9Mo55DbTT+JK9Ng
0d1iSQBmz/M5ThjYGDBYW1Ltq7zwSDxBIHwVBkKpopRPanbXSYHsByTMB3LNGDn1
Uou9MCr65MqZNajbk+vE1kEvAke47+/SHau9arFVtkjcA0srdcE=
=qqLw
-----END PGP SIGNATURE-----
Merge tag 'riscv-dt-fixes-for-v6.14-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes
RISC-V Devicetree fix for v6.14-rc6
A single fix for an incorrect define in the jh7110 pinctrl header.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
* tag 'riscv-dt-fixes-for-v6.14-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux:
riscv: dts: starfive: Fix a typo in StarFive JH7110 pin function definitions
Link: https://lore.kernel.org/r/20250305-sip-unable-d56ef7dbf86b@spud
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- 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>
