for 7.2, please pull the following:
- Daniel removes the non-functional EL2 timer interrupt which is not
connected on 2712
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmpfpvkACgkQh9CWnEQH
BwRm7A//dxlBGxIAu/DPjcRYRaSzkQU6EVs5a0qDJkSp5m3XTcnMp3GiKIMFN2b2
TRTyLc+9RjTpEb1jEAqCqgq77LBUZhwog+u3I35bnTpIzX2l5XiQdZKNW+icBCBG
F4h/eNXJfx/W2pyDOYFrT8F0NklZH8QHEy2HU8EzuOlihPXBpc8sKpZHcpYIEpeQ
Xz3rHxRH+A7Fj1uwWr7rCaXQ6J+/QhM4abv1hvdpJJ/h5kh7wbfqr3v6/VEUOX95
lnH3sYX8tB0R2nseXJsR0xrnrsXzSnGmGErEn1ghgBRkbyJWB/0EHkGbAVMneeU+
w3uVJWrnDK25VDo4T9vKzduJmg0P28i/4K874IzuN6ZHVC720OXVnGK/QqYvV/xe
XBE+KkX9/DjILuMcGJiXreSXsu5cPUExulRN7VVDSRWlHjdNzwuA0GVqzHpJC2Gq
VD7z1LxPmKBljBnSBgtYt6AhQgZF0YDqwRTaGeVP2b0crtaLIGR8+wG1QtwXOc2G
KCLRtkh7vKSPrUtRCfJ7mFnDry4APvfQ2E74JVjEPyBcu5I9Ka/xUW50JMR+OjJI
Y7cpOerBbprBrU1wZqeqJbLCav+uR88yl5dEMCN9DfrJGpzcUqJTvCq219w2xV5+
31Xa0aQgc/FDU394nGZ06vUACGo9Iy/c8LWg2tyS4SGegDrMh5o=
=RdUX
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmpjj38ACgkQmmx57+YA
GNn4KQ//W4rfAiRKwa2+3Sm3CBc1BqN/3SHILnn5THqFP684w5MHEgMrU0/4it0A
HkFZNGqytxcArn39zKiQYR/XnFZsq85Vuc77ppHWvO92JiH3MgV4lSQ95U4s5Ezp
8jsZu9uMCug97LUxIpcvJET1IYNQZkImdWKCCRwkscns69I2pBYwHu6YbC+WKRA6
yiiw/jC8noJTSbugXgGIXDf9+W/qWpWni0Fs4YY0QiqXxmBTnNSqPz3SD4r3T+P9
iFy54VvFcC/nxijBiy4Qg84t8YIUvihlTsxo19B8xXkBxxkBRZkMwAKxYkpfiNbg
iEyU64NYWjKmalUv3aDx6+tdprtlNNTy/sf+UFpaRtT9qJvoKPWeeiqvFi9tYhY8
pCAMtGf3+cgLDaEQUVVPVReE3M6IIhecBDr8fmeymrXgud8UWOh8ouPaVObu8fRQ
ox6t3orNIqNdWQV3nYkImjewbLPdtMv3i29kgi6lsnr7uR1exdC9CqZwGFRpq445
NAXYGmoyLpswSRNBs5tz6HiQ5td5Xjik5atFMAjoAIP0M1YZzThbSm7TxW/Cxk8R
FVT9ESeK1UzW8kcFlPL+/3vhZl1DNF688VbtDDYEYGGiy9tZ3fdES4iJoAD+TFVB
R76VLlFXSj/xHtQFBzpYE5sUDHGqRFjuWx2OChucjEJAWTRvD6s=
=QOkB
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-7.2/devicetree-arm64-fixes' of https://github.com/Broadcom/stblinux into arm/fixes
This pull request contains Broadcom ARM64-based SoCs Device Tree fixes
for 7.2, please pull the following:
- Daniel removes the non-functional EL2 timer interrupt which is not
connected on 2712
* tag 'arm-soc/for-7.2/devicetree-arm64-fixes' of https://github.com/Broadcom/stblinux:
arm64: dts: broadcom: bcm2712: Remove non-functional EL2 virtual timer
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Before this change the HSMP data plane runs without any coordination with
driver teardown: open /dev/hsmp fds and hwmon sysfs reads call
hsmp_send_message() while probe and remove bring sockets up and down.
misc_deregister() does not drain already-open fds, so an in-flight message
can race a concurrent unbind and touch a freed socket array or an unmapped
mailbox.
Add the read side of hsmp_sock_rwsem to the data plane. Split the message
send into hsmp_send_message_locked(), which does the bounds check and MMIO
access and asserts the rwsem is held, and hsmp_send_message(), which wraps
it in guard(rwsem_read). Probe and remove hold the rwsem for write, so they
drain in-flight messages and keep new ones out while they tear a socket
down.
The probe-time senders run under the probe write lock and so must not take
the rwsem again: route hsmp_test(), hsmp_cache_proto_ver() and
hsmp_get_tbl_dram_base() through hsmp_send_message_locked() to avoid
recursive locking. A single rwsem therefore covers both the data plane and
the probe/remove handshake, with no separate probe lock:
- acpi.c already holds it for write across probe for the socket-array and
misc-registration handshake, so the mailbox handshake now nests under
that same lock.
- plat.c takes it for write around init_platform_device(). It is not held
across devm_add_action_or_reset() so the release action, which also
takes it for write, cannot deadlock if that registration fails.
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260723094656.3806028-7-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The ACPI driver binds one platform device per socket but shares a single
socket array and a single /dev/hsmp misc device across them. Replace the
is_probed flag with state that tracks this shared ownership:
- miscdevice.this_device tells whether /dev/hsmp is registered, so the
misc device is registered on the first socket and torn down last. A
preceding change clears mdev.this_device on deregister so this gate
stays reliable across a re-probe.
- a kref tracks the sockets that share the array. The first probe
initializes it, each further probe takes a reference and every remove
(or probe failure) drops one; the last put runs the release callback.
All get/put happen under hsmp_sock_rwsem held for write, so the counting
is already serialized and kref's atomic is not strictly needed, but kref
gives the clearer get/put interface and a release callback. The shared
socket array is allocated with kcalloc() on the first probe and freed by
the release callback once the last reference is dropped.
hsmp_acpi_sock_release() is the single teardown helper, run from
kref_put(): it deregisters /dev/hsmp if registered, unmaps any
metric-table DRAM, destroys the per-socket mutexes and frees the array.
The remove path and the probe-failure path both reach it through the last
put, so the teardown lives in one place.
Both paths also clear this socket's dev, so a message issued after a
non-final unbind (or to a socket that failed to probe on a multi-socket
system, whose array stays alive and whose remove() is never called) cannot
reach the mailbox that devres is about to unmap.
Two lifetime fixes fall out of the array persisting across a non-final
unbind:
- hsmp_get_tbl_dram_base() iounmap()s any stale metric_tbl_addr before
remapping, so a rebind does not leak one mapping per cycle. It runs
during (re)probe before the metric sysfs attribute is exposed, so no
reader can be using the old mapping.
- The ACPI path registers /dev/hsmp unparented by passing NULL to
hsmp_misc_register(). Its per-socket devices can be unbound individually
and out of order and the misc device outlives all but the last of them,
so parenting it to one socket's device would leave a dangling parent.
hsmp_misc_register() now takes the parent from its caller, so the
platform driver keeps parenting /dev/hsmp to its single device.
hsmp_sock_rwsem is held for write across probe and remove, so the release
and probe-failure cleanup run with it already held; an upcoming change adds
its read side so the same lock also drains the data plane.
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260723094656.3806028-6-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
misc_deregister() destroys the device but leaves miscdevice.this_device
pointing at the freed struct device. Clear it so any later check of
this_device, and a subsequent re-register, does not observe a stale
pointer. An upcoming change uses this_device to track whether /dev/hsmp is
registered across the shared ACPI sockets and relies on it being NULL after
deregister.
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260723094656.3806028-5-muralidhara.mk@amd.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
HSMP_GET_METRIC_TABLE makes the firmware refill a shared per-socket metric
DRAM region, which hsmp_metric_tbl_read() then copies out with
memcpy_fromio(). Two concurrent readers of the metrics_bin sysfs attribute
on the same socket can race: one can trigger a fresh fill while the other
is mid-copy and return a torn snapshot. (The hwmon path does not touch
this region; it only issues power messages via hsmp_send_message().)
Embed a struct mutex metric_read_lock in each hsmp_socket and hold it
across the fill-and-copy in hsmp_metric_tbl_read(). Add
hsmp_init_metric_read_locks() and hsmp_destroy_metric_read_locks(), which
take only struct hsmp_plat_device and iterate pdev->sock[] over
pdev->num_sockets so the caller cannot pass a count that disagrees with the
array.
Wire them into both front-ends' probe and teardown paths so the mutex is
always initialized before metrics_bin is exposed: the platform driver and
the ACPI driver both drive hsmp_metric_tbl_read() through the same 0444
metrics_bin attribute. Doing this in one patch avoids a bisection point
where an ACPI read would lock an uninitialized mutex.
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260723094656.3806028-4-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The metric-table DRAM region is mapped with devm_ioremap(), which ties the
mapping to the socket device's devres scope. An upcoming change lets the
ACPI front-end share the socket array across sockets and run its own
coordinated teardown, so the mapping can no longer be pinned to a single
per-socket devres scope.
Map it with plain ioremap() instead and add hsmp_unmap_metric_tbls(), which
drops every socket's metric_tbl_addr mapping. The platform driver registers
that helper with devm_add_action_or_reset() so the mappings are released on
both remove and probe failure, while the socket array itself stays
devm-managed.
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260723094656.3806028-3-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Add hsmp_sock_rwsem and export it, then hold it for write across ACPI
probe, remove and init_acpi() so concurrent per-socket platform probes
cannot race the is_probed handshake or the one-time socket-array
allocation. Use lockdep_assert_held_write() in init_acpi() to catch
incorrect locking under lockdep.
An rw_semaphore is used rather than a plain mutex because an upcoming
change adds a read side so data-plane messages run concurrently with each
other while probe/remove hold it for write to drain in-flight messages.
Introducing it as an rwsem now keeps the lock type stable across that
change.
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260723094656.3806028-2-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The reg-offset hack only works when the IXP4xx platform is
running in big endian mode, and it is there to byte-offset
the byte where the serial registers appear in the BE config.
This is clearly wrong, workarounds need to be in the
drivers. Drop the reg-offset.
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://lore.kernel.org/r/20260724-ixp4xx-dts-fix-v1-1-09bf7111e94e@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Make it possible to boot IXP4xx in little endian mode. This is
dependent on the patch for the xscale decompress header
submitted through Russell's patch tracker.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAmpjHGMACgkQQRCzN7AZ
XXPJUQ/8DeTQOXTU+tXikpPoxGQ0mLPKSkSQIAjPzTC1/Z/xrWYHF/tDHszXn5Sc
u7qPBsi9uP2tnNMJW9MrucZLJWMNDrWqF6wGsz/KBlQBTxuBG1m8gTcAadd4iwIi
3/BOtkyVfFY521FxO+u2TQXXK8qq1P8p4Nyz/14wk9FIDlHJNUX8Ra/RVaXeSHiu
KYWTLoJS0vzvJ8vRILrH4waxwXZhNrUAXF8SUR+BIAUyV59zcs6U4Lt4VMdzkkqO
5bumjJtzXKZz0+OsQ2C4xuU0ku3940F8F/f4zgGvRIGq4wiZByxZdw+FksmJ9ZOl
U/BkXDwaNnK1/X+ciYLj3DNC6GIhXAvSQGKxdvg5RI94ZLiYfqckrlkz1t4B2RS0
40f5uLeEqMycQzl03BYlmkY3sBpMqFuUEujwaPqMGtZvXI736gDEmCBcWS9mFZld
FHd+Vso48AtVh8Ac3C5/QhZvCwV1vbGDJJGjOIXUbL7N8R9L4ehgwkaf5Eg8AI6d
nhu6p5MfaQz3W8eO+Y5/KqRU7ab+9g51dKUESV8GsbaoCtHTVpBPIa9eKMrJug/t
DwhHbXYLebFTgU53zCD7AQoOCFIgYqMV4sS1WFrFVOJFr39OdDO8HKww4R+Fr4Yi
xvExzP6z3soAJXw6NId16J0/Z8ouxzz8hybyavVW0s68y/9ig2M=
=ZlWa
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmpjjmgACgkQmmx57+YA
GNlfxxAAgdH0C9OOyUoB7seiDRq8Vw0HRlBQ65/YI4CDSHGw/pEm5NcsZ48PawK4
uPTIW+dfLYD/KaViXnlMH9aYbfs0nr+TzdAxEHK0316+UJQQo5DMJbkkksQz/LWH
IrhabEZur62qQCRo3tw1KQ7jaFhlvgloObC6MosXDM3ct4WAnNbsIUjK/TENwxUS
6DrzuerJH8EgNUZBMzC5CKpzeFpYi6mb8rZDftRYsyYUzuAFmm/aGEqIypjLvatb
dc0pnmp3gstbOZY0RV3nStZFOUCBkZCPXN/9HyCG71s3mQGf9jSkwmCnpTHsV1wb
0B6GpM+Adz2B2ZczR5c39M6VOllx/EpgibeRExog4Rlo2PcjtLovB+IWEgCu2X/J
QwBWyjloFF0kSWQiNESdvGk8xZOUC73CXAinOnX2ii64yMOAsYuLg2IF4nqPrsYL
IuIScV9JKDUdmwbVNCTi/j60QaisBH99CKJAuEgw7nN/kFUUVJW4GPi/GepbeRJI
7PAEOd4gl1pmpf1F7YIo3rldtDja+NE71+du5uj3XWdGYxunuw0XlEz2O0LLPnCj
WBsdEEbXKRDoEAHoR72S5Z8gyeUfjs6g0idGcf5ET/XELo3WJEmowEcOa0PzpYEF
6Jqgmw3jZ3BkSTa2HTujvjONskjevCCic0C0ACTv8FWfBgJEGbs=
=mnKY
-----END PGP SIGNATURE-----
Merge tag 'ixp4xx-arm-v7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator into soc/arm
IXP4xx ARM changes for v7.3:
Make it possible to boot IXP4xx in little endian mode. This is
dependent on the patch for the xscale decompress header
submitted through Russell's patch tracker.
* tag 'ixp4xx-arm-v7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator:
ARM: ixp4xx: Relax endianness
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A collection of SCMI core and transport fixes addressing resource
lifetimes, teardown races and error handling. Most of these issues
are reported by Sashiko as existing issues while reviewing new feature
additions to SCMI.
The changes:
- publish channel state before mailbox and SMC callbacks can run,
- quiesce notification work before tearing down transport channels,
- fix partial channel setup and mailbox allocation cleanup,
- make IDR iteration and shared-channel teardown safe,
- correct SCMI device, OF node, handle, bus ID and SystemPower lifetimes;,
- harden requested-device registration and removal against races and
partial failures,
- reject out-of-range DT protocol IDs, and
- simplify notification allocations using flexible arrays.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmpjMg8ACgkQAEG6vDF+
4pg3Kw/+N09f4Zd1c8xwQi5NEfwv8uEKRE73VSAL18aNn89mGj6J1cGOs1NWHJ0b
bKDOuhoJWYynHDGbaZGFVLhh3l2Jj2yE+Hr9sq2nOHktA7HFqSVV5ea8RuRD/XHt
3rNIX6UBLSEp7N40ehkwD506zr3eRcfwtUwS8taEvl0NWNKrPJ+TpMxN3LBGWzBq
oXaD7642Mb9rDyApuwOGWlHitDPU1qQv5JrLLWP8/Nx4PQlb1TX6171FXvrMdjdx
qKUiUBZM9Q9w4gaKgnIEcq0KCBWdxa5ZKPupZTUzt60NEpkemjYcmjxoJFDIArGC
013Z/dXhynkigaEjfvWPhoNaoLx1Q3NTk5ChljaKLizI6sE0N02wuax8rHIuKSnL
fhbyNcpmsEgiVwnX4zw6l44AakWHx8qkE3avtx0yks+joAWt8ERzIHCd+uWF1z15
b18humBSxcs3DmmejH8JMMCTpL7OxI3PHtdntttXWpvM43/pZnO6vF23Nfo0KQ3q
ZrOD15W4qQ8M9nGKmpaa6f6tDPoWuULLcMhMHZo3FLdOYa5lnGtAs1Rj7MvJ5I0b
u8/t4P2hoCskSVN973P51ZA3r1NI9ZK+uZ3Krq9TFEvgI5ZZQTfDoz6Zc4q9/ERV
80k8/wRP8vCjBM2mQ+WVlWG1gJEq487t6bBPfQVeHmS+/BI0g+s=
=w04g
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmpjjIsACgkQmmx57+YA
GNmWgQ//e5oKyKC8Ac6vcjbRbwb6joIX0u0N8slFoKi3rano2Hb0e0TOLSywjCq8
w2G/n5tBjZKfp9RSqSWY0lZHjZhyyokosiSldtr8rX6v0LLQurHIPHakFHI0uW1h
1iquU37P+TJ8C/EcBHcG/3jrvMGPO2PFln7+XVNE2eG2Q79E26NcU9sNoLJeBTlt
AZrwpJ9jnUnay+zbc5jtqxqN50cam5I+lNNu+sZmDd67rN+wOUX68yn8vE6Buk+5
li1Ni0W6sKTbMchx+G56ibqnvTcLnouD5wvSNcgJOVycYsykzMB6pSKgqnUGqBTu
uHtvRJ1/Nzp+iQqdiGnzGw4x4bB7tackKIQtOww2wUYuE9KY+OCmnieS3hPpg/Od
kRBHrxaZ6fyfb++Mw+Ze5gwFEwhQDI0UgGAqu7DsSAuWefcCdPTo4ia9G+HGS1ID
80SNS/GdUmtLdCfsVIqOtvOY2TKwgfsqBWgimyF2apl3nQgbAUkjUlLTUTIFbhXo
em2oi6yLQVvte3HGc5r9NbmBnO3KRYIXYRU+t73bOBYeAKNdIPsA357dcrx/5MnN
eGli+DrKk/oC1zrvl9OjpAcD83enZ76EPHKRav8zGAnYQ1sLS+GweJsbSg9Yj4Dq
XbJGb8LM7mCFefrDvZKOVSWy5DMazHiofguPBOSgEnqASdp+Ydo=
=JO1v
-----END PGP SIGNATURE-----
Merge tag 'scmi-updates-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers
Arm SCMI updates/fixes for v7.3
A collection of SCMI core and transport fixes addressing resource
lifetimes, teardown races and error handling. Most of these issues
are reported by Sashiko as existing issues while reviewing new feature
additions to SCMI.
The changes:
- publish channel state before mailbox and SMC callbacks can run,
- quiesce notification work before tearing down transport channels,
- fix partial channel setup and mailbox allocation cleanup,
- make IDR iteration and shared-channel teardown safe,
- correct SCMI device, OF node, handle, bus ID and SystemPower lifetimes;,
- harden requested-device registration and removal against races and
partial failures,
- reject out-of-range DT protocol IDs, and
- simplify notification allocations using flexible arrays.
* tag 'scmi-updates-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: (25 commits)
firmware: arm_scmi: Unrequest devices if driver registration fails
firmware: arm_scmi: Roll back partial protocol table registration
firmware: arm_scmi: Fix requested device removal race
firmware: arm_scmi: Fix transport device teardown lookup
firmware: arm_scmi: Fix SCMI device destroy lifetimes
firmware: arm_scmi: Unwind P2A receiver mailbox setup failure
firmware: arm_scmi: Unwind TX receiver mailbox setup failure
firmware: arm_scmi: Fix OF node reference handling
firmware: arm_scmi: Clear SystemPower flag on create failure
firmware: arm_scmi: Drop handle on protocol bind failures
firmware: arm_scmi: Protect device request lookup with RCU
firmware: arm_scmi: Use channel ID for transport teardown
firmware: arm_scmi: Reject out of range DT protocol IDs
firmware: arm_scmi: Avoid IDR updates while cleaning channels
firmware: arm_scmi: Free transport channel on IDR failure
firmware: arm_scmi: Clean up channels on setup failure
firmware: arm_scmi: Quiesce notifications before teardown
firmware: arm_scmi: Unregister device notifier before IDR teardown
firmware: arm_scmi: Publish channel state before callbacks
firmware: arm_scmi: Simplify notification allocations
...
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
In panthor_fw_load_section_entry(), the data size to copy is calculated
without validating it against the allocated section_size:
section->data.size = hdr.data.end - hdr.data.start;
If a crafted firmware sets data.size larger than the allocated memory,
this could cause a heap buffer overflow in panthor_fw_init_section_mem()
memcpy(section->mem->kmap, section->data.buf, section->data.size);
Additionally, if the section->data.size exceeds the BO size, could this
memset underflow the size calculation, leading to a massive out-of-bounds
zeroing of kernel memory?
memset(section->mem->kmap + section->data.size, 0,
panthor_kernel_bo_size(section->mem) - section->data.size);
Reject section entries whose initial data is larger than the section size.
Fixes: 2718d91816 ("drm/panthor: Add the FW logical block")
Cc: stable@vger.kernel.org
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20260716143939.21903-1-osama.abdelkader@gmail.com
Signed-off-by: Steven Price <steven.price@arm.com>
Add the newly created official mailing list for the exfat file system.
This mailing list will be shared and used for both the kernel driver
and the exfatprogs utility project.
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
When a shared writable mapping has its valid_size extended by a buffered
write or a page fault, exfat zeroes the page-cache gap below the new
valid_size. A store through the mapping can race with this zeroing and be
overwritten.
Fix this by zeroing the gap lazily. Drop ->map_pages so that every first
write fault goes through exfat_page_mkwrite(), which advances valid_size to
cover the faulting page. With fault-around enabled, a store could install a
writable PTE, skip ->page_mkwrite(), and land past valid_size without
advancing it. Extending valid_size one faulting page at a time also leaves
never-written pages in a large mapping alone.
The gap is filled with block granularity, zeroing only the not-uptodate
blocks and preserving blocks that may hold data stored through the mapping.
On the buffered-write path the invalidate lock is held and the gap is
unmapped before zeroing, so a racing store re-faults and, under the inode
lock, completes only after the gap has been zeroed and valid_size covers
it.
Fixes: 82a81a7352 ("exfat: add iomap buffered I/O support")
Co-developed-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
Signed-off-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
There are two drivers in the ideapad-laptop module: a wmi_driver and a
platform_driver. The former is registered before the latter, but the
unregistration order is the same as the init one instead of the reverse.
Fix the driver unregistration order by reversing it.
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260723-ideapad-rev-exit-v2-1-9c31159022de@rong.moe
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Sashiko reports a possible information leak that can occur as follows:
1. In parse_package(), memory allocated for data->device_mode_info is not
zerozed initially as it is allocated with devm_kmalloc_array().
2. In the for loop after the allocation, a malformed ACPI package
provided by firmware can cause some fields in data->device_mode_info
to remain uninitialized.
3. Later in update_sar_data(), the uninitialized fields gets copied to
the fields of context->sar_data, which can be exposed to userspace
through sysfs attribute read (intc_data_show()).
Fix the leak by switching to use devm_kcalloc() for allocation.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260710052806.100107-1-nihaal%40cse.iitm.ac.in
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Link: https://patch.msgid.link/20260723-platx86-v4-2-93b4a178b595@cse.iitm.ac.in
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The memory allocated for device_mode_info in parse_package() called by
sar_get_data() is not freed in some of the error paths in sar_probe().
Fix that by converting to use device managed allocations.
Fixes: dcfbd31ef4 ("platform/x86: BIOS SAR driver for Intel M.2 Modem")
Cc: stable@vger.kernel.org
Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Link: https://patch.msgid.link/20260723-platx86-v4-1-93b4a178b595@cse.iitm.ac.in
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Merge the pmdomain fixes for v7.2-rc[n] into the next branch, to allow
them to get tested together with the pmdomain changes that are targeted
for the next release.
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
KVM services local TLB flushes on "full" nested VM-Exits (through
__nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to
failed VMCS checks in nested_vmx_enter_non_root_mode()).
However, it is possible that KVM had queued TLB flushes that need to be
performed, even if the nested VM-Enter was not successful. For example,
if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if
via the MSR load lists, as the SDM says:
If any MSR is being loaded in such a way that would architecturally
require a TLB flush, the TLBs are updated so that, after VM entry, the
logical processor will not use any translations that were cached before
the transition.
The SDM is unclear about when the TLB flush should occur, and whether or
not a failed VM entry would flush the TLB, so it is safer to always
do the TLB flush in this case.
More concretely, KVM also updates the last VPID L1 used for L2 in
nested_vmx_transition_tlb_flush() (i.e. last_vpid), even if the VM entry
ultimately fails. With the current code, KVM could miss a TLB flush if
L1 changes L2's VPID, then does a failed VM entry followed by a
successful one, as the failed VM entry would update last_vpid but not
actually flush the TLB. Servicing local TLB flushes on failed VM entries
makes sure that the TLB is always flushed when last_vpid is updated.
Fixes: 5c614b3583 ("KVM: nVMX: nested VPID emulation")
Cc: stable@vger.kernel.org
Reported-by: Sashiko <sashiko-bot@kernel.org> # Internal review
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Yosry Ahmed <yosry@kernel.org>
Link: https://patch.msgid.link/20260722230128.1587363-1-yosry@kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
When {de,en}crypting memory of an SEV or SEV-ES guest on an SNP-enabled
host via a temporary buffer, allocate a full 4KiB page for the buffer to
ensure the page containing the buffer is wholly owned by KVM, i.e. won't
be concurrently allocated and accessed by other kernel code while KVM is
using the buffer to {de,en}crypt memory. On SNP-enabled platforms, when
sending SEV/SEV-ES commands that trigger firmware writes to memory, the
to-be-written page(s) must be (temporarily) assigned to Firmware (as
required by the SNP architecture, to guard against using such commands as
gadgets to attack SNP guests). See snp_map_cmd_buf_desc() and friends.
Unfortunately, transferring ownership of a page to Firmware makes the page
inaccessible to software, and thus writes generate RMP #PF violations. If
KVM uses a sub-page allocation for its temporary buffer, some other actor
in the kernel can allocate and use the other portions of the page, and thus
trigger unexpected (and seemingly spurious) RMP #PF violations due to
software attempting to access a Firmware-owned page.
BUG: unable to handle page fault for address: ffff906ae30f0300
#PF: supervisor write access in kernel mode
#PF: error_code(0x80000003) - RMP violation
PGD 6b1b80d067 P4D 6b1b80d067 PUD 100231e2063 PMD 10055a88063 PTE 80000100630f0163
SEV-SNP: PFN 0x100630f0 unassigned, dumping non-zero entries in 2M PFN region: [0x10063000 - 0x10063200]
Oops: Oops: 0003 [#1] SMP
CPU: 70 UID: 0 PID: 10658 Comm: svw_WaiterThrea Tainted: G U W O 7.1.0-smp--c22293789940-seanjc-next #1 PREEMPTLAZY
Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE
Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026
RIP: 0010:memset+0xf/0x20
Call Trace:
<TASK>
__kvmalloc_node_noprof+0x2a4/0x710
do_getxattr+0x4e/0x130
path_getxattrat+0x125/0x1b0
do_syscall_64+0x10a/0x480
entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7f3a22cb6daa
</TASK>
Modules linked in: kvm_amd kvm irqbypass vfat fat ccp k10temp sha3 libsha3 i2c_piix4 gq(O) cdc_acm xhci_pci xhci_hcd
gsmi: Log Shutdown Reason 0x03
CR2: ffff906ae30f0300
---[ end trace 0000000000000000 ]---
RIP: 0010:memset+0xf/0x20
Kernel panic - not syncing: Fatal exception
Kernel Offset: 0x39e00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
gsmi: Log Shutdown Reason 0x02
Fixes: 4c735bf1bc ("KVM: SEV: Allocate only as many bytes as needed for temp crypt buffers")
Cc: stable@vger.kernel.org
Cc: Michael Roth <michael.roth@amd.com>
Debugged-by: Michael Roth <michael.roth@amd.com>
Link: https://patch.msgid.link/20260723211306.75397-1-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
devm_drm_dev_alloc() returns an ERR_PTR() on failure, but panthor_probe()
always converts that failure to -ENOMEM. Preserve the actual error code
returned by the DRM core instead.
Fixes: 4bdca11507 ("drm/panthor: Add the driver frontend block")
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Signed-off-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/20260716140337.10679-1-osama.abdelkader@gmail.com
Without a module description modpost emits a build warning:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pmdomain/imx/imx8m-blk-ctrl.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pmdomain/imx/imx8mp-blk-ctrl.o
So add the required string to these two drivers.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
The i2c subsystem currently blocks during adapter deregistration
whenever there are consumers holding a reference.
Switch to using of_get_i2c_adapter_by_node() which also takes a
reference to the adapter module so that an attempt to unload the module
while in use fails gracefully instead of blocking uninterruptibly.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patch.msgid.link/20260717143119.1815106-3-johan@kernel.org
For the PCIE_PHY (also called PEXTP_PHY) type of RTFF hardware,
there is special handling setting CLK_DIS before performing the
NRESTORE sequence for resetting the RTFF and start sequencing
from a clean state.
That special handling, though, poses an issue in case the machine
specific bootchain (bootloader in particular) ends up booting the
kernel with both PCIe MAC and PHY enabled (not just power domains)
as doing so will partially corrupt the PCIe MAC/PHY registers in
an unpredictable manner, producing either an initialization fail
in the PCI-Express drivers, or even a hard lockup!
Resolve this by simply removing the special handling: in this case
the bootchain, or remote processors, setting is getting honored by
the later check for PWR_RTFF_SAVE_FLAG presence in the RTFF ctl
register.
Fixes: 9d02c94342 ("pmdomain: mediatek: Add support for RTFF Hardware in MT8196/MT6991")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
Add support for the power domains found in the MediaTek MT6858 SoC.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nikolai Burov <nikolai.burov@jolla.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
On recent MediaTek SoCs such as MT6858, the kernel is required to use
a secure monitor call (SMC) to enable or disable the modem power domain.
The power domain control register can be read, but firmware prevents it
from being modified directly. Some other parts of the power sequence,
such as setting the ext_buck_iso register, still need to be performed on
the kernel side.
In preparation for modem support, add a flag to enable this new power
sequence for SoCs that need it. Power domains using this flag are not
expected to configure any bus protection registers, since these are
handled internally by the SMC call.
Signed-off-by: Nikolai Burov <nikolai.burov@jolla.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
Merge the immutable branch dt into next, to allow the updated DT bindings
to be tested together with the pmdomain changes that are targeted for the
next release.
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
Add a new compatible and document bindings for the power domain
controller of the MT6858 SoC.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Nikolai Burov <nikolai.burov@jolla.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
The RK3568 NPU rail (vdd_npu) needs to be enabled before the domain is
powered on and disabled after it is powered off. Give DOMAIN_RK3568 a
regulator parameter (like DOMAIN_RK3588 already has) so the NPU domain
can set need_regulator, letting genpd manage the rail wired up as the
domain's domain-supply instead of marking it always-on in DT.
Suggested-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Signed-off-by: Midgy BALON <midgy971@gmail.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
This line was lost when cping from amd-staging-drm-next to drm-fixes.
So add it back.
Cc: stable@vger.kernel.org
Fixes: 8382cd2349 ("drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock")
Reported-by: Lu Yao <yaolu@kylinos.cn>
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260723134450.13838-1-sunpeng.li@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
-----BEGIN PGP SIGNATURE-----
iQFPBAABCAA5FiEEe7vIQRWZI0iWSE3xu+CwddJFiJoFAmpjWAEbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyAAoJELvgsHXSRYia05cH/RmNDT1xgDYobPcl1fDI
3FkFG4n/cARfh1wWFbV/niNi6q63fq9KyHjNPzkANzDM3CpvdIHzUvF9EzTnj+bW
6tsdO2qlNMzdB2xAKpGtRqKIuGb1JeG5OtWc/+sHrt8ASdMdQCuufxVe6cKtNCMl
Xa3JfqNldG4ZSaT+I4OJBkbOVuHtSO/VCX6RTItqXc3NH5CjyMZR+V+3FK/TwvNn
TAo+MFhTI9tDSge4rDrJSD9Pxddi3UIhvlPxEqlOT0tPUp2PJYCeoOMtPVR/c2LW
Cz03EwLZWbDg9qTC6cy/ZZu8/7+84VgrQwkNlLkpnPTPaTJ2s04Lg+FIjDCv/LcG
+Cc=
=MKn/
-----END PGP SIGNATURE-----
Merge tag 'slab-for-7.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab
Pull slab fixes from Vlastimil Babka:
- Prevent unbounded recursion in free path with memory allocation
profiling, which has caused a stack overflow on a Meta production
host due to a 125-deep __free_slab<->kfree recursion (Harry Yoo)
- Fix type-based partitioning confusing sparse which does not know
__builtin_infer_alloc_token() (Marco Elver)
- Fix a potential memory leak in bulk freeing path on NUMA machines
(Shengming Hu)
* tag 'slab-for-7.2-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab:
slab: silence sparse warning with type-based partitioning
mm/slab: prevent unbounded recursion in free path with new kmalloc type
lib/alloc_tag: introduce mem_alloc_profiling_permanently_disabled()
mm/slab: decouple SLAB_NO_SHEAVES from SLAB_NO_OBJ_EXT
mm/slab: fix a memory leak due to bootstrapping sheaves twice
mm/slub: fix lost local objects when bulk remote free batch fills
The vblank on/off callbacks mixed use of amdgpu_irq_get/put() and
amdgpu_dm_crtc_set_vupdate_irq() to enable and disable IRQs.
With get/put, base driver will callback into DC to disable IRQs when
refcount == 0. With set_vupdate_irq(), DC is called directly to disable
IRQs, bypassing base driver's refcount tracking.
During gpu reset, base driver can restore IRQs via
amdgpu_irq_gpu_reset_resume_helper() > amdgpu_irq_update(). So if
get/put() is not used (i.e. refcount == 0), then vupdate_irq will be
disabled.
This is problematic if DRM requests vblank on before amdgpu_irq_update()
is called: drm_vblank_on() > set_vupdate_irq() enables vupdate_irq, but
the refcount is still 0. gpu_reset_resume_helper() > irq_update() then
immediately disables it, thus leading to flip done timeouts.
This is made worse on DCN since VUPDATE_NO_LOCK is the only IRQ enabled.
Prior to 8382cd2349, a combination of GRPH_FLIP and VSTARTUP IRQs were
used, and they used get/put(). This explains why 8382cd2349 exposed
this issue.
Fix by using get/put() instead of set_vupdate_irq(). DCE is unchanged,
since it relies on unbalanced enable/disable calls based on VRR status,
and hence requires direct set_vupdate_irq(). Plus, it also uses
GRPH_FLIP and VLINE IRQs, which are properly tracked by get/put().
Cc: stable@vger.kernel.org
Fixes: 8382cd2349 ("drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock")
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260723180159.52121-1-sunpeng.li@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Here are some fixes for 7.2:
- fix data loss on keyspan_pda throttle
- fix memory corruption with malicious edgeport devices
- fix memory corruption with corrupt io_ti firmware
- fix OOB read with corrupt mxuport firmware
Included are also some new ftdi and modem device ids.
All have been in linux-next with no reported issues.
-----BEGIN PGP SIGNATURE-----
iJEEABYKADkWIQQHbPq+cpGvN/peuzMLxc3C7H1lCAUCamNNlhsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwyLDIACgkQC8XNwux9ZQgZ/gEAgK5keVsvCTAuDjg9cvyu
zBSPRaAEK82JEQNQqvM/8DABAOE+5B4Czqz0sqNefMj88i1MO9hN0+eyp8gkzO8h
mcAN
=pG38
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-7.2-rc4' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
Johan writes:
USB serial fixes for 7.2-rc4
Here are some fixes for 7.2:
- fix data loss on keyspan_pda throttle
- fix memory corruption with malicious edgeport devices
- fix memory corruption with corrupt io_ti firmware
- fix OOB read with corrupt mxuport firmware
Included are also some new ftdi and modem device ids.
All have been in linux-next with no reported issues.
* tag 'usb-serial-7.2-rc4' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
USB: serial: io_edgeport: cap received transmit credits
USB: serial: option: add TDTECH MT5710-CN
USB: serial: io_ti: reject oversized boot-mode firmware
USB: serial: mxuport: validate firmware header size
USB: serial: ftdi_sio: add support for E+H FXA291
USB: serial: keyspan_pda: fix data loss on receive throttling
msm_iommu_probe() adds its devm-managed IOMMU object to
qcom_iommu_devices before adding the IOMMU sysfs device and registering
it with the IOMMU core.
If iommu_device_sysfs_add() fails, probe returns with the object still on
qcom_iommu_devices. The driver core then releases the devm allocation,
leaving a dangling list entry that later list walks may dereference.
If iommu_device_register() fails, the same dangling list entry remains
and the sysfs device is left registered as well.
Unwind the sysfs device and global list entry in reverse setup order on
the corresponding failure paths.
Fixes: 42df43b361 ("iommu/msm: Make use of iommu_device_register interface")
Cc: stable@vger.kernel.org
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Signed-off-by: Weimin Xiong <xiongwm2026@163.com>
Signed-off-by: Will Deacon <will@kernel.org>
The OF translation path appends each unique stream ID from an IOMMU
specifier to the fixed mids array in the per-master object. It currently
has no capacity check before storing at mids[num_mids] and incrementing
num_mids.
Return -ENOSPC when the array is full rather than writing the next ID
beyond it.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Will Deacon <will@kernel.org>
The WCN6855 and WCN7851 combo chips are available in M.2 card variants
that differ by their BT interface: some expose BT over UART while others
expose BT over USB. Both variants use the same PCIe device ID for the
WiFi interface, distinguished only by their sub-system device ID.
The bare PCI_DEVICE() entries match all sub-system IDs, so both UART and
USB variants hit the same table entry and trigger UART serdev creation.
For USB variants this is wrong — there is no UART BT interface on such
a card, and the serdev probe will fail.
Narrow the matches to UART variants only by using PCI_DEVICE_SUB with
their respective sub-system IDs, so USB variants no longer trigger
UART serdev creation.
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
Link: https://patch.msgid.link/20260724-hamoa-m2-sub-id-v2-v3-1-af97de70bbbe@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Convert 2 "/**" comments to use plain C "/*" comment style to avoid
kernel-doc warnings:
Warning: include/uapi/linux/capability.h:114 expecting prototype for
POSIX(). Prototype was for CAP_CHOWN() instead
Warning: include/uapi/linux/capability.h:175 expecting prototype for
Linux(). Prototype was for CAP_SETPCAP() instead
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Serge Hallyn <sergeh@kernel.org>
The Razer Barracuda X 2.4 GHz USB headset dongle (0x1532:0x0552)
reports a minimum volume register value of cval->min = -16800.
In UAC 1/256 dB units, -16800 corresponds to -65.625 dB. However,
stock ALSA misinterprets this raw integer as 1/100 dB units
(-168.00 dB), causing user-space audio servers (PipeWire /
PulseAudio) to map their volume curves against an incorrectly wide
range.
Add an explicit usbmix_dB_map entry overriding Unit 2 to -6562
(-65.62 dB) to accurately report the physical hardware
attenuation bounds.
Signed-off-by: Markus Lindner <lindner.markus@outlook.at>
Link: https://patch.msgid.link/AS8P195MB2142F4EFF83980BD02BA6566E1C12@AS8P195MB2142.EURP195.PROD.OUTLOOK.COM
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add support for querying and switching the graphics MUX mode on HP
systems via WMI. This introduces the 'gpu_mux_mode' sysfs attribute
under the hp-wmi platform device, allowing userspace tools to check
and safely switch between available graphics modes (e.g., UMA, Hybrid,
Discrete).
The hardware capabilities mask is primarily read using the modern
128-byte System Design Data query. However, to ensure backward
compatibility with older models, a fallback mechanism is implemented.
By mirroring the behavior of the Windows Omen Gaming Hub software, if
the modern query fails but the MUX WMI endpoint (0x52) responds
successfully to a read request, the driver defaults to a standard
Hybrid + Discrete support mask (0x06).
Signed-off-by: Kürşat Abaylı <hello@kursatabayli.dev>
Link: https://patch.msgid.link/20260723172734.18361-1-hello@kursatabayli.dev
[ij: add kstrtox.h]
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
ntfs_utf16_to_nls() appends a trailing NUL to the converted output,
but it passes the caller-supplied size directly to the conversion loop.
For the UTF-8 path, utf16s_to_utf8s() can legitimately fill all
buf_len bytes and return buf_len, after which ntfs_utf16_to_nls()
writes the terminator one byte past the end of the destination buffer.
The same contract problem exists for the NLS path when a converted
character consumes the last available byte.
Reserve one byte for the terminator before doing either conversion.
The function continues to return the number of converted bytes,
excluding the NUL terminator.
Assisted-by: Codex:gpt-5.5
Signed-off-by: Kyle Zeng <kylebot@openai.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
attr_wof_frame_info() may reuse a cached offsets folio. In that case the
loop can fill the output offsets without calling attr_load_runs_range()
or ntfs_read_run(), leaving err uninitialized before the common return
path. Initialize err to 0 for the successful cached path.
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
When CONFIG_NTFS3_64BIT_CLUSTER is enabled, sbi->maxbytes_sparse is set
to -1. As a signed loff_t this is -1LL, the most negative value. Any
lseek on a sparse or compressed file passes this as maxsize to
vfs_setpos(), which returns -EINVAL whenever offset > maxsize, and
since -1LL is less than any non-negative offset, every seek fails,
including lseek(fd, 0, SEEK_SET).
The intent of -1 here appears to be "no limit" (matching the spirit of
MAX_LFS_FILESIZE assigned to sbi->maxbytes and sb->s_maxbytes in the
same block), but the signed type makes it the minimum instead of the
maximum.
Fix by assigning MAX_LFS_FILESIZE to sbi->maxbytes_sparse in the
64-bit cluster path, consistent with the other two limits set there.
Observed on a 16 TB NTFS volume with 0xFFFFFEFF total clusters compiled
with CONFIG_NTFS3_64BIT_CLUSTER=y. Sequential reads via dd/cp worked
correctly; any lseek call on sparse files returned EINVAL, preventing
archive managers and other tools from random-accessing files on the
volume. The non-64-bit-cluster path correctly sets maxbytes_sparse to
(1ull << (cluster_bits + 32)) - 1, a large positive value.
Signed-off-by: Senjin <senjin@hatchling.org>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
When $MFT's ATTR_BITMAP attribute is heavily fragmented, its run list
can span multiple MFT extension records (attribute list entries with
vcn > 0). The non-primary segment handler in ntfs_read_mft() only
processed ATTR_DATA extension segments for MFT_REC_MFT, silently
skipping any ATTR_BITMAP segments. This left sbi->mft.bitmap.run
incomplete, causing wnd_init() to fail with -ENOENT when wnd_rescan()
tried to look up a VCN not covered by the truncated run list.
Observed on a 16 TB NTFS volume (0xFFFFFEFF total clusters) whose MFT
bitmap run list was split across 97 extents in extension records.
wnd_rescan() successfully looked up VCNs 0-122 from the runs loaded
from the base record, then failed at VCN 123 (the last cluster of the
bitmap) whose run was only present in an extension record.
Fix by extending the MFT_REC_MFT special case to also handle
ATTR_BITMAP extension segments, storing their runs into
sbi->mft.bitmap.run the same way the primary segment does.
Signed-off-by: Senjin <senjin@hatchling.org>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Hard to say about copy_to_user_iter(), but at least the first splat
looks correct. At the end of fill_name_de(), data layout is:
struct NTFS_DE *e = buf;
...
|<- data_size + sizeof(struct NTFS_DE) ->|<- XXX ->|
buf |-----------------------------------------------------------
|<- ALIGN(data_size, 8) + sizeof(struct NTFS_DE) ->| ;; e->size
If 'buf' was allocated with kmalloc(), XXX remains uninitialized and
passed as such to memcpy() called from hdr_insert_de().
So using kzalloc() for all buffers passed to fill_name_de() looks
the simplest and most safe solution. OTOH if someone would have
said that an overhead of PAGE_SIZE'd memset() is too large, more
fine-granted solution is to memset() XXX only.
Reported-by: syzbot+905d785c4923bea2c1db@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=905d785c4923bea2c1db
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
