pull the following:
- Andrea adds the RP1 entry for all of the drivers pertaining to that
chip
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmhi3v0ACgkQh9CWnEQH
BwT2ng//UIA/GNT+ounrsubIjZf0CuNQfY2HlOlZ5n7ZsZT+umHf5Np8QVE1YVqT
aNz3VGESkRddFOVGBv3jDvZAETsAIC/0w3SO0k/pifh584+TAmKlO44Ft15LCDH9
59DfWQjcPufxN3aOQ7nUeS3Ad5L2cz1cp7Bc04y1ioq211lYmV5mt+WXsmS6J876
QpLcBw9AunQPmggnCV9Kp9je07x16Ql4wIC/pW4BEJittKEnPh6PY0wEuVwQn6+W
LYcP9F18SC+JhjnvZpaGYB8bI9x9ZpXdxAGusnJeIQrsWQ0l2el8KYShUBh9kIcw
xMA91RwbRrEXC6esIBq5JxyI9nHNrzC1xg9ifHbgYP/9DXZJvGTP1bHj9haMosNh
EF9/T4EXJaHnat0evz/PwE1609vDQ/GFf1cZRCD+yySX57ktsPs4dAFyBKPuBglm
QMWrWotZKPbWZwUR1RGu0iLtRQzif06jjrkgcxY/dG9gLLiaUSDpBMpfPa3A9fNk
2l9dLim7ObY0GymzitYgwdwOy4IxDpdHa6oDZPRd8Sh9K9HdPk0d6ZecOQXIr0Wo
xavnmRi5qAFE1zEFVMRPlMJU1r63QIgfFPzS8Q9a4xEizeCet4mRlnvFkT9Jqqk/
5FpDWMFz5PhHL/bDV5WaC8iBQagRQ+44DKcrhY/JAM4wcmh/inI=
=EoAs
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmh+VQwACgkQmmx57+YA
GNmB3RAAudz9gJiaZ+4NXhcComj/N4NiGbE0azDPApCD3W4D4vnDPGbl7CNq07Tg
wtUMseP/sMxIUILzCoCwwCZf1Kq+OeauYEfKkgiekJ4nj6Phz7BSUUr+TjbQcHLD
vz42gOyNpbjbD33gK98Xha1NnIHHOfvj7y4CnW++8TPA/BPVcGQTMFtefLo9eSL6
c4DxjtngqEc1+AUrLRyeLWBb0WSMRRjKzTLrBmYXTS5PLKeVirnyN7s4jsPkcMX7
cqOQPyHe6fgSWRFoIRzjWSB93NLtbEMTJ522DlEStBlyuRso6bRdPGC2wrzOZ1Cm
rxr1xq9DBvhqmlZWXjuJVRF5GOgRhRVFys7IR+oikpRNJOhnHIXoq3iKJX/mFgkH
awOCp1WRJY2gGDiz2tfugeKzE+MUTctA69rIjmIP7YBiT0mFeQxIjmmE/snpyGpy
Z8wb4QYyyJmq9q+xqfgFvNITiJUjSSbcB421RNmkp6Wfr0Zb8o3qMYu6dPXKYu9K
h72aBVQv1ecpeDxBSbOAyYPy1Hf9t6IVBLaPp7N9eFCS/N46TY6apeFthcL4QKxF
KH10xAaP9HGI0AoIizu76QagjzWC5QwVpzeegGU/P1NbRFcD6ZXOfn0hu0l6iOL8
otV0wOFsd+Ez9HiAJ9rQ/2IS0WqZVIPc838txtXcvSrW12FEgp4=
=wV2B
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-6.17/maintainers' of https://github.com/Broadcom/stblinux into soc/drivers
This pull request contains MAINTAINERS file updates for 6.17, please
pull the following:
- Andrea adds the RP1 entry for all of the drivers pertaining to that
chip
* tag 'arm-soc/for-6.17/maintainers' of https://github.com/Broadcom/stblinux:
MAINTAINERS: add Raspberry Pi RP1 section
Link: https://lore.kernel.org/r/20250630190216.1518354-5-florian.fainelli@broadcom.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCgA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmh9azkeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiG7GIH/0lpQtHRl6N+q2Qs
v75iG2ZouWyw2JlhUOHAToKU58MZqqTXLZzc8ZdY6fAd7DpXWKRGSDsyWVyLbUkt
UKGzXEIJsHXYvw2QIPbhkY9gQBWpdZTh4tHztFyKb0QLn81qkibVP6ChOwSzOGa/
xUyQ5v6yH+JvQlnQaCgy6hi7cMrLNSNZmuIjy0yc5Y153YPEtX5OUPO2PstpUx5r
AuiOhU4ewW9QCe07X/Pk7tdn0T2Jg8Kwk1FViaM0RBUf/0GXGfsovIxpUP/eCyMc
MA+9SXXLlDa/4Z8w3EsQYx6m2MnNmm0HPeevCmWqq3+Ocooik4si1BpzHfUaE6n/
/0D8zBg=
=NzEi
-----END PGP SIGNATURE-----
Merge tag 'v6.16-rc7' into tty-next
We need the tty/serial fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Enable Andes SoC config in defconfig to allow the default
upstream kernel to boot on Voyager board.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
Link: https://lore.kernel.org/r/20250711133025.2192404-9-ben717@andestech.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Introduce the device tree support for Voyager development board.
Currently only support booting into console with only uart,
other features will be added later.
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
Link: https://lore.kernel.org/r/20250711133025.2192404-8-ben717@andestech.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Add the DT binding documentation for Andes machine timer.
The RISC-V architecture defines a machine timer that provides a real-time
counter and generates timer interrupts. Andes machiner timer (PLMT0) is
the implementation of the machine timer, and it contains memory-mapped
registers (mtime and mtimecmp). This device supports up to 32 cores.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
Link: https://lore.kernel.org/r/20250711133025.2192404-6-ben717@andestech.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Add the DT binding documentation for Andes machine-level software
interrupt controller.
In the Andes platform such as QiLai SoC, the PLIC module is instantiated a
second time with all interrupt sources tied to zero as the software
interrupt controller (PLICSW). PLICSW can generate machine-level software
interrupts through programming its registers.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
Link: https://lore.kernel.org/r/20250711133025.2192404-5-ben717@andestech.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Add a new compatible string for Andes QiLai PLIC.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
Link: https://lore.kernel.org/r/20250711133025.2192404-4-ben717@andestech.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Add DT binding documentation for the Andes QiLai SoC and the
Voyager development board.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
Link: https://lore.kernel.org/r/20250711133025.2192404-3-ben717@andestech.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This adds a single cleanup commit for the mtk-mutex driver,
clarifying the usage of the MUTEX_MOD1, MUTEX_MOD2 registers
for applying display controller sub-component mute settings
on all MediaTek SoCs.
-----BEGIN PGP SIGNATURE-----
iJ4EABYKAEYWIQQn3Xxr56ypAcSHzXSaNgTPrZeEeAUCaHDEnSgcYW5nZWxvZ2lv
YWNjaGluby5kZWxyZWdub0Bjb2xsYWJvcmEuY29tAAoJEJo2BM+tl4R4HTEBAMK9
47KycyByOmJY01X+usWVfo2omdHJvcpgp9wmOXS7AQCfWfBhKGIG51SHQjmPaQJh
XPyGUOMV54hbvA+3/p+iBg==
=di4q
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmh+U4cACgkQmmx57+YA
GNmfMg//Sm2efrPXfOq1OI5H1rIybp3vfKcR12tNitDyTkKSGB0D+CMs8XfwelVu
mEhf2WHn42WfQJYRbqcohQrELImaEGsFuM6P0po4fPXic8uyTZTO7orObuUZpHbg
J3PGeHeo6l1Pp4TedzEG/7oJXz/DXRTgOSuUVmgE15DueX/ZxLH+56+LxI1AEmg5
kynIC5w3fup/e0IKsdlELCZmLTOsv4RI+vAR2hza361KGbMw/ZXGR2d/VdL1wLak
25vOa0SYmPeWpWZKxEEp7Hfa9LgyzahfZVZ2kzB0xfMwbFzTGtoYd9TuLZwPGN2h
v4bZtuhF5GYlns5orSXO0OR6kHihw/fbY8JkiNY6JEfZMp+jSYfmKkxZOTr/85sU
uSVfHg6NgDR5+caef8tup//oPP7LlKCD+ggaHsitOFKucfZveHsVPA0xaOJRDHWa
k6fXvF+n/yfH2HtkphckeZ/m5GKjzQI663OzKXie/6lTtUYHJeS4fF9x8Z6Wgp2m
4ja79UiEWM+ZzVJ1tt7hcCEK4z7kvhEwuy91PbXeYKfIeyr6YPlPi9qcjO1beD9b
mn2udXtwv42kO6vMxZIetiSp6JYpo1oBiVvTiwoHQR3lClm/CNAq2AcuESWvTlm0
FTIkZwlV6eXt9Jln5yE5cUSMHVuvM9Z24yc6kPLIFb3DkosSYpo=
=fVc1
-----END PGP SIGNATURE-----
Merge tag 'mtk-soc-for-v6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into soc/drivers
MediaTek soc driver updates for v6.17
This adds a single cleanup commit for the mtk-mutex driver,
clarifying the usage of the MUTEX_MOD1, MUTEX_MOD2 registers
for applying display controller sub-component mute settings
on all MediaTek SoCs.
* tag 'mtk-soc-for-v6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux:
soc: mediatek: mtk-mutex: Fix confusing usage of MUTEX_MOD2
Link: https://lore.kernel.org/r/20250711083656.33538-4-angelogioacchino.delregno@collabora.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
DRM_DEBUG_SELFTEST was removed in commit fc8d29e298 (drm: selftest:
convert drm_mm selftest to KUnit) and all functions under it were
converted to KUnit, under the DRM_KUNIT_TEST option
This conversion however did not occur in the Kconfig.debug file in the
i915 directory.
This patch replaces the select for DRM_DEBUG_SELFTEST, an option that no
longer exists, with the correct select, DRM_KUNIT_TEST.
Signed-off-by: Ruben Wauters <rubenru09@aol.com>
Link: https://lore.kernel.org/r/20250701115511.5445-1-rubenru09@aol.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
There is a extraneous space before a newline in a pr_warn message.
Remove it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://patch.msgid.link/20250721135016.2500117-1-colin.i.king@gmail.com
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
- Use dev_fwnode() instead of of_fwnode_handle()
- Use new GPIO line value setter callbacks
-----BEGIN PGP SIGNATURE-----
iJIEABYKADoWIQQQ/+b4s5DeF6zCYyNoqS/rAbjdeAUCaG9cHRwcY2hyaXN0b3Bo
ZS5sZXJveUBjc2dyb3VwLmV1AAoJEGipL+sBuN14RH0A/RtUuPKD0WO77GCuKyWm
/k0NfZn/QnpR2m1+WPQ5EjRwAP4qsR5bEAM7OY8m+BBdZPgWR3Si5l3zH11KEm8p
RlpECw==
=ehqy
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmh+Uo0ACgkQmmx57+YA
GNlnVA//Wn6thIIadTjlVarRQ8uV5V3ATR0ipKpP1bNSJA46EMj5fG32w02iD3P2
h5OgJ8xQUlnxMrbDIfctPEtF7N0uodE/KfW3d4Cgl5jHYS1QVZUFDHIkMD2QZy0j
yuz265Cpv4jRIQBQP6d+2dEVY+hHF499hIUMKa33k7zf+X2zxLl07iYbjEvTQ5a7
26K7HHNDJg+AgjzPzfmCkXiz8bM8/bKZ45UvwaWU/jr4U/cdrWl/1KCUKWqupDol
wW7EDO8XVKxsbUpqV9Nknh9vFZJxhDVlIxP6Pkwa671vuzedm4faeXIL3P/dc6OB
0JA3wgPLlEJ248xdkAr3EbIvEeoE60VISHFobkks4juY573G2GGRnStVBjukDSMY
fKMDEAXu6yAhB7evvyh+lI+thhNYxxYJLb3aX6xL27zR28qpWdA7uHFCGHsB8IP/
2Pt7hBVu4sXNeas/a/zXMwZkSe2L5LNYUKOIT6aQMrp3Dq9+okBezkHsbVR2K3I2
Ehr1TQYPUw9XVoze1hvceTfCYa+tLkPkA815qYGSD+jE5h/5BRYvDETOol6Aw1wU
rzo0x4ZBQ6RcHffzZFfWk/xHk1fyejjS+zJ6Glk2uapsI5UKGHXtoZMpUczfJJ86
qDAQGpllNMItjatVwvLVXUBChebDeTEazHnUhdYo1Rin5G3+GI8=
=pjEW
-----END PGP SIGNATURE-----
Merge tag 'soc_fsl-6.17-1' of https://github.com/chleroy/linux into soc/drivers
FSL SOC Changes for 6.17:
- Use dev_fwnode() instead of of_fwnode_handle()
- Use new GPIO line value setter callbacks
* tag 'soc_fsl-6.17-1' of https://github.com/chleroy/linux:
soc: Use dev_fwnode()
soc: fsl: qe: use new GPIO line value setter callbacks
Link: https://lore.kernel.org/r/c947d537-cae5-44f0-abd8-0c558bac46d2@csgroup.eu
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The ASPEED LPC snoop driver was recently the cause of some concern. In addition
to the initial fixes, the channel configuration paths are refactored to improve
robustness against errors.
-----BEGIN PGP SIGNATURE-----
iJIEABYIADoWIQSoUT1x3bOSX/nAa8ajM9GZTrjhpgUCaGyE5RwcYW5kcmV3QGNv
ZGVjb25zdHJ1Y3QuY29tLmF1AAoJEKMz0ZlOuOGmuHQA/2nA+lhSqWy3hjK9eada
/l5d0ffV8jhbmMfWDUhcxrELAP40xkUSUdJD31LRrU/FDGjv7CIznZIldiSlD6tE
JSNyDQ==
=SNkf
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmh+UmAACgkQmmx57+YA
GNkWEQ/9G+zYrNpGXmRhvdXmiSEs0/d9V9qfCdr26dwFR0F6lsFPtm/TJ+Fqi2fJ
dV2RkJx2+31XzapxKrlyT9L7IMZ4OtfhN+MhFCqv0cB1HDSnxVQKue9/0BsomRUd
8ZpV5GUTHrYPQvqJUN/eK8BO4INqEnp6XZ9ArTzRDUvbOiCSLzXP8nVaHwSbq3WB
FqwbMKMah26sW+PgokEhG4Xopa27pN4wbD+0/d3NFFXFDE/KUNBGtxEKz1NOr7qx
nnpMBZ7KWIg7UltiZ3h6by5yiVQYOW8ekS+j1GcrHLN++LPEJhYlk/Ab91jxCln3
/U+aWlbQuYiqVVZINeks/RyOhwB8eofV0OvqAJu3TmnkZq28w22cTJESvs5KO3d9
eKXTd8Xz4mimK9ov8xKof0G/CN4m38FdwSr6YsjIZhWYVh64z0AtA3DlyXbRBjbV
EY1ePVZZy3S56LdPDk/ADxtHHDC0PL/nIupeCwQLr9GYZeJQrRkPNV9CS8sJeW+o
YPWM/14V4jCxERauUkCimLDOnRgD+9TVEdS5+a5gz2Bdw3YQCOzyJgqHj8STXlYV
zZt3NGbb3WC9NXy8EW2U8nyRRg1w1KDQU1d+T6VF7m1WVG8+mbXqVNTw7cUKEsCu
1MO5V8AfFqyA0fKSN8bGX/5j671u/v611gZGetpwRg135HP46j0=
=CrwR
-----END PGP SIGNATURE-----
Merge tag 'aspeed-6.17-drivers-1' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux into soc/drivers
ASPEED SoC driver updates for 6.17
The ASPEED LPC snoop driver was recently the cause of some concern. In addition
to the initial fixes, the channel configuration paths are refactored to improve
robustness against errors.
* tag 'aspeed-6.17-drivers-1' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux:
soc: aspeed: lpc-snoop: Lift channel config to const structs
soc: aspeed: lpc-snoop: Consolidate channel initialisation
soc: aspeed: lpc-snoop: Use dev_err_probe() where possible
soc: aspeed: lpc-snoop: Switch to devm_clk_get_enabled()
soc: aspeed: lpc-snoop: Rearrange channel paths
soc: aspeed: lpc-snoop: Rename 'channel' to 'index' in channel paths
soc: aspeed: lpc-snoop: Constrain parameters in channel paths
soc: aspeed: lpc-snoop: Ensure model_data is valid
soc: aspeed: lpc-snoop: Don't disable channels that aren't enabled
soc: aspeed: lpc-snoop: Cleanup resources in stack-order
Link: https://lore.kernel.org/r/9123f151280e52c63dcb645cb07d4eee3462c067.camel@codeconstruct.com.au
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
1. A fix is introduced to correct turbo frequency marking for 64-bit
devices with sustained frequencies over 4GHz, ensuring accurate turbo
frequency identification.
2. Debug capabilities are being improved by introducing in-flight transfer
tracking using debug counters, which help diagnose transfer congestion
and behavior. Additional tracepoints are added to log in-flight counts
at transfer begin and end, offering better runtime insight. The debug
counters now support decrement operations using a newly added
scmi_dec_count helper, making counter tracking symmetric and more robust.
3. A race condition in suspend-resume logic is being resolved by ensuring
SCMI_SYSPOWER_IDLE state is set early during resume, improving suspend
reliability under certain conditions. New suspend and resume operations
are added to the scmi_bus_type to enable finer power management control
for SCMI-based devices.
4. Finally enhancements are also made to avoid registering notifiers for
events that a platform does not support, reducing unnecessary overhead
by checking for unsupported event types during protocolinitialization.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmhuPrYACgkQAEG6vDF+
4pgtcg/9GcgWqz1Oq93LbR3BY75dKd9pjTVraivT9sDII/uiRow6NCf6DyIuKzB4
2sL3JSWz5jCiKn8YxnoyYT7EKuxQBBAe8CQbC9deQSx8F835Mwho8MCeKwiylId9
9fQrOE79+HgCNvU2znVdQ4MUixliC5Sdn8nijzLeYkFEo26novlxDf39IOTuBPv2
gbp5X8KOsUE8hglXdYLaxrghT2jrH1RmjzTMv3dr39fcBOpU3dW2FWTaP8myXeql
lrLzWxdcA/E6vmQTvNvMsDf/mxxEUKkeszlX9iwrZ+RAVmAMgJWVg3o1n+iTas72
dTs9WA8EgTV2r62vv1i6houu7gjKmrm0n96rmY9eRsuRJ8Wnyi6kF5DnG5o4R32Y
4oczLHcUaC8e5yLxFykqsKw1OyYpPfdElz/UwFB44ZVyl7LSlXGja4xPqmneA1wF
pxHvfsPlyUUmVkyMlQQn7HXSWWZ5nm/VGAkJEJTEaD5Gk+nRGcZ/P/F1QRvr3CAA
Y4LsxnPrrXS9upzUEZYPJ76rtn+uwQeo1o6mTMrjHijB39mILMPC4P9nkRTy7BAw
mV2aMmQw8jz5+kdELpeOYjKCsDNOQRkr/orVyobIaChk9uTLtcMM/Blkk4p4/dLd
bgt+Lp+VDFnuED/FPT57VBI16s+G9lxcPkW0/W/SS+5LoCvTV6o=
=9o+P
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmh+UaIACgkQmmx57+YA
GNl3PQ//YogYHtNEOrveIAaVPUENumw8i/4B24r4Qu9Mt72x/rCWJ2MafddQ1yyj
fh4UiMTr7lWMIde9QG5BiQqdkONi0IpGzJr1uSHgjYxarq8l4PlN05MtMtEK/1s5
9Zh5XTpqsAcFMThNOQXYBZAl12ZHlXxKL/dVnlHZyvcQF7dPYbolxSA7/qms4R7e
8lFO6UZxcDyEAjOS6oVSlHZqkJFNro6CpHgdISJtjAucyXj1HTmGFXF0VgOUTxNR
psJUlLw8nIdH8G5pN5dQJhjazzBE5k4hPSFX8hkxh+YI9sEuI7ObpZIyPDcz4KGI
FutUybgVBYxBYaGoYw8eqTsMJKtdExm6OxLS0IiycVxUeG6mqa4CyDX39KTfvnPE
NcAvnGUgbYRHz7UizK1RFVpsQRwe+Blooo/0LQZgfJ4bEBbsij7n7tOitPn7eLwg
nifQBbNN79O3aHWwIJdF62nIr/ETexzHW0OAPzC7K0Q26yy858bKpAZcB6bzJ8F9
16F80rawrisVqr2DOkwQIyG3Eb1R+QcDq/AJN66ZqaT++4mANDMLvhPY0EEv9021
SN35R2DaVGeo4t8Oqqf+hddeowYntvHksrPlJUF2VAjsZ7QG5QntpYdv7bgO5ZeR
Q1gIZP50XhQCpi9TjGIWMZ5CZNMzCsFZU+I2nZ0UwkTXuvcq01k=
=yON3
-----END PGP SIGNATURE-----
Merge tag 'scmi-updates-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers
Arm SCMI updates for v6.17
1. A fix is introduced to correct turbo frequency marking for 64-bit
devices with sustained frequencies over 4GHz, ensuring accurate turbo
frequency identification.
2. Debug capabilities are being improved by introducing in-flight transfer
tracking using debug counters, which help diagnose transfer congestion
and behavior. Additional tracepoints are added to log in-flight counts
at transfer begin and end, offering better runtime insight. The debug
counters now support decrement operations using a newly added
scmi_dec_count helper, making counter tracking symmetric and more robust.
3. A race condition in suspend-resume logic is being resolved by ensuring
SCMI_SYSPOWER_IDLE state is set early during resume, improving suspend
reliability under certain conditions. New suspend and resume operations
are added to the scmi_bus_type to enable finer power management control
for SCMI-based devices.
4. Finally enhancements are also made to avoid registering notifiers for
events that a platform does not support, reducing unnecessary overhead
by checking for unsupported event types during protocolinitialization.
* tag 'scmi-updates-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Convert to SYSTEM_SLEEP_PM_OPS
firmware: arm_scmi: Avoid notifier registration for unsupported events
firmware: arm_scmi: power_control: Ensure SCMI_SYSPOWER_IDLE is set early during resume
firmware: arm_scmi: Add power management operations to SCMI bus
include: trace: Add tracepoint support for inflight xfer count
firmware: arm_scmi: Track number of inflight SCMI transfers
firmware: arm_scmi: Add support for debug counter decrement
firmware: arm_scmi: Fix up turbo frequencies selection
Link: https://lore.kernel.org/r/20250709122907.1171913-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Just a single update extending arm_smccc_hypervisor_has_uuid() to
support both SMC and HVC conduits, enabling UUID retrieval when Linux
runs as the root partition under Microsoft Hypervisor (MSHV), where
SMC is used. It leverages arm_smccc_1_1_invoke() to dynamically select
the appropriate conduit, enhancing compatibility beyond just HVC.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmhuPJ0ACgkQAEG6vDF+
4pjqARAAlh6YarQMJi7zwqIafEyBYmW5o5x9MAW3J7rQLS4C2/ozEFCPMjoQ2g5b
Hnb0wfCk9KLxOygXGxWRbTJOI42wIcM8VO6+Ge5pOificfMEtlYmoZw/LeR9yuub
R0QTr/r1QF21vEk8F/ZhQoJGE9kb5aTbHPJ6TWy1gdXOep0kXfZvc1hE5cZoiT0I
Bgl4Rsf997DQQgsp+0hXdFLC485nq1nvEjYNR/OqpbSxiOb10ZHoNBi1vekH3N6r
pP/krMOkYGONbVgHcVjj5Coi92pWWWgL+l8AbOLHK2MCO0xyxDN2xVmIkhiZ1M/z
oaG5fnYdtljTcxqW4eBwPxxYtUO7LJoiT8YHOY+luwrWaEsCl4/5LDVb4sktH+a8
4tami+TjJfWNlHe1xLfUGz+FAsPqYPH36KxpyGGERz2pSqYLLZ3YtAVe06/neaQ6
TBWOJJjKI0G4j4xetIjYtT/v+DIz/Lz4fx0hNoclUKUZ51QF/sd+Hv52W+5p2fVY
hhR7aFKXg8k1RjSfdPAOHcAYnsPtIhBdCUbES+ra9GEezE/b83yR4+ki/njylP5w
qhji5bhQlUQxWU1BeLeNTqP3GGtbFQP4IJvcQoIEYi9IB8x3zHaIRvi0LeosNwbb
IJEiH+9puGYjXu2QKskGg9hZCHTfOUmDXfM1WqJpOXDeHyH3Ruw=
=Ud+7
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmh+UVUACgkQmmx57+YA
GNmS3g//X05D2kUOMZDZQ1qng8jAUrNfjFmTYoUpOaHWvGIH3z9trxQIV0gGPNys
3JLwxtXrqyrN0AozuTe3CZUrJJlKkOSgdT+H824knjqSZ1UCj4xxo84VZk3u9/gu
HOVPD36qXZB6/q2FtAPljz5/yV0cN6FQIFIX3bXmQt/VwjMuJLd8pcHWzNVxs3rz
egRXQQBRnypAHHlIopFV4049QfcATO1DkXKIQ26N1BY7ObhBVvw8PAP5gg+3FYiC
nC3i5pDNPMcgEgHgm9FUmOtAPGYZo2LVr+x1hbuFb0x65GjavLoOJoknntVCo9j8
3kYkx6C6OorDZZ6T//ktp8no1exzlIc4+R2zNHfqvEXFWbGdVgsr2adzfZ1sGTWQ
AsNVMqTPW3FlkZG0u3DhEoDvOiv8qRn5RQwssBdhjtHjSkDYasd/aNTIoOPN6C3E
AsDvJGoFDJULOKjrwje7XCxM4hvgJPs3szPDoxYsRtQecrTwSv6EwAtOclSxpmVv
exzGU3PQc22jlI2yPtJ7Q0N6kcMjI+V9eG+NjPXv0LJA/rMCyY4RvYnA96b13N5E
wMS13z5zj0meZWE8Uj43axxYerb7hPQRov7xtI1fi2CvC5lQSPZWiGQWrsNgWrtM
bVn217qQFJ+FQCOl+hq3zn5pRa1Zz5ThYyC2/QMO5cxAt7pLTD0=
=Rwqz
-----END PGP SIGNATURE-----
Merge tag 'smccc-updates-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers
firmware: smccc: Update for v6.17
Just a single update extending arm_smccc_hypervisor_has_uuid() to
support both SMC and HVC conduits, enabling UUID retrieval when Linux
runs as the root partition under Microsoft Hypervisor (MSHV), where
SMC is used. It leverages arm_smccc_1_1_invoke() to dynamically select
the appropriate conduit, enhancing compatibility beyond just HVC.
* tag 'smccc-updates-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: smccc: Support both smc and hvc conduits for getting hyp UUID
Link: https://lore.kernel.org/r/20250709122615.1171419-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Merge series from Heiko Schocher <hs@denx.de>:
This series introduces the changes needed for trivial spi
based sensors from ABB, currently operated from userspace.
The xe_vram_region_alloc() function returns NULL on error. It never
returns error pointers. Update the error checking to match.
Fixes: 4b0a5f5ce7 ("drm/xe: Unify the initialization of VRAM regions")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/5449065e-9758-4711-b706-78771c0753c4@sabinyo.mountain
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The second instance of TBSVC_MATCH_PROTOCOL_VERSION seems to have been
intended to be TBSVC_MATCH_PROTOCOL_REVISION.
Fixes: d1ff70241a ("thunderbolt: Add support for XDomain discovery protocol")
Cc: stable <stable@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Link: https://lore.kernel.org/r/20250721050136.30004-1-ebiggers@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The current power direction of an USB-C port also influences the
power_supply's online status, so a power role change should also update
the power_supply.
Fixes an issue on some systems where plugging in a normal USB device in
for the first time after a reboot will cause upower to erroneously
consider the system to be connected to AC power.
Cc: stable <stable@kernel.org>
Fixes: 0e6371fbfb ("usb: typec: ucsi: Report power supply changes")
Signed-off-by: Myrrh Periwinkle <myrrhperiwinkle@qtmlabs.xyz>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20250721-fix-ucsi-pwr-dir-notify-v1-1-e53d5340cb38@qtmlabs.xyz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ucsi_psy_get_current_max would return 0mA as the maximum current if
UCSI detected a BC or a Default USB Power sporce.
The comment in this function is true that we can't tell the difference
between DCP/CDP or SDP chargers, but we can guarantee that at least 1-unit
of USB 1.1/2.0 power is available, which is 100mA, which is a better
fallback value than 0, which causes some userspaces, including the ChromeOS
power manager, to regard this as a power source that is not providing
any power.
In reality, 100mA is guaranteed from all sources in these classes.
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Jameson Thies <jthies@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20250717200805.3710473-1-bleung@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes a race condition communication error, which ends up in
PD hard resets when losing the race. Some systems, like the Radxa ROCK
5B are powered through USB-C without any backup power source and use a
FUSB302 chip to do the PD negotiation. This means it is quite important
to avoid hard resets, since that effectively kills the system's
power-supply.
I've found the following race condition while debugging unplanned power
loss during booting the board every now and then:
1. lots of TCPM/FUSB302/PD initialization stuff
2. TCPM ends up in SNK_WAIT_CAPABILITIES (tcpm_set_pd_rx is enabled here)
3. the remote PD source does not send anything, so TCPM does a SOFT RESET
4. TCPM ends up in SNK_WAIT_CAPABILITIES for the second time
(tcpm_set_pd_rx is enabled again, even though it is still on)
At this point I've seen broken CRC good messages being send by the
FUSB302 with a logic analyzer sniffing the CC lines. Also it looks like
messages are being lost and things generally going haywire with one of
the two sides doing a hard reset once a broken CRC good message was send
to the bus.
I think the system is running into a race condition, that the FIFOs are
being cleared and/or the automatic good CRC message generation flag is
being updated while a message is already arriving.
Let's avoid this by caching the PD RX enabled state, as we have already
processed anything in the FIFOs and are in a good state. As a side
effect that this also optimizes I2C bus usage :)
As far as I can tell the problem theoretically also exists when TCPM
enters SNK_WAIT_CAPABILITIES the first time, but I believe this is less
critical for the following reason:
On devices like the ROCK 5B, which are powered through a TCPM backed
USB-C port, the bootloader must have done some prior PD communication
(initial communication must happen within 5 seconds after plugging the
USB-C plug). This means the first time the kernel TCPM state machine
reaches SNK_WAIT_CAPABILITIES, the remote side is not sending messages
actively. On other devices a hard reset simply adds some extra delay and
things should be good afterwards.
Fixes: c034a43e72 ("staging: typec: Fairchild FUSB302 Type-c chip driver")
Cc: stable <stable@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20250704-fusb302-race-condition-fix-v1-1-239012c0e27a@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Selecting DRM_AUX_HPD_BRIDGE is not possible from a built-in driver when
CONFIG_DRM=m:
WARNING: unmet direct dependencies detected for DRM_AUX_HPD_BRIDGE
Depends on [m]: HAS_IOMEM [=y] && DRM [=m] && DRM_BRIDGE [=y] && OF [=y]
Selected by [y]:
- UCSI_LENOVO_YOGA_C630 [=y] && USB_SUPPORT [=y] && TYPEC [=y] && TYPEC_UCSI [=y] && EC_LENOVO_YOGA_C630 [=y] && DRM_BRIDGE [=y] && OF [=y]
arm-linux-gnueabi-ld: drivers/gpu/drm/bridge/aux-hpd-bridge.o: in function `drm_aux_hpd_bridge_notify':
aux-hpd-bridge.c:(.text.drm_aux_hpd_bridge_notify+0x28): undefined reference to `drm_bridge_hpd_notify'
arm-linux-gnueabi-ld: drivers/gpu/drm/bridge/aux-hpd-bridge.o: in function `drm_aux_hpd_bridge_probe':
aux-hpd-bridge.c:(.text.drm_aux_hpd_bridge_probe+0x20): undefined reference to `__devm_drm_bridge_alloc'
Add a dependency to force UCSI_LENOVO_YOGA_C630 to be a loadable module as
well in this configuration.
Fixes: eb90d36bfa ("usb: typec: ucsi: yoga-c630: register DRM HPD bridge")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20250717133045.991254-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1. In func configfs_composite_bind() -> composite_os_desc_req_prepare():
if kmalloc fails, the pointer cdev->os_desc_req will be freed but not
set to NULL. Then it will return a failure to the upper-level function.
2. in func configfs_composite_bind() -> composite_dev_cleanup():
it will checks whether cdev->os_desc_req is NULL. If it is not NULL, it
will attempt to use it.This will lead to a use-after-free issue.
BUG: KASAN: use-after-free in composite_dev_cleanup+0xf4/0x2c0
Read of size 8 at addr 0000004827837a00 by task init/1
CPU: 10 PID: 1 Comm: init Tainted: G O 5.10.97-oh #1
kasan_report+0x188/0x1cc
__asan_load8+0xb4/0xbc
composite_dev_cleanup+0xf4/0x2c0
configfs_composite_bind+0x210/0x7ac
udc_bind_to_driver+0xb4/0x1ec
usb_gadget_probe_driver+0xec/0x21c
gadget_dev_desc_UDC_store+0x264/0x27c
Fixes: 37a3a53342 ("usb: gadget: OS Feature Descriptors support")
Cc: stable <stable@kernel.org>
Signed-off-by: Tao Xue <xuetao09@huawei.com>
Link: https://lore.kernel.org/r/20250721093908.14967-1-xuetao09@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix a checkpatch warning:
CHECK: Please use a blank line after function/struct/union/enum declarations
Reported-by: Xu Yang <xu.yang_2@nxp.com>
Acked-by: Peter Chen <peter.chen@kernel.org>
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/36d1c961-319e-4457-bdc1-69f8b6bed33e@sabinyo.mountain
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Documentation/filesystems/sysfs.rst mentions that show() should only
use sysfs_emit() or sysfs_emit_at() when formating the value to be
returned to user space. So replace scnprintf() with sysfs_emit().
Signed-off-by: Sumanth Gavini <sumanth.gavini@yahoo.com>
Link: https://lore.kernel.org/r/20250718175037.299710-1-sumanth.gavini@yahoo.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch cleans up a few cases where assignments were made
inside of if conditions, like
if ((rv = func()) < 0)
into two lines, to improve readability and be more in-line with
Linux kernel coding style. It also cleans up checkpatch warnings
like:
ERROR: do not use assignment in if condition
No functional change, just a style and maintainability fix.
Signed-off-by: Darshan Rathod <darshan.rathod@siqol.com>
Link: https://lore.kernel.org/r/20250718091045.264129-1-darshan.rathod@siqol.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On the devices that need their endpoints to get an
initial clear_halt, this needs to be done before
the devices can be opened. That means it needs to be
before the devices are registered.
Fixes: 15bf722e6f ("cdc-acm: Add support of ATOL FPrint fiscal printers")
Cc: stable <stable@kernel.org>
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/20250717141259.2345605-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When INTEL_PMT_TELEMETRY is in a loadable module, the discovery
test cannot be built-in:
x86_64-linux-ld: drivers/platform/x86/intel/pmt/discovery-kunit.o: in function `test_intel_pmt_get_regions_by_feature':
discovery-kunit.c:(.text+0x29d): undefined reference to `intel_pmt_get_regions_by_feature'
x86_64-linux-ld: discovery-kunit.c:(.text+0x2c3): undefined reference to `intel_pmt_put_feature_group'
Add a Kconfig dependency to prevent this.
Fixes: b9707d46a9 ("platform/x86/intel/pmt: KUNIT test for PMT Enhanced Discovery API")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20250714081559.4056777-1-arnd@kernel.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
On g4x we currently use the 96MHz non-SSC refclk, which can't actually
generate an exact 2.7 Gbps link rate. In practice we end up with 2.688
Gbps which seems to be close enough to actually work, but link training
is currently failing due to miscalculating the DP_LINK_BW value (we
calcualte it directly from port_clock which reflects the actual PLL
outpout frequency).
Ideas how to fix this:
- nudge port_clock back up to 270000 during PLL computation/readout
- track port_clock and the nominal link rate separately so they might
differ a bit
- switch to the 100MHz refclk, but that one should be SSC so perhaps
not something we want
While we ponder about a better solution apply some band aid to the
immediate issue of miscalculated DP_LINK_BW value. With this
I can again use 2.7 Gbps link rate on g4x.
Cc: stable@vger.kernel.org
Fixes: 665a7b0409 ("drm/i915: Feed the DPLL output freq back into crtc_state")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-2-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
(cherry picked from commit a8b874694d)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Merge the fixes branch into the for-next branch to resolve Makefile
conflict and include the power supply accessor work that is required
by the upcoming Uniwill driver.
We have a common error path where we abort the transaction, but like this
in case we get a transaction abort stack trace we don't know exactly which
previous function call failed. Instead abort the transaction after any
function call that returns an error, so that we can easily identify which
function failed.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The label is only used once and we can instead return directly where it's
used, besides the fact that all we do under the label is to return the
value of 'ret'. So get rid of the label and return directly.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: David Sterba <dsterba@suse.com>
Instead of having a common btrfs_abort_transaction() call for when any of
the two btrfs_dec_ref() calls fail, move the btrfs_abort_transaction() to
happen immediately after each one of the calls, so that when analysing a
stack trace with a transaction abort we know which call failed.
Reviewed-by: Boris Burkov <boris@bur.io>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: David Sterba <dsterba@suse.com>
Instead of having a common btrfs_abort_transaction() call for when either
insert_tree_block_ref() failed or when insert_extent_data_ref() failed,
move the btrfs_abort_transaction() to happen immediately after each one of
those calls, so that when analysing a stack trace with a transaction abort
we know which call failed.
Reviewed-by: Boris Burkov <boris@bur.io>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: David Sterba <dsterba@suse.com>
Instead of having a common btrfs_abort_transaction() call for when either
btrfs_orphan_add() failed or when btrfs_add_link() failed, move the
btrfs_abort_transaction() to happen immediately after each one of those
calls, so that when analysing a stack trace with a transaction abort we
know which call failed.
Reviewed-by: Boris Burkov <boris@bur.io>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: David Sterba <dsterba@suse.com>
Commit 12724ce3fe ("iommu/vt-d: Optimize iotlb_sync_map for
non-caching/non-RWBF modes") dynamically set iotlb_sync_map. This causes
synchronization issues due to lack of locking on map and attach paths,
racing iommufd userspace operations.
Invalidation changes must precede device attachment to ensure all flushes
complete before hardware walks page tables, preventing coherence issues.
Make domain->iotlb_sync_map static, set once during domain allocation. If
an IOMMU requires iotlb_sync_map but the domain lacks it, attach is
rejected. This won't reduce domain sharing: RWBF and shadowing page table
caching are legacy uses with legacy hardware. Mixed configs (some IOMMUs
in caching mode, others not) are unlikely in real-world scenarios.
Fixes: 12724ce3fe ("iommu/vt-d: Optimize iotlb_sync_map for non-caching/non-RWBF modes")
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/20250721051657.1695788-1-baolu.lu@linux.intel.com
Signed-off-by: Will Deacon <will@kernel.org>
If the BIOS sets a _PPC frequency limit upfront, it will fail to take
effect due to a call ordering issue. Namely, freq_qos_update_request()
is called before freq_qos_add_request() for the given request causing
the constraint update to be ignored. The call sequence in question is
as follows:
cpufreq_policy_online()
acpi_cpufreq_cpu_init()
acpi_processor_register_performance()
acpi_processor_get_performance_info()
acpi_processor_get_platform_limit()
freq_qos_update_request(&perflib_req) <- inactive QoS request
blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
CPUFREQ_CREATE_POLICY)
acpi_processor_notifier()
acpi_processor_ppc_init()
freq_qos_add_request(&perflib_req) <- QoS request activation
Address this by adding an acpi_processor_get_platform_limit() call
to acpi_processor_ppc_init(), after the perflib_req activation via
freq_qos_add_request(), which causes the initial _PPC limit to be
picked up as appropriate. However, also ensure that the _PPC limit
will not be picked up in the cases when the cpufreq driver does not
call acpi_processor_register_performance() by adding a pr->performance
check to the related_cpus loop in acpi_processor_ppc_init().
Fixes: d15ce41273 ("ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier")
Signed-off-by: Jiayi Li <lijiayi@kylinos.cn>
Link: https://patch.msgid.link/20250721032606.3459369-1-lijiayi@kylinos.cn
[ rjw: Consolidate pr-related checks in acpi_processor_ppc_init() ]
[ rjw: Subject and changelog adjustments ]
Cc: 5.4+ <stable@vger.kernel.org> # 5.4+: 2d8b39a62a ACPI: processor: Avoid NULL pointer dereferences at init time
Cc: 5.4+ <stable@vger.kernel.org> # 5.4+: 3000ce3c52 cpufreq: Use per-policy frequency QoS
Cc: 5.4+ <stable@vger.kernel.org> # 5.4+: a1bb46c36c ACPI: processor: Add QoS requests for all CPUs
Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add LUT entry for MSI/IOMMU in Endpoint mode by calling
imx_pcie_add_lut_by_rid() helper function. Since only one physical function
is supported in the Endpoint mode for now, '0' is passed as the Device ID.
This sets up a single LUT entry required for MSI/IOMMU.
The Endpoint function can operate without LUT configuration if neither
IOMMU nor MSI is used by the platform. This LUT configuration is used for
the EP doorbell feature by allowing the Root Complex to trigger the
doorbell on the Endpoint with the help of the Endpoint MSI controller.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
[mani: reworded the comments & commit message and dropped tested-by tag]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250710-ep-msi-v21-2-57683fc7fb25@nxp.com
Add helper function imx_pcie_add_lut_by_rid(), which will be used by the
upcoming LUT configuration for MSI/IOMMU in the Endpoint mode. No
functional change.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
[mani: reworded commit message and dropped tested-by tag]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20250710-ep-msi-v21-1-57683fc7fb25@nxp.com
In __vcpu_run() and do_vsie_run(), we enter an RCU extended quiescent
state (EQS) by calling guest_enter_irqoff(), which lasts until
__vcpu_run() calls guest_exit_irqoff(). However, between the two we
enable interrupts and may handle interrupts during the EQS. As the IRQ
entry code will not wake RCU in this case, we may run the core IRQ code
and IRQ handler without RCU watching, leading to various potential
problems.
It is necessary to unmask (host) interrupts around entering the guest,
as entering the guest via SIE will not automatically unmask these. When
a host interrupt is taken from a guest, it is taken via its regular
host IRQ handler rather than being treated as a direct exit from SIE.
Due to this, we cannot simply mask interrupts around guest entry, and
must handle interrupts during this window, waking RCU as required.
Additionally, between guest_enter_irqoff() and guest_exit_irqoff(), we
use local_irq_enable() and local_irq_disable() to unmask interrupts,
violating the ordering requirements for RCU/lockdep/tracing around
entry/exit sequences. Further, since this occurs in an instrumentable
function, it's possible that instrumented code runs during this window,
with potential usage of RCU, etc.
To fix the RCU wakeup problem, an s390 implementation of
arch_in_rcu_eqs() is added which checks for PF_VCPU in current->flags.
PF_VCPU is set/cleared by guest_timing_{enter,exit}_irqoff(), which
surround the actual guest entry.
To fix the remaining issues, the lower-level guest entry logic is moved
into a shared noinstr helper function using the
guest_state_{enter,exit}_irqoff() helpers. These perform all the
lockdep/RCU/tracing manipulation necessary, but as sie64a() does not
enable/disable interrupts, we must do this explicitly with the
non-instrumented arch_local_irq_{enable,disable}() helpers:
guest_state_enter_irqoff()
arch_local_irq_enable();
sie64a(...);
arch_local_irq_disable();
guest_state_exit_irqoff();
[ajd@linux.ibm.com: rebase, fix commit message]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Janosch Frank <frankja@linux.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Paul E. McKenney <paulmck@kernel.org>
Cc: Sven Schnelle <svens@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Link: https://lore.kernel.org/r/20250708092742.104309-3-ajd@linux.ibm.com
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Message-ID: <20250708092742.104309-3-ajd@linux.ibm.com>
All architectures have an interruptible RCU extended quiescent state
(EQS) as part of their idle sequences, where interrupts can occur
without RCU watching. Entry code must account for this and wake RCU as
necessary; the common entry code deals with this in irqentry_enter() by
treating any interrupt from an idle thread as potentially having
occurred within an EQS and waking RCU for the duration of the interrupt
via rcu_irq_enter() .. rcu_irq_exit().
Some architectures may have other interruptible EQSs which require
similar treatment. For example, on s390 it is necessary to enable
interrupts around guest entry in the middle of a period where core KVM
code has entered an EQS.
So that architectures can wake RCU in these cases, this patch adds a
new arch_in_rcu_eqs() hook to the common entry code which is checked in
addition to the existing is_idle_thread() check, with RCU woken if
either returns true. A default implementation is provided which always
returns false, which suffices for most architectures.
As no architectures currently implement arch_in_rcu_eqs(), there should
be no functional change as a result of this patch alone. A subsequent
patch will add an s390 implementation to fix a latent bug with missing
RCU wakeups.
[ajd@linux.ibm.com: rebase, fix commit message]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Paul E. McKenney <paulmck@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sven Schnelle <svens@linux.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Link: https://lore.kernel.org/r/20250708092742.104309-2-ajd@linux.ibm.com
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Message-ID: <20250708092742.104309-2-ajd@linux.ibm.com>
