Now that the bitwise parameter definitions are gone for PCM
parameters, we don't have to cast with ugly __force prefix.
Simply drop a superfluous cast.
Acked-by: Cezary Rojewski <cezary.rojewski@intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260812060557.80445-13-tiwai@suse.de
Now that the bitwise parameter definitions are gone for PCM
parameters, we don't have to cast with ugly __force prefix.
Simply drop those superfluous casts.
Reviewed-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260812060557.80445-12-tiwai@suse.de
Now that the bitwise parameter definitions are gone for control
parameters, we don't have to cast with ugly __force prefix.
Simply drop those superfluous casts.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260812060557.80445-11-tiwai@suse.de
Now that the bitwise parameter definitions are gone for PCM
parameters, we don't have to cast with ugly __force prefix.
Simply drop a superfluous cast.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260812060557.80445-10-tiwai@suse.de
Now that the bitwise parameter definitions are gone for PCM and
control parameters, we don't have to cast with ugly __force prefix.
Simply drop those superfluous casts.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260812060557.80445-9-tiwai@suse.de
Now that the bitwise parameter definitions are gone for PCM
parameters, we don't have to cast with ugly __force prefix.
Simply drop those superfluous casts.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260812060557.80445-8-tiwai@suse.de
Now that the bitwise parameter definitions are gone for PCM
parameters, we don't have to cast with ugly __force prefix.
Simply drop those superfluous casts
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260812060557.80445-7-tiwai@suse.de
Now that the bitwise parameter definitions are gone for PCM
parameters, we don't have to cast with ugly __force prefix.
Simply drop those superfluous casts.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260812060557.80445-6-tiwai@suse.de
Now that the bitwise parameter definitions are gone for control
parameters, we don't have to cast with ugly __force prefix.
Simply drop those superfluous casts.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260812060557.80445-5-tiwai@suse.de
Avoid macros to define SNDRV_PCM_FMTBIT_* and SNDRV_PCM_SUBFMTBIT_*
contants but use plain bit shifts, instead. This allows bindgen and
other tools aware of those definitions.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260812060557.80445-4-tiwai@suse.de
Now that the bitwise parameter definitions are gone for PCM
parameters, we don't have to cast with ugly __force prefix.
Simply drop those superfluous casts.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260812060557.80445-3-tiwai@suse.de
We've used __bitwise and __force for some integer parameters for
sanity-checks via sparse, with a hope that it'll reduce the misuse or
incorrect assignments. This worked in principle, but OTOH, it's been
quite a PITA, making the code much uglier than its gain, too, because
one had to cast with __force everywhere. Also, Rust-binding would
skip those defines because of __force usage, which will become more
pains in near future.
So let's drop __bitwise and __force prefix usages. In this patch, we
start cleaning up the UAPI headers at first. The former bit-wised
typedefs are still kept for compatibility for now.
As it's only markers for sparse, the changes are absolutely safe, per
se. Only that we'll need to watch out more carefully about the
variable usage for PCM format type, etc.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260812060557.80445-2-tiwai@suse.de
Fix a NULL pointer dereference in 1394 OHCI PCI driver when probe()
returns early with an error, as detected by Syzkaller.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQE66IEYNDXNBPeGKSsLtaWM8LwEwUCan2ycwAKCRCsLtaWM8Lw
ExX4APkBTU8zkvG/Gy7oSsFtLZWmy2BXkWxh88PiLkbs2GG3sgEA/x9Y43ysmoM+
OTLeNES8O/tmGjGrq8tZxfYL+AjCCg0=
=l4pB
-----END PGP SIGNATURE-----
Merge tag 'firewire-fixes-7.2-final' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
Pull firewire fix from Takashi Sakamoto:
"Fix a NULL pointer dereference in 1394 OHCI PCI driver when probe()
returns early with an error, as detected by Syzkaller"
* tag 'firewire-fixes-7.2-final' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: ohci: fix NULL pointer dereference in ar_context_release
- use raw_spinlock_t in gpio-ml-ioh to avoid locking context issues
- fix a race condition in gpio-ml-ioh by sharing the register locks
across channels
- fix a use-after-free bug in unbind path in gpio-sloppy-logic-analyzer
-----BEGIN PGP SIGNATURE-----
iQIyBAABCgAdFiEEkeUTLeW1Rh17omX8BZ0uy/82hMMFAmp9fVYACgkQBZ0uy/82
hMM2bg/4lIfsWQF7GiSs7cgOa/J0DNIo1PZuf2h9cSJYuR10gMBszCVrBrM/qFT0
05MbJGQcaPSW8Zq8QwR+BoaZ20d64iXuipWOkqg53lN5whU28Tm2z2/YFdC/UHAO
niXbIstc4d26mm1hc6AwjGV4p6lgzTR2W+IcbkImUAAUQDJX+YE6iasclL2EViz5
fufRQ2VaF159AD5zeNjMxoYRwGlZGAU+qeXwbYDhkt0CBOhAZ0eUhnyQi8zYcnpN
OsKmqRplq/tm6jdUjGBoHOFWoXnp4QdukvyEHP/M56WfxyYPOcc9ABCMK45MqpvX
b+9eAy0LjQg+38D6geQIP53ZzVKUrbg4NnLItGV8ad6WR9e0t8+xm0c01hKQ9fdw
n5R12KMr2OdYjSjq1MAuBbUSRrwBjwdgZuxcE5fo3w0aLYfaVAX9LoFkpuv8WP/U
hSUuO9cMxLRnb2ckDVCoazI4lBNuBG2E7si3eodPkFfU6UoiAN8+TQFW3O1AeOnz
LDFMnRb3EADMC4LFdnYSUiQRRm0mHnjhLj1BNZ4Rjgd3ZEgfsHv7ez2JNtIyJs5F
r7H4XBMH1cthyaIkdXWPoKPyE2AJiEg9g0KyvNTHqp2+ORDtz7o3m11AsXDAjGZm
y22YVJUPKUwqVzAabOuoJY872fPQ1N9Zkf9aLrGWNL9MvI+bAw==
=Mmpx
-----END PGP SIGNATURE-----
Merge tag 'gpio-fixes-for-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
- use raw_spinlock_t in gpio-ml-ioh to avoid locking context issues
- fix a race condition in gpio-ml-ioh by sharing the register locks
across channels
- fix a use-after-free bug in unbind path in gpio-sloppy-logic-analyzer
* tag 'gpio-fixes-for-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: sloppy-logic-analyzer: fix use-after-free via debugfs trigger on unbind
gpio: ml-ioh: share the register lock across channels
gpio: ml-ioh: use raw_spinlock_t for the register lock
gpiolib: Check gc->get_direction() before calling gpiod_get_direction()
When vfio_ap_mdev_probe_queue() creates the sysfs attribute group,
the queue's driver data has not yet been set. A concurrent read of
the 'status' attribute can therefore call dev_get_drvdata() and
get NULL, which is then passed directly to
vfio_ap_mdev_for_queue() where q->apqn is unconditionally
dereferenced, causing a NULL pointer dereference.
Fix this by acquiring the update locks before calling
sysfs_create_group(). The status_show() function acquires
guests_lock before reading the driver data, so any concurrent
read will block until after dev_set_drvdata() has been called
and the update locks are released.
As a bonus, the APQN no longer needs to be read from the queue
struct after allocation — it can be read directly from apdev
before allocation and stored in a local variable, which is then
assigned to q->apqn once the allocation succeeds.
Fixes: 260f3ea141 ("s390/vfio-ap: move probe and remove callbacks to vfio_ap_ops.c")
Cc: stable@vger.kernel.org
Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
The vfio_ap_mdev_hot_unplug_cfg() function uses the return value of
bitmap_andnot() to determine whether the guest APCB needs to be updated.
However, bitmap_andnot() returns false when the resulting destination
bitmap is empty. This means that if the only adapter, domain or control
domain assigned to an mdev is removed from the host's AP configuration,
the bit is correctly cleared from the shadow APCB, but bitmap_andnot()
returns false because the result is an empty bitmap. Consequently,
do_hotplug remains 0 and vfio_ap_mdev_update_guest_apcb() is never called,
leaving the KVM guest with stale hardware access to the unplugged AP
devices.
Fix this by replacing the bitmap_andnot() return value check with
bitmap_intersects() to determine whether the shadow APCB actually
overlaps with the removal mask. If there is an intersection, call
bitmap_andnot() solely for its side effect of clearing the bits, then
unconditionally set do_hotplug to trigger the guest APCB update.
Fixes: eeb386aeb5 ("s390/vfio-ap: handle config changed and scan complete notification")
Cc: stable@vger.kernel.org
Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
The DECLARE_BITMAP(apm_filtered, AP_DEVICES) macro allocates the bitmap
on the stack without zero-initializing it.
In vfio_ap_mdev_hot_plug_cfg(), the vfio_ap_mdev_filter_matrix() function
is only called to initialize and populate apm_filtered if either
filter_adapters or filter_domains is true. If the hot plug configuration
change only adds control domains (meaning filter_cdoms is true, but
filter_adapters and filter_domains are both false),
vfio_ap_mdev_filter_matrix() is bypassed.
Consequently, apm_filtered is passed to reset_queues_for_apids() with
uninitialized stack garbage. This can cause reset_queues_for_apids() to
interpret arbitrary stack garbage bits as valid APIDs to reset, potentially
performing unintended guest hardware queue resets.
Fix this by zero-initializing the apm_filtered bitmap at the beginning of
vfio_ap_mdev_hot_plug_cfg() using bitmap_zero().
Fixes: eeb386aeb5 ("s390/vfio-ap: handle config changed and scan complete notification")
Cc: stable@vger.kernel.org
Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
The vfio_ap_config_remove function uses the bitmap_andnot function to clear
bits from the matrix_mdev->matrix.adm bitmap (specifies the control domains
assigned to the mdev). This prevents the explicitly unplugged control
domains from being removed the KVM guest. The bitmap_and function is used
instead.
Fixes: eeb386aeb5 ("s390/vfio-ap: handle config changed and scan complete notification")
Cc: stable@vger.kernel.org
Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
In the vfio_ap_mdev_cfg_add function, the apm_add, aqm_add and adm_add
fields of an ap_matrix_mdev object fields are modified while not holding
the matrix_dev->mdevs_lock. This lock must be held while making these
to guard against a race condition with another caller that may be
concurrently modifying these fields or any of the fields in the
matrix_mdev->matrix.
Fixes: eeb386aeb5 ("s390/vfio-ap: handle config changed and scan complete notification")
Cc: stable@vger.kernel.org
Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
In order to traverse or add/remove ap_matrix_mdev objects in the
matrix_dev->mdev_list, the matrix_dev->guests_lock mutex must be held.
There are two functions that access the list without holding the mutex:
vfio_ap_mdev_probe function
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The vfio_ap_mdev_probe function uses the matrix_dev->mdevs_lock
mutex to guard the add of a newly created ap_matrix_mdev object to the
matrix_dev->mdev_list. This mutex does not protect list access; its purpose
is to guard against concurrent access to fields contained in an
ap_matrix_mdev object. This could lead to kernel memory corruption or
use-after-free if another mdev is created or removed concurrently.
The adding of an ap_matrix_mdev object to matrix_dev->mdev_list
is now guarded by the matrix_dev->guests_lock which is the correct
way to protect against concurrent mdev_list access.
Also removed the following two lines of code because the matrix_mdev is
allocated via vfio_alloc_device macro which uses kzalloc, so req_trigger
and cfg_chg_trigger are already zero-initialised when the struct is
allocated before the call to vfio_register_emulated_iommu_dev. This
prevents a window whereby these triggers are set to NULL after
the device is exposed to userspace.
matrix_mdev->req_trigger = NULL;
matrix_mdev->cfg_chg_trigger = NULL;
vfio_ap_mdev_for_queue function
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The status_show function that supports display of the status attribute of
the devices in /sys/bus/ap/devices calls the vfio_ap_mdev_for_queue
function which iterates the matrix_dev->mdev_list to find the object
representing the queue device whose status is to be displayed. In order to
traverse this list, the matrix_dev->guests_lock mutex must be held.
To fix this, the guests_lock mutex is taken prior to taking the
matrix_dev->mdevs_lock mutex in the status_show function. It is taken
there rather than the vfio_ap_mdev_for_queue function - where it is
needed - because it must be taken prior to the mdevs_lock mutex in order to
adhere to the proper locking order and prevent a lockdep splat; also
because the mdevs_lock is needed there to access fields within
the matrix_mdev object in that function.
See the vfio-ap-locking.rst in the linux kernel tree.
Fixes: 2c1ee8983a ("s390/vfio-ap: prepare for dynamic update of guest's APCB on queue probe/remove")
Cc: stable@vger.kernel.org
Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
The ap_driver structure has two fields which are function pointers to
callbacks:
* .on_config_changed: called at the start of the AP bus scan function to
notify the device driver that the host AP
configuration has changed and the associated AP
devices will be added or removed accordingly. This
gives the implementor a chance to evaluate the
configuration changes and respond to them before
the associated devices are added or removed.
* .on_scan_complete: Called at the end of the AP bus scan function to
notify the device driver that the host AP
configuration has changed and the AP devices have
been added or removed accordingly. This gives the
implementor the opportunity to respond to the
changes after the associated devices are added or
removed.
These two callbacks are implemented in the vfio_ap device driver via the
vfio_ap_on_cfg_changed and vfio_ap_on_scan_complete functions respectively.
Within the call stack of these two callback functions the
matrix_mdev->kvm->lock mutex is taken without checking whether
matrix_mdev->kvm is NULL or not. If matrix_mdev->kvm has never been set,
trying to take the lock will trigger a NULL pointer dereference. This patch
adds checks for matrix_mdev->kvm == NULL before taking the
matrix_mdev->kvm->lock mutex.
Note that the matrix_mdev->kvm->lock mutex taken in the
vfio_ap_mdev_hot_plug_config function is moved to the calling function
along with the matrix_dev->mdevs_lock which is needed there to access
the fields of the matrix_mdev. It makes little sense to make the change
the check for matrix_mdev->kvm there before taking the kvm->lock
mutex only to have to move it out via another patch, so it is done in
this patch.
It is important to make note of the following:
1. The matrix_dev->guests_lock is acquired at the start of both callback
functions. This ensures that matrix_mdev will not be removed via the
vfio_ap_mdev_remove function because it too takes matrix_dev_guests_lock
before removing the object; so, matrix_mdev will be available for the
duration of the callback functions.
2. The matrix_dev->mdevs_lock mutex must be taken in order to access
fields within the matrix_mdev structure
3. matrix_mdev->kvm->lock mutex must be taken before the
matrix_dev->mdevs_lock to prevent a lockdep splat.
4: The kvm->lock must be held while plugging the guest's AP configuration
into its SIE state description via the vfio_ap_mdev_update_guest_apcb
function.
5. The vfio_ap_mdev_update_guest_apcb checks matrix_mdev->kvm to verify it
is not NULL before doing the hot plug of the guest's AP configuration.
Fixes: eeb386aeb5 ("s390/vfio-ap: handle config changed and scan complete notification")
Cc: stable@vger.kernel.org
Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
The do_remove flag in vfio_ap_mdev_cfg_remove() is initialised to zero
before the loop that iterates over the list of matrix mdevs, but is
never reset at the start of each iteration. Since do_remove is
OR-accumulated across iterations, a positive result from one mdev
carries over to subsequent mdevs.
The fix is to set the do_remove flag with the first call to bitmap_and;
for example: do_remove = bitmap_an rather than do_remove |= bitmap_and.
Fixes: eeb386aeb5 ("s390/vfio-ap: handle config changed and scan complete notification")
Cc: stable@vger.kernel.org
Signed-off-by: Anthony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
- m68k: Define NR_CPUS to 1.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCan13fAAKCRCKwlD9ZEnx
cIo6AP9d3BCY2IMGKEHyeF/W+KUtQ5Abgmpe3IW+aztsxtsZgwD+MR6iM0TIaTg+
e5zlvNICBmIiKHDo3sD1vSssHB3WaQU=
=VhE7
-----END PGP SIGNATURE-----
Merge tag 'm68k-for-v7.2-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k
Pull m68k fix from Geert Uytterhoeven:
"Define NR_CPUS to 1.
This fixes a long-standing but never critical before oddity on m68k,
that turned into a serious configuration issue after a recent erofs
change"
* tag 'm68k-for-v7.2-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
m68k: Define NR_CPUS to 1
When scale is large enough that scaled_font exceeds the display
dimensions, rows or columns become 0. A columns value of 0 causes
an infinite loop in drm_log_draw_kmsg_record() because the loop
never decrements len.
Check for zero rows/columns in drm_log_setup_modeset() and return
an error, cleaning up the already allocated buffer to avoid a leak.
Fixes: 8a4b913df4 ("drm/log: Add integer scaling support")
Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260729084815.692944-1-oushixiong1025@163.com
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
drm_log_draw_kmsg_record() accesses s[len - 1] to strip the trailing
newline, but len is unsigned int. If len is 0, the subtraction wraps
to UINT_MAX, causing an out-of-bounds read.
Add an early return when len is 0.
Fixes: 25e2c2a3ef ("drm/log: Color the timestamp, to improve readability")
Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260729084520.688087-1-oushixiong1025@163.com
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
The scale module parameter can be set to 0 via kernel command line.
When scale is 0, scaled_font_h and scaled_font_w become 0, causing
a division by zero in the rows/columns calculation.
Since the scale module parameter is read-only (0444 permissions), it
cannot be changed at runtime via sysfs. Clamp it to 1 once in
drm_log_register().
Fixes: 8a4b913df4 ("drm/log: Add integer scaling support")
Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/20260730014440.66323-1-oushixiong1025@163.com
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
This set of fixes is bulked out quite a bit by the inclusion of a lot of
quirks for various x86 platforms, though there are a few driver specific
fixes in here too. Nothing here is terribly critical, we should be fine
waiting for the merge window if it's too much.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmp9tZ0ACgkQJNaLcl1U
h9DXYAf/R1QWsCP/mXjOb7M5A2KNRvOR4uIUDtbQYYRF3jibOEWgcq8eRUH40w/P
wHKuCQVKGLyFv7g3yiGjfMccHn/CAcOtUBMarnjFWL9c465LLwNkydJAcEe3K7Vf
XUNIMEzj7qq4rbCVouWRm3UuPOQXoPwbJxtsDIjKApPD2ml5dmmL7E5e7aC3m4hf
RgVzWn4KUvWvr30EdiCUj/5LleysY+OgEDl8MkDm4ZJb1hcZ2wswkGkx1rILVkjR
2ZsqUl2/HYGhYbMerhsuIfTGN9SSMYgPJ4qAWoPhAmfhZHNCwGYGvMg/1Uo3JjB+
/Wmk4NA0yoW9msrCqmFu9ZNDfAQ54A==
=3J8V
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v7.2-rc7' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.2
This set of fixes is bulked out quite a bit by the inclusion of a lot of
quirks for various x86 platforms, though there are a few driver specific
fixes in here too. Nothing here is terribly critical, we should be fine
waiting for the merge window if it's too much.
vcs1 and vecs1 may also be present on the first media slice, so take
vcs1/vecs1 also into account when determining if the first media slice is
absent.
Bspec: 67103, 77977
Cc: Gustavo Sousa <gustavo.sousa@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260729230645.3052178-2-ashutosh.dixit@intel.com
(cherry picked from commit 1dff677209)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Breno Leitao says:
====================
netconsole: replace target_list_lock by RCU on userdata hot path
I would like to move netconsole to use RCU on the hot path for
a while instead of target_list_lock. My goal is to have no lock on the
tx side at all and eventually drop CON_NBCON_ATOMIC_UNSAFE, if that is
possible [1].
Start removing target_list_lock on certain parts of the code. This patch
transforms the userdata array into a RCU-protected pointer, and uses the
dynamic mutex as the write lock.
Added a selftest, given we didn't have any netconsole selftest for
userdata operations. Feel free to drop it if this is not useful, dear
maintainers.
Link: https://lore.kernel.org/all/20251121-nbcon-v1-0-503d17b2b4af@debian.org/[1]
Signed-off-by: Breno Leitao <leitao@debian.org>
====================
Link: https://patch.msgid.link/20260810-netcons-userdata-rcu-v3-0-f65557f769ce@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The userdata payload is rebuilt and republished on every configfs write,
including while the target is enabled and messages are being sent.
Add netcons_userdata.sh that runs random tests with userdata.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260810-netcons-userdata-rcu-v3-2-f65557f769ce@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
update_userdata() takes target_list_lock to swap nt->userdata and
nt->userdata_length, then frees the old buffer. Since commit
7eab73b186 ("netconsole: convert to NBCON console infrastructure")
that lock is also the console's device_lock, so writing a userdata value
from configfs serialises against the printk core emitting messages.
The buffer is immutable once published, which is what RCU is for. Move
the string and its length into a single netcons_userdata object and
publish it with rcu_replace_pointer(), freeing the old one with
kfree_rcu().
New userdata design:
0) Unify the userdata fields into a struct netcons_userdata
1) update_userdata() no longer needs target_list_lock.
2) writers stay serialised by dynamic_netconsole_mutex.
3) reading userdata needs an RCU read lock.
No functional change intended.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260810-netcons-userdata-rcu-v3-1-f65557f769ce@debian.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
In cases where min frequency was actually greater than BMG_MIN_FREQ,
we were not using the updated min frequency as there was a missing
call to pc_action_query_task_state() between the two settings of
min frequency. Since we know what min_freq was last set, use that
cached value while comparing to BMG_MIN_FREQ to fix this issue.
v2: pc->freq_ready is not set until after pc_adjust_freq_bounds(). Stay
with pc_action_query_task_state() instead.
v3: Update commit message (Stuart)
Fixes: bdde16c9ac ("drm/xe/bmg: Update Wa_14022085890")
Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Reviewed-by: Stuart Summers <stuart.summers@intel.com>
Link: https://patch.msgid.link/20260805234649.2076384-1-vinay.belgaumkar@intel.com
(cherry picked from commit a2c2d2b13a)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
drmm_mutex_init() can fail while registering its managed cleanup action.
On failure, the reset path destroys the mutex, so continuing OA setup
leaves an unusable lock that later paths may acquire.
Return the error from per-GT OA initialization and abort device-wide OA
initialization if the metrics lock cannot be initialized.
Fixes: a9f905ae7b ("drm/xe/oa/uapi: Initialize OA units")
Fixes: cdf02fe1a9 ("drm/xe/oa/uapi: Add/remove OA config perf ops")
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Link: https://patch.msgid.link/20260713083053.321091-1-lilinmao@kylinos.cn
(cherry picked from commit 360b293de2)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
xe_oa_emit_oa_config() releases the sync entries and the syncs array
only on its success path. When it fails before the point of no return
(fence allocation, config buffer allocation or batch submission), it
returns without touching stream->syncs.
The stream open path handles such failures in the caller, but
xe_oa_config_locked() propagates the error without any cleanup, so the
syncs array and the fence references held by the parsed entries are
leaked. The next config ioctl overwrites stream->syncs, making the
memory unreachable for good.
Clean up the parsed syncs when xe_oa_emit_oa_config() fails, matching
the cleanup done by the stream open error path.
Fixes: 9920c8b88c ("drm/xe/oa: Add syncs support to OA config ioctl")
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Link: https://patch.msgid.link/20260731011932.3426219-1-lilinmao@kylinos.cn
(cherry picked from commit 8af97b3da2)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Problem: CTX_TIMESTAMP MMIO reads could be stale if a context
switched out between check and read; LRC stores a sentinel while
a context starts that must not be treated as a real timestamp.
Fix: Check the LRC-stored sentinel before and after the MMIO read;
return the LRC value if the context switched out to avoid TOCTOU.
Note: Keep XE_LRC_CTX_TIMESTAMP_ACTIVE in xe_lrc.h as the
canonical sentinel.
Fixes: d243ef6a39 ("drm/xe/lrc: Refactor xe_lrc_timestamp to simplify logic")
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7956
Assisted-by: GitHub-Copilot:claude-sonnet-5
Signed-off-by: Gajendra Uttamchand <gajendra.uttamchand@intel.com>
Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Acked-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Link: https://patch.msgid.link/20260810071812.213358-4-gajendra.uttamchand@intel.com
(cherry picked from commit a806534474)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Suspend/resume causes the PXP keys to become invalid, but doesn't
actually kill the session. The driver also doesn't explicitly kill and
re-start the session until a new PXP request comes in, which means that
the "zombie" session can potentially stick around if there are no new
requests from userspace. While this is not an issue for PXP, HDCP has a
new behavior starting on PTL where a communication is sent to GSC if a
session is active at suspend time (even if it doesn't have a valid key),
which can lead to delays in the suspend flow if we suspend while the
zombie session is still active.
To avoid this, we can trigger a termination on resume and kill the
zombie session immediately, instead of delaying the termination to the
next PXP request. Due to restrictions in the rpm suspend/resume flow, we
can't call the termination flow from within the resume call itself, so
the pxp irq worker is expanded to cover this scenario.
The existing logic in the worker doesn't work as-is for the new flow,
because the pm_get_if_active will fail if the worker runs before the
pci_resume call has completed (which is possible, since we queue it
from within that call) or after we're started to suspend again.
Given that we always want to run the worker after a resume (differently
from the irq case, where we want to skip if we're suspended), we can
solve this by just taking the PM reference before queueing the worker.
As part of this rework, the pxp->events variable has been moved to atomic,
to avoid having to take xe->irq.lock from non-irq related paths.
Fixes: b1dcec9bd8 ("drm/xe/ptl: Enable PXP for PTL")
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Julia Filipchuk <julia.filipchuk@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Link: https://patch.msgid.link/20260720222757.3876338-2-daniele.ceraolospurio@intel.com
(cherry picked from commit 757bda2b8b)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
The ring buffer and the LRC context image are both mapped WC, so the ring
tail update can become visible to the device before the ring contents it
is meant to publish.
The GuC CT send does contain an xe_device_wmb(), so sending the H2G would
flush the ring contents. The problem is that it comes too late:
xe_lrc_set_ring_tail() publishes the tail before the H2G is sent, and the
device samples the tail from the context image independently of it, either
at context switch-in or while the context is already resident. A submitter
which is interrupted between updating the tail and sending its H2G
therefore leaves the device free to observe the new tail while the ring
contents behind it are not yet visible:
1. Thread A emits a job into the ring, sets the tail to T_A and sends
the H2G, which flushes A's ring contents. The GuC starts scheduling
the context in, but it is not executing yet.
2. Thread B emits a job into ring[T_A..T_B]. Those writes are not yet
visible to the device.
3. Thread B updates the ring tail to T_B. That write targets a
different page and becomes visible first.
4. Thread B is interrupted before it sends its H2G, so the flush which
would have published ring[T_A..T_B] has not happened yet.
5. The context is switched in and samples the ring tail from the
context image, picking up T_B rather than T_A.
6. The GPU executes A's job, advances HEAD to T_A, and continues on to
ring[T_A..T_B], which still holds the previous wrap's contents, so
the CS parses stale commands.
The result is command stream corruption, which typically manifests as a
hang or a spurious pagefault rather than anything that points back at the
submission path.
Kernel jobs are by far the most likely to hit this. Kernel queues such as
the migration queue are shared and can be driven by many threads
concurrently, producing back-to-back submissions on an LRC which is
already executing. User queues are typically tied to a single submitting
thread, so the same interleaving is much harder to produce.
Add an xe_device_wmb() at the end of xe_lrc_write_ring() so that it covers
every ring tail publication site, and so the invariant is local: once
xe_lrc_write_ring() returns, the ring contents are visible to the device.
Fixes: dd08ebf6c3 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8651
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7810
Cc: stable@vger.kernel.org
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Assisted-by: GitHub_Copilot:claude-opus-5
Reviewed-by: Stuart Summers <stuart.summers@intel.com>
Link: https://patch.msgid.link/20260807171716.140475-1-matthew.brost@intel.com
(cherry picked from commit 136360290f)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
On Pre-Xe3p platform, the GAM write the UM queue through DPA using UC.
if GuC reads the queue via GGTT (WB), stale data may be observed
when the cacheline has been polluted by another agent.
To match the GAM's UC writes, configure the GuC mapping as UC as well.
Fixes: 9c57bc0865 ("drm/xe/lnl: Drop force_probe requirement")
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: <stable@vger.kernel.org> # v6.12+
Signed-off-by: Jia Yao <jia.yao@intel.com>
Reviewed by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260804165057.129529-4-jia.yao@intel.com
(cherry picked from commit 9daa302a82)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
On iGPU, the UM queue BO is allocated in system memory. On dGFX, the BO
was previously created in system memory and later reallocated in
xe_guc_realloc_post_hwconfig(). Allocate the UM queue BO directly in
VRAM on dGFX, where it is ultimately required.
Fixes: 9c57bc0865 ("drm/xe/lnl: Drop force_probe requirement")
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: <stable@vger.kernel.org> # v6.12+
Signed-off-by: Jia Yao <jia.yao@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260804165057.129529-3-jia.yao@intel.com
(cherry picked from commit ace076ef0a)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Move the UM queues into a dedicated BO (ads->um_queue_bo) and avoid
CPU memset operations on it, which eliminates the CPU as a potential
cacheline-polluting agent and helps maintain consistency between GAM
writes and GuC reads.
We also need to ensure the base_dpa for the queue is contiguous on hw
where this is used instead of a GGTT address. Another good reason to
split this out to a separate BO.
Fixes: 9c57bc0865 ("drm/xe/lnl: Drop force_probe requirement")
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: <stable@vger.kernel.org> # v6.12+
Signed-off-by: Jia Yao <jia.yao@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260804165057.129529-2-jia.yao@intel.com
(cherry picked from commit 6af05de0dc)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Remove the fallback for VRAM to system memory, I tested it and that
doesn't work at all, only a black screen with pipe fault errors were
observed.
On systems with media GT, extra latency is added when accessing stolen
memory when the GT is in MC6. Since we additionally aren't counting how
much memory is used for stolen and we could in theory fill up the
entire stolen area with DPT's, avoid using stolen and only use the
default memory region.
Using stolen may also result in random system hangs under load.
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7513
Fixes: 775d0adc01 ("drm/xe/fbdev: Limit the usage of stolen for LNL+")
Cc: <stable@vger.kernel.org> # v6.12+
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260630135523.1775379-2-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
(cherry picked from commit a196406a38)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
In cases where min frequency was actually greater than BMG_MIN_FREQ,
we were not using the updated min frequency as there was a missing
call to pc_action_query_task_state() between the two settings of
min frequency. Since we know what min_freq was last set, use that
cached value while comparing to BMG_MIN_FREQ to fix this issue.
v2: pc->freq_ready is not set until after pc_adjust_freq_bounds(). Stay
with pc_action_query_task_state() instead.
v3: Update commit message (Stuart)
Fixes: bdde16c9ac ("drm/xe/bmg: Update Wa_14022085890")
Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Reviewed-by: Stuart Summers <stuart.summers@intel.com>
Link: https://patch.msgid.link/20260805234649.2076384-1-vinay.belgaumkar@intel.com
(cherry picked from commit a2c2d2b13a)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
has_drm_ras flag is meant to facilitate drm_ras feature. Move it to the
correct layer where it belongs.
Fixes: 63dfab5786 ("drm/xe/xe_ras: Add drm_ras feature flag")
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Riana Tauro <riana.tauro@intel.com>
Link: https://patch.msgid.link/20260810124101.105832-1-raag.jadav@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
(cherry picked from commit 9f15135fe2)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Currently, we xe_ras_process_errors() inside xe_ras_init() to handle boot
time errors. But this can potentially result in declaring the device as
wedged quite early in the driver load sequence, which is problematic due to
the lack of registered drm device or required wedged cleanup hooks at this
point.
Call xe_ras_process_errors() only after the prerequisites are available.
Fixes: d9732e498f ("drm/xe/xe_ras: Query errors from system controller on probe")
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
Link: https://patch.msgid.link/20260730110635.925537-1-raag.jadav@intel.com
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
(cherry picked from commit 20bc4883c7)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
During the error handling path of the driver's probe function, a NULL
pointer dereference can occur in ar_context_release().
When pci_probe() fails early (e.g., if pcim_enable_device() or MMIO mapping
fails), the devres cleanup mechanism invokes release_ohci(). This function
unconditionally calls ar_context_release() to clean up the asynchronous
receive contexts. However, if ar_context_init() was not yet called,
ctx->ohci remains NULL (as the fw_ohci structure is zero-initialized by
devres_alloc()).
ar_context_release() immediately dereferences ctx->ohci to get the dev
pointer before checking if the context was actually initialized, leading to
a crash:
Oops: general protection fault, probably for non-canonical address
0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
RIP: 0010:ar_context_release+0x3f/0x380 drivers/firewire/ohci.c:543
Call Trace:
release_ohci+0x3f/0x60 drivers/firewire/ohci.c:3567
release_nodes drivers/base/devres.c:546 [inline]
devres_release_all+0x1a8/0x260 drivers/base/devres.c:576
device_unbind_cleanup drivers/base/dd.c:597 [inline]
really_probe+0x451/0xae0 drivers/base/dd.c:772
To fix this, move the assignment of the dev pointer after the !ctx->buffer
check. If ctx->buffer is NULL, it indicates that the context was never
successfully initialized and there is nothing to release, safely avoiding
the dereference of the uninitialized ctx->ohci pointer.
Fixes: 5716e58aec ("firewire: ohci: release buffer for AR req/resp contexts when managed resource is released")
Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot
Reported-by: syzbot+d30aad27833a559defab@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=d30aad27833a559defab
Link: https://syzkaller.appspot.com/ai_job?id=10a18617-7893-42dd-bf1c-cd49e19e95d9
Signed-off-by: Aleksandr Nogikh <nogikh@google.com>
Link: https://lore.kernel.org/r/90c5db71-dd1f-4d46-b9d3-2f1046cbd5ea@mail.kernel.org
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
The TMP113 temperature sensor part is register compatible with TMP102,
add non-DT I2C device ID. Unlike TMP102 and TMP110, the TMP113 does
have additional unique ID registers, those are currently unused.
Signed-off-by: Marek Vasut <marex@nabladev.com>
Link: https://lore.kernel.org/r/20260813090456.70816-2-marex@nabladev.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
