| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"A couple of fixes here, one very minor Kconfig fix and a fix for a
nasty issue with error reporting in the tps65219 driver"
* tag 'regulator-fix-v7.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: tps65219: fix irq_data.rdev not being assigned
regulator: Kconfig: fix a typo in help
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
- Implement the GPIO .get_direction() callback in the Mediatek driver
to rid dmesg warnings
- Mark the Qualcomm IPQ4019 pins used as GPIO as using the GPIO pin
function, so there is no conflict with orthogonal muxing
- Fix incorrect settings of the "PUPD" (pull-up-pull-down) register
during suspend/resume in the Renesas RZG2L
- Fix the SMT register cache to be per-bank in the Renesas RZG2L
- Fix the QDSS track clock and control pin group names in the Qualcomm
Eliza driver
- Fix a deadlock in the Amlogic driver, caused by playing around in
sysfs
- Fix some GPIO wakeup interrupt handling in Qualcomm QCS615. and a
similar fix for the Qualcomm SM8150
- Allow parsing DTs without explicit function nodes in the Freescale
i.MX1 driver
- Enable the IRQ for the WACF2200 touchscreen using a DMI quirk
* tag 'pinctrl-v7.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl-amd: enable IRQ for WACF2200 touchscreen on Lenovo Yoga 7 14AGP11
pinctrl: imx1: Allow parsing DT without function nodes
pinctrl: qcom: Fix wakeirq map by removing disconnected irqs for sm8150
pinctrl: qcom: Fix GPIO to PDC wake irq map for qcs615
pinctrl: meson: amlogic-a4: fix deadlock issue
pinctrl: qcom: eliza: Fix QDSS trace clock/control pingroup names
pinctrl: renesas: rzg2l: Fix SMT register cache handling
pinctrl: renesas: rzg2l: Fix incorrect PUPD register offset for high pins during suspend/resume
pinctrl: qcom: ipq4019: mark gpio as a GPIO pin function
pinctrl: mediatek: moore: implement gpio_chip::get_direction()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
- propagate the error code from regulator_enable() in resume path in
gpio-pca953x
- take the device lock when calling device_is_bound() in virtual GPIO
drivers
- fix software node leak in remove path in gpio-aggregator
- fix a potential use-after-free in gpio-aggregator
- harden the GPIO character device uAPI: check that line config
attributes are correctly zeroed
* tag 'gpio-fixes-for-v7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: virtuser: lock device when calling device_is_bound()
gpio: aggregator: lock device when calling device_is_bound()
gpio: sim: lock device when calling device_is_bound()
gpio: aggregator: remove the software node when deactivating the aggregator
gpio: aggregator: fix a potential use-after-free
gpio: cdev: check if uAPI v2 config attributes are correctly zeroed
gpio: pca953x: propagate regulator_enable() error from resume
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"As expected, we still continue receiving lots of small fixes.
One major change is about HD-audio pending IRQ handling, but this
would influence only on odd machines or slow VMs. There are a few
other fixes for the core part, but most of them are not-too-serious
UAF fixes, while the rest are mostly device-specific fixes and quirks.
ALSA Core:
- Fix for PCM silencing with bogus iov_iter
- Fixes for past-the-end iterators in timer and seq
- Serialization of UMP output teardown
- Rate-limit ELD parsing errors
HD-audio:
- Fixes for IRQ work handling and SSID matching
- Various Realtek quirks for HP and ASUS laptops, including LED fixes
ASoC:
- Intel: ACPI match table updates for PTL, NVL, and ARL platforms
- Cirrus Logic: Fixes for cs-amp-lib and cs35l56 codecs
- Various platform fixes for AMD, FSL SAI, TI OMAP, and Qualcomm
- DT-binding fix for MediaTek
Others:
- USB ua101: Reject too-short USB descriptors
- Scarlett2: Fix for flash writes
- ASIHPI: Fix for potential OOB access
- AMD SPI: Fix for bus number in ACPI probe
MAINTAINERS:
- Updates for SOF and TI maintainers"
* tag 'sound-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (47 commits)
ASoC: codecs: pcm512x: fix null-ptr dereference in pcm512x_overclock_xxx_put()
ASoC: Intel: soc-acpi-intel-ptl-match: Remove unnecessary cs42l43 match
ASoC: soc-acpi-intel-ptl-match: Make Chrome matches conditional
ASoC: Intel: soc-acpi: Add entry for sof_es8336 in NVL match table.
ASoC: Intel: sof_sdw: Add support for nvlrvp in NVL platform
ASoC: cs-amp-lib: Fix typo in error message: write -> read
ASoC: cs-amp-lib: Fix missing dput() after debugfs_lookup()
ASoC: cs-amp-lib: Fix wrong sizeof() in _cs_amp_set_efi_calibration_data()
ASoC: cs35l56: Fix flushing of IRQ work in cs35l56_sdw_remove()
MAINTAINERS: ASoC: Intel/SOF: Remove Ranjani Sridharan as maintainer
ALSA: seq: Serialize UMP output teardown with event_input
ALSA: scarlett2: Allow flash writes ending at segment boundary
ALSA: hda/realtek: Add LED quirk for HP ProBook 430 G6
ALSA: hda/intel: Make sure to cancel irq-pending work at closing PCM stream
ALSA: hda: Move irq pending work into hda-intel stream
ASoC: soc-utils: Add missing va_end in snd_soc_ret()
ALSA: ua101: Reject too-short USB descriptors
ALSA: hda/realtek: Fix mute and mic-mute LEDs for HP 16 Piston OmniBook X
ALSA: seq: avoid past-the-end iterator in snd_seq_create_port()
ALSA: timer: avoid past-the-end iterator in snd_timer_dev_register()
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull block fixes from Jens Axboe:
- NVMe pull request via Keith:
- Fix memory leak for peer-to-peer addresses
- Fix dma map leaks on resource errors
- Another bio integrity fix, fixing a recent regression
- Fix for an issue with the request pre-allocation and caching when IO
is queued, where if a bio split occurred and ended up blocking, the
list could be corrupted
* tag 'block-7.1-20260522' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
block: avoid use-after-free in disk_free_zone_resources()
blk-mq: pop cached request if it is usable
nvme-pci: fix dma mapping leak on data setup error
nvme-pci: fix dma_vecs leak on p2p memory
bio-integrity-fs: pass data iter to bio_integrity_verify()
|
|
Add debugfs entries to expose hardware configuration and diagnostic
information that aids in debugging driver initialization and runtime
operations without adding noise to dmesg.
The debugfs directory for each PCI device is named using pci_name()
(the unique BDF address), and its creation and removal is integrated
into mana_gd_setup() and mana_gd_cleanup_device() respectively, so
that all callers (probe, remove, suspend, resume, shutdown) share a
single code path.
Device-level entries (under /sys/kernel/debug/mana/<BDF>/):
- num_msix_usable, max_num_queues: Max resources from hardware
- gdma_protocol_ver, pf_cap_flags1: VF version negotiation results
- num_vports, bm_hostmode: Device configuration
Per-vPort entries (under /sys/kernel/debug/mana/<BDF>/vportN/):
- port_handle: Hardware vPort handle
- max_sq, max_rq: Max queues from vPort config
- indir_table_sz: Indirection table size
- steer_rx, steer_rss, steer_update_tab, steer_cqe_coalescing:
Last applied steering configuration parameters
Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260519064621.772154-1-ernis@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When build_skb() fails in tun_xdp_one(), the function sets ret to
-ENOMEM and jumps to the out label, which returns without freeing the
page that vhost_net_build_xdp() allocated for the frame. As with the
short-frame rejection path, tun_sendmsg() discards the per-buffer error
and still returns total_len, so vhost_tx_batch() takes the success path
and never frees the page. Each build_skb() failure in a batch leaks one
page-frag chunk.
Free the page before taking the error path, matching the put_page() the
other error exits of tun_xdp_one() already perform.
Fixes: 043d222f93ab ("tuntap: accept an array of XDP buffs through sendmsg()")
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Reviewed-by: Dongli Zhang <dongli.zhang@oracle.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260521163312.1479805-2-bestswngs@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL,
and returns -ENOMEM when build_skb() fails. Both paths jump to the err
label without freeing the page that vhost_net_build_xdp() allocated for
the frame. tap_sendmsg() discards the per-buffer return value and always
returns 0, so vhost_tx_batch() takes the success path and never frees
the page; each rejected frame in a batch leaks one page-frag chunk.
Free the page on both error paths, before the skb is built. This is the
tap counterpart of the same leak in tun_xdp_one().
Fixes: 0efac27791ee ("tap: accept an array of XDP buffs through sendmsg()")
Fixes: ed7f2afdd0e0 ("tap: add missing verification for short frame")
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Reviewed-by: Dongli Zhang <dongli.zhang@oracle.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260521163230.1478627-2-bestswngs@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The input buffer size is pcu->max_in_size, but pcu->max_out_size is
passed to usb_free_coherent().
Change size to match the allocation size.
Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
Link: https://patch.msgid.link/20260522085412.45430-2-fourier.thomas@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
Adjust white space in thermal_trip_of_attr().
Signed-off-by: Mayur Kumar <kmayur809@gmail.com>
[ rjw: Added changelog, added tabs before backslash ]
Link: https://patch.msgid.link/20260511175246.217788-1-kmayur809@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
The refactoring is going to alter the default behavior of
alloc_workqueue() to be unbound by default.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU. For more details see the Link tag below.
This workqueue has no benefits being per-CPU, so make it unbound adding
WQ_UNBOUND, removing also the WQ_POWER_EFFICIENT flag.
Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
[ rjw: Subject tweak ]
Link: https://patch.msgid.link/20260515084920.70544-1-marco.crivellari@suse.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Improve warning message on HWP-disabled hybrid processors to state that
intel_pstate requires HWP to be enabled on such processors [1].
Previously it warned that "intel_pstate: CPU model not supported", but
it was misleading.
Link: https://docs.kernel.org/admin-guide/pm/intel_pstate.html [1]
Signed-off-by: Yohei Kojima <yohei.kojima@sony.com>
[ rjw: Changelog tweaks ]
Link: https://patch.msgid.link/87f69971a9bf89fb4b51f128e8ae519cbaf5894e.1779406085.git.yohei.kojima@sony.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Since commit 8b793a92d862 ("x86/cpu: Remove M486/M486SX/ELAN support"),
the AMD Elan SC4* is no longer supported, so the CPU frequency driver
is no longer needed.
Signed-off-by: Sean Young <sean@mess.org>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
[ rjw: Changelog tweaks ]
Link: https://patch.msgid.link/20260507090107.10113-1-sean@mess.org
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The Kconfig in the parent directory already has an 'if X86' condition
wrapping the inclusion of this file, meaning that each of the individual
'depends on' statements in this file is a duplicate dependency (dead
code).
Leave the outer 'if X86...endif' and remove the individual 'depends on
X86' statement from each option.
This dead code was found by kconfirm, a static analysis tool for Kconfig.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Changelog edits ]
Link: https://patch.msgid.link/20260417230652.305414-1-julianbraha@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
cs_dbs_update() performs explicit checks against policy->min/max
before updating the target frequency. These checks are redundant as
__cpufreq_driver_target() already clamps the requested frequency to
the valid policy limits.
Remove the unnecessary boundary checks and simplify the update logic.
This also fixes an issue introduced by commit 00bfe05889e9 ("cpufreq:
conservative: Decrease frequency faster for deferred updates"), where
stale target comparisons could cause frequency updates to be skipped
entirely after deferred adjustments.
Closes: https://lore.kernel.org/all/20260421123545.1745998-1-zhenglifeng1@huawei.com/
Fixes: 00bfe05889e9 ("cpufreq: conservative: Decrease frequency faster for deferred updates")
Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com>
Co-developed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Link: https://patch.msgid.link/292e6d937890f135e30ec0d2107eaad47cb9a976.1779423281.git.viresh.kumar@linaro.org
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Drivers setting CPUFREQ_NEED_UPDATE_LIMITS expect target() to be
invoked even if the target frequency remains unchanged, so they can
update their internal policy limits state.
Currently the core invokes target() unconditionally whenever the
requested frequency matches policy->cur for such drivers, even if
policy->min and policy->max haven't changed since the previous update.
Track pending policy limit updates explicitly and skip redundant
target() invocations when neither the target frequency nor the
effective limits changed.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Lifeng Zheng <zhenglifeng1@huawei.com>
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
Link: https://patch.msgid.link/d0107c364b709abca21acf88072220bc05478594.1779423281.git.viresh.kumar@linaro.org
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This patch provides basic support for the K230 clock, which covers
all clocks in K230 SoC.
The clock tree of the K230 SoC consists of a 24MHZ external crystal
oscillator, PLLs and an external pulse input for timerX, and their
derived clocks.
Co-developed-by: Troy Mitchell <TroyMitchell988@gmail.com>
Signed-off-by: Troy Mitchell <TroyMitchell988@gmail.com>
Signed-off-by: Xukai Wang <kingxukai@zohomail.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
|
|
Coccinelle (scripts/coccinelle/api/string_choices.cocci) flags an
opportunity to replace the open-coded ternary expression in the probe
dev_info() call:
k3-ringacc.c:1439:3-32: opportunity for
str_enabled_disabled(ringacc->dma_ring_reset_quirk)
Replace the ternary with str_enabled_disabled() and add the required
include for <linux/string_choices.h>.
Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com>
Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com>
Link: https://patch.msgid.link/20260512170623.3174416-12-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
pktdma_get_regs() returns a void __iomem * but uses ERR_PTR() on the
error path, causing sparse to warn about an address space mismatch.
Replace ERR_PTR() with IOMEM_ERR_PTR() to resolve the warning cleanly.
Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com>
Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com>
Link: https://patch.msgid.link/20260512170623.3174416-11-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
smatch warns:
knav_dma.c:390 of_channel_match_helper() warn: unsigned
'args.args[0]' is never less than zero.
of_phandle_args.args[] is uint32_t, so the 'args.args[0] < 0' check
is always false. of_parse_phandle_with_fixed_args() already handles
errors by returning a non-zero code, which is checked immediately
above. Remove the dead check.
Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com>
Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com>
Link: https://patch.msgid.link/20260512170623.3174416-10-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
DMA_PRIO_MASK (GENMASK(3, 0)) is defined alongside the other priority
macros but is never referenced in the code. tx_priority and rx_priority
are only ever assigned DMA_PRIO_DEFAULT (0) and are never sourced from
device tree or user-controlled input, so no out-of-range value is
possible. W=2 builds report:
knav_dma.c:32:9: warning: macro is not used [-Wunused-macros]
32 | #define DMA_PRIO_MASK GENMASK(3, 0)
Remove the dead macro.
Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com>
Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com>
Link: https://patch.msgid.link/20260512170623.3174416-9-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Fix knav_init_acc_range() use of 'Return ...' instead of 'Return:'
kernel-doc comment, which produces a warning with W=2:
knav_qmss_acc.c:473: No description found for return value of
'knav_init_acc_range'
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com>
Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260512170623.3174416-8-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Fix several address-space and type annotation issues reported by sparse:
- Change pdsp->command from 'void __iomem *' to 'u32 __iomem *' to
match the other union members (acc_command, qos_command); adjust
the offset in knav_queue_load_pdsp() from +0x18 to +0x6 to
preserve the 24-byte offset.
- Fix knav_queue_pdsp_wait() declaration: correct the parameter
annotation from 'u32 * __iomem' (pointer-in-iomem-space) to
'u32 __iomem *' (pointer-to-iomem); use 'unsigned int' for the
timeout parameter instead of bare 'unsigned'; fix the continuation-
line alignment.
- Use IOMEM_ERR_PTR() in knav_queue_map_reg() instead of ERR_PTR()
when returning an error as void __iomem *.
- Annotate the firmware data array as 'const __be32 *' instead of
'u32 *', as be32_to_cpu() requires __be32 input.
Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com>
Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com>
Link: https://patch.msgid.link/20260512170623.3174416-7-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Coccinelle (scripts/coccinelle/misc/ptr_err_to_pe.cocci) flags the
dev_err() call in knav_pool_create():
knav_qmss_queue.c:789:9-16: WARNING: Consider using %pe to print
PTR_ERR()
Replace the %ld / PTR_ERR() pair with %pe and pass the error pointer
directly to also print the symbolic error name.
Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com>
Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com>
Link: https://patch.msgid.link/20260512170623.3174416-6-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Fix functions that use inline 'Returns ...' instead of 'Return:'
kernel-doc comments, producing warnings with W=2:
knav_qmss_queue.c:524: No description found for return value
of 'knav_queue_open'
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com>
Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260512170623.3174416-5-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
knav_dev_lock_held() is a single-use wrapper around
lockdep_is_held(&knav_dev_lock), used only as the lockdep condition
in for_each_handle_rcu. When CONFIG_PROVE_RCU_LIST is disabled,
list_for_each_entry_rcu() elides the condition argument entirely,
causing clang to report the macro as unused with W=2:
knav_qmss_queue.c:30:9: warning: macro is not used [-Wunused-macros]
30 | #define knav_dev_lock_held() \
Remove the intermediate macro and open-code lockdep_is_held() directly
in the for_each_handle_rcu definition.
Reviewed-by: Andrew Davis <afd@ti.com>
Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com>
Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com>
Link: https://patch.msgid.link/20260512170623.3174416-4-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Building with W=2 (clang, LLVM=1) produces 22 -Wshadow warnings in
knav_qmss_queue.c because the file-scoped singleton 'kdev' is shadowed
by a parameter of the same name in 21 internal functions and one local
variable, e.g.:
knav_qmss_queue.c:194:49: warning: declaration shadows a variable
in the global scope [-Wshadow]
194 | knav_queue_match_id_to_inst(struct knav_device *kdev, unsigned id)
Rename the global singleton from kdev to knav_qdev rather than
renaming all ~21 function parameters, as this requires fewer changes
and leaves function signatures, struct field accesses, and header
macros in knav_qmss.h untouched.
Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com>
Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com>
Link: https://patch.msgid.link/20260512170623.3174416-3-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Commit 168d2fb78055 ("soc: ti: knav_qmss: Remove ENOMEM printks")
removed redundant dev_err() calls after allocation failures in
knav_queue_setup_regions, knav_queue_init_qmgrs and
knav_queue_init_pdsps, but missed three further instances in
knav_pool_create, knav_queue_setup_region and knav_setup_queue_range.
Remove the missed instances.
Reviewed-by: Sai Sree Kartheek Adivi <s-adivi@ti.com>
Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com>
Link: https://patch.msgid.link/20260512170623.3174416-2-nm@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
When a CPU goes offline with HWP disabled, intel_pstate_set_min_pstate()
sets the MSR_IA32_PERF_CTL to minimum frequency to prevent SMT siblings
from being restricted. However, the policy->cur value was not updated,
leaving it at the previous value.
When the CPU comes back online, governor->limits() checks if target_freq
equals policy->cur and skips the frequency adjustment if they match. Since
policy->cur still holds the previous value, the governor does not call
cpufreq_driver->target to update MSR_IA32_PERF_CTL.
Fix this by synchronizing policy->cur with the hardware state when setting
minimum pstate during CPU offline.
Fixes: bb18008f8086 ("intel_pstate: Set core to min P state during core offline")
Cc: stable@vger.kernel.org # 3.15+
Suggested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
[ rjw: Subject refinement ]
Link: https://patch.msgid.link/20260520032119.30615-1-fushuai.wang@linux.dev
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
This reverts commit f649e63d4a6423eda8eb208638849fd6396aedd7.
The read-only feature requires further consideration.
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20260521162930.1451042-1-lizhi.hou@amd.com
|
|
The current implementation uses pci_num_vf() while holding the
memory_lock to prevent changing the power state of a PF when
VFs are enabled. This creates a lockdep circular dependency
warning because memory_lock is held during device probing.
[ 286.997167] ======================================================
[ 287.003363] WARNING: possible circular locking dependency detected
[ 287.009562] 7.0.0-dbg-DEV #3 Tainted: G S
[ 287.015074] ------------------------------------------------------
[ 287.021270] vfio_pci_sriov_/18636 is trying to acquire lock:
[ 287.026942] ff45bea2294d4968 (&vdev->memory_lock){+.+.}-{4:4}, at:
vfio_pci_core_runtime_resume+0x1f/0xa0
[ 287.036530]
[ 287.036530] but task is already holding lock:
[ 287.042383] ff45bea3a96b8230 (&new_dev_set->lock){+.+.}-{4:4}, at:
vfio_group_fops_unl_ioctl+0x44d/0x7b0
[ 287.051879]
[ 287.051879] which lock already depends on the new lock.
[ 287.051879]
[ 287.060070]
[ 287.060070] the existing dependency chain (in reverse order) is:
[ 287.067568]
[ 287.067568] -> #2 (&new_dev_set->lock){+.+.}-{4:4}:
[ 287.073941] __mutex_lock+0x92/0xb80
[ 287.078058] vfio_assign_device_set+0x66/0x1b0
[ 287.083042] vfio_pci_core_register_device+0xd1/0x2a0
[ 287.088638] vfio_pci_probe+0xd2/0x100
[ 287.092933] local_pci_probe_callback+0x4d/0xa0
[ 287.098001] process_scheduled_works+0x2ca/0x680
[ 287.103158] worker_thread+0x1e8/0x2f0
[ 287.107452] kthread+0x10c/0x140
[ 287.111230] ret_from_fork+0x18e/0x360
[ 287.115519] ret_from_fork_asm+0x1a/0x30
[ 287.119983]
[ 287.119983] -> #1 ((work_completion)(&arg.work)){+.+.}-{0:0}:
[ 287.127219] __flush_work+0x345/0x490
[ 287.131429] pci_device_probe+0x2e3/0x490
[ 287.135979] really_probe+0x1f9/0x4e0
[ 287.140180] __driver_probe_device+0x77/0x100
[ 287.145079] driver_probe_device+0x1e/0x110
[ 287.149803] __device_attach_driver+0xe3/0x170
[ 287.154789] bus_for_each_drv+0x125/0x150
[ 287.159346] __device_attach+0xca/0x1a0
[ 287.163720] device_initial_probe+0x34/0x50
[ 287.168445] pci_bus_add_device+0x6e/0x90
[ 287.172995] pci_iov_add_virtfn+0x3c9/0x3e0
[ 287.177719] sriov_add_vfs+0x2c/0x60
[ 287.181838] sriov_enable+0x306/0x4a0
[ 287.186038] vfio_pci_core_sriov_configure+0x184/0x220
[ 287.191715] sriov_numvfs_store+0xd9/0x1c0
[ 287.196351] kernfs_fop_write_iter+0x13f/0x1d0
[ 287.201338] vfs_write+0x2be/0x3b0
[ 287.205286] ksys_write+0x73/0x100
[ 287.209233] do_syscall_64+0x14d/0x750
[ 287.213529] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 287.219120]
[ 287.219120] -> #0 (&vdev->memory_lock){+.+.}-{4:4}:
[ 287.225491] __lock_acquire+0x14c6/0x2800
[ 287.230048] lock_acquire+0xd3/0x2f0
[ 287.234168] down_write+0x3a/0xc0
[ 287.238019] vfio_pci_core_runtime_resume+0x1f/0xa0
[ 287.243436] __rpm_callback+0x8c/0x310
[ 287.247730] rpm_resume+0x529/0x6f0
[ 287.251765] __pm_runtime_resume+0x68/0x90
[ 287.256402] vfio_pci_core_enable+0x44/0x310
[ 287.261216] vfio_pci_open_device+0x1c/0x80
[ 287.265947] vfio_df_open+0x10f/0x150
[ 287.270148] vfio_group_fops_unl_ioctl+0x4a4/0x7b0
[ 287.275476] __se_sys_ioctl+0x71/0xc0
[ 287.279679] do_syscall_64+0x14d/0x750
[ 287.283975] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 287.289559]
[ 287.289559] other info that might help us debug this:
[ 287.289559]
[ 287.297582] Chain exists of:
[ 287.297582] &vdev->memory_lock --> (work_completion)(&arg.work)
--> &new_dev_set->lock
[ 287.297582]
[ 287.310023] Possible unsafe locking scenario:
[ 287.310023]
[ 287.315961] CPU0 CPU1
[ 287.320510] ---- ----
[ 287.325059] lock(&new_dev_set->lock);
[ 287.328917]
lock((work_completion)(&arg.work));
[ 287.336153] lock(&new_dev_set->lock);
[ 287.342523] lock(&vdev->memory_lock);
[ 287.346382]
[ 287.346382] *** DEADLOCK ***
[ 287.346382]
[ 287.352315] 2 locks held by vfio_pci_sriov_/18636:
[ 287.357125] #0: ff45bea208ed3e18 (&group->group_lock){+.+.}-{4:4},
at: vfio_group_fops_unl_ioctl+0x3e3/0x7b0
[ 287.367048] #1: ff45bea3a96b8230 (&new_dev_set->lock){+.+.}-{4:4},
at: vfio_group_fops_unl_ioctl+0x44d/0x7b0
[ 287.376976]
[ 287.376976] stack backtrace:
[ 287.381353] CPU: 191 UID: 0 PID: 18636 Comm: vfio_pci_sriov_
Tainted: G S 7.0.0-dbg-DEV #3 PREEMPTLAZY
[ 287.381355] Tainted: [S]=CPU_OUT_OF_SPEC
[ 287.381356] Call Trace:
[ 287.381357] <TASK>
[ 287.381358] dump_stack_lvl+0x54/0x70
[ 287.381361] print_circular_bug+0x2e1/0x300
[ 287.381363] check_noncircular+0xf9/0x120
[ 287.381364] ? __lock_acquire+0x5b4/0x2800
[ 287.381366] __lock_acquire+0x14c6/0x2800
[ 287.381368] ? pci_mmcfg_read+0x4f/0x220
[ 287.381370] ? pci_mmcfg_write+0x57/0x220
[ 287.381371] ? lock_acquire+0xd3/0x2f0
[ 287.381373] ? pci_mmcfg_write+0x57/0x220
[ 287.381374] ? lock_release+0xef/0x360
[ 287.381376] ? vfio_pci_core_runtime_resume+0x1f/0xa0
[ 287.381377] lock_acquire+0xd3/0x2f0
[ 287.381378] ? vfio_pci_core_runtime_resume+0x1f/0xa0
[ 287.381379] ? lock_is_held_type+0x76/0x100
[ 287.381382] down_write+0x3a/0xc0
[ 287.381382] ? vfio_pci_core_runtime_resume+0x1f/0xa0
[ 287.381383] vfio_pci_core_runtime_resume+0x1f/0xa0
[ 287.381384] ? __pfx_pci_pm_runtime_resume+0x10/0x10
[ 287.381385] __rpm_callback+0x8c/0x310
[ 287.381386] ? ktime_get_mono_fast_ns+0x3d/0xb0
[ 287.381389] ? __pfx_pci_pm_runtime_resume+0x10/0x10
[ 287.381390] rpm_resume+0x529/0x6f0
[ 287.381392] ? lock_is_held_type+0x76/0x100
[ 287.381394] __pm_runtime_resume+0x68/0x90
[ 287.381396] vfio_pci_core_enable+0x44/0x310
[ 287.381398] vfio_pci_open_device+0x1c/0x80
[ 287.381399] vfio_df_open+0x10f/0x150
[ 287.381401] vfio_group_fops_unl_ioctl+0x4a4/0x7b0
[ 287.381402] __se_sys_ioctl+0x71/0xc0
[ 287.381404] do_syscall_64+0x14d/0x750
[ 287.381405] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 287.381406] ? trace_irq_disable+0x25/0xd0
[ 287.381409] entry_SYSCALL_64_after_hwframe+0x77/0x7f
Introduce a private flag 'sriov_active' in the vfio_pci_core_device
struct. This allows the driver to track the SR-IOV power state requirement
without relying on pci_num_vf() while holding the memory_lock. The lock is
now only held to set the flag and ensure the device is in D0, after which
pci_enable_sriov() can be called without the lock.
Fixes: f4162eb1e2fc ("vfio/pci: Change the PF power state to D0 before enabling VFs")
Cc: stable@vger.kernel.org
Suggested-by: Jason Gunthorpe <jgg@ziepe.ca>
Suggested-by: Alex Williamson <alex@shazbot.org>
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Link: https://lore.kernel.org/r/20260514173449.3282188-1-rananta@google.com
[promote bitfield to plain bool to avoid storage-unit races]
Signed-off-by: Alex Williamson <alex@shazbot.org>
|
|
tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without
freeing the page that vhost_net_build_xdp() allocated for it.
tun_sendmsg() discards that -EINVAL and still returns total_len, so
vhost_tx_batch() takes the success path and never frees the page; each
short frame in a batch leaks one page-frag chunk.
A local process that can open /dev/net/tun and /dev/vhost-net can hit
this path: it attaches a tun/tap device as the vhost-net backend and
feeds TX descriptors whose length minus the virtio-net header is below
ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a
tight submission loop exhausts host memory and triggers an OOM panic.
Free the page before returning -EINVAL, matching the XDP-program error
path in the same function.
Fixes: 049584807f1d ("tun: add missing verification for short frame")
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Reviewed-by: Dongli Zhang <dongli.zhang@oracle.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260520160020.375349-2-bestswngs@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael Wysocki:
"These fix maximum frequency computation in the intel_pstate driver for
two processor models, update its documentation and fix issues related
to the dynamic EPP support (added during the current development
cycle) in the amd-pstate driver:
- Fix maximum frequency computation in the intel_pstate driver for
Raptor Lake-E and Bartlett Lake that are SMP platforms derived from
hybrid ones (Rafael Wysocki, Henry Tseng)
- Fix the description of asymmetric packing with SMT in the
intel_pstate driver documentation (Ricardo Neri)
- Fix multiple amd-pstate driver issues related to dynamic EPP
support added recently, including making it opt-in only (K Prateek
Nayak, Mario Limonciello)"
* tag 'pm-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq/amd-pstate: Drop Kconfig option for dynamic EPP
cpufreq: intel_pstate: Use HYBRID_SCALING_FACTOR_ADL for Bartlett Lake
cpufreq: intel_pstate: Use correct scaling factor on Raptor Lake-E
Documentation: intel_pstate: Fix description of asymmetric packing with SMT
cpufreq/amd-pstate-ut: Drop policy reference before driver switch
cpufreq/amd-pstate: Use "epp_default_dc" as default when dynamic_epp is disabled
cpufreq/amd-pstate: Reorder notifier unregistration and floor perf reset
cpufreq/amd-pstate: Allow writes to dynamic_epp when state isn't modified
cpufreq/amd-pstate: Return -ENOMEM on failure to allocate profile_name
cpufreq/amd-pstate: Grab "amd_pstate_driver_lock" when toggling dynamic_epp
|
|
Gen9 platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes. Let's expose this as a property to
allow userspace to program a desired value.
This patch is based on earlier work by Chandra Konduru and Matt Roper.
Between 2018 and now, intel/display has changed so much that another
rewrite was necessary.
v2:
- Set initial background color (black) via proper helper function (Bob)
- Fix debugfs output
- General rebasing
v3 (Maarten):
- Rebase on top of recent changes.
v4 (Maarten):
- Complete rewrite based on the solution that went upstream, and
on the new intel color management features.
Cc: Chandra Konduru <chandra.konduru@intel.com>
Cc: dri-devel@lists.freedesktop.org
Co-developed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Link: https://patch.msgid.link/20260505200133.636584-2-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
Make sure that the interrupt-out endpoint max packet size is at least
eight bytes to avoid user-controlled slab corruption or NULL-pointer
dereference should a malicious device report a smaller size.
Fixes: 3416eaa1f8f8 ("USB: cypress_m8: Packet format is separate from characteristic size")
Cc: stable@vger.kernel.org # 2.6.26
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI support fix from Rafael Wysocki:
"Unbreak system wakeup on critical battery status in the ACPI battery
driver inadvertently broken during the 7.0 development cycle"
* tag 'acpi-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: battery: Fix system wakeup on critical battery status
|
|
The code for initializing struct ublksrv_io_desc on I/O dispatch is
largely duplicated in 3 places. Commit 4d4a512a1f87 ("ublk: add PFN-
based buffer matching in I/O path") added support to ublk_setup_iod()
for matching request buffers against registered UBLK_F_SHMEM_ZC buffers,
but missed adding it to ublk_setup_iod_zoned() for zoned requests. Move
the duplicated logic to a new helper ublk_init_iod(). This way, zone
appends can also benefit from avoiding the data copy.
Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Link: https://patch.msgid.link/20260520203654.1413640-3-csander@purestorage.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Move ublk_req_build_flags() above its callers so it doesn't need to be
forward-declared.
Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Link: https://patch.msgid.link/20260520203654.1413640-2-csander@purestorage.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
ublk_rq_has_data() currently uses bio_has_data(), which involves 2
indirections and several branches. Use blk_rq_has_data() instead to save
an indirection and NULL check.
Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Link: https://patch.msgid.link/20260513211846.1956810-3-csander@purestorage.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
The current unwritten grammar for RTP rules is as follows:
rules = disjunction;
disjunction = conjunction, { "OR", conjunction };
conjunction = single_rule, { single_rule };
(* the AND operator is implicit *)
single_rule = ? GRAPHICS_VERSION(...), MEDIA_VERSION(...),
FUNC(...), etc ?
While rule_matches() currently works for the grammar above, it doesn't
easily resemble it. Let's replace it with an implementation that is
structured in a way to resemble the grammar.
Such a new implementation, although a bit more verbose, is arguably
easier to reason about and to adapt to any extension we do to the
grammer in the future.
Also take this opportunity to update the kernel-doc for XE_RTP_RULES()
to include the grammar, so that it is not unwritten anymore.
v2:
- Include the grammar in the code documentation. (Matt)
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-7-0c51039899f4@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
The function rule_matches() short-circuits evaluation of the implicit
conjunctions (each substring of rules not containing OR) and the
explicit disjunctions (implicit conjunctions joined by OR). In other
words:
- in a conjunction, once a rule evaluate to false, we skip to the next
OR (if any) to evaluate the next conjunction;
- in a disjunction, once a conjunction evaluates to true, we return
true and skip evaluating all the remaining rules.
While this behavior results in a correct logical value, due to how the
"OR" short-circuiting is implemented, it has the side-effect that rule
set does not get fully "parsed", allowing incomplete constructs like
(rule1, OR) to evaluate to true when rule1 is true. We should treat
such constructs as invalid and treat them the same way we do for stuff
like (OR, rule1).
As such, update rule_matches() to "parse" the whole rule set, and that
while keeping the short-circuit aspect of evaluation. With that, we can
fix the FIXME test cases that cover that behavior.
v2:
- Do not change short-circuit *evaluation* behavior. (Matt)
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-6-0c51039899f4@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
The current logic in rule_matches() mixes individual rule matching
with the logic necessary for handling OR operations. Let's simplify
rule_matches() to focus on the latter by extracting individual rule
matching into a separate function called rule_match_item().
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-5-0c51039899f4@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
With the current implementation, the RTP framework will cause parsing of
the rule set to be interrupted if one rule requires a context item (gt
or hwe) that is missing (i.e. when the value is NULL).
This is arguably a semantic error instead of a syntactic one, meaning
that RTP should not interrupt parsing the rules. With the current
behavior, we would miss detecting other errors that could appear in the
remaining rules and could also prevent valid rules joined by "OR" from
being evaluated.
Make sure that we do not stop parsing the rule set when detecting
missing context and let's add rtp_rules_test_cases to reflect that.
v2:
- Add "missing-context" in the test case names to indicate that those
are about rules that are missing the necessary context. (Matt)
- Rebase: treat the new match type XE_RTP_MATCH_PLATFORM_STEP in the
same way when the platform is missing step information.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com> # v1
Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-4-0c51039899f4@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
While RTP processing evaluates true on the "yes-or" case (i.e. a
conjunction of rules that evaluate to true followed by an "OR" without
the right hand operand), it does not on the "or-yes" one.
Both cases are considered malformed and could be a result of someone
dropping checks deemed not necessary anymore and forgetting to drop the
superfluous "OR". Nevertheless, we should aim for consistency, and
having the "or-yes" case also evaluating to true while also causing a
warning seems reasonable. So let's do that.
The "or-yes" pattern being evaluated to false comes from the fact that
that we unconditionally short-circuit upon finding XE_RTP_MATCH_OR on
the outer loop. We should only do that if the preceding conjunction of
rules evaluated to true (meaning that rcount must be non-zero) and
continue the evaluation otherwise.
Do that and also add extra test cases to validate the short-circuiting
behavior.
Notice that some of the new test cases have a "FIXME" comment, which
comes from the fact that we are unable to detect syntax errors after the
short-circuit point. That is going to be fixed in a follow-up change.
Link: https://lore.kernel.org/intel-xe/871pfw4lo9.fsf@intel.com/
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-3-0c51039899f4@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
The kunit test cases for the RTP framework are currently separated into
three groups:
(1) rtp_rules_cases:
Those to verify rule matching logic.
(2) rtp_to_sr_cases:
Those to verify generation of save/restore tables from RTP tables.
(3) rtp_cases
Those to verify processing of RTP tables without save/restore action
associated, which are used for OOB workarounds.
Today we have some cases in (2) and (3) that are actually meant to
verify rule matching logic. Now that we have (1), let's cleanup (2)
and (3) so that they become focused on their main objectives.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-2-0c51039899f4@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
The kunit test cases for the RTP framework are currently separated into
those that validate xe_rtp_process_to_sr() and those that validate
xe_rtp_process(). In both of them, we also have mixed stuff to validate
rule matching functionality, which should rather be done in a separate
test case group.
Let's create such a group, specific for validating rule matching, and
also add an initial set of cases. In an upcoming change, we will do a
cleanup of the other groups by migrating those cases intended for rule
matching to this new group.
v2:
- s/no-yes-or-no-yes/no-yes-or-yes-no/ (Matt)
- Drop leftover include of <kunit/test.h>.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260522-rtp-rule-parser-v3-1-0c51039899f4@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
Unlike other drivers, the DPU driver checks for exact UBWC version,
making it hard to add minor versions if necessary. Invert the order of
UBWC checks, letting the DPU driver handle new minors transparently.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/726511/
Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-21-72f2749bc807@oss.qualcomm.com
|
|
Stop using ubwc_dec_version (the version of the UBWC block in the
display subsystem) for detecting the enablement of the UBWC. Use only
ubwc_enc_version, the version of the UBWC which we are setting up for.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/726515/
Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-20-72f2749bc807@oss.qualcomm.com
|
|
Use freshly defined helper instead of checking the UBWC version
directly.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/726525/
Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-19-72f2749bc807@oss.qualcomm.com
|
|
In order to simplify handling of UBWC minor revisions (like 3.1 or 4.3)
use version ranges instead of a case switch.
Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/726506/
Link: https://lore.kernel.org/r/20260520-ubwc-rework-v5-18-72f2749bc807@oss.qualcomm.com
|
